Very simple DCL question

[Arne Vajhøj]

$ type z.com
$ write sys$output "''p1'"
$ @z a
A
$ @z "a"
a

This is not really surprising.

But are there any way to preserve pn case without
double-quoting it?

Like this hypothetical syntax:

$ set proc/parse=(extended,pnkeepcase)

Arne

[Chris Townley]

There is of course

$ SET PROCESS /CASE=CASE_LOOKUP=SENSITIVE /PARSE_STYLE=EXTENDED

Does this not work?


--
Chris

[Arne Vajhøj]

On 12/28/2022 1:29 PM, Chris Townley wrote:
> On 28/12/2022 16:45, Arne Vajhøj wrote:
>> $ type z.com
>> $ write sys$output "''p1'"
>> $ @z a
>> A
>> $ @z "a"
>> a
>>
>> This is not really surprising.
>>
>> But are there any way to preserve pn case without
>> double-quoting it?
>>
>> Like this hypothetical syntax:
>>
>> $ set proc/parse=(extended,pnkeepcase)
>

> There is of course
>
> $ SET PROCESS /CASE=CASE_LOOKUP=SENSITIVE /PARSE_STYLE=EXTENDED
>
> Does this not work?

I did not know that. But no.

$ SET PROCESS /CASE=CASE_LOOKUP=SENSITIVE /PARSE_STYLE=EXTENDED

%DCL-W-IVKEYW, unrecognized keyword - check validity and spelling
\CASE_LOOKUP\
$ SET PROCESS /CASE_LOOKUP=SENSITIVE /PARSE_STYLE=EXTENDED
$ @z a
%DCL-E-OPENIN, error opening DISK2:[ARNE.gpcp]z.COM; as input
-RMS-E-FNF, file not found
$ @z.com a
A
$ @z.com "a"
a

Arne

[Chris Townley]

Interesting. What version of VMS are you on?

My example was straight from the VSI DCL dictionary. I was vaguely aware
of something like that.

Presumably the command affects the current process - do you need to have
it in z.com? Although you shouldn't as you are double quoting the symbol
substitution.

--
Chris

[Craig A. Berry]

Case sensitivity doesn't really have anything to do with case
preservation. I don't know of any way to do what Arne wants here except
to avoid DCL. Write a C program (or use something written in C, such as
Perl or Python, instead of DCL) and set extended parse in the process
and DECC$ARGV_PARSE_STYLE in the environment before running the C program.

[Arne Vajhøj]

> Interesting. What version of VMS are you on?

$ write sys$output f$getsyi("version")
V8.4-2L2

> My example was straight from the VSI DCL dictionary. I was vaguely aware
> of something like that.
>
> Presumably the command affects the current process - do you need to have
> it in z.com? Although you shouldn't as you are double quoting the symbol
> substitution.

I am pretty sure that the problem has already happened when the first
line in z.com is executed.

Arne

[Arne Vajhøj]

On 12/28/2022 3:07 PM, Craig A. Berry wrote:
>>> On 28/12/2022 16:45, Arne Vajhøj wrote:
>>>> $ type z.com
>>>> $ write sys$output "''p1'"
>>>> $ @z a
>>>> A
>>>> $ @z "a"
>>>> a
>>>>
>>>> This is not really surprising.
>>>>
>>>> But are there any way to preserve pn case without
>>>> double-quoting it?
>>>>
>>>> Like this hypothetical syntax:
>>>>
>>>> $ set proc/parse=(extended,pnkeepcase)

> Case sensitivity doesn't really have anything to do with case
> preservation.  I don't know of any way to do what Arne wants here except
> to avoid DCL.  Write a C program (or use something written in C, such as
> Perl or Python, instead of DCL) and set extended parse in the process
> and DECC$ARGV_PARSE_STYLE in the environment before running the C program.

:-(

But thanks.

Arne

[Chris Townley]

Interesting

$ SET PROCESS /CASE_LOOKUP=SENSITIVE /PARSE_STYLE=EXTENDED

$ aa = "a"
$ show sym aa
AA = "a"

$ @z.com 'aa'
A
$ @z.com "''aa'"
a

Not sure what else to suggest...

--
Chris

[Arne Vajhøj]

I will use the double quotes.

But just for fun:

$ type zz.com
$ write sys$output "''p1' ''p2' ''p3'"
$ run realp
$ write sys$output "''p1' ''p2' ''p3'"
$ @zz aaaa BBBB CcCc
AAAA BBBB CCCC
aaaa BBBB CcCc

But there is a gazillion things that can go wrong with that
realp.

Code below.

Arne



.title realp
$SSDEF
$DSCDEF
.macro if_end_command,lbl
cmpl r3,r4
bgeq lbl
.endm
.macro if_space,lbl
cmpb (r3),#32
beql lbl
.endm
.psect $LOCAL quad,pic,con,lcl,noshr,noexe,wrt
cmdlen: .blkw 1
cmdbuf: .blkb 256
pnam: .ascid "P1"
pval: .blkw 1
.byte DSC$K_DTYPE_T
.byte DSC$K_CLASS_S
.address pvala
pvala: .blkb 256
.psect $CODE quad,pic,con,lcl,shr,exe,nowrt
.entry realp,^m<r2,r3,r4,r5>
; grab copy of command line
movl #CTL$AG_CLIDATA,r0
movl W^PPD$L_PRC(r0),r0
movl W^PRC_L_RECALLPTR(r0),r0 ; r0 = next command
subl2 #2,r0
cvtwl (r0),r1 ; r1 = length current command
subl2 r1,r0 ; r0 = current command
movw r1,cmdlen ; copy of length of command line
movc3 r1,(r0),cmdbuf ; copy of command line
movab cmdbuf,r3 ; r3 = current character on
command line
cvtwl cmdlen,r1
addl3 r1,r3,r4 ; r4 = end of command line
; skip command itself
100$: if_end_command done
if_space start
incl r3 ; move to next character
brb 100$
; process parameters
start: incl r3 ; r3 = start first argument
movl #1,r2 ; r2 = n = 1
200$: if_end_command done
movw #0,pval ; reset parameter data
movab pvala,r5 ; r5 = where to copy parameter data
300$: if_end_command 500$
if_space 400$
incw pval ; add to pval/pvala
movb (r3),(r5)
incl r3
incl r5
brb 300$
400$: incl r3 ; skip space between parameters
500$: pushl #0
pushab pval
pushab pnam
calls #3,G^LIB$SET_SYMBOL
incb pnam+9 ; Pn -> Pn+1
incl r2 ; n = n + 1
cmpl r2,#8 ; while n <= 8
bleq 200$
done: movl #SS$_NORMAL,r0
ret
.end realp

[VAXman-]

Good grief! I needed an airsick bag and bottle of Tums after reading that.

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

I speak to machines with the voice of humanity.

[Arne Vajhøj]

That bad? Hmmm.

Well - I have not written much Macro-32 the last 25 years so ...

Arne

[alanfe...@gmail.com]

I don't think it's possible without quotation marks. Upcasing is done in the first phase of command parsing/evaluation/whatever.

See section 12.13 of the v8.4-2L1 Alpha user's manual. It doesn't mention the upcasing, by experiments I did long ago do seem to indicate that the upcasing does indeed occur in phase 1.

See also section 2.3. I could swear there was some example like abc"def"ghi, but maybe you need an older manual to find that.

Found some stuff.
First use SHOW SYMBOL instead of write sys$output "''p1"

$ type z.com
$ write sys$output "''p1'"

$ show symbol p1
$
$ @Z abc"def"ghi
ABCDEFGHI
P1 = "ABC"def"GHI"
$

See Help @ for that example.

[Bill Gunshannon]

On 12/28/22 21:58, Arne Vajhøj wrote:
>
>
> That bad? Hmmm.
>
> Well - I have not written much Macro-32 the last 25 years so ...
>

Gee... My MACRO skills are still pretty sharp.

Oh wait... You meant MACRO-32. Never mind. :-)

bill

[Arne Vajhøj]

On 12/28/2022 9:58 PM, Arne Vajhøj wrote:
> On 12/28/2022 10:49 PM, VAX...@SendSpamHere.ORG wrote:
>> In article <toisqe$p0r$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
>> <ar...@vajhoej.dk> writes:

[Macro-32 omitted]

>> Good grief!  I needed an airsick bag and bottle of Tums after reading
>> that.
>
> That bad? Hmmm.

You will probably not like the zweiter sehr verbesserte ausgabe either.

.title realp
$SSDEF
$DSCDEF
SPACE=32
PRC_C_CMDBUFSIZ=4097 ; 1025 on VAX
PRC$W_PROCLEVEL=56

.macro if_end_command,lbl
cmpl r3,r4
bgeq lbl
.endm
.macro if_space,lbl

cmpb (r3),#SPACE
beql lbl
.endm
.psect $PDATA quad,pic,con,lcl,shr,noexe,nowrt
nomsg: .ascid "This is not run from first level COM file so no action
taken"
.psect $LOCAL quad,pic,con,lcl,noshr,noexe,wrt
copy1: .blkb PRC_C_CMDBUFSIZ
copy2: .blkb PRC_C_CMDBUFSIZ

pnam: .ascid "P1"
pval: .blkw 1
.byte DSC$K_DTYPE_T
.byte DSC$K_CLASS_S
.address pvala
pvala: .blkb 256
.psect $CODE quad,pic,con,lcl,shr,exe,nowrt

.entry realp,^m<r2,r3,r4,r5,r6>
; phase 1 : grab copy of recall buffer
; out r0 = command length
; out r1 = command address
; temp r2 & r3 for working storage
; temp r6 = pointer recall buffer P1 space
movl #CTL$AG_CLIDATA,r6
movl W^PPD$L_PRC(r6),r6
cmpw W^PRC$W_PROCLEVEL(r6),#1 ; test if run from first level
COM file
bneq nogood
movc3 #PRC_C_CMDBUFSIZ,W^PRC_G_COMMANDS(r6),copy1 ; make two
copies of data to handle circular buffer
movc3 #PRC_C_CMDBUFSIZ,W^PRC_G_COMMANDS(r6),copy2
movab W^PRC_G_COMMANDS(r6),r2 ; find address next command
movl W^PRC_L_RECALLPTR(r6),r3
subl3 r2,r3,r1
movab copy2,r6
addl2 r6,r1
subl2 #2,r1 ; find length current command
cvtwl (r1),r0
subl2 r0,r1 ; find address current command
; phase 2 : parse
; in r0 = command length
; in r1 = command address
; temp r2 = parameter number
; temp r3 = current character in command
; temp r4 = end of command
; temp r5 = current Pn output character
movl r1,r3 ; current character = first
character
addl3 r0,r3,r4 ; find end of command

; skip command itself
100$: if_end_command done
if_space start

incl r3 ; skip if not space
brb 100$
; process parameters
start: incl r3 ; skip space between command
itself and P1
movl #1,r2 ; n = 1

200$: if_end_command done
movw #0,pval ; reset parameter data
movab pvala,r5

300$: if_end_command 500$
if_space 400$

incw pval ; add to parameter data
movb (r3)+,(r5)+
brb 300$
400$: incl r3 ; skip space between Pn and Pn+1
500$: pushl #0
pushab pval ; set Pn symbol
pushab pnam
calls #3,G^LIB$SET_SYMBOL
incb pnam+9 ; update Pn -> Pn+1

incl r2 ; n = n + 1
cmpl r2,#8 ; while n <= 8
bleq 200$

brb done
; message due to to not being run from first level COM file
nogood: pushab nomsg
calls #1,G^LIB$PUT_OUTPUT
; all done

done: movl #SS$_NORMAL,r0
ret
.end realp

Arne

[Chris Townley]

That reminds why I told the development manager, when being interviewed
to join the programming team, that I would not do macro...

I still got the job!

Later when there was a problem with any of the macro, I just rewrote in
a high level language


--
Chris

[Stephen Hoffman]

On 2022-12-31 21:03:24 +0000, Arne Vajh j said:

Didn't review the code, definitely some things I'd do different, but it
seems this code is expecting traditional (#8) and not extended (#16)
parsing.

#16

> bleq 200$
> brb done
> ; message due to to not being run from first level COM file
> nogood: pushab nomsg
> calls #1,G^LIB$PUT_OUTPUT
> ; all done
> done: movl #SS$_NORMAL,r0
> ret
> .end realp
>
> Arne

--
Pure Personal Opinion | HoffmanLabs LLC

[gah4]

(snip)

> But are there any way to preserve pn case without
> double-quoting it?

Can you do it with CLD?

I do remember that TeX uses CLD, and I don't remember quoting command line arguments.

[Arne Vajhøj]

On 12/31/2022 7:07 PM, Stephen Hoffman wrote:
> On 2022-12-31 21:03:24 +0000, Arne Vajh j said:

>> .title realp

> Didn't review the code, definitely some things I'd do different,

Probably also better. But ...

> but it
> seems this code is expecting traditional (#8) and not extended (#16)
> parsing.

>> cmpl r2,#8 ; while n <= 8

> #16

This is interesting. One can get COM files to accept 16 parameters?
How?

Arne

[Jan-Erik Söderholm]

Is it a mixup between number of COM file parameters
and number of sub-directoy levels?

[Volker Halle]

> > This is interesting. One can get COM files to accept 16 parameters?
> > How?

See DCL_CTLFLAGS bit 3

If clear (the default), command procedure supports the default eight optional parameters (that is, (P1,P2,...P8)). If set, command procedure supports up to sixteen optional parameters (that is, (P1,P2,...P16)). This is also applicable when using the CALL command to transfer control to a subroutine.

Reference: https://wiki.vmssoftware.com/DCL_CTLFLAGS

Volker.

[Stephen Hoffman]

I'd usually suggest reading the manuals.

Officially: "With OpenVMS Version 8.4, DCL commands and qualifiers have
been enhanced to support upto [sic] 16 parameters as command line input
with command procedures. For more details on DCL enhancements, see the
HPE OpenVMS Version 8.4 New Features and Documentation Overview guide."

Alas, the OpenVMS User's Guide lacks this particular DCL update. "These
symbols, named P1, P2, and so on through P8", " and... P7 = "" P8 = ""
but no P9, and "DCL places parameters passed to command procedures in
the local symbols P1 to P8.", etc. I also see DCL examples with the
INQUIRE command used, too. 🤮

Somebody (and I'm pretty sure I know who it was) did fix the @
documentation in the DCL Dictionary, not that most folks will know or
will remember that @ is documented there.
https://docs.vmssoftware.com/vsi-openvms-dcl-dictionary-a-m/

I'd expect there are some other gaps in the docs for the features added
in the V8 era.

The docs need some help. Some recipes are needed, too. VSI was working
on their version of DEC TIMA/STARS articles (many of which are
effectively recipes), and which will help those with support.

[Stephen Hoffman]

On 2023-01-01 16:03:05 +0000, Jan-Erik S derholm said:

> Is it a mixup between number of COM file parameters and number of
> sub-directoy levels?

I've definitely been known to be forgetful, and worse, but I'm pretty
sure DCL supports P1 to P16 as of OpenVMS V8.4 See the DCL dictionary
@ doc, and see my other recent reply here.

Also pretty sure the directory depths on ODS-5 now max out at 255, and
not 8 or 16. See the ODS-5/EFS doc: "There can be up to 255 levels of
directories. The name of each directory can be up to 236 8-bit or 118
16-bit characters long..."

From an earlier discussion of the DCL P1 to P16 parameter support:
https://groups.google.com/g/comp.os.vms/c/KjlzbRje4go/m/ab3NOE7ZDRoJ

Lots of old code around with old limits, and probably some old doc with
old limits, too.

[Arne Vajhøj]

On 1/1/2023 12:02 PM, Stephen Hoffman wrote:
> On 2023-01-01 15:52:57 +0000, Arne Vajh j said:
>
>> On 12/31/2022 7:07 PM, Stephen Hoffman wrote:
>>> On 2022-12-31 21:03:24 +0000, Arne Vajh j said:
>>>> .title  realp
>>
>>> Didn't review the code, definitely some things I'd do different,
>>
>> Probably also better. But ...
>>
>>> but it seems this code is expecting traditional (#8) and not extended
>>> (#16) parsing.
>>
>>  >>          cmpl    r2,#8                   ; while n <= 8
>>
>>  > #16
>>
>> This is interesting. One can get COM files to accept 16 parameters?
>> How?
>
> I'd usually suggest reading the manuals.

Fair enough.

But sometimes it is not easy to find the right place.

> Officially: "With OpenVMS Version 8.4, DCL commands and qualifiers have
> been enhanced to support upto [sic] 16 parameters as command line input
> with command procedures. For more details on DCL enhancements, see the
> HPE OpenVMS Version 8.4 New Features and Documentation Overview guide."
>
> Alas, the OpenVMS User's Guide lacks this particular DCL update. "These
> symbols, named P1, P2, and so on through P8", "  and... P7 = "" P8 = ""
> but no P9, and "DCL places parameters passed to command procedures in
> the local symbols P1 to P8.", etc.  I also see DCL examples with the
> INQUIRE command used, too. 🤮
>
> Somebody (and I'm pretty sure I know who it was) did fix the @
> documentation in the DCL Dictionary, not that most folks will know or
> will remember that @ is documented there.
> https://docs.vmssoftware.com/vsi-openvms-dcl-dictionary-a-m/

Yes. And it points to DCL_CTLFLAGS bit 3.

And that leads to:

https://wiki.vmssoftware.com/DCL_CTLFLAGS

So:

DCL_CTLFLAGS=8

in modparams.dat and autogen.

Maybe I will try it. Even though I don't really have a need
for 16 parameters.

Arne

[Robert A. Brooks]

On 1/1/2023 12:17 PM, Stephen Hoffman wrote:

> Lots of old code around with old limits, and probably some old doc with old
> limits, too.

CMS, even the version that was updated for ODS-5, still had a hardcoded limit
of 8 depths of directories.

That issue was fixed in some VSI CMS release.

--

--- Rob

[Arne Vajhøj]

So much to learn so little time.

I have a strong feeling that very few has set that bit.

Arne

[Stephen Hoffman]

On 2023-01-01 17:25:08 +0000, Arne Vajh j said:

> On 1/1/2023 12:02 PM, Stephen Hoffman wrote:
>>
>> I'd usually suggest reading the manuals.
>
> Fair enough.
>
> But sometimes it is not easy to find the right place.

The docs need help, yes. So too do the defaults.

>> ...

>> Somebody (and I'm pretty sure I know who it was) did fix the @
>> documentation in the DCL Dictionary, not that most folks will know or
>> will remember that @ is documented there.
>> https://docs.vmssoftware.com/vsi-openvms-dcl-dictionary-a-m/
>
> Yes. And it points to DCL_CTLFLAGS bit 3.

> ...

P9 to P16 should have been enabled by default, and disabled with
DCL_CTLFLAGS when or if that was needed.

Make the defaults better over time. Not worse.

Compatibility inevitably extracts its costs in complexity and confusion
and effort.

Look around. This DCL feature has been available for over a dozen
years. And few here even knew of its existence. That's a problem.

[Arne Vajhøj]

On 1/1/2023 12:54 PM, Stephen Hoffman wrote:
> On 2023-01-01 17:25:08 +0000, Arne Vajh j said:
>> On 1/1/2023 12:02 PM, Stephen Hoffman wrote:
>>> Somebody (and I'm pretty sure I know who it was) did fix the @
>>> documentation in the DCL Dictionary, not that most folks will know or
>>> will remember that @ is documented there.
>>> https://docs.vmssoftware.com/vsi-openvms-dcl-dictionary-a-m/
>>
>> Yes. And it points to DCL_CTLFLAGS bit 3.
>

> P9 to P16 should have been enabled by default, and disabled with
> DCL_CTLFLAGS when or if that was needed.
>
> Make the defaults better over time. Not worse.
>
> Compatibility inevitably extracts its costs in complexity and confusion
> and effort.
>
> Look around. This DCL feature has been available for over a dozen years.
> And few here even knew of its existence. That's a problem.

On the other hand then breaking compatibility also requires
a justification.

Who needs more than 8 parameters? Obviously someone
did since the feature was added, but it does not seem
like something many wants.

I think the most ugly part is making it a system
parameter.

I assume there are implementation reasons behind
it, but having made it a process supervisor mode
logical would have made it a bit more "accessible".

Arne

[Stephen Hoffman]

On 2023-01-01 17:26:59 +0000, Robert A. Brooks said:

> On 1/1/2023 12:17 PM, Stephen Hoffman wrote:
>
>> Lots of old code around with old limits, and probably some old doc with
>> old limits, too.
>
>
> CMS, even the version that was updated for ODS-5, still had a hardcoded
> limit of 8 depths of directories.

Ayup. Lots of my old code sorta-kinda tolerates ODS-5, but doesn't use
it, and doesn't allow its full use.

> That issue was fixed in some VSI CMS release.

Yes; for those using CMS, the VSI updates have fixed various issues. If
you're using CMS, get the latest VSI version.

I've wondered whether it was possible to bridge the CMS API into a
DVCS. Bridging into git might be trouble here given its
less-than-portable design, but there are other DVCS options. But
pragmatically, I'm usually using the DVCS elsewhere, and copying the
files to or from OpenVMS.

But I digress.

There are a number of other areas of APIs and apps with ODS-5 issues
and limits.

Most stuff just doesn't try using the full capabilities of ODS-5, and
thus kinda-sorta works.

For some common issues in code that anyone here is maintaining, scan
for 255-byte buffers and NAM$C_MAXRSS or similar references for
filename buffers, for just one area of issues. (NAML$C_MAXRSS is your
friend.) Same checks for any FH2DEF and for various NAMDEF references.
(OO APIs are just vastly easier here, too.)

I'd expect most user-written code that tries to parse a filename
locally—local parsing, without using the system APIs—is broken, too. As
an example of broken local-to-the-app parsing, PCSI mishandled < and >
for many years, and that's not even remotely new syntax.

[Stephen Hoffman]

On 2023-01-01 18:02:17 +0000, Arne Vajh j said:

> On the other hand then breaking compatibility also requires a justification.

Arguably, you have that backwards. But then, DEC arguably had that
backwards, too. The justification is required for keeping the old and
under- or un-maintained code around. Those sites are variously not
upgrading, and are not investing. And when or if they do upgrade, make
them set compatibility where and as needed. Make them aware of where
their code will break in the future too, when or if deprecation and
removal is planned. Let the under- or un-maintained sites LTS
themselves for a decade or so, and with best-effort support. And move
on.

Don't make things harder for updates and for new development. Both for
users, and for new VSI work. Shorter-term thinking, versus longer-term
thinking. Making user app updates harder and new user app work harder
is The Bad Place. For everybody.

And because I have to explicitly state this each time because nuance is
not expected or assumed, I am not suggesting breaking stuff without
very good reason. But if there are good reasons, break it, and provide
a path for existing apps and code to get there over the next ~decade.
Even Microsoft Windows breaks compatibility, on occasion.

And I've yet to see any existing DCL break with the advent of P9 to
P16. Outside of maybe some code that got Really Creative to work around
the lack of P9 to P16, that is. I have seen CSV-ified parameters,
passing arguments by file, passing by symbol and logical names, and
other uglies. But yes, DCL... has issues.

Whether VSI has the staff, the budget, and the development horizon for
longer-term investments and longer-term work? Operating systems are big
and complex and expensive, and products and services and expectations
are all evolving. The world of 1978 just doesn't exist any more.

[Craig A. Berry]

On 1/1/23 12:09 PM, Stephen Hoffman wrote:
> I've wondered whether it was possible to bridge the CMS API into a DVCS.
> Bridging into git might be trouble here given its less-than-portable
> design, but there are other DVCS options.

The following might be of interest, though your mention of the CMS API
perhaps indicates you were thinking of interacting with CMS in a way
that actually operates on a git repository under the hood.

https://github.com/nomadbyte/cms-export

http://www.vms2linux.de/cmsimport.html

[Johnny Billquist]

On 2023-01-01 19:02, Arne Vajhøj wrote:
> On 1/1/2023 12:54 PM, Stephen Hoffman wrote:
>> Compatibility inevitably extracts its costs in complexity and
>> confusion and effort.
>>
>> Look around. This DCL feature has been available for over a dozen
>> years. And few here even knew of its existence. That's a problem.
>
> On the other hand then breaking compatibility also requires
> a justification.

I would sortof agree with that.

> Who needs more than 8 parameters?  Obviously someone
> did since the feature was added, but it does not seem
> like something many wants.

I might be very rusty here, but isn't there a way to just get the whole
command line as well, as as such, if there are more than 8 parameters,
you could extract that anyway? Just a little bit of more coding required?

In RSX this is definitely the case anyway. P9 is actually everything
beyond the 8th parameter, so if you wanted the ninth, you'd go ahead and
parse it out from P9. And there is even a function available to do that
parsing for you. So no more than one additional line of code to get to
it. (There is also the COMMAN variable that holds the full command line.)

Johnny

[Arne Vajhøj]

I am not aware of any supported way of getting the command
line from DCL.

A program can get it via LIB$GET_FOREIGN.

Arne

[Dave Froble]

I have a strong feeling that you are correct ...

Frankly, while there may occasionally be some use for up to 16 arguments,
usually there are better methods for passing large amounts of data. My opinion,
for what it's worth ...


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

[Bill Gunshannon]

On 1/1/23 12:17, Stephen Hoffman wrote:
>
>
> Also pretty sure the directory depths on ODS-5 now max out at 255, and
> not 8 or 16. See the ODS-5/EFS doc: "There can be up to 255 levels of
> directories. The name of each directory can be up to 236 8-bit or 118
> 16-bit characters long..."
>

What happens if you try to exceed that limit? I remember someone doing
that on PRIMOS and the results were not pretty. :-)

bill

[Bill Gunshannon]

On 1/1/23 13:02, Arne Vajhøj wrote:
> On 1/1/2023 12:54 PM, Stephen Hoffman wrote:
>> On 2023-01-01 17:25:08 +0000, Arne Vajh j said:
>>> On 1/1/2023 12:02 PM, Stephen Hoffman wrote:
>>>> Somebody (and I'm pretty sure I know who it was) did fix the @
>>>> documentation in the DCL Dictionary, not that most folks will know
>>>> or will remember that @ is documented there.
>>>> https://docs.vmssoftware.com/vsi-openvms-dcl-dictionary-a-m/
>>>
>>> Yes. And it points to DCL_CTLFLAGS bit 3.
>>
>> P9 to P16 should have been enabled by default, and disabled with
>> DCL_CTLFLAGS when or if that was needed.
>>
>> Make the defaults better over time. Not worse.
>>
>> Compatibility inevitably extracts its costs in complexity and
>> confusion and effort.
>>
>> Look around. This DCL feature has been available for over a dozen
>> years. And few here even knew of its existence. That's a problem.
>
> On the other hand then breaking compatibility also requires
> a justification.

How would adding the ability to have 8 addition parameters break
anything?

>
> Who needs more than 8 parameters?  Obviously someone
> did since the feature was added, but it does not seem
> like something many wants.

Then don't use it. But allowing 16 won't break any code that only
uses 8 and it gives a capability someone might need or want.

bill

[alanfe...@gmail.com]

On Sunday, January 1, 2023 at 12:17:41 PM UTC-5, Stephen Hoffman wrote:
> On 2023-01-01 16:03:05 +0000, Jan-Erik S derholm said:
>

[...]
[...]

> --
> Pure Personal Opinion | HoffmanLabs LLC

On Alpha, starting with OpenVMS v7.2, you can have deep directories even on ODS-2 disks.

Ref. https://vmssoftware.com/docs/VSI_USERS_MANUAL.pdf p. 67
(Section 4.2)

Directory depth is definitely .gt. 8 on Alpha (EISNER)
$ CRE/DIR [.1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.0.1.2.3.4.5.6.7.8.9.0]

Command was run on an ODS-2 disk.

[Arne Vajhøj]

On 1/1/2023 4:31 PM, Bill Gunshannon wrote:
> On 1/1/23 13:02, Arne Vajhøj wrote:
>> On 1/1/2023 12:54 PM, Stephen Hoffman wrote:
>>> On 2023-01-01 17:25:08 +0000, Arne Vajh j said:
>>>> On 1/1/2023 12:02 PM, Stephen Hoffman wrote:
>>>>> Somebody (and I'm pretty sure I know who it was) did fix the @
>>>>> documentation in the DCL Dictionary, not that most folks will know
>>>>> or will remember that @ is documented there.
>>>>> https://docs.vmssoftware.com/vsi-openvms-dcl-dictionary-a-m/
>>>>
>>>> Yes. And it points to DCL_CTLFLAGS bit 3.
>>>
>>> P9 to P16 should have been enabled by default, and disabled with
>>> DCL_CTLFLAGS when or if that was needed.
>>>
>>> Make the defaults better over time. Not worse.
>>>
>>> Compatibility inevitably extracts its costs in complexity and
>>> confusion and effort.
>>>
>>> Look around. This DCL feature has been available for over a dozen
>>> years. And few here even knew of its existence. That's a problem.
>>
>> On the other hand then breaking compatibility also requires
>> a justification.
>
> How would adding the ability to have 8 addition parameters break
> anything?

In practice it probably won't bother the vast majority.

But at least in theory the symbols P9..P16 could be
used for something else.

Like a foreign command.

There is a lot of weird stuff out there.

https://xkcd.com/1172/

>> Who needs more than 8 parameters?  Obviously someone
>> did since the feature was added, but it does not seem
>> like something many wants.
>
> Then don't use it.  But allowing 16 won't break any code that only
> uses 8 and it gives a capability someone might need or want.

See above.

Arne

[Phillip Helbig (undress to reply)]

In article <tosfqf$gvu$2...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=

<ar...@vajhoej.dk> writes:

> I have a strong feeling that very few has set that bit.

I know some who have need of it and have set it.

What is your value of MAIL$SYSTEM_FLAGS? :-)

[cao...@pitbulluk.org]

On Wednesday, December 28, 2022 at 4:45:45 PM UTC, Arne Vajhøj wrote:
> $ type z.com
> $ write sys$output "''p1'"
> $ @z a
> A
> $ @z "a"
> a
>
> This is not really surprising.

>
> But are there any way to preserve pn case without
> double-quoting it?
>

> Like this hypothetical syntax:
>
> $ set proc/parse=(extended,pnkeepcase)
>
> Arne

Taking z.com, for really simple single-parameter stuff, we used to:

$ z == "@z """ (that's three double-quotes at the end)
then
$ z fff aaa bbb
fff aaa bbb

K

[Phillip Helbig (undress to reply)]

Which makes use of the undocumented "feature" that one can sometimes
leave off the trailing double-quote.

[Simon Clubley]

On 2023-01-03, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>
> Which makes use of the undocumented "feature" that one can sometimes
> leave off the trailing double-quote.
>

What DCL _really_ needs is:

$ set dcl/mode=bash

:-)

Simon.

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

[DeanW]

On Tue, Jan 3, 2023 at 10:30 AM Simon Clubley via Info-vax <
info...@rbnsn.com> wrote:

> On 2023-01-03, Phillip Helbig (undress to reply) <
> hel...@asclothestro.multivax.de> wrote:
> >
> > Which makes use of the undocumented "feature" that one can sometimes
> > leave off the trailing double-quote.
> >
>
> What DCL _really_ needs is:
>
> $ set dcl/mode=bash
>
> :-)
>

Only if I can also

$ export bash_mode="DCL"

--
Dean Woodward =o&o
dean.w...@gmail.com

[Arne Vajhøj]

On 1/3/2023 6:28 AM, cao...@pitbulluk.org wrote:
> On Wednesday, December 28, 2022 at 4:45:45 PM UTC, Arne Vajhøj wrote:
>> $ type z.com
>> $ write sys$output "''p1'"
>> $ @z a
>> A
>> $ @z "a"
>> a
>>
>> This is not really surprising.
>>
>> But are there any way to preserve pn case without
>> double-quoting it?
>>
>> Like this hypothetical syntax:
>>
>> $ set proc/parse=(extended,pnkeepcase)
>

> Taking z.com, for really simple single-parameter stuff, we used to:
>
> $ z == "@z """ (that's three double-quotes at the end)
> then
> $ z fff aaa bbb
> fff aaa bbb

That is pretty clever.

But I do get an extra space first in the value and
everything go in P1 despite any spaces.

Arne

[cao...@pitbulluk.org]

Yeah, it's not perfect. We had a TELL command with the syntax TELL <userID> <message> to allow ordinary users to broadcast a one-liner to the specified user. It was done using a server which could handle the server-to-server details when the userID included a DECnet node name. For a conversation, most users would define a symbol, like z to preserve the case of the message when in heated one-liners with others, otherwise you would have to:
$ tell bloggs "Stop hogging the CPU!"

K