Suggested DCL enhancement

[Simon Clubley]

Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.

For example, typing:

$ show device <Ctrl-P>

where <Ctrl-P> is the control character, would result in a list of all
the qualifiers (along with any optional arguments to the qualifiers)
that can be used at that point. The CLD format could also be enhanced
with a single-line help text per qualifier that would also be displayed
as part of the output.

The output would also show that a parameter, labeled as (for example)
"Device_Name", could be supplied at this point as well.

Likewise, typing:

$ show d<Ctrl-P>

(with no space between the "d" and the Ctrl-P) would show all the valid
options beginning with "d" at that point.

Any comments ?

Simon.

[Andy Burns]

Post by Simon Clubley
$ show device <Ctrl-P>
Any comments ?

Just don't type it on the console (of certain machines).

[Simon Clubley]

Post by Andy Burns

Post by Simon Clubley
$ show device <Ctrl-P>
Any comments ?

Just don't type it on the console (of certain machines).

You lot are a bunch of sarky devils. :-)

The Ctrl-P was just an example placeholder character. I did realise
shortly after posting however the other use of Ctrl-P and did wonder
if someone would comment on it.

Nice to see you lot did not disappoint. :-)

So now you have all had your fun, what do you think of the idea itself ?

Simon.

[Andy Burns]

I did realise shortly after posting however the other use of Ctrl-P
and did wonder if someone would comment on it.

I think ~25 years are sufficient delay that a story can be told ...

I went down to London to install our product for Texaco (on a cluster of
VAX 8800s as I recall) they didn't have a desk available for me to work
from, so asked If I minded working on the console in the server room, no
problem.

We only had lowly uVAX 3100s for our develop/test systems, and those
don't use ctrl-P, but I was aware of it on bigger machines, however it
took me a few seconds to wonder why my session had ground to a halt, and
by the time I realised and tried to type "C" the dreaded CNXMAN cluster
state transition messages started scrolling by ... sorry ALL-IN-1 users.

[Bob Eager]

Post by Simon Clubley
So now you have all had your fun, what do you think of the idea itself ?

I think it works well. I did a pretty identical thing on a homebrew
operating system for which I wrote the CLI in 1976 (on a PDP-11).

And there are many similar systems in CLIs all over the place. Useful.

[Dave Froble]

Post by Simon Clubley

Post by Andy Burns

Post by Simon Clubley
$ show device <Ctrl-P>
Any comments ?

Just don't type it on the console (of certain machines).

You lot are a bunch of sarky devils. :-)
The Ctrl-P was just an example placeholder character. I did realise
shortly after posting however the other use of Ctrl-P and did wonder
if someone would comment on it.
Nice to see you lot did not disappoint. :-)
So now you have all had your fun, what do you think of the idea itself ?
Simon.

What's the cost?

The way I look at it, VMS is an OS for getting things done, not some
"desktop" (for lack of another term) system that caters to the user.

So, what would be the cost of completion, help, and things like that.
When I use the word "cost", I'm looking at overhead, not dollars.

I'm figuring there would be significant compute and other resource
overhead for such things, along with significant development efforts.

[Arne Vajhøj]

Post by Dave Froble

Post by Simon Clubley

Post by Andy Burns

    $ show device <Ctrl-P>
Any comments ?

Just don't type it on the console (of certain machines).

You lot are a bunch of sarky devils. :-)
The Ctrl-P was just an example placeholder character. I did realise
shortly after posting however the other use of Ctrl-P and did wonder
if someone would comment on it.
Nice to see you lot did not disappoint. :-)
So now you have all had your fun, what do you think of the idea itself ?

What's the cost?
The way I look at it, VMS is an OS for getting things done, not some
"desktop" (for lack of another term) system that caters to the user.
So, what would be the cost of completion, help, and things like that.
When I use the word "cost", I'm looking at overhead, not dollars.
I'm figuring there would be significant compute and other resource
overhead for such things, along with significant development efforts.

Given how VMS is used today (practically no end users working at the DCL
prompt), then such enhancements would be very hard to justify.

VSI is not going to sell more VMS licenses by adding
such enhancements.

No customer will switch to VMS or drop switching from VMS, because
of such enhancements.

Arne

[Phillip Helbig (undress to reply)]

Post by Arne Vajhøj
Given how VMS is used today (practically no end users working at the DCL
prompt),

How do you know?

[Jan-Erik Söderholm]

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj
Given how VMS is used today (practically no end users working at the DCL
prompt),

How do you know?

General knowledge regarding the OpenVMS market, maybe?
Apart from some system managers, there are probably very
few and close to none end-users on DCL today.

Hobbyists and small shops not on support does not count,
as usual.

[Phillip Helbig (undress to reply)]

Post by Jan-Erik Söderholm

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj
Given how VMS is used today (practically no end users working at the DCL
prompt),

How do you know?

General knowledge regarding the OpenVMS market, maybe?
Apart from some system managers, there are probably very
few and close to none end-users on DCL today.

I don't know. There are not just system managers but people who manage
applications, developers, testers, all working at the DCL prompt. It's
not THAT uncommon.

[Arne Vajhøj]

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj
Given how VMS is used today (practically no end users working at the DCL
prompt),

How do you know?

Terminal and command line are not for end users today. Not on
VMS. Not on any other server OS.

Arne

[Phillip Helbig (undress to reply)]

Post by Arne Vajhøj

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj
Given how VMS is used today (practically no end users working at the DCL
prompt),

How do you know?

Terminal and command line are not for end users today. Not on
VMS. Not on any other server OS.

That depends on the definition of "end user". Of course, if "end user"
is defined as someone who doesn't use the command line, or excludes
developers, then it's a tautology. There are certainly people (how
many, I don't know) who do no system management at all and who are not
developers but who work at the command line.

[Arne Vajhøj]

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj
Given how VMS is used today (practically no end users working at the DCL
prompt),

How do you know?

Terminal and command line are not for end users today. Not on
VMS. Not on any other server OS.

That depends on the definition of "end user". Of course, if "end user"
is defined as someone who doesn't use the command line, or excludes
developers, then it's a tautology. There are certainly people (how
many, I don't know) who do no system management at all and who are not
developers but who work at the command line.

Traditional division is:
* system managers - they people taking care of the system
* developers - the people creating the applications to run on the system
* end users - the people using the applications to do whatever the
purpose of the system is

Arne

[Phillip Helbig (undress to reply)]

Post by Arne Vajhøj

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj
Terminal and command line are not for end users today. Not on
VMS. Not on any other server OS.

That depends on the definition of "end user". Of course, if "end user"
is defined as someone who doesn't use the command line, or excludes
developers, then it's a tautology. There are certainly people (how
many, I don't know) who do no system management at all and who are not
developers but who work at the command line.

* system managers - they people taking care of the system
* developers - the people creating the applications to run on the system
* end users - the people using the applications to do whatever the
purpose of the system is

Right, but who installs the application (no, no DEVOPS stuff), does
trouble-shooting, makes backups (say, of the database, not VMS BACKUP),
archives log files, and so on? I know many people who do that. What
about Jan-Erik? Isn't he like that (i.e. neither end-user, nor
developer, nor system manager, at least not mainly)?

[Arne Vajhøj]

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj
Terminal and command line are not for end users today. Not on
VMS. Not on any other server OS.

That depends on the definition of "end user". Of course, if "end user"
is defined as someone who doesn't use the command line, or excludes
developers, then it's a tautology. There are certainly people (how
many, I don't know) who do no system management at all and who are not
developers but who work at the command line.

* system managers - they people taking care of the system
* developers - the people creating the applications to run on the system
* end users - the people using the applications to do whatever the
purpose of the system is

Right, but who installs the application (no, no DEVOPS stuff), does
trouble-shooting, makes backups (say, of the database, not VMS BACKUP),
archives log files, and so on?

The system manager.

Post by Phillip Helbig (undress to reply)
I know many people who do that.

Possible.

But try to look at the big picture. Company. City. Country.

It will be:

number system managers < number of developers < number of end users

Arne

[Phillip Helbig (undress to reply)]

Post by Arne Vajhøj

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj
* system managers - they people taking care of the system
* developers - the people creating the applications to run on the system
* end users - the people using the applications to do whatever the
purpose of the system is

Right, but who installs the application (no, no DEVOPS stuff), does
trouble-shooting, makes backups (say, of the database, not VMS BACKUP),
archives log files, and so on?

The system manager.

Sometimes that is a VERY different role, i.e. a system manager with
experience elsewhere could easily take it over, whereas the other job
requires a knowledge of the applications, of third-party software, and
so on.

Post by Arne Vajhøj

Post by Phillip Helbig (undress to reply)
I know many people who do that.

Possible.
But try to look at the big picture. Company. City. Country.
number system managers < number of developers < number of end users

I think that the answer is "it depends" There are definitely places
with about 100 developers, about 5 system managers, about 30
"application support people", and maybe about 30 end users. There are
people here who have never worked on a standalone VMS system, others who
have never worked on a cluster.

[Dave Froble]

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj
Given how VMS is used today (practically no end users working at the DCL
prompt),

How do you know?

End users (the definition could be vague) run apps, not operating
systems. DCL is a method of communicating with the OS.

[Phillip Helbig (undress to reply)]

Post by Dave Froble

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj
Given how VMS is used today (practically no end users working at the DCL
prompt),

How do you know?

End users (the definition could be vague) run apps, not operating
systems. DCL is a method of communicating with the OS.

OK, but the point was that hardly anyone works at the prompt, when there
are people who do so, who are neither end-users, nor system managers,
nor developers.

[Stephen Hoffman]

Post by Phillip Helbig (undress to reply)

Post by Dave Froble

Post by Phillip Helbig (undress to reply)

Post by Arne Vajhøj
Given how VMS is used today (practically no end users working at the
DCL prompt),

How do you know?

End users (the definition could be vague) run apps, not operating
systems. DCL is a method of communicating with the OS.

OK, but the point was that hardly anyone works at the prompt, when
there are people who do so, who are neither end-users, nor system
managers, nor developers.

Hardly anyone is working at the command line.

Pretty much everybody here is using the command line.

Most app-using folks are either running GUI apps, or web-based apps, or
running "canned" command-line apps.

With OpenVMS, command-line usage is necessary for app developers, for
system administration, for those troubleshooting, and for networking
folks, too.

Which isn't very many folks.

That list of command-line users is not a big number of users in
comparison with the numbers of app-using folks around, whether OpenVMS,
or in computing generally.

And edit-compile-link-debug usage is generally fading, too.

Though that list of folks is ~all of the folks posting here.

IDE usage and management UI usage and app user interface designs are
all shifting developers and administrators and networking folks and
end-users away from the command-line, too.

Ponder:
Loading Image...

[John E. Malmberg]

IDE usage and management UI usage and app user interface designs are all
shifting developers and administrators and networking folks and
end-users away from the command-line, too.

I have been doing devops on and QA automation on Linux and windows for a
while now, and I can assure you that it command line is the dominant
method used for actually getting stuff configured and doing functional
tests.

GUIs are find for end users at admins that have to deal with a few
systems, but when a small collection of systems to manage is at least
100, anything requiring or using a GUI is PITA. And I have been
routinely dealing with much higher numbers of systems.

Much of GUI testing is running the system in a "Dead Rodent Mode" from a
command line session and if needed scanning a screen shot to validate
that the requested operation succeeded.

All the linux systems that I am involved with are serial console only.
The only time a monitor is connected to them is when a crash cart
needs to be connected.

Quite a bit of Microsoft Windows automation and Android automation is
command line based. Tools like SikuliX are fall backs for when that is
the only method available.

Cygwin along with Samba is still heavily used for Windows automation
because it is easier to automate the setup and install on new system
than remote powershell, especially on older versions of Microsoft Windows.

While the end user may see a GUI, where the work actually gets done or
troubleshooting gets done is usually on the command line.

I don't see that changing any time soon. Only the newest server
systems have a remote KVM included in the BIOS, and again, that is only
used when we can not get into the system any other way.

What is heavily used is one of in no particular order, Ansible, Chef,
Puppet, etc., as configuration control methods. And these all are
wrappers for command line access.

If you are designing a system or application to be managed with a GUI
instead of those methods, you are going to be hurting your market share.

Regards,
-John
***@qsl.net_work

[Stephen Hoffman]

Post by John E. Malmberg

Post by Stephen Hoffman
IDE usage and management UI usage and app user interface designs are
all shifting developers and administrators and networking folks and
end-users away from the command-line, too.

I have been doing devops on and QA automation on Linux and windows for
a while now, and I can assure you that it command line is the dominant
method used for actually getting stuff configured and doing functional
tests.
GUIs are find for end users at admins that have to deal with a few
systems, but when a small collection of systems to manage is at least
100, anything requiring or using a GUI is PITA. And I have been
routinely dealing with much higher numbers of systems.
...
If you are designing a system or application to be managed with a GUI
instead of those methods, you are going to be hurting your market share.

What's the general trend? More command line? Or toward more automation
and simpler interfaces?

All of what I'm seeing is trending toward GUI, toward web-managed
interfaces, toward simpler, and toward automation.

Yes, with command-line underneath.

[Craig A. Berry]

Post by Stephen Hoffman

Post by John E. Malmberg

Post by Stephen Hoffman
IDE usage and management UI usage and app user interface designs are
all shifting developers and administrators and networking folks and
end-users away from the command-line, too.

I have been doing devops on and QA automation on Linux and windows for
a while now, and I can assure you that it command line is the dominant
method used for actually getting stuff configured and doing functional
tests.
GUIs are find for end users at admins that have to deal with a few
systems, but when a small collection of systems to manage is at least
100, anything requiring or using a GUI is PITA.   And I have been
routinely dealing with much higher numbers of systems.
...
If you are designing a system or application to be managed with a GUI
instead of those methods, you are going to be hurting your market share.

What's the general trend? More command line? Or toward more automation
and simpler interfaces?
All of what I'm seeing is trending toward GUI, toward web-managed
interfaces, toward simpler, and toward automation.

The general trend for server management, devops, and, to a lesser extent
even development is definitely away from the GUI and back to the command
line. Witness, for example, Microsoft Server Core,[1] which is Windows
Server with no "Desktop Experience," or, in other words, Windows with no
windows.

The whole devops movement is based on the premise that automating
operations is just another kind of code to write and developers already
know how to do that. That code consists of commands written in various
CLIs.

Development tools and frameworks increasingly promote and even rely on
commands typed in terminal or PowerShell windows integrated into the
IDE, though code editing is still generally done in a GUI editor.

I find all this ironic after a few decades of trying to convince junior
developers to use the command line and generally being greeted with
terror and confusion. But the command line is definitely back.


[1]
<https://docs.microsoft.com/en-us/windows-server/administration/server-core/what-is-server-core>

[Stephen Hoffman]

Post by Craig A. Berry

Post by Stephen Hoffman

Post by John E. Malmberg
...
If you are designing a system or application to be managed with a GUI
instead of those methods, you are going to be hurting your market share.

What's the general trend? More command line? Or toward more automation
and simpler interfaces?
All of what I'm seeing is trending toward GUI, toward web-managed
interfaces, toward simpler, and toward automation.

The general trend for server management, devops, and, to a lesser
extent even development is definitely away from the GUI and back to the
command line.

I am exceedingly skeptical that command line interaction is the future.
As a stopgap, yes.

I'm seeing an approach similar to FILEVIEW on OpenVMS DECwindows, or a
web GUI for various hosting providers, where somebody scripts
something, and then that script is callable from or triggered by a
controller app or by a user at a remote GUI.

All of what I'm seeing is headed away from the command line, save for
those folks creating the apps.

Which is most of the folks responding here.

[Arne Vajhøj]

Post by Stephen Hoffman

Post by Craig A. Berry

Post by Stephen Hoffman

Post by John E. Malmberg
...
If you are designing a system or application to be managed with a
GUI instead of those methods, you are going to be hurting your
market share.

What's the general trend? More command line? Or toward more
automation and simpler interfaces?
All of what I'm seeing is trending toward GUI, toward web-managed
interfaces, toward simpler, and toward automation.

The general trend for server management, devops, and, to a lesser
extent even development is definitely away from the GUI and back to
the command line.

I am exceedingly skeptical that command line interaction is the future.
As a stopgap, yes.
I'm seeing an approach similar to FILEVIEW on OpenVMS DECwindows, or a
web GUI for various hosting providers, where somebody scripts something,
and then that script is callable from or triggered by a controller app
or by a user at a remote GUI.

Traditional GUI where the actual actions are done once on the GUI
are not an option today due to the time waste and the lack of
repeatability.

Interactive (non-script) CLI has the same problems.

What is needed today is scripts and a CLI that can
execute them.

Whether the language is bash or perl or python or
something proprietary is less important.

And whether the scripts are sftp'ed up and executed in a ssh
session or run from a fancy GUI where one pick the script
and the target is also less important.

The server does not need a GUI - it only needs a CLI to
execute the scripts.

The work computer of the guy writing the scripts may
benefit from various GUI tools.

Arne

[Bill Gunshannon]

Post by Craig A. Berry

Post by Stephen Hoffman

Post by John E. Malmberg

Post by Stephen Hoffman
IDE usage and management UI usage and app user interface designs are
all shifting developers and administrators and networking folks and
end-users away from the command-line, too.

I have been doing devops on and QA automation on Linux and windows
for a while now, and I can assure you that it command line is the
dominant method used for actually getting stuff configured and doing
functional tests.
GUIs are find for end users at admins that have to deal with a few
systems, but when a small collection of systems to manage is at least
100, anything requiring or using a GUI is PITA.   And I have been
routinely dealing with much higher numbers of systems.
...
If you are designing a system or application to be managed with a GUI
instead of those methods, you are going to be hurting your market share.

What's the general trend? More command line? Or toward more automation
and simpler interfaces?
All of what I'm seeing is trending toward GUI, toward web-managed
interfaces, toward simpler, and toward automation.

The general trend for server management, devops, and, to a lesser extent
even development is definitely away from the GUI and back to the command
line.  Witness, for example, Microsoft Server Core,[1] which is Windows
Server with no "Desktop Experience," or, in other words, Windows with no
windows.

Are you sure about that? Are you sure the intent isn't just Remote
Desktop using RDP? It's how I ran my datacenter even when Windows
Server still had a GUI presented.

Post by Craig A. Berry
The whole devops movement is based on the premise that automating
operations is just another kind of code to write and developers already
know how to do that.  That code consists of commands written in various
CLIs.

The biggest reason I ever found for using CLIs was the shortcomings
of GUI based tools. For example, do you know how much of Cisco's
capabilities can not even be done if you use the web based GUI?

Post by Craig A. Berry
Development tools and frameworks increasingly promote and even rely on
commands typed in terminal or PowerShell windows integrated into the
IDE, though code editing is still generally done in a GUI editor.
I find all this ironic after a few decades of trying to convince junior
developers to use the command line and generally being greeted with
terror and confusion.  But the command line is definitely back.

I don't see that as likely, but it will remain the bastion of
dinosaurs like me.

bill

[Craig A. Berry]

Post by Craig A. Berry

Post by Stephen Hoffman

Post by John E. Malmberg

Post by Stephen Hoffman
IDE usage and management UI usage and app user interface designs
are all shifting developers and administrators and networking folks
and end-users away from the command-line, too.

I have been doing devops on and QA automation on Linux and windows
for a while now, and I can assure you that it command line is the
dominant method used for actually getting stuff configured and doing
functional tests.
GUIs are find for end users at admins that have to deal with a few
systems, but when a small collection of systems to manage is at
least 100, anything requiring or using a GUI is PITA.   And I have
been routinely dealing with much higher numbers of systems.
...
If you are designing a system or application to be managed with a
GUI instead of those methods, you are going to be hurting your
market share.

What's the general trend? More command line? Or toward more
automation and simpler interfaces?
All of what I'm seeing is trending toward GUI, toward web-managed
interfaces, toward simpler, and toward automation.

The general trend for server management, devops, and, to a lesser extent
even development is definitely away from the GUI and back to the command
line.  Witness, for example, Microsoft Server Core,[1] which is Windows
Server with no "Desktop Experience," or, in other words, Windows with no
windows.

Are you sure about that?  Are you sure the intent isn't just Remote
Desktop using RDP?  It's how I ran my datacenter even when Windows
Server still had a GUI presented.

You snipped the link I provided that explained it all in detail. Remote
management using GUI tools that run on the remote system is one of the
options, at least for some features. There are very few GUI tools
available locally. There is no WordPad or Windows Explorer, for example.

Post by Craig A. Berry
Development tools and frameworks increasingly promote and even rely on
commands typed in terminal or PowerShell windows integrated into the
IDE, though code editing is still generally done in a GUI editor.
I find all this ironic after a few decades of trying to convince junior
developers to use the command line and generally being greeted with
terror and confusion.  But the command line is definitely back.

I don't see that as likely, but it will remain the bastion of
dinosaurs like me.

It's already happened. For example, Angular, one of the two biggest web
frameworks, heavily pushes the use of angular-cli, a set of command-line
utilities for managing various aspects of an Angular project. It's in
all the documentation, blogs, training videos, and books; all of the
leaders in the Angular community seem to emphasize that if you want to
be adept with Angular, you need to be familiar with the CLI.

[Bill Gunshannon]

Post by Craig A. Berry

Post by Stephen Hoffman

Post by John E. Malmberg

Post by Stephen Hoffman
IDE usage and management UI usage and app user interface designs
are all shifting developers and administrators and networking
folks and end-users away from the command-line, too.

I have been doing devops on and QA automation on Linux and windows
for a while now, and I can assure you that it command line is the
dominant method used for actually getting stuff configured and
doing functional tests.
GUIs are find for end users at admins that have to deal with a few
systems, but when a small collection of systems to manage is at
least 100, anything requiring or using a GUI is PITA.   And I have
been routinely dealing with much higher numbers of systems.
...
If you are designing a system or application to be managed with a
GUI instead of those methods, you are going to be hurting your
market share.

What's the general trend? More command line? Or toward more
automation and simpler interfaces?
All of what I'm seeing is trending toward GUI, toward web-managed
interfaces, toward simpler, and toward automation.

The general trend for server management, devops, and, to a lesser extent
even development is definitely away from the GUI and back to the command
line.  Witness, for example, Microsoft Server Core,[1] which is Windows
Server with no "Desktop Experience," or, in other words, Windows with no
windows.

Are you sure about that?  Are you sure the intent isn't just Remote
Desktop using RDP?  It's how I ran my datacenter even when Windows
Server still had a GUI presented.

You snipped the link I provided that explained it all in detail.  Remote
management using GUI tools that run on the remote system is one of the
options, at least for some features.  There are very few GUI tools
available locally.  There is no WordPad or Windows Explorer, for example.

Sorry, I was just addressing your comment. And, it appears I was right.
This isn't so much CLI vs. GUI as it is "lights Out
Datacenters".

bill

[Phillip Helbig (undress to reply)]

Post by Stephen Hoffman
What's the general trend? More command line? Or toward more automation
and simpler interfaces?

What about command line AND more automation and simpler interfaces? :-|

[David Jones]

Post by Stephen Hoffman
What's the general trend? More command line? Or toward more automation
and simpler interfaces?

What about command line AND more automation and simpler interfaces? :-|

Is voice command closer to command line or GUI?

[Jiří Kašpar]

Post by David Jones

Post by Stephen Hoffman
What's the general trend? More command line? Or toward more automation
and simpler interfaces?

What about command line AND more automation and simpler interfaces? :-|

Is voice command closer to command line or GUI?

And how about telepathic interface ?

[Stephen Hoffman]

Post by Phillip Helbig (undress to reply)

Post by Stephen Hoffman
What's the general trend? More command line? Or toward more automation
and simpler interfaces?

What about command line AND more automation and simpler interfaces? :-|

The majority of OpenVMS configuration and setup—prolly 75%—is rank and
utter and complete manure, needless complexity, developers on too-short
schedules with insufficient UI remediation and refactoring, with the
usual dollops of compatibility hindered by archaic hardware and
software limitations, and a legacy of trade-offs. By this I mean the
majority of the OpenVMS install and configuration prompts should have
been automated long ago. Defaults and default behaviors established.
I'd be embarrassed to ship the current OpenVMS clustering setup
mechanisms now, and the TCP/IP Services networking configuration spends
a bazillion prompts on meaningless or automatable choices that have
been inexplicably preserved and which then lead to varying network and
UIC and username configurations which then leads to more documentation
and more scripting, the majority if not the whole of the script-driven
startup processing needs to be gone, and the list goes on from there.
(But then some of that morass also ties back to the
non-integrated-networking operating system design approach, and of
which OpenVMS is among the last adherents.)

OpenVMS has to get better about installation and remote management, as
the current schemes just don't work well for hosted and remote hardware.

For app-related scripting, sure, whatever the app designers expect of
their users. Whether that's command-line, or app-related scripting.
And yes, OpenVMS system and OpenVMS-provided app scripting is stuck
decades back, too.

But then again, I really don't think we're headed for more command line
interfaces and tools as the UI, save where the existing tools force
that. It's just not the long-term trend that we're on in this business.

[Phillip Helbig (undress to reply)]

The majority of OpenVMS configuration and setup---prolly 75%---is rank and
utter and complete manure, needless complexity, developers on too-short
schedules with insufficient UI remediation and refactoring, with the
usual dollops of compatibility hindered by archaic hardware and
software limitations, and a legacy of trade-offs.

Yes; I was referring to modern stuff, ansible and so on, which appears
to be mostly command line.

[Simon Clubley]

Post by Dave Froble
I'm figuring there would be significant compute and other resource
overhead for such things, along with significant development efforts.

Why ?

There's no run-time cost until you press the triggering character.

Once triggered, everything you need for the output is in the command
definition.

DCL already has a parser to determine if what the user typed is valid
after they press return. It just needs extending to report the valid
options and keywords at that point in the user's input when the triggering
character is pressed.

Simon.

[Dave Froble]

Post by Simon Clubley

Post by Dave Froble
I'm figuring there would be significant compute and other resource
overhead for such things, along with significant development efforts.

Why ?
There's no run-time cost until you press the triggering character.

There is no run-time until one powers up a system. So what?
There is no run-time cost until some application is invoked.
Would you agree that using ^T causes some compute effort?

Post by Simon Clubley
Once triggered, everything you need for the output is in the command
definition.

That takes CPU cycles, and perhaps other things, which are then no
longer available to whatever job(s) the system is working on.

Post by Simon Clubley
DCL already has a parser to determine if what the user typed is valid
after they press return. It just needs extending to report the valid
options and keywords at that point in the user's input when the triggering
character is pressed.

Since the capability does not now exist, implementing it will take
developer time. Time perhaps best spent on other than allowing you to
play around with DCL and such.

[Simon Clubley]

Post by Dave Froble

Post by Simon Clubley

Post by Dave Froble
I'm figuring there would be significant compute and other resource
overhead for such things, along with significant development efforts.

Why ?
There's no run-time cost until you press the triggering character.

There is no run-time until one powers up a system. So what?
There is no run-time cost until some application is invoked.
Would you agree that using ^T causes some compute effort?

You were the one talking about overheads. There are no run-time overheads
worth measuring.

Post by Dave Froble

Post by Simon Clubley
Once triggered, everything you need for the output is in the command
definition.

That takes CPU cycles, and perhaps other things, which are then no
longer available to whatever job(s) the system is working on.

Seriously, David ???

Simon.

[Ian Miller]

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.
$ show device <Ctrl-P>
where <Ctrl-P> is the control character, would result in a list of all
the qualifiers (along with any optional arguments to the qualifiers)
that can be used at that point. The CLD format could also be enhanced
with a single-line help text per qualifier that would also be displayed
as part of the output.
The output would also show that a parameter, labeled as (for example)
"Device_Name", could be supplied at this point as well.
$ show d<Ctrl-P>
(with no space between the "d" and the Ctrl-P) would show all the valid
options beginning with "d" at that point.
Any comments ?
Simon.
--
Walking destinations on a map are further away than they appear.

interesting idea. Would use just the DCL table that DCL has already loaded. Obviously control P is not the right character to use due to prior use on certain consoles including current Itanium servers.

[Phillip Helbig (undress to reply)]

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.
$ show device <Ctrl-P>
where <Ctrl-P> is the control character, would result in a list of all
the qualifiers (along with any optional arguments to the qualifiers)
that can be used at that point. The CLD format could also be enhanced
with a single-line help text per qualifier that would also be displayed
as part of the output.
The output would also show that a parameter, labeled as (for example)
"Device_Name", could be supplied at this point as well.
$ show d<Ctrl-P>
(with no space between the "d" and the Ctrl-P) would show all the valid
options beginning with "d" at that point.
Any comments ?

Don't use Ctrl-P since that takes you to the console. :-)

[Stephen Hoffman]

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character
that when typed causes DCL to dump all the valid options or keywords
available at that point by reading from the CLD.
$ show device <Ctrl-P>
where <Ctrl-P> is the control character, would result in a list of all
the qualifiers (along with any optional arguments to the qualifiers)...
...
Any comments ?

^P? Yeah. As was mentioned: don't try that on some of the OPA0:
consoles. 😳😱🤬🤯

As a workaround for that CLD-dumping function, I use the VERB utility.

How this mechanism might differentiate documented from undocumented
qualifiers—yes, there are undocumented qualifiers—is fodder for another
discussion or three.

Closest analog now available is backspacing and inserting HELP. ^H
HELP on OpenVMS, and ^A man with various shells. Obviously.

[Simon Clubley]

Post by Stephen Hoffman
How this mechanism might differentiate documented from undocumented
qualifiers?yes, there are undocumented qualifiers?is fodder for another
discussion or three.

If it's in the command definition, it's documented as far as my suggestion
is concerned and it would show up in the output if eligible to be used at
that point.

Since VERB became available, anything in a command definition should now
be considered to be public knowledge. Sticking something sensitive in the
command definition and hoping someone does not find it is not exactly a
viable long-term strategy.

Simon.

[Stephen Hoffman]

Post by Simon Clubley

Post by Stephen Hoffman
How this mechanism might differentiate documented from undocumented
qualifiers—yes, there are undocumented qualifiers—is fodder for another
discussion or three.

If it's in the command definition, it's documented as far as my
suggestion is concerned and it would show up in the output if eligible
to be used at that point.
Since VERB became available, anything in a command definition should
now be considered to be public knowledge. Sticking something sensitive
in the command definition and hoping someone does not find it is not
exactly a viable long-term strategy.

VSI gets to decide this one.

Under the Ancien Régime, there was a difference between what was
considered public, and what was considered documented¹ and supported.

What was considered supported was that listed in the SPD and in the
documentation².

What wasn't, well, wasn't.

What was latent in the CLDs, or the comments in the help files², or in
the various API definitions and behaviors³, was not considered an
indication of support or stability.

There's a whole pile of stuff that's considered semi-stable (at best)
included in the LIB definitions, too.


🦶🏼🎶

¹That the obsolete features manual is now itself considered obsolete is
its own doc-ouroboros. And that the doc for the new features shipped
with some of the V8.4 UPDATE kits was sometimes not incorporated adds
to the mess. And one of the few examples of SYS$CLI API documentation
is in some long-gone release notes.
ftp://bitsavers.informatik.uni-stuttgart.de/www.computer.museum.uq.edu.au/pdf/AA-D015B-TE%20VAX-VMS%20Release%20Notes.pdf


²Yes, OpenVMS help files do support comments. Those comments were and
can be used as a means to disable viewing some some help text. Some
experienced system managers became aware of certain undocumented and
unsupported changes by exploring there. Extracting the entirety of the
help libraries and then looking for any comments was common practice
for some of us. DECnet proxies were "announced" this way.

³Hyrum's Law applies. https://xkcd.com/1172/ Various of the behaviors
of even documented OpenVMS APIs are (were) considered undocumented,
whether due to timing or undocumented extensions or bugs or hooks or
otherwise. That undocumented assumption has backfired badly on
occasion, such as at VAX/VMS V5.0 with asynchronous I/O completion, and
the OpenVMS I/O change there was backed out.

[Simon Clubley]

Post by Stephen Hoffman
VSI gets to decide this one.
Under the Ancien Régime, there was a difference between what was
considered public, and what was considered documented¹ and supported.
What was considered supported was that listed in the SPD and in the
documentation².

Ok, if this is a real problem, the solution is to set a flag in the
definition against the "something" to indicate that it is unsupported
and ignore it in the output.

Simon.

[Jonathan]

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.
$ show device <Ctrl-P>
where <Ctrl-P> is the control character, would result in a list of all
the qualifiers (along with any optional arguments to the qualifiers)
that can be used at that point. The CLD format could also be enhanced
with a single-line help text per qualifier that would also be displayed
as part of the output.
The output would also show that a parameter, labeled as (for example)
"Device_Name", could be supplied at this point as well.
$ show d<Ctrl-P>
(with no space between the "d" and the Ctrl-P) would show all the valid
options beginning with "d" at that point.
Any comments ?
Simon.
--
Walking destinations on a map are further away than they appear.

TOPS had this forty years ago. Not bitter. Anymore.

[Tony Nicholson]

Post by Jonathan

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.

[snip]

Post by Jonathan
TOPS had this forty years ago. Not bitter. Anymore.

Indeed it did. Everything old is new again!!!

Remnants still exist and can be seen if you have Innosoft's
(now Process Software's) PMDF email system on OpenVMS
just type a '?' anywhere to see it - e.g.

$ pmdf mail
EMAIL> send ?
files to send
Optional group of input filenames, possibly containing wildcards.
-or-
Optional qualifier, must be chosen from:
(1) /abort Abort on any error
(2) /bcc_list Specify Bcc: (blind copy) recipients
(3) /bcc_prompt Prompt for Bcc: (blind copy) recipients
(4) /block Process input files in block mode
(5) /cc_list Specify Cc: (copy) recipients
(6) /cc_prompt Prompt for Cc: (copy) recipients
(7) /comments Set Comments: header to specified string
(8) /confirm Request confirmation before acting
(9) /delay_warnings Ask that delay notifications be returned
(10) /delivery_receipt Request delivery receipt
(11) /digest Include digest of selected messages
(12) /edit Invoke editor prior to sending
(13) /eightbit Control use of eightbit in text files
(14) /encapsulate Encapsulate input files as message parts
(15) /encoding Apply specified encoding to input file
(16) /filename Include file names as Content-Type parameters
(17) /foreign Process input files in block mode
More?

etc...

Tony

[Simon Clubley]

Post by Jonathan
TOPS had this forty years ago. Not bitter. Anymore.

In that case, perhaps someone should tell Clair that he could bring
a bit of TOPS-20 to VMS if he added this capability to DCL. :-)

[Clair worked on TOPS-20 before he came to VMS...]

Simon.

[Jon Pinkley]

Post by Simon Clubley

Post by Jonathan
TOPS had this forty years ago. Not bitter. Anymore.

In that case, perhaps someone should tell Clair that he could bring
a bit of TOPS-20 to VMS if he added this capability to DCL. :-)
[Clair worked on TOPS-20 before he came to VMS...]
Simon.
--
Walking destinations on a map are further away than they appear.

I assume what is being referred to is the COMND JSYS. See http://www.columbia.edu/kermit/dec20.html at the end of the "Introduction" section, right before "Programming Languages"

[V***@SendSpamHere.ORG]

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.
$ show device <Ctrl-P>
where <Ctrl-P> is the control character, would result in a list of all
the qualifiers (along with any optional arguments to the qualifiers)
that can be used at that point. The CLD format could also be enhanced
with a single-line help text per qualifier that would also be displayed
as part of the output.
The output would also show that a parameter, labeled as (for example)
"Device_Name", could be supplied at this point as well.
$ show d<Ctrl-P>
(with no space between the "d" and the Ctrl-P) would show all the valid
options beginning with "d" at that point.
Any comments ?

Have fun at the console.

[Rich Alderson]

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.
$ show device <Ctrl-P>
where <Ctrl-P> is the control character, would result in a list of all
the qualifiers (along with any optional arguments to the qualifiers)
that can be used at that point. The CLD format could also be enhanced
with a single-line help text per qualifier that would also be displayed
as part of the output.
The output would also show that a parameter, labeled as (for example)
"Device_Name", could be supplied at this point as well.
$ show d<Ctrl-P>
(with no space between the "d" and the Ctrl-P) would show all the valid
options beginning with "d" at that point.
Any comments ?

VMS Engineering will never go for it, because that's the way it works in the
TOPS-20 EXEC: Type a ? to get possible follow-ons at any point in the command
line. And what's more, any user mode program which uses the COMND% JSYS
("system call") gets exactly the same behavior.

But Bell's scions will never go for it...

:-) :-) :-) :-) :-) :-) :-) :-)

(Hi, Clair!)

[Dave Froble]

Post by Rich Alderson

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.
$ show device <Ctrl-P>
where <Ctrl-P> is the control character, would result in a list of all
the qualifiers (along with any optional arguments to the qualifiers)
that can be used at that point. The CLD format could also be enhanced
with a single-line help text per qualifier that would also be displayed
as part of the output.
The output would also show that a parameter, labeled as (for example)
"Device_Name", could be supplied at this point as well.
$ show d<Ctrl-P>
(with no space between the "d" and the Ctrl-P) would show all the valid
options beginning with "d" at that point.
Any comments ?

VMS Engineering will never go for it, because that's the way it works in the
TOPS-20 EXEC: Type a ? to get possible follow-ons at any point in the command
line. And what's more, any user mode program which uses the COMND% JSYS
("system call") gets exactly the same behavior.
But Bell's scions will never go for it...
:-) :-) :-) :-) :-) :-) :-) :-)
(Hi, Clair!)

Rich, what's happening with the museum?

I noticed that Paul's heirs weren't too happy with the space launch
endeavor.

[Rich Alderson]

Typo in previous subject: That should be *36*, of course...

Post by Dave Froble
Rich, what's happening with the museum?
I noticed that Paul's heirs weren't too happy with the space launch
endeavor.

Hi, Dave,

First, let me make it clear that I am not an official spokesperson for LCM+L,
Vulcan Inc., or the Allen family, as I am no longer working for any of the
above.

The museum was closed due to the pandemic in early March, a week before the
governor of Washington ordered a shutdown. We expected to return sometime in
the summer.

At the end of May, we were informed that the museum would remain closed for the
next 12-18 months, and that we would all be laid off as of 1 July. We spent
the next month cleanly shutting down all the systems and documenting how to
bring them back up for our successors, whoever they may be.

That's as much as I know. As I said, I'm no longer in the loop.

Thanks for asking.

[IanD]

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.
$ show device <Ctrl-P>
where <Ctrl-P> is the control character, would result in a list of all
the qualifiers (along with any optional arguments to the qualifiers)
that can be used at that point. The CLD format could also be enhanced
with a single-line help text per qualifier that would also be displayed
as part of the output.
The output would also show that a parameter, labeled as (for example)
"Device_Name", could be supplied at this point as well.
$ show d<Ctrl-P>
(with no space between the "d" and the Ctrl-P) would show all the valid
options beginning with "d" at that point.
Any comments ?
Simon.
--
Walking destinations on a map are further away than they appear.

Next you'll be wanting command completion too!!! 😃

Nothing wrong with enhancements if the increases usability, productivity and reduces chances for errors/mistakes

Reminds me of when they added in place contextual menu options in Blender, it improved productively by orders of magnitude even though it was not a key feature request by a lot of people. It's all part of synergy in my opinion

For VMS the command line might not feature in the scope of the end user perhaps, but it certainly is used by application support folks, developers / system test case creators, dba's, troubleshooters etc

I suspect that to the degree that VMS is DevOps ready is inversely proportional to the amount of command line interaction that is required to maintain things and support applications

VMS is a long way off from the DevOps model, especially for infrastructure deployments and things like Chef, Ansible, Puppet and Terraform etc are possibly not even on the radar yet???

Nothing wrong with the idea although the engagement trigger will require serious thought (I know you know about cntrl P). Perhaps a double cntrl <key> combination might work?

[Hein RMS van den Heuvel]

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.
$ show device <Ctrl-P>
where <Ctrl-P> is the control character, would result in a list of all
the qualifiers (along with any optional arguments to the qualifiers)
that can be used at that point. The CLD format could also be enhanced
with a single-line help text per qualifier that would also be displayed
as part of the output.
The output would also show that a parameter, labeled as (for example)
"Device_Name", could be supplied at this point as well.
$ show d<Ctrl-P>
(with no space between the "d" and the Ctrl-P) would show all the valid
options beginning with "d" at that point.
Any comments ?
Simon.
--
Walking destinations on a map are further away than they appear.

Too little too late, but still welcome!
No doubt the character would have to be <TAB> (HT, 0x09), compatible with Powershell and others.
It has no meaning/value in DCL and using it on an older system would not create bad surprises, just nothing useful.
In Powershell <TAB> circles through all completion options in alphabetical order.
Shift-<TAB> goes backwards but that's not available in a regular terminal session on OpenVMS

TABbing should include filename lookup/completion when appropriate in the command line position.

Cheers,
Hein

[Simon Clubley]

Post by Hein RMS van den Heuvel
Too little too late, but still welcome!

It sounds like you have some additional ideas. I would be interested in
hearing what they are in case VSI feel like implementing them.

Post by Hein RMS van den Heuvel
No doubt the character would have to be <TAB> (HT, 0x09), compatible with Powershell and others.
It has no meaning/value in DCL and using it on an older system would not create bad surprises, just nothing useful.
In Powershell <TAB> circles through all completion options in alphabetical order.
Shift-<TAB> goes backwards but that's not available in a regular terminal session on OpenVMS
TABbing should include filename lookup/completion when appropriate in the command line position.
Cheers,
Hein

Tab would be incompatible with filename completion in this case as you
might want to press Tab to get a list of all the files in the current
directory before you have typed any part of the filename.

I find that quite useful in Bash at times.

Escape or a function key (including maybe one of the PF keys) might be
a possibility if you don't want to type Ctrl-{something} (but you would
have to wait a full second for the Escape to timeout if you used that).

Simon.

[David Jones]

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.
$ show device <Ctrl-P>
where <Ctrl-P> is the control character, would result in a list of all
the qualifiers (along with any optional arguments to the qualifiers)
that can be used at that point. The CLD format could also be enhanced
with a single-line help text per qualifier that would also be displayed
as part of the output.
Any comments ?

I would suggest Ctrl-G over Ctrl-P to avoid accidents at the console. There's always
the literal prefix if you need to insert the BEL character into the input.

[Jiří Kašpar]

Post by Simon Clubley
Here's an idea for a DCL enhancement: implement a control character that
when typed causes DCL to dump all the valid options or keywords available
at that point by reading from the CLD.

I'd suggest TAB for keyword/qualifier/filename completion and PF2 for help.
There is a lot of ideas how to enhance the DCL, my preferred is specifying filenames as a string in quotes (like in dos prompt) instead of extended parse syntax.
But it will not happen because of reasons already mentioned many times.
So, the only solution seems to be to write a new DCL ourselves.
Let’s call it “dclsh” (sorry, the name openDCL is already in use).
I started this project 15 months ago in secret, as I didn’t know what problems could be expected.
The aim of the project is to provide the best features from all three worlds (vms, unix, windows), a configurable user interface (line editing, command and file name syntax), and to support vms, unix and windows image activations.
Current status:
1. CDU mostly rewriten in C. There are some enhancements: for example HELP keyword and linux command syntax support. It accepts all .CLD files from sys$update, but does not generate the code for disallow clause yet.
2. A new implementation of the command line editing with a history.
3. Command parsing and CLI routines are reimplemented in C. Not all value types are now supported, TAB and PF2 helper keys are prepared, but not yet implemented.
It runs on linux, but it is written with respect to backport to VMS.

Keep tuned, I’ll try to document the project as soon as possible, as I need it to attract some students to work on it as their diploma projects. I’d like to have a limited function of the shell before VMS 9.2 announcement.

Jiri