On 2023-01-01 17:25:08 +0000, Arne Vajhj 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.

--
Pure Personal Opinion | HoffmanLabs LLC

On 1/1/2023 12:54 PM, Stephen Hoffman wrote:
> On 2023-01-01 17:25:08 +0000, Arne Vajhj 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

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.

--
Pure Personal Opinion | HoffmanLabs LLC

On 2023-01-01 18:02:17 +0000, Arne Vajhj 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.

--
Pure Personal Opinion | HoffmanLabs LLC

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

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

On 1/1/2023 2:59 PM, Johnny Billquist wrote:
> On 2023-01-01 19:02, Arne Vajhøj wrote:
>> 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.)

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

On 1/1/2023 12:27 PM, Arne Vajhøj wrote:
> On 1/1/2023 11:29 AM, Volker Halle wrote:
>>>> 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
>
> So much to learn so little time.
>
> I have a strong feeling that very few has set that bit.

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: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

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

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

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.

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

In article <tosfqf$gvu$2@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=
<arne@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? :-)

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

In article <80b26bd3-9e9a-4b1c-9556-0b64648b4ef0n@googlegroups.com>, "cao...@pitbulluk.org" <caoimhe@pitbulluk.org> writes:
> 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

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

On 2023-01-03, Phillip Helbig (undress to reply) <helbig@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.

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

On Thursday, January 5, 2023 at 1:51:06 AM UTC, Arne Vajhøj wrote:
> 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

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