10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
...............^
%COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
data-item

How do you put PQL$ items in to a COBOL "byte"?

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
> ..............^
> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
> data-item
>
> How do you put PQL$ items in to a COBOL "byte"?

I never knew much COBOL and haven't looked at any in decades, but I
would think for a one-byte integer it would be "PIC 9(1)" rather than
"PIC X(1)".

On 6/10/22 1:16 PM, Craig A. Berry wrote:
> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>    10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>> ..............^
>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>> data-item
>>
>> How do you put PQL$ items in to a COBOL "byte"?
>
> I never knew much COBOL and haven't looked at any in decades, but I
> would think for a one-byte integer it would be "PIC 9(1)" rather than
> "PIC X(1)".

And based on an error message telling you to use COMP, perhaps follow
its advice? Something like this:

ENQ-TYPE PIC 9(1) USAGE IS COMP VALUE EXTERNAL PQL$_ENQLM.

just a guess from a non-COBOL person.

On 6/10/22 14:16, Craig A. Berry wrote:
> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>    10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>> ..............^
>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>> data-item
>>
>> How do you put PQL$ items in to a COBOL "byte"?
>
> I never knew much COBOL and haven't looked at any in decades, but I
> would think for a one-byte integer it would be "PIC 9(1)" rather than
> "PIC X(1)".

PIC X(1) would be more likely to be a byte than PIC 9(1) as
PIC 9(1) is one decimal digit and PIC X(1) is one character.

But neither is correct.

bill

On 6/10/22 1:27 PM, Bill Gunshannon wrote:
> On 6/10/22 14:16, Craig A. Berry wrote:
>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>>    10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>>> ..............^
>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>>> data-item
>>>
>>> How do you put PQL$ items in to a COBOL "byte"?
>>
>> I never knew much COBOL and haven't looked at any in decades, but I
>> would think for a one-byte integer it would be "PIC 9(1)" rather than
>> "PIC X(1)".
>
> PIC X(1) would be more likely to be a byte than PIC 9(1) as
> PIC 9(1) is one decimal digit and PIC X(1) is one character.
>
> But neither is correct.

So, since you frequently brag about your COBOL prowess here, why not
give the correct answer?

I did forget that "size" doesn't actually mean size but rather display
digits or something. "PIC 9(9) COMP" is a 4-byte integer, "PIC 9(4)
COMP" is a 2-byte integer. By extension, "PIC 9(3) COMP" *might* be a
1-byte integer, but I couldn't quickly find any documentation on it.

In article <t804ht$a69$1@dont-email.me>, "Craig A. Berry" <craigberry@nospam.mac.com> writes:
>
>On 6/10/22 1:27 PM, Bill Gunshannon wrote:
>> On 6/10/22 14:16, Craig A. Berry wrote:
>>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>>>    10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>>>> ..............^
>>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>>>> data-item
>>>>
>>>> How do you put PQL$ items in to a COBOL "byte"?
>>>
>>> I never knew much COBOL and haven't looked at any in decades, but I
>>> would think for a one-byte integer it would be "PIC 9(1)" rather than
>>> "PIC X(1)".
>>
>> PIC X(1) would be more likely to be a byte than PIC 9(1) as
>> PIC 9(1) is one decimal digit and PIC X(1) is one character.
>>
>> But neither is correct.
>
>So, since you frequently brag about your COBOL prowess here, why not
>give the correct answer?
>
>I did forget that "size" doesn't actually mean size but rather display
>digits or something. "PIC 9(9) COMP" is a 4-byte integer, "PIC 9(4)
>COMP" is a 2-byte integer. By extension, "PIC 9(3) COMP" *might* be a
>1-byte integer, but I couldn't quickly find any documentation on it.

You and Bill know more than I about COBOL. It doesnt even look like code to
me.

The customer said that they got this code many years ago. The problem is that
without defining those quotas, a process can not run a new piece of code. They
don't understand it and call it "SPAWNing" which is how they do most of their
COBOL (COBOL writes .COM, LIB$SPAWN runs it). Fugly.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 6/10/22 15:03, Craig A. Berry wrote:
>
> On 6/10/22 1:27 PM, Bill Gunshannon wrote:
>> On 6/10/22 14:16, Craig A. Berry wrote:
>>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>>>    10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>>>> ..............^
>>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>>>> data-item
>>>>
>>>> How do you put PQL$ items in to a COBOL "byte"?
>>>
>>> I never knew much COBOL and haven't looked at any in decades, but I
>>> would think for a one-byte integer it would be "PIC 9(1)" rather than
>>> "PIC X(1)".
>>
>> PIC X(1) would be more likely to be a byte than PIC 9(1) as
>> PIC 9(1) is one decimal digit and PIC X(1) is one character.
>>
>> But neither is correct.
>
> So, since you frequently brag about your COBOL prowess here, why not
> give the correct answer?

I haven't touched VMS COBOL in 2 decades since they threw both COBOL
and VMS out the door at the University of Scranton. But, in any event
I have no idea what POL$_ENOLM means or what he is trying to do with it.
A rough guess would be rather than declaring it external he needs to
use some VMS Specific function to grab the value and load it into
ENO-TYPE.

>
> I did forget that "size" doesn't actually mean size but rather display
> digits or something.  "PIC 9(9) COMP" is a 4-byte integer, "PIC 9(4)
> COMP" is a 2-byte integer.  By extension, "PIC 9(3) COMP" *might* be a
> 1-byte integer, but I couldn't quickly find any documentation on it.

Possible. I no longer have my Grey Wall or I wold look it up. :-)

bill

On 6/10/22 15:22, VAXman-@SendSpamHere.ORG wrote:
> In article <t804ht$a69$1@dont-email.me>, "Craig A. Berry" <craigberry@nospam.mac.com> writes:
>>
>> On 6/10/22 1:27 PM, Bill Gunshannon wrote:
>>> On 6/10/22 14:16, Craig A. Berry wrote:
>>>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>>>>    10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>>>>> ..............^
>>>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>>>>> data-item
>>>>>
>>>>> How do you put PQL$ items in to a COBOL "byte"?
>>>>
>>>> I never knew much COBOL and haven't looked at any in decades, but I
>>>> would think for a one-byte integer it would be "PIC 9(1)" rather than
>>>> "PIC X(1)".
>>>
>>> PIC X(1) would be more likely to be a byte than PIC 9(1) as
>>> PIC 9(1) is one decimal digit and PIC X(1) is one character.
>>>
>>> But neither is correct.
>>
>> So, since you frequently brag about your COBOL prowess here, why not
>> give the correct answer?
>>
>> I did forget that "size" doesn't actually mean size but rather display
>> digits or something. "PIC 9(9) COMP" is a 4-byte integer, "PIC 9(4)
>> COMP" is a 2-byte integer. By extension, "PIC 9(3) COMP" *might* be a
>> 1-byte integer, but I couldn't quickly find any documentation on it.
>
> You and Bill know more than I about COBOL. It doesnt even look like code to
> me.
>
> The customer said that they got this code many years ago. The problem is that
> without defining those quotas, a process can not run a new piece of code. They
> don't understand it and call it "SPAWNing" which is how they do most of their
> COBOL (COBOL writes .COM, LIB$SPAWN runs it). Fugly.
>

To each his own. I think PHP and Python are ugly. :-)

I don't suppose the program has any documentation. :-)

bill

On Friday, June 10, 2022 at 4:00:11 PM UTC-4, Bill Gunshannon wrote:
> On 6/10/22 15:22, VAX...@SendSpamHere.ORG wrote:
> > In article <t804ht$a69$1...@dont-email.me>, "Craig A. Berry" <craig...@nospam.mac.com> writes:
> >>
> >> On 6/10/22 1:27 PM, Bill Gunshannon wrote:
> >>> On 6/10/22 14:16, Craig A. Berry wrote:
> >>>> On 6/10/22 12:39 PM, VAX...@SendSpamHere.ORG wrote:
> >>>>> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
> >>>>> ..............^
> >>>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
> >>>>> data-item
> >>>>>
> >>>>> How do you put PQL$ items in to a COBOL "byte"?
> >>>>
> >>>> I never knew much COBOL and haven't looked at any in decades, but I
> >>>> would think for a one-byte integer it would be "PIC 9(1)" rather than
> >>>> "PIC X(1)".
> >>>
> >>> PIC X(1) would be more likely to be a byte than PIC 9(1) as
> >>> PIC 9(1) is one decimal digit and PIC X(1) is one character.
> >>>
> >>> But neither is correct.
> >>
> >> So, since you frequently brag about your COBOL prowess here, why not
> >> give the correct answer?
> >>
> >> I did forget that "size" doesn't actually mean size but rather display
> >> digits or something. "PIC 9(9) COMP" is a 4-byte integer, "PIC 9(4)
> >> COMP" is a 2-byte integer. By extension, "PIC 9(3) COMP" *might* be a
> >> 1-byte integer, but I couldn't quickly find any documentation on it.
> >
> > You and Bill know more than I about COBOL. It doesnt even look like code to
> > me.
> >
> > The customer said that they got this code many years ago. The problem is that
> > without defining those quotas, a process can not run a new piece of code. They
> > don't understand it and call it "SPAWNing" which is how they do most of their
> > COBOL (COBOL writes .COM, LIB$SPAWN runs it). Fugly.
> >
> To each his own. I think PHP and Python are ugly. :-)
>
> I don't suppose the program has any documentation. :-)
>
> bill

A quick look in my "Programming VAX-11 Cobol" student workbook shows:

PIC 9(5) COMP is a word
PIC 9(9) COMP is a longword

Knowing what system service is being called that requires the PQL$_ENQLM would help to provide the correct Cobol line.

Dan

Yes, I do know about things other than PDP-10s...

VAXman- @SendSpamHere.ORG writes:

> In article <t804ht$a69$1@dont-email.me>, "Craig A. Berry"
> <craigberry@nospam.mac.com> writes:

>> On 6/10/22 1:27 PM, Bill Gunshannon wrote:

>>> On 6/10/22 14:16, Craig A. Berry wrote:

>>>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:

>>>>>    10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>>>>> ..............^
>>>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>>>>> data-item

>>>>> How do you put PQL$ items in to a COBOL "byte"?

>>>> I never knew much COBOL and haven't looked at any in decades, but I would
>>>> think for a one-byte integer it would be "PIC 9(1)" rather than "PIC
>>>> X(1)".

>>> PIC X(1) would be more likely to be a byte than PIC 9(1) as
>>> PIC 9(1) is one decimal digit and PIC X(1) is one character.

>>> But neither is correct.

>> So, since you frequently brag about your COBOL prowess here, why not
>> give the correct answer?

>> I did forget that "size" doesn't actually mean size but rather display
>> digits or something. "PIC 9(9) COMP" is a 4-byte integer, "PIC 9(4)
>> COMP" is a 2-byte integer. By extension, "PIC 9(3) COMP" *might* be a
>> 1-byte integer, but I couldn't quickly find any documentation on it.

> You and Bill know more than I about COBOL. It doesnt even look like code to
> me.

> The customer said that they got this code many years ago. The problem is
> that without defining those quotas, a process can not run a new piece of
> code. They don't understand it and call it "SPAWNing" which is how they do
> most of their COBOL (COBOL writes .COM, LIB$SPAWN runs it). Fugly.

https://support.hpe.com/hpesc/public/docDisplay?docId=c04621339&docLocale=en_US

See page 5-99 and pages 5-138 to 5-149 of the HPE COBOL Reference Manual. The
appropriate incantation would appear to be

10 ENQ-TYPE PIC X USAGE IS COMP-5 VALUE EXTERNAL PQL$_ENQLM.
^^^^^^^^^^^^^^^

Possibly use COMP-X instead of COMP-5. Note that these USAGEs are only
available on Alpha or Itanium processors.

Also note that "X(1)" is redundant; "X" is a single byte specification.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On 6/10/22 3:05 PM, abrsvc wrote:

> Knowing what system service is being called that requires the PQL$_ENQLM would help to provide the correct Cobol line.

Um, $CREPRC is in the subject line. And PQL$_ENQLM only makes sense for
the quota parameter:

https://wiki.vmssoftware.com/$CREPRC

On 6/10/22 2:57 PM, Bill Gunshannon wrote:
> On 6/10/22 15:03, Craig A. Berry wrote:
>>
>> On 6/10/22 1:27 PM, Bill Gunshannon wrote:
>>> On 6/10/22 14:16, Craig A. Berry wrote:
>>>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>>>>    10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>>>>> ..............^
>>>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>>>>> data-item
>>>>>
>>>>> How do you put PQL$ items in to a COBOL "byte"?

> I have no idea what POL$_ENOLM means or what he is trying to do with it.
> A rough guess would be rather than declaring it external he needs to
> use some VMS Specific function to grab the value and load it into
> ENO-TYPE.

If SDL produces COBOL text libraries and there is a way to include them
(some variant of COPY?) then yes, he might be able to do the equivalent
of "#include <pqldef.h>" and not need the external declaration. But the
external declaration is an ancient hack that at one time was more
reliable than depending on the existence of programmer-friendly
definitions, and also, if you were willing to link at installation time,
could insulate against version-specific changes to the symbol value.

On 6/10/22 16:34, Craig A. Berry wrote:
>
> On 6/10/22 2:57 PM, Bill Gunshannon wrote:
>> On 6/10/22 15:03, Craig A. Berry wrote:
>>>
>>> On 6/10/22 1:27 PM, Bill Gunshannon wrote:
>>>> On 6/10/22 14:16, Craig A. Berry wrote:
>>>>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>>>>>    10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>>>>>> ..............^
>>>>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on
>>>>>> COMP
>>>>>> data-item
>>>>>>
>>>>>> How do you put PQL$ items in to a COBOL "byte"?
>
>> I have no idea what POL$_ENOLM means or what he is trying to do with it.
>> A rough guess would be rather than declaring it external he needs to
>> use some VMS Specific function to grab the value and load it into
>> ENO-TYPE.
>
> If SDL produces COBOL text libraries and there is a way to include them
> (some variant of COPY?) then yes, he might be able to do the equivalent
> of "#include <pqldef.h>" and not need the external declaration.  But the
> external declaration is an ancient hack that at one time was more
> reliable than depending on the existence of programmer-friendly
> definitions, and also, if you were willing to link at installation time,
> could insulate against version-specific changes to the symbol value.

COBOL does have the equivalent of #include but that wasn't what I was
thinking of. It looked to me based on the one line of code!) like he
was trying to get some value from the VMS environment and assign it to
ENO-TYPE. I thought there might be a pre-defined, VMS specific function
to get that value making it possible to to do something like:

10 ENO-TYPE PIC 999.

.......

MOVE FUNCTION VMS$GET_VALUE(POL$ENQLM) TO ENO-TYPE.

But, obviously, there is a VMS specific method for doing it rather than
a COBOL way of doing it. :-)

bill

On 6/10/2022 1:39 PM, VAXman-@SendSpamHere.ORG wrote:
> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
> ..............^
> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
> data-item
>
> How do you put PQL$ items in to a COBOL "byte"?

Disclaimer: I don't do Cobol.

As I read the fine manual then VMS Cobol only have
16, 32 and 64 bit binary integers.

So one has to cheat.

Here is my suggestion for cheating:

$ type pack.cob
identification division.
program-id.pack.
* data division.
working-storage section.
01 packrec.
03 b1 pic x.
03 lw1 pic s9(9) comp.
03 b2 pic x.
03 lw2 pic s9(9) comp.
* procedure division.
main-paragraph.
move function char(11 + 1) to b1
move 22 to lw1
move function char (33 + 1) to b2
move 44 to lw2
call "dump" using
by reference packrec
by value 10
end-call
stop run.
$ type packsup.c
#include <stdio.h>

void dump(char *b, int len)
{ int i;
for(i = 0; i < len; i++)
{
printf(" %d", b[i]);
}
printf("\n");
}

$ cob pack
$ cc packsup
$ link pack + packsup
$ run pack
11 22 0 0 0 33 44 0 0 0

The code should be pretty self explanatory.

And you will of course need to move from one variable
with external to the single byte text variable.

Arne

On 6/10/2022 3:57 PM, Bill Gunshannon wrote:
> On 6/10/22 15:03, Craig A. Berry wrote:
>>
>> On 6/10/22 1:27 PM, Bill Gunshannon wrote:
>>> On 6/10/22 14:16, Craig A. Berry wrote:
>>>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>>>>    10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>>>>> ..............^
>>>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>>>>> data-item
>>>>>
>>>>> How do you put PQL$ items in to a COBOL "byte"?
>>>>
>>>> I never knew much COBOL and haven't looked at any in decades, but I
>>>> would think for a one-byte integer it would be "PIC 9(1)" rather than
>>>> "PIC X(1)".
>>>
>>> PIC X(1) would be more likely to be a byte than PIC 9(1) as
>>> PIC 9(1) is one decimal digit and PIC X(1) is one character.
>>>
>>> But neither is correct.
>>
>> So, since you frequently brag about your COBOL prowess here, why not
>> give the correct answer?
>
> I haven't touched VMS COBOL in 2 decades since they threw both COBOL
> and VMS out the door at the University of Scranton.  But, in any event
> I have no idea what POL$_ENOLM means or what he is trying to do with it.
> A rough guess would be rather than declaring it external he needs to
> use some VMS Specific function to grab the value and load it into
> ENO-TYPE.

PQL$_ENQLM is a VMS constant.

The external keyword tells the program to get the value
from the linker.

Demo:

$ type ext.cob
identification division.
program-id.ext.
* data division.
working-storage section.
01 magic pic s9(9) comp value external extval.
01 showit pic 9(9) display.
* procedure division.
main-paragraph.
move magic to showit
display showit
stop run.
$ type extsup.c
globalvalue int extval = 123;
$ cob ext
$ cc extsup
$ link ext + extsup
$ run ext
000000123

Arne

On 11/06/2022 1:39 am, VAXman-@SendSpamHere.ORG wrote:
> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
> ..............^
> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
> data-item
>
> How do you put PQL$ items in to a COBOL "byte"?
>

Unfortunately COBOL has never supported by integers but there are
several ways to do it. (I haven't fired up my VMS machines in 5 years
otherwise I'd give you an example. Back in the day when google groups
could search the archives you could find one of several $creprc examples
with all parameters including TCB)

Cumbersome: -

01 enqlm_word pic 9(4) comp value external pql$_enqlm.
01 enqlm_byte redefines enqlm_word.
03 pql_enqlm pic x.

move pql_enqlm to somewhere.

Lose external symbols and hard code: -

Hexadecimal literals:

10 ENQ-TYPE PIC X(1) VALUE x"00".

Special Names:

SPECIAL-NAMES.
PQL$_ENQLM value is 44. (I don't know the value)

10 ENQ-TYPE PIC X(1) VALUE PQL$_ENQLM.

The way I do it: -

Define a global .PSECT in the same .MAR file that you already probably
do for $pqldef GLOBAL

Just lay it out as you would for macro.

..psect fred long, gbl,shr,wrt,blah

..byte pql$_enqlm

Then declare an EXTERNAL variable as the same name as your global psect.

01 fred external.
03 pql$_enqlm pic x. (doesn't have to be same name)
03 pic x.

* The last byte is NECESSARY to round up the psect size on Alpha, and
* Itanium. Macro does this automatically.

Again many examples in cov over the years

On Friday, June 10, 2022 at 9:05:25 PM UTC-4, Richard Maher wrote:
> On 11/06/2022 1:39 am, VAX...@SendSpamHere.ORG wrote:
> > 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
> > ..............^
> > %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
> > data-item
> >
> > How do you put PQL$ items in to a COBOL "byte"?
> >
> Unfortunately COBOL has never supported by integers but there are
> several ways to do it. (I haven't fired up my VMS machines in 5 years
> otherwise I'd give you an example. Back in the day when google groups
> could search the archives you could find one of several $creprc examples
> with all parameters including TCB)
>
> Cumbersome: -
>
> 01 enqlm_word pic 9(4) comp value external pql$_enqlm.
> 01 enqlm_byte redefines enqlm_word.
> 03 pql_enqlm pic x.
>
> move pql_enqlm to somewhere.
>
> Lose external symbols and hard code: -
>
> Hexadecimal literals:
>
> 10 ENQ-TYPE PIC X(1) VALUE x"00".
>
> Special Names:
>
> SPECIAL-NAMES.
> PQL$_ENQLM value is 44. (I don't know the value)
>
> 10 ENQ-TYPE PIC X(1) VALUE PQL$_ENQLM.
>
> The way I do it: -
>
> Define a global .PSECT in the same .MAR file that you already probably
> do for $pqldef GLOBAL
>
> Just lay it out as you would for macro.
>
> .psect fred long, gbl,shr,wrt,blah
>
> .byte pql$_enqlm
>
> Then declare an EXTERNAL variable as the same name as your global psect.
>
> 01 fred external.
> 03 pql$_enqlm pic x. (doesn't have to be same name)
> 03 pic x.
>
> * The last byte is NECESSARY to round up the psect size on Alpha, and
> * Itanium. Macro does this automatically.
>
> Again many examples in cov over the years

The other issue here is that this one value is part (or all) of the itemlist that is for the quota parameter.of CREPRC.
The entire list structure must be built, not just this one value.

On 11/06/2022 10:04 am, abrsvc wrote:
> On Friday, June 10, 2022 at 9:05:25 PM UTC-4, Richard Maher wrote:
>> On 11/06/2022 1:39 am, VAX...@SendSpamHere.ORG wrote:
>>> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM. ..............^
>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on
>>> COMP data-item
>>>
>>> How do you put PQL$ items in to a COBOL "byte"?
>>>
>> Unfortunately COBOL has never supported by integers but there are
>> several ways to do it. (I haven't fired up my VMS machines in 5
>> years otherwise I'd give you an example. Back in the day when
>> google groups could search the archives you could find one of
>> several $creprc examples with all parameters including TCB)
>>
>> Cumbersome: -
>>
>> 01 enqlm_word pic 9(4) comp value external pql$_enqlm. 01
>> enqlm_byte redefines enqlm_word. 03 pql_enqlm pic x.
>>
>> move pql_enqlm to somewhere.
>>
>> Lose external symbols and hard code: -
>>
>> Hexadecimal literals:
>>
>> 10 ENQ-TYPE PIC X(1) VALUE x"00".
>>
>> Special Names:
>>
>> SPECIAL-NAMES. PQL$_ENQLM value is 44. (I don't know the value)
>>
>> 10 ENQ-TYPE PIC X(1) VALUE PQL$_ENQLM.
>>
>> The way I do it: -
>>
>> Define a global .PSECT in the same .MAR file that you already
>> probably do for $pqldef GLOBAL
>>
>> Just lay it out as you would for macro.
>>
>> .psect fred long, gbl,shr,wrt,blah
>>
>> .byte pql$_enqlm
>>
>> Then declare an EXTERNAL variable as the same name as your global
>> psect.
>>
>> 01 fred external. 03 pql$_enqlm pic x. (doesn't have to be same
>> name) 03 pic x.
>>
>> * The last byte is NECESSARY to round up the psect size on Alpha,
>> and * Itanium. Macro does this automatically.
>>
>> Again many examples in cov over the years
>
> The other issue here is that this one value is part (or all) of the
> itemlist that is for the quota parameter.of CREPRC. The entire list
> structure must be built, not just this one value.

I understand but each solution offered scales.

IMHO the best solution is to build everything in a macro PSECT(s) and
just match its length and attributes and your COBOL and MACRO get to
initialize of modify the same area of memory as they see fit.

Being able to OR flags together is also next to useless in COBOL with
having to use mth$jior or math$or (I can't remember)

COBOL's PSECT attributes for all EXTERNAL declarations can be found at
the end of the .LIS file.

On 11/06/2022 9:05 am, Richard Maher wrote:
> On 11/06/2022 1:39 am, VAXman-@SendSpamHere.ORG wrote:
>>    10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>> ..............^
>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>> data-item
>>
>> How do you put PQL$ items in to a COBOL "byte"?
>>
>
> Unfortunately COBOL has never supported by integers but there are
> several ways to do it. (I haven't fired up my VMS machines in 5 years
> otherwise I'd give you an example. Back in the day when google groups
> could search the archives you could find one of several $creprc examples
> with all parameters including TCB)
>
> Cumbersome: -
>
> 01 enqlm_word pic 9(4) comp value external pql$_enqlm.
> 01 enqlm_byte redefines enqlm_word.
>    03  pql_enqlm pic x.
>
> move pql_enqlm to somewhere.
>
> Lose external symbols and hard code: -
>
> Hexadecimal literals:
>
> 10  ENQ-TYPE      PIC X(1)  VALUE x"00".
>
> Special Names:
>
> SPECIAL-NAMES.
>     PQL$_ENQLM value is 44. (I don't know the value)
>
> 10  ENQ-TYPE      PIC X(1)  VALUE PQL$_ENQLM.
>
> The way I do it: -
>
> Define a global .PSECT in the same .MAR file that you already probably
> do for $pqldef GLOBAL
>
> Just lay it out as you would for macro.
>
> .psect fred long, gbl,shr,wrt,blah
>
> .byte pql$_enqlm
>
> Then declare an EXTERNAL variable as the same name as your global psect.
>
> 01 fred external.
>    03 pql$_enqlm pic x. (doesn't have to be same name)
>    03 pic x.
>
> * The last byte is NECESSARY to round up the psect size on Alpha, and
> * Itanium. Macro does this automatically.
>
> Again many examples in cov over the years

Below is an entry response. Need to find whole conversation or
view-as-tree: -

https://groups.google.com/g/comp.os.vms/c/xJptlKOregU/m/y0s3fbcoqtQJ

https://groups.google.com/g/comp.os.vms/c/xJptlKOregU/m/y0s3fbcoqtQ

https://groups.google.com/g/comp.os.vms/c/TAmi6i8fMo0/m/1f1JnjqS8RsJ

In article <t80pog$hnn$1@gioia.aioe.org>, Richard Maher <maher_rjSPAMLESS@hotmail.com> writes:
>On 11/06/2022 1:39 am, VAXman-@SendSpamHere.ORG wrote:
>> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
>> ..............^
>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>> data-item
>>
>> How do you put PQL$ items in to a COBOL "byte"?
>>
>
>Unfortunately COBOL has never supported by integers but there are
>several ways to do it. (I haven't fired up my VMS machines in 5 years
>otherwise I'd give you an example. Back in the day when google groups
>could search the archives you could find one of several $creprc examples
>with all parameters including TCB)
>
>Cumbersome: -
>
>01 enqlm_word pic 9(4) comp value external pql$_enqlm.
>01 enqlm_byte redefines enqlm_word.
> 03 pql_enqlm pic x.
>
>move pql_enqlm to somewhere.
>
>Lose external symbols and hard code: -
>
>Hexadecimal literals:
>
>10 ENQ-TYPE PIC X(1) VALUE x"00".
>
>Special Names:
>
>SPECIAL-NAMES.
> PQL$_ENQLM value is 44. (I don't know the value)
>
>10 ENQ-TYPE PIC X(1) VALUE PQL$_ENQLM.
>
>The way I do it: -
>
>Define a global .PSECT in the same .MAR file that you already probably
>do for $pqldef GLOBAL
>
>Just lay it out as you would for macro.
>
>..psect fred long, gbl,shr,wrt,blah
>
>..byte pql$_enqlm
>
>Then declare an EXTERNAL variable as the same name as your global psect.
>
>01 fred external.
> 03 pql$_enqlm pic x. (doesn't have to be same name)
> 03 pic x.
>
>* The last byte is NECESSARY to round up the psect size on Alpha, and
>* Itanium. Macro does this automatically.
>
>Again many examples in cov over the years

Thanks Richard. I found a program on the customer's system that was written
decades ago to invoke $CREPRC. It's author did something similar entirely
within COBOL. Got the integer values and then did MOVEs to move the lower
byte into the QUOTA list item code field.

The current "coder" cut bits and pieces from that original not knowing what
it was doing. I thoguht it odd when I asked the programmer about passing a
numeric value as the $CREPRC<pidadr>. It was a "decimal" value converted
from a hexadecimal PID. The "programmer" said it worked. It did but only
because the constant was writeable in COBOL. This was my first indication
that they were NOT calling $CREPRC correctly.

I got on this system early this morning (4:00) because I was up to get ready
for a launch event I took that original program and launched a .COM with a
simple $ WAIT 1:: in it. Then, I stepped though the same program and just
prior to the call to $CREPRC, I deposited %hex(2000000) as the PGFLQUOTA.
Sure enough, the created process had that ridiculously large PGFLQUOTA when
I looked.

COBOL is barely a read-only language for me but I was able to see that this
is doable if one DOESN'T disregard system call parameters that one does NOT
understand.

Two weeks wasted on this with a reticent programmer. Now, I can get back to
an sshfs problem.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On Saturday, 11 June 2022 at 6:17:11 pm UTC+10, Richard Maher wrote:
> On 11/06/2022 9:05 am, Richard Maher wrote:
> > On 11/06/2022 1:39 am, VAX...@SendSpamHere.ORG wrote:
> >> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
> >> ..............^
> >> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
> >> data-item
> >>
> >> How do you put PQL$ items in to a COBOL "byte"?
> >>
> >
> > Unfortunately COBOL has never supported by integers but there are
> > several ways to do it. (I haven't fired up my VMS machines in 5 years
> > otherwise I'd give you an example. Back in the day when google groups
> > could search the archives you could find one of several $creprc examples
> > with all parameters including TCB)
> >
> > Cumbersome: -
> >
> > 01 enqlm_word pic 9(4) comp value external pql$_enqlm.
> > 01 enqlm_byte redefines enqlm_word.
> > 03 pql_enqlm pic x.
> >
> > move pql_enqlm to somewhere.
> >
> > Lose external symbols and hard code: -
> >
> > Hexadecimal literals:
> >
> > 10 ENQ-TYPE PIC X(1) VALUE x"00".
> >
> > Special Names:
> >
> > SPECIAL-NAMES.
> > PQL$_ENQLM value is 44. (I don't know the value)
> >
> > 10 ENQ-TYPE PIC X(1) VALUE PQL$_ENQLM.
> >
> > The way I do it: -
> >
> > Define a global .PSECT in the same .MAR file that you already probably
> > do for $pqldef GLOBAL
> >
> > Just lay it out as you would for macro.
> >
> > .psect fred long, gbl,shr,wrt,blah
> >
> > .byte pql$_enqlm
> >
> > Then declare an EXTERNAL variable as the same name as your global psect.
> >
> > 01 fred external.
> > 03 pql$_enqlm pic x. (doesn't have to be same name)
> > 03 pic x.
> >
> > * The last byte is NECESSARY to round up the psect size on Alpha, and
> > * Itanium. Macro does this automatically.
> >
> > Again many examples in cov over the years
> Below is an entry response. Need to find whole conversation or
> view-as-tree: -
>
> https://groups.google.com/g/comp.os.vms/c/xJptlKOregU/m/y0s3fbcoqtQJ" rel="nofollow" target="_blank">https://groups.google.com/g/comp.os.vms/c/xJptlKOregU/m/y0s3fbcoqtQJ
>
> https://groups.google.com/g/comp.os.vms/c/xJptlKOregU/m/y0s3fbcoqtQ
>
> https://groups.google.com/g/comp.os.vms/c/TAmi6i8fMo0/m/1f1JnjqS8RsJ

Boldly going where no COBOL has been before

Nice to see dclexh used in anger again

I always found that compiling with /LIST and /MAP=DECLARED
showed you what the layout actually is, rather than what you thought it was

On 11/06/2022 5:39 pm, VAXman-@SendSpamHere.ORG wrote:
> In article <t80pog$hnn$1@gioia.aioe.org>, Richard Maher
> <maher_rjSPAMLESS@hotmail.com> writes:
>> On 11/06/2022 1:39 am, VAXman-@SendSpamHere.ORG wrote:
>>> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
>>> ..............^ %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored
>>> - valid only on COMP data-item
>>>
>>> How do you put PQL$ items in to a COBOL "byte"?
>>>
>>
>> Unfortunately COBOL has never supported by integers but there are
>> several ways to do it. (I haven't fired up my VMS machines in 5
>> years otherwise I'd give you an example. Back in the day when
>> google groups could search the archives you could find one of
>> several $creprc examples with all parameters including TCB)
>>
>> Cumbersome: -
>>
>> 01 enqlm_word pic 9(4) comp value external pql$_enqlm. 01
>> enqlm_byte redefines enqlm_word. 03 pql_enqlm pic x.
>>
>> move pql_enqlm to somewhere.
>>
>> Lose external symbols and hard code: -
>>
>> Hexadecimal literals:
>>
>> 10 ENQ-TYPE PIC X(1) VALUE x"00".
>>
>> Special Names:
>>
>> SPECIAL-NAMES. PQL$_ENQLM value is 44. (I don't know the value)
>>
>> 10 ENQ-TYPE PIC X(1) VALUE PQL$_ENQLM.
>>
>> The way I do it: -
>>
>> Define a global .PSECT in the same .MAR file that you already
>> probably do for $pqldef GLOBAL
>>
>> Just lay it out as you would for macro.
>>
>> ..psect fred long, gbl,shr,wrt,blah
>>
>> ..byte pql$_enqlm
>>
>> Then declare an EXTERNAL variable as the same name as your global
>> psect.
>>
>> 01 fred external. 03 pql$_enqlm pic x. (doesn't have to be same
>> name) 03 pic x.
>>
>> * The last byte is NECESSARY to round up the psect size on Alpha,
>> and * Itanium. Macro does this automatically.
>>
>> Again many examples in cov over the years
>
> Thanks Richard. I found a program on the customer's system that was
> written decades ago to invoke $CREPRC. It's author did something
> similar entirely within COBOL. Got the integer values and then did
> MOVEs to move the lower byte into the QUOTA list item code field.
>
> The current "coder" cut bits and pieces from that original not
> knowing what it was doing. I thoguht it odd when I asked the
> programmer about passing a numeric value as the $CREPRC<pidadr>. It
> was a "decimal" value converted from a hexadecimal PID. The
> "programmer" said it worked. It did but only because the constant
> was writeable in COBOL. This was my first indication that they were
> NOT calling $CREPRC correctly.
>
> I got on this system early this morning (4:00) because I was up to
> get ready for a launch event I took that original program and
> launched a .COM with a simple $ WAIT 1:: in it. Then, I stepped
> though the same program and just prior to the call to $CREPRC, I
> deposited %hex(2000000) as the PGFLQUOTA. Sure enough, the created
> process had that ridiculously large PGFLQUOTA when I looked.
>
> COBOL is barely a read-only language for me but I was able to see
> that this is doable if one DOESN'T disregard system call parameters
> that one does NOT understand.
>
> Two weeks wasted on this with a reticent programmer. Now, I can get
> back to an sshfs problem.
>

"All's well that ends" - Hein

On 2022-06-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>
> COBOL is barely a read-only language for me but I was able to see that this
> is doable if one DOESN'T disregard system call parameters that one does NOT
> understand.
>

Using COBOL to interface to VMS has been a serious eye-opener for me in
reading this thread. I guess no-one is going to be doing even a bare metal
LED blinker in COBOL any time soon... :-)

> Two weeks wasted on this with a reticent programmer. Now, I can get back to
> an sshfs problem.
>

sshfs on VMS ? Is that using sshfs as a client or as a server on VMS ?

I am also curious which software you are using on VMS to support sshfs.

Thanks,

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <t87tg0$h5a$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-06-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>
>> COBOL is barely a read-only language for me but I was able to see that this
>> is doable if one DOESN'T disregard system call parameters that one does NOT
>> understand.
>>
>
>Using COBOL to interface to VMS has been a serious eye-opener for me in
>reading this thread. I guess no-one is going to be doing even a bare metal
>LED blinker in COBOL any time soon... :-)

Bare metal COBOL. Thankfully, I haven't poured the first beer yet or I'd have
wasted a good ale, and I'd be cleaning it up from the screen and keyboard.

>> Two weeks wasted on this with a reticent programmer. Now, I can get back to
>> an sshfs problem.
>>
>
>sshfs on VMS ? Is that using sshfs as a client or as a server on VMS ?

It's OBVIOUS you haven't tried it. sshfs from linux or OSX to VMS works well.
I use it to move files to and from quite often. It works with TCPIP Services
ssh althought you need to supply some -o parameters to dumb it down. Process
ssh for OpenVMS works too and the -o dumb-downs aren't needed. My Mac and my
linux have a /mnt/VMS directory for the mount point and a simple script that
does the sshfs magic. Public keys make it all easy-peasy.

>I am also curious which software you are using on VMS to support sshfs.

See above.

My sshfs is a problem between OSX and linux involving some data I want to use
for a web site. I just haven't had the free time to dick-about with it. Do
not assume, because I mentioned it here, that it had anything to do with VMS.

I'm now distracted again fixing the php in a plug-in I installed. I need to
make an <svg>...</svg> handle doing a transform: rotate but the author of the
plug-in php really horked a simple implementation.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

> Using COBOL to interface to VMS has been a serious eye-opener for me in
> reading this thread. I guess no-one is going to be doing even a bare
> metal LED blinker in COBOL any time soon... :-)

Never underestimate the chance that some weirdo may combine some COMP
data, the REVERSE verb, and some overlay moves. I mean, there's
http://www.coboloncogs.org/ so...

/me ponders how to nmost obscurely get GPIO on a vax or itanic.

De