[Info-vax] Calling $CREPRC in COBOL

[Dave Froble]

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 ???

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