[Info-vax] Calling $CREPRC in COBOL

[VAXman- at SendSpamHere.ORG]

In article <t80pog$hnn$1 at gioia.aioe.org>, Richard Maher <maher_rjSPAMLESS at hotmail.com> writes:
>On 11/06/2022 1:39 am, VAXman- at 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.