[Info-vax] Calling $CREPRC in COBOL

[Richard Maher]

On 20/06/2022 10:28 pm, Dave Froble wrote:
> On 6/20/2022 7:37 AM, VAXman- at SendSpamHere.ORG wrote:
>> In article <t8olit$71c$1 at dont-email.me>, Dave Froble 
>> <davef at tsoft-inc.com> writes:
> 
>> PQL$_ENQLM is provided by a simple Macro:
>> 
>> .TITLE PQLDEF $PQLDEF    GLOBAL .END
>> 
>> This is assembled/complied to create global symbols available at
>> link time.  Any VMS programmer (sh/w)ould be aware of this.
> 
> Guess I am now.  Never did this particular thing.
> 
>>> From my occasional playing with CREPRC what I remember is that
>>> the PQL parameters are used when a specific parameter is not
>>> provided.  Thus, just don't provide that parameter to CREPRC.  I
>>> never did.
>> 
>> $PQLDEF definitions are used to create a quota list for the $CREPRC
>>  system service that define process quotes for the created process.
>> Typically, the SYSGEN minimum and or default quota parameters will
>> suffice for the created process quota for the crux of most
>> processing.
> 
> Most/all of my usage of CREPRC has been for creating detached 
> processes.  Now that you made me think (I hate when that happens) I
> seem to recall that for detached processes the PQL parameters are
> used for defaults when a particular parameter is not in the item
> list.  I also seem to recall that that may not happen for other than
> detached processes.  Didn't do much of that.
> 
> Regardless, if using a PQL parameter, unless they have been
> customized, (which I did on systems running our software), the value
> may not be of much use, if it is too low, and I also seem to recall
> that the supplied values were usually too low.  Thus my initial
> puzzlement as to why you wanted to use any PQL parameters.
> 
> My solution was to have some application data, one set for each
> detached processes application, which specified needed parameters and
> such.  Thru time, more and more of our applications used detached
> processes, and the design turned out to be quite helpful.  Not so
> many people working with "terminals" these days, and more services
> serving trading partner inquiries, orders, and such.
> 

So Dave's solution is "Application Data". Sounds good; what's stored there?

1) We already know you have quotas
2) How about privileges and maybe a UIC?
3) Default working directory and base priority perhaps?
4) Maybe an account for charge back accounting

What did you call it? DAVES_AF.DAT :-(