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-@SendSpamHere.ORG wrote:
>>>>>>> In article <t8olit$71c$1@dont-email.me>, Dave Froble
>>>>>>> <davef@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!