[Info-vax] Calling $CREPRC in COBOL

[Dave Froble]

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

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