[Info-vax] Calling $CREPRC in COBOL

[Richard Maher]

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