On Mon, 2022-06-13 at 22:54 -0500, Dennis Boone wrote:
>  > Using COBOL to interface to VMS has been a serious eye-opener for
> me in
>  > reading this thread.  I guess no-one is going to be doing even a
> bare
>  > metal LED blinker in COBOL any time soon...  :-)
>
> Never underestimate the chance that some weirdo may combine some COMP
> data, the REVERSE verb, and some overlay moves.  I mean, there's
> http://www.coboloncogs.org/ so...
>
> /me ponders how to nmost obscurely get GPIO on a vax or itanic.

Raspberry Pi, using OpenCOBOL. See the 9th post on
https://forums.raspberrypi.com/viewtopic.php?t=139325 for the gory
details :-D

IDENTIFICATION DIVISION.
PROGRAM-ID. HELLOWORLD.

DATA DIVISION.
WORKING-STORAGE SECTION.
01 WS-GPIO-INIT PIC x(40) VALUE 'echo "21" >
/sys/class/gpio/export'.
01 WS-GPIO-DIR PIC x(80) VALUE 'echo "out" >
/sys/class/gpio/gpio21/direction'.
01 WS-GPIO-ON PIC x(80) VALUE 'echo "1" >
/sys/class/gpio/gpio21/value'.
01 WS-GPIO-OFF PIC x(80) VALUE 'echo "0" >
/sys/class/gpio/gpio21/value'.
01 WS-GPIO-ClR PIC x(80) VALUE 'echo "21" >
/sys/class/gpio/unexport'.
--
Tactical Nuclear Kittens

On 2022-06-13, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <t87tg0$h5a$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>On 2022-06-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>>>
>>> COBOL is barely a read-only language for me but I was able to see that this
>>> is doable if one DOESN'T disregard system call parameters that one does NOT
>>> understand.
>>>
>>
>>Using COBOL to interface to VMS has been a serious eye-opener for me in
>>reading this thread. I guess no-one is going to be doing even a bare metal
>>LED blinker in COBOL any time soon... :-)
>
> Bare metal COBOL. Thankfully, I haven't poured the first beer yet or I'd have
> wasted a good ale, and I'd be cleaning it up from the screen and keyboard.
>

Oh, Brian. :-)

I thought you would have learnt by now not to have anything in your mouth
just in case before you read a post from me. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-06-13, Dennis Boone <drb@ihatespam.msu.edu> wrote:
> > Using COBOL to interface to VMS has been a serious eye-opener for me in
> > reading this thread. I guess no-one is going to be doing even a bare
> > metal LED blinker in COBOL any time soon... :-)
>
> Never underestimate the chance that some weirdo may combine some COMP
> data, the REVERSE verb, and some overlay moves. I mean, there's
> http://www.coboloncogs.org/ so...
>
> /me ponders how to nmost obscurely get GPIO on a vax or itanic.
>

Most obscure would probably be using the control signals on a _real_
serial port, not USB serial port, as GPIO pins.

Abusing a parallel port would also do it, but that's not as obscure
as using the control signals on a serial port.

There are designs for building low-cost microcontroller programmers
that work with control signals on real serial ports on PCs running
Linux. Just be aware of potential voltage compatibility issues with
current microcontrollers before trying the designs however.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-06-14, Single Stage to Orbit <alex.buell@munted.eu> wrote:
> On Mon, 2022-06-13 at 22:54 -0500, Dennis Boone wrote:
>>  > Using COBOL to interface to VMS has been a serious eye-opener for
>> me in
>>  > reading this thread.  I guess no-one is going to be doing even a
>> bare
>>  > metal LED blinker in COBOL any time soon...  :-)
>>
>> Never underestimate the chance that some weirdo may combine some COMP
>> data, the REVERSE verb, and some overlay moves.  I mean, there's
>> http://www.coboloncogs.org/ so...
>>
>> /me ponders how to nmost obscurely get GPIO on a vax or itanic.
>
> Raspberry Pi, using OpenCOBOL. See the 9th post on
> https://forums.raspberrypi.com/viewtopic.php?t=139325 for the gory
> details :-D
>

That is _NOT_ bare metal however. :-)

Bare metal is where your code is running directly on the hardware without
any operating system underneath it and where your COBOL program is directly
reading and writing from/to device registers and directly receiving device
interrupts.

You are allowed to use an assembly language dispatcher for the interrupt
handler that then calls your COBOL interrupt handler but that means your
COBOL code still needs to be able to work in interrupt context for the
device in question.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/06/2022 6:10 pm, Phil Howell wrote:
> On Saturday, 11 June 2022 at 6:17:11 pm UTC+10, Richard Maher wrote:
>> On 11/06/2022 9:05 am, Richard Maher wrote:
>>> On 11/06/2022 1:39 am, VAX...@SendSpamHere.ORG wrote:
>>>> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
>>>> ..............^
>>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>>>> data-item
>>>>
>>>> How do you put PQL$ items in to a COBOL "byte"?
>>>>
>>>
>>> Unfortunately COBOL has never supported by integers but there are
>>> several ways to do it. (I haven't fired up my VMS machines in 5 years
>>> otherwise I'd give you an example. Back in the day when google groups
>>> could search the archives you could find one of several $creprc examples
>>> with all parameters including TCB)
>>>
>>> Cumbersome: -
>>>
>>> 01 enqlm_word pic 9(4) comp value external pql$_enqlm.
>>> 01 enqlm_byte redefines enqlm_word.
>>> 03 pql_enqlm pic x.
>>>
>>> move pql_enqlm to somewhere.
>>>
>>> Lose external symbols and hard code: -
>>>
>>> Hexadecimal literals:
>>>
>>> 10 ENQ-TYPE PIC X(1) VALUE x"00".
>>>
>>> Special Names:
>>>
>>> SPECIAL-NAMES.
>>> PQL$_ENQLM value is 44. (I don't know the value)
>>>
>>> 10 ENQ-TYPE PIC X(1) VALUE PQL$_ENQLM.
>>>
>>> The way I do it: -
>>>
>>> Define a global .PSECT in the same .MAR file that you already probably
>>> do for $pqldef GLOBAL
>>>
>>> Just lay it out as you would for macro.
>>>
>>> .psect fred long, gbl,shr,wrt,blah
>>>
>>> .byte pql$_enqlm
>>>
>>> Then declare an EXTERNAL variable as the same name as your global psect.
>>>
>>> 01 fred external.
>>> 03 pql$_enqlm pic x. (doesn't have to be same name)
>>> 03 pic x.
>>>
>>> * The last byte is NECESSARY to round up the psect size on Alpha, and
>>> * Itanium. Macro does this automatically.
>>>
>>> Again many examples in cov over the years
>> Below is an entry response. Need to find whole conversation or
>> view-as-tree: -
>>
>> https://groups.google.com/g/comp.os.vms/c/xJptlKOregU/m/y0s3fbcoqtQJ" rel="nofollow" target="_blank">https://groups.google.com/g/comp.os.vms/c/xJptlKOregU/m/y0s3fbcoqtQJ
>>
>> https://groups.google.com/g/comp.os.vms/c/xJptlKOregU/m/y0s3fbcoqtQ
>>
>> https://groups.google.com/g/comp.os.vms/c/TAmi6i8fMo0/m/1f1JnjqS8RsJ
>
> Boldly going where no COBOL has been before
>
> Nice to see dclexh used in anger again
>
> I always found that compiling with /LIST and /MAP=DECLARED
> showed you what the layout actually is, rather than what you thought it was
>

My not be strictly COBOL but the memory lingers: -

https://github.com/RichardMaher/Brotkrumen/blob/master/testmap.html

<script type="application/javascript">
'use strict';

/* identification division.
* program-id. YouCantTouchThis-BreakItDown.
* author. Richard Maher.
* version. 1.0
*/

Because of the hard-coded Google Map Key, you must copy the file to your
local system to run it.

Seems a lot of effort to get smooth marker movement but it's not up to me.

On 6/13/22 13:52, Simon Clubley wrote:
>
> I guess no-one is going to be doing even a bare metal
> LED blinker in COBOL any time soon... :-)
>

Which, of course, isn't the function of COBOL, but it's OK go
ahead and blame the language.

bill

On 6/16/2022 2:47 PM, Bill Gunshannon wrote:
> On 6/13/22 13:52, Simon Clubley wrote:
>>                            I guess no-one is going to be doing even a
>> bare metal
>> LED blinker in COBOL any time soon... :-)
>
> Which, of course, isn't the function of COBOL, but it's OK go
> ahead and blame the language.

Assuming that he means COmmon Business Oriented Language and
not COmmon Baremetal Oriented Language, then I totally agree.

:-)

Arne

On Thursday, June 16, 2022 at 1:47:27 PM UTC-5, Bill Gunshannon wrote:
> On 6/13/22 13:52, Simon Clubley wrote:
> >
> > I guess no-one is going to be doing even a bare metal
> > LED blinker in COBOL any time soon... :-)
> >
> Which, of course, isn't the function of COBOL, but it's OK go
> ahead and blame the language.
>
The bare metal COBOL SORT would be interesting!

Better yet would be the bare metal COBOL REPORT WRITER.

In article <92d24d2c-6f49-40c7-b71b-da2454dc4876n@googlegroups.com>, seasoned_geek <roland@logikalsolutions.com> writes:
>On Thursday, June 16, 2022 at 1:47:27 PM UTC-5, Bill Gunshannon wrote:
>> On 6/13/22 13:52, Simon Clubley wrote:
>> >
>> > I guess no-one is going to be doing even a bare metal
>> > LED blinker in COBOL any time soon... :-)
>> >
>> Which, of course, isn't the function of COBOL, but it's OK go
>> ahead and blame the language.
>>
>The bare metal COBOL SORT would be interesting!
>
>Better yet would be the bare metal COBOL REPORT WRITER.

What sort/type of report?

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2022-06-18 22:22, VAXman-@SendSpamHere.ORG wrote:
> In article <92d24d2c-6f49-40c7-b71b-da2454dc4876n@googlegroups.com>, seasoned_geek <roland@logikalsolutions.com> writes:
>> On Thursday, June 16, 2022 at 1:47:27 PM UTC-5, Bill Gunshannon wrote:
>>> On 6/13/22 13:52, Simon Clubley wrote:
>>>>
>>>> I guess no-one is going to be doing even a bare metal
>>>> LED blinker in COBOL any time soon... :-)
>>>>
>>> Which, of course, isn't the function of COBOL, but it's OK go
>>> ahead and blame the language.
>>>
>> The bare metal COBOL SORT would be interesting!
>>
>> Better yet would be the bare metal COBOL REPORT WRITER.
>
> What sort/type of report?

I don't think the COBOL language definition tells exactly what algorithm
used, but the ability to perform sorts is in the language.

I suspect it's the same with the report writer thingy.

Johnny

On 6/10/2022 4:34 PM, Craig A. Berry wrote:
>
> On 6/10/22 2:57 PM, Bill Gunshannon wrote:
>> On 6/10/22 15:03, Craig A. Berry wrote:
>>>
>>> On 6/10/22 1:27 PM, Bill Gunshannon wrote:
>>>> On 6/10/22 14:16, Craig A. Berry wrote:
>>>>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>>>>> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
>>>>>> ..............^
>>>>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>>>>>> data-item
>>>>>>
>>>>>> How do you put PQL$ items in to a COBOL "byte"?
>
>> I have no idea what POL$_ENOLM means or what he is trying to do with it.
>> A rough guess would be rather than declaring it external he needs to
>> use some VMS Specific function to grab the value and load it into
>> ENO-TYPE.
>
> If SDL produces COBOL text libraries and there is a way to include them
> (some variant of COPY?) then yes, he might be able to do the equivalent
> of "#include <pqldef.h>" and not need the external declaration. But the
> external declaration is an ancient hack that at one time was more
> reliable than depending on the existence of programmer-friendly
> definitions, and also, if you were willing to link at installation time,
> could insulate against version-specific changes to the symbol value.

What I'm having a problem with is expecting the linker to find the declared
external data. PQL_ENQLM is a SYSGEN parameter. Not something the linker could
find, unless linking against the system image, and I have no idea if linking
against the system image would provide that parameter.

I could be wrong, hell I'm usually wrong these days. I do not think Brian gave
enough information.

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.

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

On 20/06/2022 10:20 am, Dave Froble wrote:
> On 6/10/2022 4:34 PM, Craig A. Berry wrote:
>>
>> On 6/10/22 2:57 PM, Bill Gunshannon wrote:
>>> On 6/10/22 15:03, Craig A. Berry wrote:
>>>>
>>>> On 6/10/22 1:27 PM, Bill Gunshannon wrote:
>>>>> On 6/10/22 14:16, Craig A. Berry wrote:
>>>>>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>>>>>> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
>>>>>>> ..............^ %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause
>>>>>>> ignored - valid only on COMP data-item
>>>>>>>
>>>>>>> How do you put PQL$ items in to a COBOL "byte"?
>>
>>> I have no idea what POL$_ENOLM means or what he is trying to do
>>> with it. A rough guess would be rather than declaring it external
>>> he needs to use some VMS Specific function to grab the value and
>>> load it into ENO-TYPE.
>>
>> If SDL produces COBOL text libraries and there is a way to include
>> them (some variant of COPY?) then yes, he might be able to do the
>> equivalent of "#include <pqldef.h>" and not need the external
>> declaration. But the external declaration is an ancient hack that
>> at one time was more reliable than depending on the existence of
>> programmer-friendly definitions, and also, if you were willing to
>> link at installation time, could insulate against version-specific
>> changes to the symbol value.
>
> What I'm having a problem with is expecting the linker to find the
> declared external data. PQL_ENQLM is a SYSGEN parameter. Not
> something the linker could find, unless linking against the system
> image, and I have no idea if linking against the system image would
> provide that parameter.
>
> I could be wrong, hell I'm usually wrong these days. I do not think
> Brian gave enough information.
>
> 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.
>

I think you'll find the process defaults rarely match your needs. For me
I create a server process username and $persona_assume before the
$creprc but also preload the quotas from a $getuai before hand.

The linker resolved PQL$m_ENQLM symbol does NOT contain a value for lock
limits it is merely telling creprc that the next item-list parameter
contains this value.

In article <t8olit$71c$1@dont-email.me>, Dave Froble <davef@tsoft-inc.com> writes:
>On 6/10/2022 4:34 PM, Craig A. Berry wrote:
>>
>> On 6/10/22 2:57 PM, Bill Gunshannon wrote:
>>> On 6/10/22 15:03, Craig A. Berry wrote:
>>>>
>>>> On 6/10/22 1:27 PM, Bill Gunshannon wrote:
>>>>> On 6/10/22 14:16, Craig A. Berry wrote:
>>>>>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>>>>>> 10 ENQ-TYPE PIC X(1) VALUE EXTERNAL PQL$_ENQLM.
>>>>>>> ..............^
>>>>>>> %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause ignored - valid only on COMP
>>>>>>> data-item
>>>>>>>
>>>>>>> How do you put PQL$ items in to a COBOL "byte"?
>>
>>> I have no idea what POL$_ENOLM means or what he is trying to do with it.
>>> A rough guess would be rather than declaring it external he needs to
>>> use some VMS Specific function to grab the value and load it into
>>> ENO-TYPE.
>>
>> If SDL produces COBOL text libraries and there is a way to include them
>> (some variant of COPY?) then yes, he might be able to do the equivalent
>> of "#include <pqldef.h>" and not need the external declaration. But the
>> external declaration is an ancient hack that at one time was more
>> reliable than depending on the existence of programmer-friendly
>> definitions, and also, if you were willing to link at installation time,
>> could insulate against version-specific changes to the symbol value.
>
>What I'm having a problem with is expecting the linker to find the declared
>external data. PQL_ENQLM is a SYSGEN parameter. Not something the linker could
>find, unless linking against the system image, and I have no idea if linking
>against the system image would provide that parameter.
>
>I could be wrong, hell I'm usually wrong these days. I do not think Brian gave
>enough information.

Brian gave ample information for anyone who has used this abhorrent "launguage"
called COBOL..

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.

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

In this case, the client was calling a module I wrote for them that *dynamically*
loads an environment to produce Ex(h)el spreadsheets. Their own programs are fat!
In fact, their programs are grossly obese. Their new code made "My 600 lbs Life"
look like a documentary on anorexia. When this program was launched, there was an
insufficient page file quota and thus, the program hacked up SS$_INSFMEM hairball
errors when trying to load the dynamically loaded spreadsheet code.

This is what happens when ?programmers? write code like:

PERFORM 1000A-CODE THRU
1000Z-CODE-EXIT.
PERFORM 2000A-CODE THRU
2000Z-CODE-EXIT.

PERFORM 3000A-CODE THRU
3000Z-CODE-EXIT.

:
:
1000A-CODE.
<a line of COBOL>.
1000Z-CODE-EXIT.

2000A-CODE.
<a line of COBOL>.
2000Z-CODE-EXIT.

3000A-CODE.
<a line of COBOL>.
3000Z-CODE-EXIT.

ad infinitum, compiling and linking everything /DEBUG/NOOPTIMIZE and /DEBUG,
and running the programs RUN/NODEBUG. $CREPRC launched programs are jacketed
in a .COM procedure that does '$ RUN/NODEBG <grossly-obese--program>'.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

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.

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

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

On 20/06/2022 11:23 am, Richard Maher wrote:
> On 20/06/2022 10:20 am, Dave Froble wrote:
>> On 6/10/2022 4:34 PM, Craig A. Berry wrote:
>>>
>>> On 6/10/22 2:57 PM, Bill Gunshannon wrote:
>>>> On 6/10/22 15:03, Craig A. Berry wrote:
>>>>>
>>>>> On 6/10/22 1:27 PM, Bill Gunshannon wrote:
>>>>>> On 6/10/22 14:16, Craig A. Berry wrote:
>>>>>>> On 6/10/22 12:39 PM, VAXman-@SendSpamHere.ORG wrote:
>>>>>>>> 10  ENQ-TYPE      PIC X(1)  VALUE EXTERNAL PQL$_ENQLM.
>>>>>>>> ..............^ %COBOL-E-EXTREFVAL, VALUE EXTERNAL clause
>>>>>>>> ignored - valid only on COMP data-item
>>>>>>>>
>>>>>>>> How do you put PQL$ items in to a COBOL "byte"?
>>>
>>>> I have no idea what POL$_ENOLM means or what he is trying to do
>>>> with it. A rough guess would be rather than declaring it external
>>>> he needs to use some VMS Specific function to grab the value and
>>>> load it into ENO-TYPE.
>>>
>>> If SDL produces COBOL text libraries and there is a way to include
>>> them (some variant of COPY?) then yes, he might be able to do the
>>> equivalent of "#include <pqldef.h>" and not need the external
>>> declaration.  But the external declaration is an ancient hack that
>>> at one time was more reliable than depending on the existence of
>>> programmer-friendly definitions, and also, if you were willing to
>>> link at installation time, could insulate against version-specific
>>> changes to the symbol value.
>>
>> What I'm having a problem with is expecting the linker to find the
>> declared external data.  PQL_ENQLM is a SYSGEN parameter.  Not
>> something the linker could find, unless linking against the system
>> image, and I have no idea if linking against the system image would
>> provide that parameter.
>>
>> I could be wrong, hell I'm usually wrong these days.  I do not think
>>  Brian gave enough information.
>>
>> 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.
>>
>
> I think you'll find the process defaults rarely match your needs. For me
> I create a server process username and $persona_assume before the
> $creprc but also preload the quotas from a $getuai before hand.
>
> The linker resolved PQL$m_ENQLM symbol does NOT contain a value for lock
> limits it is merely telling creprc that the next item-list parameter
> contains this value.

More pearls go unnoticed

BTW If someone is better at the GOOGLE Groups interface than me you can
get the entire solution

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

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

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

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

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

On 2022-06-22 15:12:48 +0000, Dave Froble said:

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

Richard is discussing Microsoft Windows features.

Else-platform, your approach is akin to a home-grown version of the
preferences files that are now commonly in use on other platforms,
though those typically have different formats and structures and
settings can be nested. OpenVMS unfortunately has big gaps in its
available APIs here.

Here's the Apple equivalent:
https://developer.apple.com/documentation/foundation/nsuserdefaults

In a newer app design, LDAP would probably be used to store the
settings, as that can allow these settings on the computer, the user,
groups, or environment-wide. Outside of the lack of local commands and
lexicals, LDAP is logical names, thirty years on. And the existing
features could probably be re-hosted over onto LDAP without
significantly altering the existing OpenVMS APIs, if at all. For
strictly-local settings-related text-format stuff where I don't have an
API for preferences and defaults, I might look at using JSON or YAML as
the format, not that BASIC or most OpenVMS apps have a good path into
any of that.

Within OpenVMS, these access settings can be enforced using
identifiers, where the access control is associated with an OpenVMS
object. LDAP and local services would need access to RIGHTSLIST or an
analog to map from the text name to the binary value that then gets
attached all over the place within OpenVMS, were LDAP involved here.

LDAP itself running locally could replace the entirety of the OpenVMS
authentication system, not that I would expect to see that happen in
this decade.

I'd expect LDAP is underneath what Richard mentions, though have no
interest in wading further into the Microsoft documentation.

As for your process creation... The PQL stuff is one of those areas
where the argument is optional, where the defaults are fickle, and
where the PQL list really shouldn't be optional. The mailbox settings
are another area where the defaults are way, way, way too hazardous for
use by production apps. The IOSB argument is another area, and that
argument should never be considered optional. And as an added wrinkle
here in some application environments and particularly given the PQL
list contents aren't naturally aligned, which means there's yet another
surprise awaiting the unwary.

--
Pure Personal Opinion | HoffmanLabs LLC

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

On 22/06/2022 11:59 pm, Stephen Hoffman wrote:
> On 2022-06-22 15:12:48 +0000, Dave Froble said:
>
>> 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
>>>> ...
>>>> 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 ???
>
> Richard is discussing Microsoft Windows features.
>
> Else-platform, your approach is akin to a home-grown version of the
> preferences files that are now commonly in use on other platforms,
> though those typically have different formats and structures and
> settings can be nested.  OpenVMS unfortunately has big gaps in its
> available APIs here.
>
> Here's the Apple equivalent:
> https://developer.apple.com/documentation/foundation/nsuserdefaults
>
> In a newer app design, LDAP would probably be used to store the
> settings, as that can allow these settings on the computer, the user,
> groups, or environment-wide. Outside of the lack of local commands and
> lexicals, LDAP is logical names, thirty years on. And the existing
> features could probably be re-hosted over onto LDAP without
> significantly altering the existing OpenVMS APIs, if at all.  For
> strictly-local settings-related text-format stuff where I don't have an
> API for preferences and defaults, I might look at using JSON or YAML as
> the format, not that BASIC or most OpenVMS apps have a good path into
> any of that.
>
> Within OpenVMS, these access settings can be enforced using identifiers,
> where the access control is associated with an OpenVMS object. LDAP and
> local services would need access to RIGHTSLIST or an analog to map from
> the text name to the binary value that then gets attached all over the
> place within OpenVMS, were LDAP involved here.
>
> LDAP itself running locally could replace the entirety of the OpenVMS
> authentication system, not that I would expect to see that happen in
> this decade.
>
> I'd expect LDAP is underneath what Richard mentions, though have no
> interest in wading further into the Microsoft documentation.
>
> As for your process creation... The PQL stuff is one of those areas
> where the argument is optional, where the defaults are fickle, and where
> the PQL list really shouldn't be optional. The mailbox settings are
> another area where the defaults are way, way, way too hazardous for use
> by production apps. The IOSB argument is another area, and that argument
> should never be considered optional.  And as an added wrinkle here in
> some application environments and particularly given the PQL list
> contents aren't naturally aligned, which means there's yet another
> surprise awaiting the unwary.
>
>

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.

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

On Wednesday, June 22, 2022 at 11:59:22 AM UTC-4, Stephen Hoffman wrote:
> As for your process creation... The PQL stuff is one of those areas
> where the argument is optional, where the defaults are fickle, and
> where the PQL list really shouldn't be optional.

If they go to fix that, they should also drop the 63 character limit on the image
name argument.