[Info-vax] Calling $CREPRC in COBOL

[Richard Maher]

On 22/06/2022 11:59 pm, Stephen Hoffman wrote:
> 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.
> 
> 

Don't get me going on LDAP and JWTs :-(

Authentication *IS NOT* authorization people!