[Info-vax] Calling $CREPRC in COBOL

[Richard Maher]

On 11/06/2022 5:39 pm, VAXman- at SendSpamHere.ORG wrote:
> 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.
> 

"All's well that ends" - Hein