[Info-vax] Calling $CREPRC in COBOL

[Richard Maher]

On 23/06/2022 9:39 am, Dave Froble wrote:
> 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- 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
>>>>>     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.
> 

Your application can do whatever it likes within the bounds of the 
quotas and privileges decreed by $creprc.

Just run sys$system:loginout.exe and set the input to whatever command 
file you like and your App is free to fulfill your requirements.

Maybe the old becom.mar was never used where you've been but it shows 
you how much there was to do before $persona.

But if you don't think Service Accounts are useful or $SUBMIT/USER was 
ever necessary then I won't stand in your way.

the INPUT to the detached process says what it is going to attempt, 
loginout.exe establishes a full blown qualified execution environment 
with all permissions and restrictions deemed appropriate.