On 6/22/2022 8:30 PM, Richard Maher wrote:
> On 22/06/2022 11:12 pm, Dave Froble wrote:
>> 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
>>>> COLLECT_LETTER Collection letter codes
>>>> COLLECT_TXNS Collection transaction codes
>>>> COMPANY_NAME Company name records
>>>> CTL_DATES Date range control records
>>>> CTY_TAX Taxing location rate records
>>>> CUST_TYPE Customer type codes
>>>> DAS14 DAS14 data file list(s)
>>>> DETACH Detached process parameter records
>>>> FILENAMES Data file names and locations
>>>> FREIGHT_CODES Freight code maintenance.
>>>> GL_ACCOUNTS General ledger account records
>>>> MESSAGES Message records
>>>> NUMBERS Miscellaneous numeric data records
>>>> ORDER_TYPES Order type code records
>>>> PASSWORDS Password code records
>>>> PAYMENT_AUTH Payment authorization code records
>>>> PL-DESC Product line description records
>>>> PO-TYPE Purchase Order Type Codes
>>>> POOL_CAR Pool car records
>>>> PSO_CHANGE PSO change codes
>>>> REGION Region codes
>>>> SALESMAN Salesman code records
>>>> SALES_GROUP Sales group codes
>>>> SA_PROGRAMS Sales Analysis program records
>>>> SEQUENCES Sequence number records
>>>> SHIP_VIA Ship via code records
>>>> STATES State code records
>>>> STRINGS Miscellaneous string data records
>>>> TERMS_CODES Terms code records
>>>> TRANSACTION Inventory transaction code records
>>>> 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 ???
>>
>
>
> Just saying the *existing* sysuaf.dat et al files are already there and
> functional and appropriate for the creation of service accounts on VMS the only
> thing you may have to store somewhere else is the actual username.
>
> "Hay System Manager, I need a Service Account for my application"
>
> "Sure, I'll make sure it all fits with security policy. Done"
>
> $getuai, $persona_create, $persona_assume $creprc . . .

That is just totally wrong Richard.

The detached services we're running are part of the application. They need to
be aware of many things about the application. They really don't give a damn
about the OS, the SYSUAF, and anything not part of the application.

Just because CREPRC is used to create the detached processes doesn't mean they
are not an integral part of the application. Just because we need to provide
some "system" information to start up the detached process isn't really
important to the application, other than what's needed to get it done.

If you want to argue it, I'll just point out that the design has been running,
successfully, for over 45 years. Before VMS in fact. This design was running
on RSTS.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486