[Info-vax] Calling $CREPRC in COBOL

[Stephen Hoffman]

On 2022-06-22 15:12:48 +0000, Dave Froble said:

> On 6/22/2022 10:18 AM, Richard Maher wrote:
>> On 21/06/2022 12:07 pm, Dave Froble wrote:
>>> On 6/20/2022 8:44 PM, Richard Maher wrote:
>>>> 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 :-(
>>> 
>>> Oh, you want the long version, huh?
>>> 
>>> Way, way, back, it was determined that due to the lack of adequate 
>>> channels in Basic+, 12 to be precise, it would be advisable to have a 
>>> single file that could be used for different types of data.  Things 
>>> with just a few records, such as maybe 20 terms codes, 50 state codes, 
>>> and others.  We even called it a "codes file".  The design was for 
>>> having the capability of re-defining the data fields in the I/O buffer 
>>> for each "code type".  Even implemented a data file editor to use the 
>>> multiple record definitions.
>>> 
>>> Over time, many different record definitions were added to the utility. 
>>>  Ended up with hundreds.  Was really useful.
>>> 
>>> When we started setting up detached processes, later on on VMS, the 
>>> CODES file seemed the logical place to set up the data, assuming that 
>>> the number of detached processes we'd be running was in that 1-100 
>>> range, for which the CODES file worked so well.  That particular record 
>>> definition contained all the things we wanted a detached process to 
>>> know.
>>> 
>>> The concept worked well, to the point all applications used it.  Every 
>>> program got it's filenames from the codes file using 
>>> keys/tokens/whatever you want to call them for one example.  The entire 
>>> TOLAS and other ERP type applications were built around the concept.
>>> 
>>> From an old customer site, no longer in use:
>>> 
>>> ---Code type---------Code description------
>>> 
>>> CODES             Codes Descriptors
>>> BANK_CODE         Bank code records
>>> CHARGES           Charge code records
>>> COLLECTOR         Credit analyst codes
>>> ...
>>> WAREHOUSE         Warehouse code records
>>> WHSE_CTL          Warehouse control records
>>> 
>>> Many more in current systems ...
>>> 
>> 
>> 
>> There ain't no fixin' stupid :-(
>> 
>> https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/service-accounts 
>> 
>> 
>> 
> 
> Not sure what we're discussing now Richard ???

Richard is discussing Microsoft Windows features.

Else-platform, your approach is akin to a home-grown version of the 
preferences files that are now commonly in use on other platforms, 
though those typically have different formats and structures and 
settings can be nested.  OpenVMS unfortunately has big gaps in its 
available APIs here.

Here's the Apple equivalent: 
https://developer.apple.com/documentation/foundation/nsuserdefaults

In a newer app design, LDAP would probably be used to store the 
settings, as that can allow these settings on the computer, the user, 
groups, or environment-wide. Outside of the lack of local commands and 
lexicals, LDAP is logical names, thirty years on. And the existing 
features could probably be re-hosted over onto LDAP without 
significantly altering the existing OpenVMS APIs, if at all.  For 
strictly-local settings-related text-format stuff where I don't have an 
API for preferences and defaults, I might look at using JSON or YAML as 
the format, not that BASIC or most OpenVMS apps have a good path into 
any of that.

Within OpenVMS, these access settings can be enforced using 
identifiers, where the access control is associated with an OpenVMS 
object. LDAP and local services would need access to RIGHTSLIST or an 
analog to map from the text name to the binary value that then gets 
attached all over the place within OpenVMS, were LDAP involved here.

LDAP itself running locally could replace the entirety of the OpenVMS 
authentication system, not that I would expect to see that happen in 
this decade.

I'd expect LDAP is underneath what Richard mentions, though have no 
interest in wading further into the Microsoft documentation.

As for your process creation... The PQL stuff is one of those areas 
where the argument is optional, where the defaults are fickle, and 
where the PQL list really shouldn't be optional. The mailbox settings 
are another area where the defaults are way, way, way too hazardous for 
use by production apps. The IOSB argument is another area, and that 
argument should never be considered optional.  And as an added wrinkle 
here in some application environments and particularly given the PQL 
list contents aren't naturally aligned, which means there's yet another 
surprise awaiting the unwary.


-- 
Pure Personal Opinion | HoffmanLabs LLC