Enhancements or replacement for current VMS HELP ?

Post by Simon Clubley
Are there any plans to enhance or replace the current version of
the HELP command ? Trying to use the current HELP interface is
very, very, frustrating.
For example, it would be nice to be able to search the HELP database
for various keywords.
It would also be _really_ nice if we could have a HELP UI which doesn't
assume it's being run on a teletype. Something like GNU info or a
character cell browser interface is the kind of thing I am thinking
about.
Something where you could use the arrow keys or navigation shortcut
characters to easily move around and follow a tree of related help
nodes.
Would it also be better not to dump every single qualifier into it's
own help node but to have fewer help nodes overall with content
combined up into these fewer help nodes ?

I think HELP as is on the system is fine. If you are ssh'ing in
then this is OK.

Obviously help and/or documentation should be available and browsable
via a web browser.

Arne

TonyMcG

2017-06-20 02:27:44 UTC

For me, a good starting point is an add-on feature of the WASD web server.
See : http://wasd.vsm.com.au/wasd_root/doc/misc/vmsscripts.html
In particular, see : http://wasd.vsm.com.au/Help

Cheers from Oz,
Tony

Simon Clubley

2017-06-20 07:18:12 UTC

Post by TonyMcG
For me, a good starting point is an add-on feature of the WASD web server.
See : http://wasd.vsm.com.au/wasd_root/doc/misc/vmsscripts.html
In particular, see : http://wasd.vsm.com.au/Help

The problem is that HELP should also be available from within the
current terminal session. It's just that the current HELP interface
completely and totally sucks.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Jan-Erik Soderholm

2017-06-20 07:28:53 UTC

The problem is that HELP should also be available from within the
current terminal session. It's just that the current HELP interface
completely and totally sucks.

It does not.

Post by Simon Clubley
Simon.

Simon Clubley

2017-06-20 07:28:18 UTC

Post by Simon Clubley
The problem is that HELP should also be available from within the
current terminal session. It's just that the current HELP interface
completely and totally sucks.

It does not.

Try reading the VMS linker manual using VMS HELP and then try reading
the GNU linker manual using GNU info. There's no comparison.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Jan-Erik Soderholm

2017-06-20 07:38:51 UTC

Post by Simon Clubley
The problem is that HELP should also be available from within the
current terminal session. It's just that the current HELP interface
completely and totally sucks.

It does not.

Try reading the VMS linker manual using VMS HELP.

The Linker *manual* is not a available in VMS HELP.
The Linker *help* information is.

The manual ("OpenVMS Linker Utility Manual") is a PDF file
which I read from the same environment (my laptop), of course.

Simon Clubley

2017-06-20 12:11:42 UTC

Post by Simon Clubley
The problem is that HELP should also be available from within the
current terminal session. It's just that the current HELP interface
completely and totally sucks.

It does not.

Try reading the VMS linker manual using VMS HELP.

The Linker *manual* is not a available in VMS HELP.
The Linker *help* information is.

You are correct that only a subset of the material in the VMS Linker
manual is available in the online help - that however is another
problem in it's own right. However, that subset is still hard to navigate.

A better example I've now thought of is the online help for the C compiler.
That _does_ include the background and conceptual material that would
also be found in the manuals and it is incredibly painful to navigate
that material using the help UI.

Post by Jan-Erik Soderholm
The manual ("OpenVMS Linker Utility Manual") is a PDF file
which I read from the same environment (my laptop), of course.

Ideally, that should be just one of the various formats the VMS
documentation should be available in.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Hans Bachner

2017-06-20 17:52:43 UTC

[snip]
The manual ("OpenVMS Linker Utility Manual") is a PDF file
which I read from the same environment (my laptop), of course.

Ideally, that should be just one of the various formats the VMS
documentation should be available in.

Last time I looked, the VMS documentation actually was available in PDF
format (and HTML).

Hans.

Simon Clubley

2017-06-20 18:26:34 UTC

[snip]
The manual ("OpenVMS Linker Utility Manual") is a PDF file
which I read from the same environment (my laptop), of course.

Ideally, that should be just one of the various formats the VMS
documentation should be available in.

Last time I looked, the VMS documentation actually was available in PDF
format (and HTML).

I know it comes in PDF format but the point is that it should be
available in a variety of formats, including in a directly readable
format from a character cell command line.

BTW, I've just discovered that some of the HTML links in the online
VMS documentation appear to be broken. You can find the first page
using Google and when you click Next, you get a 404 from HPE...

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Bill Gunshannon

2017-06-20 19:34:52 UTC

[snip]
The manual ("OpenVMS Linker Utility Manual") is a PDF file
which I read from the same environment (my laptop), of course.

Ideally, that should be just one of the various formats the VMS
documentation should be available in.

Last time I looked, the VMS documentation actually was available in PDF
format (and HTML).

I know it comes in PDF format but the point is that it should be
available in a variety of formats, including in a directly readable
format from a character cell command line.

I was going to ask just how one reads PDF's on VMS given that we
repeatedly hear there is not going to be support for graphics
capability. But you summed it up pretty well.

bill

Jan-Erik Soderholm

2017-06-20 21:02:58 UTC

[snip]
The manual ("OpenVMS Linker Utility Manual") is a PDF file
which I read from the same environment (my laptop), of course.

Ideally, that should be just one of the various formats the VMS
documentation should be available in.

Last time I looked, the VMS documentation actually was available in PDF
format (and HTML).

I know it comes in PDF format but the point is that it should be
available in a variety of formats, including in a directly readable
format from a character cell command line.

I was going to ask just how one reads PDF's on VMS given that we
repeatedly hear there is not going to be support for graphics
capability. But you summed it up pretty well.
bill

Since everyone doing any serious work on VMS is accessing VMS
from an environment that does support PDF reader(s), I see little
point in having PDF support on VMS itself. As a middle way you
could access VMS using a browser and "serve" the PDFs from VMS.

This whole discussion is plain silly...

Simon Clubley

2017-06-20 22:18:15 UTC

Post by Simon Clubley
I know it comes in PDF format but the point is that it should be
available in a variety of formats, including in a directly readable
format from a character cell command line.

I was going to ask just how one reads PDF's on VMS given that we
repeatedly hear there is not going to be support for graphics
capability. But you summed it up pretty well.
bill

Who on earth said anything about having PDF support on VMS itself ?

Once again, just in case the above is not clear enough, I said the
VMS documentation should come in multiple formats and one of those
formats should be something which can be directly read from
a character cell command line.

In what possible way does that come across as me asking for a PDF
version to be readable from the DCL command line ?

Simon.

PS: It only seems silly because you clearly don't understand what
I am trying to achieve and how this same problem is solved in
other environments.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Jan-Erik Soderholm

2017-06-21 00:07:01 UTC

Post by Simon Clubley
I know it comes in PDF format but the point is that it should be
available in a variety of formats, including in a directly readable
format from a character cell command line.

I was going to ask just how one reads PDF's on VMS given that we
repeatedly hear there is not going to be support for graphics
capability. But you summed it up pretty well.
bill

Who on earth said anything about having PDF support on VMS itself ?
Once again, just in case the above is not clear enough, I said the
VMS documentation should come in multiple formats and one of those
formats should be something which can be directly read from
a character cell command line.
In what possible way does that come across as me asking for a PDF
version to be readable from the DCL command line ?
Simon.
PS: It only seems silly because you clearly don't understand what
I am trying to achieve and how this same problem is solved in
other environments.

I don't see that *any* format would be practical to use/read from
a character cell terminal due to the amount of material and text
on any normal (full) documentation. And what about any non-text
material in the documentation? And I do not agree that *that*
specific "problem" has been solved in any other character based
environment. Why would you use the character interface in Linux
when it can run a GUI (PDF or otherwise) reader?

Simon Clubley

2017-06-21 13:20:28 UTC

Post by Jan-Erik Soderholm
I don't see that *any* format would be practical to use/read from
a character cell terminal due to the amount of material and text
on any normal (full) documentation. And what about any non-text
material in the documentation? And I do not agree that *that*
specific "problem" has been solved in any other character based
environment. Why would you use the character interface in Linux
when it can run a GUI (PDF or otherwise) reader?

Look at the GNU info tool. It does this job very nicely indeed.

Using info is a _lot_ quicker than starting a PDF reader, finding
the document to read and then navigating to the required section.

I also find info to be a lot more responsive than a PDF reader
when looking through a manual and like a PDF reader (and unlike
VMS HELP) it has a search capability.

Also, when you read a manual, you are looking to read a specific
section and not the whole thing.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Stephen Hoffman

2017-06-21 15:50:40 UTC

...Look at the GNU info tool. It does this job very nicely indeed.

I'd likely also look for the BSD-licensed analogs of the GNU coreutils
— such as toybox — when dealing with commercial and particularly
closed-source software, but yes.

Whether coreutils or toybox or something else is the starting point, or
if VSI designs something equivalent or better is less interesting (to
me) than just bringing OpenVMS forward. That includes HELP, and the
rest of the documentation set for that matter; of bringing the
documentation contents, implementation, navigation, documentation
design, documentation delivery, and the whole mud-ball forward. VSI
knows many of these areas, but this is a much larger project than they
likely have time and staff for, and certainly not before the x86-64
port. This is one of those gnarly projects that crosses UI and design,
development, documentation, web teams and security, too. Probably
among other areas.

Using info is a _lot_ quicker than starting a PDF reader, finding the
document to read and then navigating to the required section.

Command-Space type some keywords, fire off a few Preview windows, off
we go. Pretty speedy, and that's on a comparatively old macOS system.
(As for performance, remember too that we're not running on HDDs
anymore, even if various of the local systems still have those storage
devices. Look forward. Don't design for and don't assume the past.
http://storagemojo.com/2017/06/19/a-transaction-processing-system-for-nvram/
As I've been commenting for a while now. But I digress.)

I'm usually accessing PDFs pretty quickly, but via the IDE. Which
accesses HTML and PDF files transparently, as well as examples and
support documentation. All from within the IDE.

This is an approach that's so fundamentally different from that of
OpenVMS, it's just not comparable. I remember dabbling in IDEs a
decade or so back, and I've been using LSEDIT since EDT was first
deprecated (before VSI un-deprecated EDT). LSEDIT far past EDT for
development. Some IDEs now are much more capable than LSEDIT. Others
– Eclipse and Netbeans tend to be slow, though I've not tried those
with Java 8 yet — could certainly be upgraded for better integration as
OpenVMS is (hypothetically) enhanced with fully-integrated HTML and PDF
documentation.

I also find info to be a lot more responsive than a PDF reader when
looking through a manual and like a PDF reader (and unlike VMS HELP) it
has a search capability.

The OpenVMS integrated search support is a decade or two out of date.
DEC developed AltaVista, but some of those cached-search fast-search
capabilities never made it over into OpenVMS.

Also, when you read a manual, you are looking to read a specific
section and not the whole thing.

Ayup. Cookbook-style documentation and readily-available and
copyright-compatible source code examples have become far more common
for many tasks, and increasingly expected. This outside of those folks
seeking expertise in the entire platform, and cookbooks and examples
and frameworks are incredibly useful even for those. In the absence
of these and other resources, most of us that have been working on
OpenVMS build up these resources ourselves, and that just doesn't scale.

Examples of text-processing tools from other platforms include macOS
textutil, mdfind, et al. These are the analogs of CONVERT and SEARCH.
Or BSD toybox, for that matter.

No, I don't think that various command-line tools such as info or man
or less are particularly stellar as designs or implementations go.
Those and other tools have for many years, however, been able do rather
more than can HELP, and more easily. That's the problem.

Being different and worse is not an auspicious competitive starting
point for any platform, even if the core content and many parts of the
OpenVMS documentation are good. The current BSD documentation is
quite good and getting better too, for those that haven't looked.

Being different and harder to figure out is yet more problematic — and
don't underestimate how much most readers of this comp.os.vms newsgroup
posting have learned about OpenVMS over the years. New folks and new
users don't have that advantage or that inclination or increasingly
even the time to read and grok what is available, which means they're
either going to pester y'all in frustration and in near perpetuity, or
the tools and documentation and examples get better, or they'll want
more pay, or they'll look elsewhere.

No, I'm not particularly fond of HELP, though it certainly was a pretty
good design for its time.

Of course VSI is industriously working on many of the most critical
areas in OpenVMS, of which HELP is not one.

--
Pure Personal Opinion | HoffmanLabs LLC

David Froble

2017-06-21 01:35:58 UTC

Post by Simon Clubley
I know it comes in PDF format but the point is that it should be
available in a variety of formats, including in a directly readable
format from a character cell command line.

I was going to ask just how one reads PDF's on VMS given that we
repeatedly hear there is not going to be support for graphics
capability. But you summed it up pretty well.
bill

Who on earth said anything about having PDF support on VMS itself ?
Once again, just in case the above is not clear enough, I said the
VMS documentation should come in multiple formats and one of those
formats should be something which can be directly read from
a character cell command line.
In what possible way does that come across as me asking for a PDF
version to be readable from the DCL command line ?
Simon.
PS: It only seems silly because you clearly don't understand what
I am trying to achieve and how this same problem is solved in
other environments.

Perhaps instead of referring to "other environments", you should be specific as
to what you propose. Maybe some will go look at "other environments", I will not.

Plain formatted text works for me.

Oh, wait, that is what HELP is. Just not as much as it could be.

David Froble

2017-06-21 12:49:56 UTC

Post by David Froble
Plain formatted text works for me.

Ok, I'm withdrawing this statement. As one example, the illustrations for item
lists can be rather helpful. Manuals, and yes, HELP, can benefit from such.
Manuals have such, HELP doesn't.

Simon Clubley

2017-06-21 13:15:19 UTC

Post by Simon Clubley
PS: It only seems silly because you clearly don't understand what
I am trying to achieve and how this same problem is solved in
other environments.

Perhaps instead of referring to "other environments", you should be specific as
to what you propose. Maybe some will go look at "other environments", I will not.

The GNU Texinfo tools are what I am thinking of here.

https://en.wikipedia.org/wiki/Texinfo

In addition to all the standard formats (PDF, HTML, etc) you also get
a info format option which allows the full manual to be read from within
a character cell environment using a tool called info.

Post by David Froble
Plain formatted text works for me.
Oh, wait, that is what HELP is. Just not as much as it could be.

There's formatted text and then there's formatted text.

The overall purpose of HELP is similar to manpages, however manpages
have a number of advantages, including that the options and related
information are on one page and that, critically, the manpage itself
can be searched.

That latter capability makes a vast difference with large manpages.

HELP is better with examples, but that's a matter of the content and
not the HELP reader itself.

Also, VMS doesn't have anything like info so more conceptual information
gets pushed into the HELP system in tiny disconnected segments and it is
very difficult to navigate.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

2017-06-21 15:35:30 UTC

Post by Simon Clubley
The overall purpose of HELP is similar to manpages, however manpages
have a number of advantages, including that the options and related
information are on one page and that, critically, the manpage itself
can be searched.
That latter capability makes a vast difference with large manpages.

Which, as you probably know, is a feature of the pager. From man man:
"By default, man uses pager -s". On my Linux system the pager is "less".

David Froble

2017-06-21 01:32:14 UTC

Post by Simon Clubley
The problem is that HELP should also be available from within the
current terminal session. It's just that the current HELP interface
completely and totally sucks.

It does not.

Try reading the VMS linker manual using VMS HELP.

The Linker *manual* is not a available in VMS HELP.
The Linker *help* information is.

You are correct that only a subset of the material in the VMS Linker
manual is available in the online help - that however is another
problem in it's own right. However, that subset is still hard to navigate.
A better example I've now thought of is the online help for the C compiler.
That _does_ include the background and conceptual material that would
also be found in the manuals and it is incredibly painful to navigate
that material using the help UI.

HELP, and manuals, are a suppliment, one first has to have a clue about what
they are attempting to do. Don't know about C, but try the Basic help. Doesn't
tell you how to program in Basic, but if you know that, then any minor questions
seem to be covered.

Post by Jan-Erik Soderholm
The manual ("OpenVMS Linker Utility Manual") is a PDF file
which I read from the same environment (my laptop), of course.

Ideally, that should be just one of the various formats the VMS
documentation should be available in.

Can't argue with that.

2017-06-20 08:56:09 UTC

Post by Simon Clubley
Try reading the VMS linker manual using VMS HELP and then try reading
the GNU linker manual using GNU info. There's no comparison.

Apples and oranges: try reading the GNU linker manual with the man utility.

Wasn't there a lengthly discussion about this - a couple of months ago?

As pointed out, you can use HELP/NOPAGE/NOPROMPT topic * to get a full
first level output of the specified topic, or use LIBRARIAN
SYS$HELP:HELPLIB.HLB/EXTRACT=topic/OUTPUT=SYS$OUTPUT to get the full
help text.

Simon Clubley

2017-06-20 12:17:05 UTC

Post by hb

Post by Simon Clubley
Try reading the VMS linker manual using VMS HELP and then try reading
the GNU linker manual using GNU info. There's no comparison.

Apples and oranges: try reading the GNU linker manual with the man utility.

You would never do that; you would use the tool which was designed
for that job (which is not man).

Post by hb
Wasn't there a lengthly discussion about this - a couple of months ago?

Actually, yes there was now that you have reminded me. I also remember
now there was some confusion between the GNU linker man page and the
GNU linker manual.

If someone uses info on Linux to read the linker manual and you end
up getting something which looks like a manpage, then make sure you
have the full GNU linker documentation installed.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

David Froble

2017-06-21 01:28:56 UTC

Post by Simon Clubley
The problem is that HELP should also be available from within the
current terminal session. It's just that the current HELP interface
completely and totally sucks.

It does not.

Try reading the VMS linker manual using VMS HELP and then try reading
the GNU linker manual using GNU info. There's no comparison.
Simon.

VMS HELP is not a replacement, nor substitute, for manuals.

Though, for me personally, you sure picked a good one. I have a difficult time
with the linker and it's documentation. Probably just me.

Stephen Hoffman

2017-06-21 03:19:44 UTC

Post by David Froble
VMS HELP is not a replacement, nor substitute, for manuals.

Yeah, that was the rational that DEC used, back when they put together
HELP, based on the various compromises and constraints that they were
operating under decades ago.
Ask yourself... why should that distinction still hold? Because of
some particular constraint that still exists? Or because HELP is too
limited?
Well... if it's the latter... that HELP is too limited to do this very
well... isn't this discussion here about fixing or replacing HELP?

--
Pure Personal Opinion | HoffmanLabs LLC

David Froble

2017-06-21 12:52:02 UTC

Post by Stephen Hoffman

Post by David Froble
VMS HELP is not a replacement, nor substitute, for manuals.

Yes, and after thinking about it a bit, I'm fully on-board with the concept of
HELP being improved.

Scott Dorsey

2017-06-21 13:38:51 UTC

Post by Simon Clubley
The problem is that HELP should also be available from within the
current terminal session. It's just that the current HELP interface
completely and totally sucks.

It does not.

Try reading the VMS linker manual using VMS HELP and then try reading
the GNU linker manual using GNU info. There's no comparison.

They're not the same thing, they aren't even intended to be the same thing.
You're compating apples and oranges.

If you want online manuals like gnu info gives you, that's great. But HELP
isn't an online manual.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Simon Clubley

2017-06-21 18:23:48 UTC

Post by Simon Clubley
Try reading the VMS linker manual using VMS HELP and then try reading
the GNU linker manual using GNU info. There's no comparison.

They're not the same thing, they aren't even intended to be the same thing.
You're compating apples and oranges.

Yes, and the VMS linker information that does exist in HELP is harder
to read than either the GNU linker summary on it's man page or the full
info format GNU linker manual.

Post by Scott Dorsey
If you want online manuals like gnu info gives you, that's great. But HELP
isn't an online manual.

Stepping back a bit, I think one of the things I am reacting to is
that HELP is being used both for man style summary documentation as
well as more detailed conceptual documentation.

This is what I think my core issues are with HELP:

1) HELP content is broken up into small fragments instead of bigger
page sized chunks and there can be sets of multiple fragments each
indexed under a different parent fragment.

This in itself makes things more cumbersome because it means you have
to navigate through the HELP content for a topic instead of just being
able to read it on just one page. While messy, this in itself would
not be too bad if you could use (say) the arrow keys and tab to move
around, but the fact you actually have to list the sub-topics and then
start typing the name you are looking for makes things very very
cumbersome indeed.

This complaint is true for both the man type documentation as well as
the more detailed stuff such as the C compiler documentation.

2) Once you are at a topic in the HELP tree, you can't search for
keywords within sub-topics if you have an idea of what you are looking
for but are not sure of the exact topic name.

This complaint is true for both the man type documentation and the more
detailed stuff.

3) Because VMS does not have it's own version of the info online reader,
the layered product groups have started pushing more conceptual stuff
such as the C manuals into HELP. Because of the above problems, it's
absolutely useless trying to read any significant quantity of that more
conceptual stuff.

[End of list.]

One of the reasons why I keep mentioning info is because it shows
you an example of how you _can_ navigate around an hierarchy of
topics and sub-topics in a somewhat efficient way if HELP is to
be kept in a big tree of small disconnected fragments.

I would prefer larger man page sized output pages from HELP instead
of the current small fragments and we need the ability to search
within the content itself just as you can with the man pager and
with info.

I also think the full VMS documentation set should be installed in
multiple formats on the VMS system disk just as it is currently done
with Linux. Make it an optional install if people want that option.

I also agree that we need both a HELP command for listing a summary
of command options and an info style character cell based reader
for the manuals.

Oh, and while I am listing my wishes, can we _PLEASE_ have proper
table of contents sidebars for _all_ the existing PDF documentation ?

Thanks,

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Keith Cayemberg

2017-06-26 19:35:44 UTC

[snipped some text there]

Post by Simon Clubley
1) HELP content is broken up into small fragments instead of bigger
page sized chunks and there can be sets of multiple fragments each
indexed under a different parent fragment.
This in itself makes things more cumbersome because it means you have
to navigate through the HELP content for a topic instead of just being
able to read it on just one page. While messy, this in itself would
not be too bad if you could use (say) the arrow keys and tab to move
around, but the fact you actually have to list the sub-topics and then
start typing the name you are looking for makes things very very
cumbersome indeed.
This complaint is true for both the man type documentation as well as
the more detailed stuff such as the C compiler documentation.
2) Once you are at a topic in the HELP tree, you can't search for
keywords within sub-topics if you have an idea of what you are looking
for but are not sure of the exact topic name.
This complaint is true for both the man type documentation and the more
detailed stuff.
3) Because VMS does not have it's own version of the info online reader,
the layered product groups have started pushing more conceptual stuff
such as the C manuals into HELP. Because of the above problems, it's
absolutely useless trying to read any significant quantity of that more
conceptual stuff.
[End of list.]
One of the reasons why I keep mentioning info is because it shows
you an example of how you _can_ navigate around an hierarchy of
topics and sub-topics in a somewhat efficient way if HELP is to
be kept in a big tree of small disconnected fragments.

[snipped some text there]

Post by Simon Clubley
Thanks,
Simon.

Hi Simon,

there was a similar discussion about HELP here on COV in December or
January of 2013. It appears what bothers many people about HELP's
hierarchical topic interface is the lack of a direct keyword search
capability, and also not having the option to freely scroll through and
between topic boundaries. I decided to enhance OpenVMS Help with a
utility (SHELP.COM) written in about 736 lines of DCL. I tried to
leverage inherent OpenVMS functionality rather than attempt a clone of
an unix/linux based tool. It's not an ideal answer of what most people
want, but I think it is still a useful improvement for anyone wanting to
lookup something relatively fast without leaving the command line
terminal session.

The procedure may be downloaded as a zip file (SHELP.ZIP) here...

https://drive.google.com/open?id=0ByHeiJKSqZgjbzMzU3lBbGlqaWc

Here is a much better explanation taken from the procedure's own
built-in help.

--------------------------------------------

Procedure: SHELP.COM (Search HELP)
Author: Keith Cayemberg
Created: January 13th, 2013
Modified: June 24st, 2017
Version: 1.3

Description: Search any OpenVMS HELP Library in SYS$HELP for keywords
and provide the full help command to the text found.

Procedure: This procedure will extract the text of any OpenVMS HELP
Library (.HLB) into a text file (HELPFILE). Then it builds
a HELP topics path list with their corresponding line
numbers, as another file (DEXFILE), These first 2 steps
are performed only when the HELPFILE or DEXFILE are not
existing or too old. Finally this procedure searches the
full text HELPFILE for the keyword(s) you provided as the
first parameter, and looks-up the DEXFILE topics path
listing. This procedure then displays the help topic paths,
and also by default the corresponding lines of help text
where the keyword(s) were found (preceded by a "»" sign).

Parameters:

P1 The keyword(s) to search within the OpenVMS Help Library.
(required) You can search for one exact string containing multiple
keywords by enclosing them in double quotes. If your
search string starts with a "/" then the search string
must be in double quotes. To find multiple keywords
anywhere on the same line, then separate the keywords with
commas, but with no spaces or quotes.

Qualifiers:

/MATch= Enter OR, AND, NOR, NAND, etc. as described in
(optional) $ HELP SEARCH /MATCH to change whether or not all,
one, or none of the keywords are to be on the same line
of help text to cause a search match.
The default is /MATCH=OR.

/LIBrary= Use to search an alternative OpenVMS help library.
(optional) The default value is the standard OpenVMS HELP Library.
To find other available help libraries use the command...

$ dir sys$help:*.hlb

/WINdow= (optional) Enter a number from 1 to 9 to set the number
(optional) of lines of output around each matched help line. The
default is /WINDOW = 1

/BRIef This qualifier will cause only the matched help topic
(optional) paths to be displayed. The matching lines of text
within the topics are not displayed.

/VERbose This qualifier will show more processing detail,
(optional) especially when building the DEXFILE.

Hints: Due to long HELP paths in the output, it is a good idea to set
your terminal width to at least 132 characters, before using
this procedure. If the first parameter is "SHELP" or "?" then
this help text will be paged to the screen.

The recommended foreign command definition for this procedure:

$ SHELP :== @mylogical:[mydir]SHELP.COM

Two foreign commands are defined for each of the first 20
matched topics. The symbols are shelpath_%% and shelptxt_%%
(where %% = 01 upto 20).

$ show symbol shelp_hlp_* ! help command to open topic
$ show symbol shelp_tpu_* ! tpu command for help text

Note: If either the HELPFILE or DEXFILE can't be found in the
SYS$HELP or SYS$SCRATCH directories, or they are too old,
then they will be recreated in the SYS$SCRATCH directory.
Neither file needs refreshing unless the specific OpenVMS
HELP Library (.HLB) has a new version or changed text. The
system manager can choose to copy both files to the
SYS$HELP directory to make them available to all users.

$ dir sys$help:SHELP*.*

Directory SYS$SYSROOT:[SYSHLP]
SHELP_HELPLIB.DEX;1 SHELP_HELPLIB.HLP;1

Total of 2 files.

$ dir sys$scratch:SHELP*.*

Directory $mydisk:[mydir]
SHELP_DBG$HELP.DEX;1 SHELP_DBG$HELP.HLP;1
SHELP_UNZIP.DEX;1 SHELP_UNZIP.HLP;1

Total of 4 files.

Examples:

$ shelp skonetski
$ shelp hoffman,skonetski
$ shelp "galaxy shared memory"
$ shelp decwindows,interface /match=AND /window=2
$ shelp decwindows,interface /mat=AND/library=DBG$HELP
$ shelp conference /lib=PHONEHELP /brief
$ shelp SMCI_FLAGS /win=4/verbose

$ shelp "/FULL_DUPLEX"

HELP LANCP SET DEVICE Qualifiers !(1)
» /FULL_DUPLEX
» /FULL_DUPLEX

Found 2 matches within 1 topics.

$ show symbol shelp_*
SHELP_HLP_01 == "HELP LANCP SET DEVICE Qualifiers"
SHELP_TPU_01 == "EDIT/TPU SYS$HELP:SHELP_HELPLIB.HLP -
/READ/START=225307"

-------------------------------

I have also tested the procedure with .HLB files installed at other
directories besides SYS$HELP. The procedure should work in these
cases as well.

It is recommended that a system manager copy at least the HELPFILE and
DEXFILE for the primary HELPLIB.HLB to SYS$HELP, (remembering to set
file protections to W:RE) so that users don't need to generate their own
local HELPFILE and DEXFILE for the large help library.

I submit SHELP.COM to the public domain with no guarantees expressed or
implied.

Cheers!

Keith Cayemberg

Simon Clubley

2017-06-27 00:11:51 UTC

Post by Keith Cayemberg
The procedure may be downloaded as a zip file (SHELP.ZIP) here...
https://drive.google.com/open?id=0ByHeiJKSqZgjbzMzU3lBbGlqaWc

Thank you Keith, I have it. I'll try it out when my new licences
arrive.

BTW, here's a product suggestion for VSI: What about giving the LMF
an option to send out warning emails xx days before a licence expires ?

Due to other matters, I missed that mine were about to expire until
there were only several days to go...

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

d***@gmail.com

2017-06-27 15:50:12 UTC

On Monday, June 26, 2017 at 8:15:36 PM UTC-4, Simon Clubley wrote:
Noted: Like most suggestions like this though, do want VMS Mail to SYSTEM or something more elaborate?

Post by Simon Clubley
BTW, here's a product suggestion for VSI: What about giving the LMF
an option to send out warning emails xx days before a licence expires ?

Perhaps this will tide you over:

$ show lice/term="+30-"/before/warn=30

Active licenses on node MYOB:

------- Product ID -------- ---- Rating ----- -- Version --
Product Producer Units Avail Activ Version Release Termination
C VSI 0 0 100 0.0 (none) 30-APR-2017
1 license has terminated or will terminate in 30 days

Post by Simon Clubley
Due to other matters, I missed that mine were about to expire until
there were only several days to go...

Simon Clubley

2017-06-27 20:53:09 UTC

Post by d***@gmail.com
Noted: Like most suggestions like this though, do want VMS Mail to SYSTEM or
something more elaborate?

Mail to SYSTEM will be absolutely fine thanks; it just needs to be
a simple heads-up notification and everyone should be reading mail
sent to SYSTEM.

Thanks,

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Steven Schweda

2017-06-27 21:25:01 UTC

Post by Simon Clubley
Mail to SYSTEM will be absolutely fine thanks; it just needs to be
a simple heads-up notification and everyone should be reading mail
sent to SYSTEM.

Mine doesn't use all the fancy options, and it sends
e-mail to me ("sms"), not SYSTEM, but it seemed to work this
year.

ALP $ type license_check.com
$! 16 March 2016. SMS.
$!
$! License/PAK expiration check.
$!
$!
$ pipe show license | search /output = nl: /nowarnings sys$input TERMIMM
$ if ($STATUS .eq. %X10000001)
$ then
$ mail /subject = " * LICENSE WARNING *" sys$input sms
Licenses have terminated or will terminate in 30 days.
For more information: SHOW LICENSE
$!
$ endif

It's run by my DAILY.COM which self-re-submits to run at
00:10:00 every day. No doubt, more complication could be
added.

David Froble

2017-06-27 22:24:03 UTC

Post by Steven Schweda

Post by Simon Clubley
Mail to SYSTEM will be absolutely fine thanks; it just needs to be
a simple heads-up notification and everyone should be reading mail
sent to SYSTEM.

Mine doesn't use all the fancy options, and it sends
e-mail to me ("sms"), not SYSTEM, but it seemed to work this
year.
ALP $ type license_check.com
$! 16 March 2016. SMS.
$!
$! License/PAK expiration check.
$!
$!
$ pipe show license | search /output = nl: /nowarnings sys$input TERMIMM
$ if ($STATUS .eq. %X10000001)
$ then
$ mail /subject = " * LICENSE WARNING *" sys$input sms
Licenses have terminated or will terminate in 30 days.
For more information: SHOW LICENSE
$!
$ endif
It's run by my DAILY.COM which self-re-submits to run at
00:10:00 every day. No doubt, more complication could be
added.

But as has been adequately demonstrated, VMS already has the capability.
Several options have been posted here. For a VMS person "it's in there".

Now for those needing assistance crossing the street, perhaps not.

V***@SendSpamHere.ORG

2017-06-28 12:18:41 UTC

Post by Steven Schweda

Post by Simon Clubley
Mail to SYSTEM will be absolutely fine thanks; it just needs to be
a simple heads-up notification and everyone should be reading mail
sent to SYSTEM.

Mine doesn't use all the fancy options, and it sends
e-mail to me ("sms"), not SYSTEM, but it seemed to work this
year.
ALP $ type license_check.com
$! 16 March 2016. SMS.
$!
$! License/PAK expiration check.
$!
$!
$ pipe show license | search /output = nl: /nowarnings sys$input TERMIMM
$ if ($STATUS .eq. %X10000001)
$ then
$ mail /subject = " * LICENSE WARNING *" sys$input sms
Licenses have terminated or will terminate in 30 days.
For more information: SHOW LICENSE
$!
$ endif
It's run by my DAILY.COM which self-re-submits to run at
00:10:00 every day. No doubt, more complication could be
added.

But as has been adequately demonstrated, VMS already has the capability.
Several options have been posted here. For a VMS person "it's in there".
Now for those needing assistance crossing the street, perhaps not.

Street crossing assisted people play on WEENDOZE.

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

I speak to machines with the voice of humanity.

David Froble

2017-06-27 22:20:30 UTC

Post by d***@gmail.com
Noted: Like most suggestions like this though, do want VMS Mail to SYSTEM or
something more elaborate?

Mail to SYSTEM will be absolutely fine thanks; it just needs to be
a simple heads-up notification and everyone should be reading mail
sent to SYSTEM.
Thanks,
Simon.

Speaking for everyone again? Perhaps not everyone logs into the SYSTEM account.

Now, a slight addition might be to allow the option to be enabled, and to be
able to specify which user account(s) will be notified.

Simon Clubley

2017-06-27 22:57:25 UTC

Post by d***@gmail.com
Noted: Like most suggestions like this though, do want VMS Mail to SYSTEM or
something more elaborate?

Mail to SYSTEM will be absolutely fine thanks; it just needs to be
a simple heads-up notification and everyone should be reading mail
sent to SYSTEM.

Speaking for everyone again?

No, I'm thinking about those people who have their VMS systems
properly configured.

Post by David Froble
Perhaps not everyone logs into the SYSTEM account.

And that has absolutely _nothing_ to do with reading mail addressed
to SYSTEM.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

David Froble

2017-06-28 02:40:20 UTC

Post by d***@gmail.com
Noted: Like most suggestions like this though, do want VMS Mail to SYSTEM or
something more elaborate?

Mail to SYSTEM will be absolutely fine thanks; it just needs to be
a simple heads-up notification and everyone should be reading mail
sent to SYSTEM.

Speaking for everyone again?

No, I'm thinking about those people who have their VMS systems
properly configured.

Post by David Froble
Perhaps not everyone logs into the SYSTEM account.

And that has absolutely _nothing_ to do with reading mail addressed
to SYSTEM.
Simon.

Well, I was assuming VMS mail. If not, then perhaps. But, as far as I know,
which may not be very far, with VMS mail, one gets notified when logging into
the user account the VMS mail is sent to. If no one ever logs into that user
account, how does anyone ever see the VMS mail?

That said, I don't think anything is needed here. Several solutions that
already exist have been mentioned, and there could be more.

Hans Bachner

2017-06-28 06:53:41 UTC

Post by d***@gmail.com
Noted: Like most suggestions like this though, do want VMS Mail to SYSTEM or
something more elaborate?

Mail to SYSTEM will be absolutely fine thanks; it just needs to be
a simple heads-up notification and everyone should be reading mail
sent to SYSTEM.

Speaking for everyone again?

No, I'm thinking about those people who have their VMS systems
properly configured.

Post by David Froble
Perhaps not everyone logs into the SYSTEM account.

And that has absolutely _nothing_ to do with reading mail addressed
to SYSTEM.
Simon.

Well, I was assuming VMS mail. If not, then perhaps. But, as far as I
know, which may not be very far, with VMS mail, one gets notified when
logging into the user account the VMS mail is sent to. If no one ever
logs into that user account, how does anyone ever see the VMS mail?
That said, I don't think anything is needed here. Several solutions
that already exist have been mentioned, and there could be more.

You can always define a forward address for user SYSTEM in VMS mail so
you get all mail to SYSTEM forwarded to your personal account (or even
to a distribution list).

Hans.

j***@yahoo.co.uk

2017-06-28 13:16:38 UTC

Post by d***@gmail.com
Noted: Like most suggestions like this though, do want VMS Mail to SYSTEM or
something more elaborate?

Mail to SYSTEM will be absolutely fine thanks; it just needs to be
a simple heads-up notification and everyone should be reading mail
sent to SYSTEM.

Speaking for everyone again?

No, I'm thinking about those people who have their VMS systems
properly configured.

Post by David Froble
Perhaps not everyone logs into the SYSTEM account.

And that has absolutely _nothing_ to do with reading mail addressed
to SYSTEM.
Simon.

Well, I was assuming VMS mail. If not, then perhaps. But, as far as I
know, which may not be very far, with VMS mail, one gets notified when
logging into the user account the VMS mail is sent to. If no one ever
logs into that user account, how does anyone ever see the VMS mail?
That said, I don't think anything is needed here. Several solutions
that already exist have been mentioned, and there could be more.

You can always define a forward address for user SYSTEM in VMS mail so
you get all mail to SYSTEM forwarded to your personal account (or even
to a distribution list).
Hans.

Might forwarding mail sent to SYSTEM to some semi-random
personal account be a security risk? Especially if the
semi-random personal account isn't particularly secure?

Anyway, it seems there's still plenty of other stuff to
think about for the world of Windows. Whether the correct
conclusion will ever reach the budget holders remains to
be seen.

Simon Clubley

2017-06-28 13:21:42 UTC

Post by j***@yahoo.co.uk

Post by Hans Bachner
You can always define a forward address for user SYSTEM in VMS mail so
you get all mail to SYSTEM forwarded to your personal account (or even
to a distribution list).

Might forwarding mail sent to SYSTEM to some semi-random
personal account be a security risk? Especially if the
semi-random personal account isn't particularly secure?

Not really, because it's just forwarded to the VMS account(s) that
you do log into during the day.

It's only if you don't log into the VMS system in question at all
as part of normal operations that you need to forward it to
an off-the-box account and that would be another work account, not
a personal account.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Jan-Erik Soderholm

2017-06-28 13:32:24 UTC

Post by j***@yahoo.co.uk

Post by Hans Bachner
You can always define a forward address for user SYSTEM in VMS mail so
you get all mail to SYSTEM forwarded to your personal account (or even
to a distribution list).

Might forwarding mail sent to SYSTEM to some semi-random
personal account be a security risk? Especially if the
semi-random personal account isn't particularly secure?

Not really, because it's just forwarded to the VMS account(s) that
you do log into during the day.

How do you know *that* for every VMS system out there?
How do you know that the mail aren't sent to somewhere else?

Post by Simon Clubley
It's only if you don't log into the VMS system in question at all
as part of normal operations that you need to forward it to
an off-the-box account and that would be another work account, not
a personal account.

And how do you know *that*?

As far as I can tell, the forward can go to any mail address.

Post by Simon Clubley
Simon.

Simon Clubley

2017-06-28 17:29:44 UTC

Post by j***@yahoo.co.uk
Might forwarding mail sent to SYSTEM to some semi-random
personal account be a security risk? Especially if the
semi-random personal account isn't particularly secure?

Not really, because it's just forwarded to the VMS account(s) that
you do log into during the day.

How do you know *that* for every VMS system out there?
How do you know that the mail aren't sent to somewhere else?

In order to forward SYSTEM mail you either need the password to the
SYSTEM account in question or access to another account on the same
system which has enough privileges to allow the user to issue a forward
command in MAIL for another user.

If you have unauthorised people with that level of access to your VMS
systems then you have far bigger problems than the forwarding of mail
sent to SYSTEM.

And how do you know *that*?

Because if an employee starts forwarding mail from their employer's
systems to their personal accounts without permission, then that
should be a serious disciplinary offence.

Post by Jan-Erik Soderholm
As far as I can tell, the forward can go to any mail address.

Technically yes (at least assuming there's no DPI firewall to stop
this forwarding). What's allowed under the employee's terms of
employment is another matter however.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Stephen Hoffman

2017-06-28 18:47:16 UTC

Post by Simon Clubley
If you have unauthorised people with that level of access to your VMS
systems then you have far bigger problems than the forwarding of mail
sent to SYSTEM.

Ayup. But then if you're using OpenVMS mail as implemented with
TCP/IP Services, you already have some problems in this area. This
whether you're accessing that SYSTEM mail remotely via IMAP, or
forwarding the message to some other host. VSI IP should fix a number
of these, or switch to one of the Process IP stacks, etc.

It's only if you don't log into the VMS system in question at all as
part of normal operations that you need to forward it to an off-the-box
account and that would be another work account, not a personal account.

And how do you know *that*?

Because if an employee starts forwarding mail from their employer's
systems to their personal accounts without permission, then that should
be a serious disciplinary offence.

That, and it's easier to just sftp or ftp or maybe use a DNS tunnel to
more directly transfer data elsewhere. Mail sent to SYSTEM is a
comparatively low-value target for a privileged user.

Post by Jan-Erik Soderholm
As far as I can tell, the forward can go to any mail address.

Technically yes (at least assuming there's no DPI firewall to stop this
forwarding). What's allowed under the employee's terms of employment is
another matter however.

Some environments can have perfectly good reasons to forward that mail
remotely, too.

--
Pure Personal Opinion | HoffmanLabs LLC

Jan-Erik Soderholm

2017-06-28 21:09:02 UTC

Post by j***@yahoo.co.uk
Might forwarding mail sent to SYSTEM to some semi-random
personal account be a security risk? Especially if the
semi-random personal account isn't particularly secure?

Not really, because it's just forwarded to the VMS account(s) that
you do log into during the day.

How do you know *that* for every VMS system out there?
How do you know that the mail aren't sent to somewhere else?

That has nothing to do with what actual address you are forwarding to.

You need the same access to SYSTEM (or privileges) to forward mail to
SYSTEM to another *local* user as to *any* email receiver.

Post by Simon Clubley
If you have unauthorised people with that level of access to your VMS
systems...

If they have the access that permits them to set an forwarding address
for SYSTEM, they are by definition "authorised". If not, they would not
be able to do that.

Post by Simon Clubley
then you have far bigger problems than the forwarding of mail
sent to SYSTEM.

I do not understand what you are talking about. To forward the mails
for SYSTEM, you need access to SYSTEM (or privileges). Again, that has
nothing to do with what *address* you are actually forwarding to.

And how do you know *that*?

Because if an employee starts forwarding mail from their employer's
systems to their personal accounts without permission...

Who has said anything about doing something without permission ??
You are just making things up...

Post by Jan-Erik Soderholm
As far as I can tell, the forward can go to any mail address.

Technically yes...

And practically. It will probably be the main mailbox for either
the system manager or a group or maybe the mail API to some ticket
handling system. Does any serious system mamanger uses the *VMS*
mailbox as their main tool to handle emails? I don't think so.

Simon Clubley

2017-06-28 22:05:05 UTC

Post by Jan-Erik Soderholm
And how do you know *that*?

Because if an employee starts forwarding mail from their employer's
systems to their personal accounts without permission...

Who has said anything about doing something without permission ??
You are just making things up...

Personal account = account that the employee personally owns (say at
Google or Yahoo) that the employer does not control.

Work account = account that the employer provides to the employee
as part of their job.

An employee may be authorised to forward to their work account
but not their personal account.

You are correct that an employee may be able to set the forwarding
address to any address they want (assuming the lack of a DPI firewall)
but it doesn't mean they are authorised to do that.

It's no different from some employees being able to technically issue
some destructive SQL or DCL commands. It doesn't mean they are actually
authorised to do that in most circumstances.

John talked about forwarding to personal accounts. I just pointed
out that instead those SYSTEM emails were going to be forwarded to
another work account.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Jan-Erik Soderholm

2017-06-28 23:05:46 UTC

Post by Jan-Erik Soderholm
And how do you know *that*?

Because if an employee starts forwarding mail from their employer's
systems to their personal accounts without permission...

Who has said anything about doing something without permission ??
You are just making things up...

Personal account = account that the employee personally owns (say at
Google or Yahoo) that the employer does not control.

That, I'd call a "private" mailbox.

I have not talked about mailboxes outside of the control of the
employer or outside of the employers environment.

Post by Simon Clubley
Work account = account that the employer provides to the employee
as part of their job.

Or personal mailbox.

Yes, and that is close to always *not* an VMS mailbox. Most system
managers would probably prefer to have their work mails gathered
in their regular mailbox. And therefore also forward the SYSTEM
mails to that mailbox.

Post by Simon Clubley
An employee may be authorised to forward to their work account
but not their personal account.

Hm, with "personal" you mean an account *outside* of the employer?
I'd call that a "private" mailbox. I can have a personal mailbox
within the employer environment. If it has my name on i and it is
only me that has access to it. I do not own it, I'm just the sole
user of it (and thus personal)

I do have a personal account on the VMS boxes also, of course.
But not any private account, of course...

A mailbox on Yahoo, OTOH, would be "private". If I do not happen
to work at Yahoo, that is... :-)

Anyway, I do understand what you mean now. :-)

Hans Bachner

2017-06-29 06:46:09 UTC

[snip]
Personal account = account that the employee personally owns (say at
Google or Yahoo) that the employer does not control.
Work account = account that the employer provides to the employee
as part of their job.
[snip]
John talked about forwarding to personal accounts. I just pointed
out that instead those SYSTEM emails were going to be forwarded to
another work account.

When I mentioned "personal account" earlier in this thread I meant this
to be an account solely used by a single person as opposed to a role
account like SYSTEM. I did not mean a private account.

Jan-Erik has already supported this definition.

Having said that, mails to SYSTEM may well be forwarded to an account
outside the company that owns the system, e.g. if operation of the
system has been outsourced.

Hans.

j***@yahoo.co.uk

2017-06-29 08:34:39 UTC

When I mentioned "personal account" earlier in this thread I meant this
to be an account solely used by a single person as opposed to a role
account like SYSTEM. I did not mean a private account.
Jan-Erik has already supported this definition.
Having said that, mails to SYSTEM may well be forwarded to an account
outside the company that owns the system, e.g. if operation of the
system has been outsourced.
Hans.

Thanks all for expanding (correctly) on what apparently wasn't
sufficiently clear when I first wrote it.

"semi-random personal account" wasn't meant to imply some random
Yahoo or gmail account; it was meant to suggest an *individually
accountable and auditable* (but employer owned) mail account.

For example, MIACT::SYSTEM vs MIACT::WALLACE vs some random
Yahoo email addres (to name a couple of non-hypothetical examples
from a couple of decades ago).

There was a time when accounts that weren't individually auditable
amd loggable were often considered a Bad Thing, be it root, SYSTEM, Administrator, or whatever.

Anyway, my initial point seems to have been reasonably well
understood, thank you. Now returning y'all to 'normal' routine.

Simon Clubley

2017-06-29 12:17:15 UTC

Post by j***@yahoo.co.uk
Thanks all for expanding (correctly) on what apparently wasn't
sufficiently clear when I first wrote it.
"semi-random personal account" wasn't meant to imply some random
Yahoo or gmail account; it was meant to suggest an *individually
accountable and auditable* (but employer owned) mail account.

In which case, that's my mistake.

I've been used to having employer controlled accounts described
explicitly as "work accounts" or similar.

For me, anything described as a personal account or similar has
always been something outside of the employer's control and something
that makes you subject to potential disciplinary action if you transfer
employer controlled data to it without explicit informed consent.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Jan-Erik Soderholm

2017-06-29 13:05:10 UTC

In which case, that's my mistake.
I've been used to having employer controlled accounts described
explicitly as "work accounts" or similar.
For me, anything described as a personal account or similar has
always been something outside of the employer's control and something
that makes you subject to potential disciplinary action if you transfer
employer controlled data to it without explicit informed consent.
Simon.

Yes, I think it is clear now. :-)

Simon Clubley

2017-06-28 22:52:24 UTC

Post by Simon Clubley
If you have unauthorised people with that level of access to your VMS
systems...

If they have the access that permits them to set an forwarding address
for SYSTEM, they are by definition "authorised". If not, they would not
be able to do that.

[I forgot to respond to this bit.]

They could be unauthorised because they are either rogue employees
or external hackers who have broken into the system.

So no, just because they have access to do something, it does not
automatically mean they are authorised to have that access.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Jan-Erik Soderholm

2017-06-28 23:08:28 UTC

Post by Simon Clubley
If you have unauthorised people with that level of access to your VMS
systems...

If they have the access that permits them to set an forwarding address
for SYSTEM, they are by definition "authorised". If not, they would not
be able to do that.

[I forgot to respond to this bit.]
They could be unauthorised because they are either rogue employees
or external hackers who have broken into the system.

Right. But that has nothing to do with mail forwarding for SYSTEM.

Post by Simon Clubley
So no, just because they have access to do something, it does not
automatically mean they are authorised to have that access.

That is an error that should be fixed. Has littel or nothing to do
with mail forwarding specifically.

Post by Simon Clubley
Simon.

David Froble

2017-06-29 02:22:14 UTC

Post by Simon Clubley
Because if an employee starts forwarding mail from their employer's
systems to their personal accounts without permission...

Who has said anything about doing something without permission ??
You are just making things up...

Yeah, he does that now and then ....

:-)

Simon Clubley

2017-06-29 12:20:15 UTC

Post by Simon Clubley
Because if an employee starts forwarding mail from their employer's
systems to their personal accounts without permission...

Who has said anything about doing something without permission ??
You are just making things up...

Yeah, he does that now and then ....
:-)

$ set response/mode=good_natured

I think you will find there's a difference between making something up
and you simply not understanding what I am trying to say. :-)

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

David Froble

2017-06-29 12:55:05 UTC

Post by Simon Clubley
Because if an employee starts forwarding mail from their employer's
systems to their personal accounts without permission...

Who has said anything about doing something without permission ??
You are just making things up...

Yeah, he does that now and then ....
:-)

$ set response/mode=good_natured
I think you will find there's a difference between making something up
and you simply not understanding what I am trying to say. :-)
Simon.

I always understand. I do not always agree.

Jan-Erik Soderholm

2017-06-28 07:38:20 UTC

Post by d***@gmail.com
Noted: Like most suggestions like this though, do want VMS Mail to SYSTEM or
something more elaborate?

Mail to SYSTEM will be absolutely fine thanks; it just needs to be
a simple heads-up notification and everyone should be reading mail
sent to SYSTEM.

Speaking for everyone again?

No, I'm thinking about those people who have their VMS systems
properly configured.

Post by David Froble
Perhaps not everyone logs into the SYSTEM account.

And that has absolutely _nothing_ to do with reading mail addressed
to SYSTEM.
Simon.

$
$
$ mail

MAIL> help set forward

SET-SHOW

FORWARD

Sets a forwarding address for your mail. After you enter the
SET FORWARD command, the address you specify will receive mail
messages.

You can read the rest of the help text, I guess...

Post by David Froble
That said, I don't think anything is needed here. Several solutions that
already exist have been mentioned, and there could be more.

Stephen Hoffman

2017-06-27 22:52:25 UTC

Post by d***@gmail.com
Noted: Like most suggestions like this though, do want VMS Mail to
SYSTEM or something more elaborate?

Short...

Mail, and OPCOM to LICENSE.

Long...

If y'all are going to design a replacement notification architecture
for OpenVMS, this'd be one of many consumers. OPCOM, the security
mailbox (set audit/listener), the error logger mailbox and the error
formatter "I bring you bad news" mail, the $set_system_event call, and
the rest of the ad-hoc mechanisms used by various OpenVMS and LPs and
users are kinda scattershot, after all. But if not or in the interim,
then mail and OPCOM to the LICENSE operator would likely be the most
typical requests. And of course there'll probably be more logical
names created for this, as there's no mechanism for storing preferences
other than that sort of hackery.

Newer systems would probably use mail, and either syslog or syslog-ng
or ilk for distributed aggregation, and maybe server push
notifications. Or a combination. Push'd be used for user-specified
critical outages, and not for all the blather that OPCOM can commonly
generate. syslog et al can be fed into data reduction tools, either
running locally or remotely; Splunk or Sagan or otherwise. This is
where syslog et al is handy.

As an example of one bunch that deals with similar cases, Apple sends
out email notifications to the folks that have push notification
certificates approaching expiration within their macOS server
configurations. (I suspect Apple just keeps track of when the
certificates are due to expire, but haven't traced the network traffic
to confirm that. That'd also work for VSI-issued or VSI-involved
licenses or certificates, though not third-party-issued licenses.)

https://www.urbanairship.com/push-notifications-explained
https://www.splunk.com
https://en.wikipedia.org/wiki/Syslog-ng
https://quadrantsec.com/sagan_solution/

--
Pure Personal Opinion | HoffmanLabs LLC

Keith Cayemberg

2017-06-26 19:45:43 UTC

I forgot to include a session example od using SHELP.COM...

$ shelp hoffman,skonetski

HELP CREATE /DIRECTORY Examples !(1)
» 4.$ CREATE/DIRECTORY [HOFFMAN.SUB]
» $ SET DEFAULT [HOFFMAN.SUB]
» subdirectory named [HOFFMAN.SUB]. This directory file is placed
» in the directory named [HOFFMAN]. The command SET DEFAULT
» [HOFFMAN.SUB] changes the current default directory to this
» [HOFFMAN.SUB].

HELP LOGIN Examples !(2)
» Username: HOFFMAN

HELP SHOW DEFAULT Examples !(3)
» $ SET DEFAULT DISK5:[SKONETSKI.SOURCES]
» DISK5:[SKONETSKI.SOURCES]

HELP SHOW USERS Examples !(4)
» S_SKONETSKI BBBBBB 1
» S_SKONETSKI BBBBBB 1

HELP SPAWN Example !(5)
» %DCL-S-SPAWNED, process SKONETSKI_1 spawned
» %DCL-S-ATTACHED, terminal now attached to process SKONETSKI_1
» %DCL-S-RETURNED, control returned to process SKONETSKI

Found 14 matches within 5 topics.

$ show symbol shelp_*
SHELP_HLP_01 == "HELP CREATE /DIRECTORY Examples"
SHELP_HLP_02 == "HELP LOGIN Examples"
SHELP_HLP_03 == "HELP SHOW DEFAULT Examples"
SHELP_HLP_04 == "HELP SHOW USERS Examples"
SHELP_HLP_05 == "HELP SPAWN Example"
SHELP_TPU_01 == "EDIT/TPU SHELPLIST:SHELP_HELPLIB.HLP /READ/START=81315"
SHELP_TPU_02 == "EDIT/TPU SHELPLIST:SHELP_HELPLIB.HLP /READ/START=241765"
SHELP_TPU_03 == "EDIT/TPU SHELPLIST:SHELP_HELPLIB.HLP /READ/START=485917"
SHELP_TPU_04 == "EDIT/TPU SHELPLIST:SHELP_HELPLIB.HLP /READ/START=493532"
SHELP_TPU_05 == "EDIT/TPU SHELPLIST:SHELP_HELPLIB.HLP /READ/START=499497"
$

Cheers

Keith

$

David Froble

2017-06-21 01:27:18 UTC

The problem is that HELP should also be available from within the
current terminal session. It's just that the current HELP interface
completely and totally sucks.
Simon.

There are very few things that cannot be improved.

However, I can use the current help system. I wouldn't go so far as to say it
sucks.

Jan-Erik Soderholm

2017-06-20 07:20:06 UTC

Post by Simon Clubley
Are there any plans to enhance or replace the current version of
the HELP command ?

Hope not.

Post by Simon Clubley
Trying to use the current HELP interface is
very, very, frustrating.

It is not. It does what it need to do. For further/deeper
"help" you can use the PDFs.

Post by Simon Clubley
Would it also be better not to dump every single qualifier into it's
own help node but to have fewer help nodes overall with content
combined up into these fewer help nodes ?

$ help /nopage copy *

Prints one long list with everything there is for the COPY command.

Post by Simon Clubley
Simon.

d***@gmail.com

2017-06-20 15:51:45 UTC

On Monday, June 19, 2017 at 8:37:36 PM UTC-4, Simon Clubley wrote:

The Librarian is callable. One could implement the UI of one's choice, even if only a prototype to encourage VSI in a particular direction.

Any focus we have at this point would be on content more than presentation and there's a lot of doc work queued up.

Simon Clubley

2017-06-20 18:20:36 UTC

Post by d***@gmail.com
The Librarian is callable. One could implement the UI of one's choice, even
if only a prototype to encourage VSI in a particular direction.

Can the librarian routines be directly called from TPU other than via the
extremely limited call_user mechanism ? I'm also assuming there's no
support for character cell based colours within TPU.

It's been a long time since I directly did anything with the SMG$ library
but looking at the SMG reference manual reminds me of how convoluted it
is by today's standards.

Reading the SMG manual shows how to set the background colour using SMG$
but not the foreground colour and searching for the word "foreground"
and phrase "text color" (US spelling) in the manual didn't find anything.

I've found a non-DEC online example which shows how to set the foreground
colour using SMG$M_USER1 to SMG$M_USER8 but if that's how you do it then
it's _seriously_ convoluted even by DEC's standards. :-)

Am I missing something when it comes to setting foreground colours in SMG ?

BTW VSI, if that is how you really set a foreground colour using SMG, then
that information really needs to be directly referenced from within the
SMG manual itself.

Do any of the languages available as part of the hobbyist program (other
than curses in C) support some higher level forms/window management
system which has colour support ?

Thanks,

Simon.

PS: And if I am motivated to do something here, it will not be in
the near future. There's a lot of other hobbyist work which is going
to come first. :-)

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

d***@gmail.com

2017-06-20 18:59:04 UTC

TPU has a HELP_TEXT built-in which will fetch from a help library into a buffer. I don't believe TPU has direct support for colors, but I haven't written much in TPU lately although I did add the following to the edit history of my full-screen directory utility written entirely in TPU:

! 18-Jan-2016 - The size of things have changed quite a bit in
! the last 30 years. Make larger filenames and
! block sizes work.
! [Version V3.2-00]

The previous edit history entry is dated 8-Nov-1990

Post by Simon Clubley
Can the librarian routines be directly called from TPU other than via the
extremely limited call_user mechanism ? I'm also assuming there's no
support for character cell based colours within TPU.

Simon Clubley

2017-06-20 22:09:20 UTC

Thank you. Unfortunately, it looks like it is the formatted and
summarised output instead of the structured help file as stored
in the help library.

This is an example TPU program I created:

help_test := create_buffer("help_test");
help_text("helplib", "help", OFF, help_test);
write_file(help_test, "sys$output:", OFF);
quit(OFF);

If you run that from the command line as:

edit/tpu/command=test_help.tpu/nosect/noini/nodisp

you get the same output as typing "help help" at DCL instead of
the file you get if you use the librarian to extract the HELP
module from HELPLIB.

As such, I can't really use it in a new HELP reader but thanks
for the idea anyway.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Bob Koehler

2017-06-20 20:53:22 UTC

Post by d***@gmail.com
The Librarian is callable. One could implement the UI of one's choice, even
if only a prototype to encourage VSI in a particular direction.

Can the librarian routines be directly called from TPU other than via the
extremely limited call_user mechanism ? I'm also assuming there's no
support for character cell based colours within TPU.

TPU has a built-in interface to help libraries. I've used it
to access my own help libraries.

Stephen Hoffman

2017-06-21 02:28:14 UTC

Post by d***@gmail.com
The Librarian is callable. One could implement the UI of one's choice,
even if only a prototype to encourage VSI in a particular direction.
Any focus we have at this point would be on content more than
presentation and there's a lot of doc work queued up.

I'm going to here separate the discussion of the HELP library contents
from the discussion of the tools, and of the general organization of
the HELP libraries and the documentation web sites.

I do not expect VSI to fix HELP. Not any time in the next five years,
or maybe longer. But eventually, it'll likely all get replaced.

HELP is limited, and as has already been discussed.

As a text viewer, HELP is crayon-grade. One of the easiest ways to
use it now, if you don't simply go to the documentation web server and
your preferred web search engine, or to your local cache of PDF files
and macOS Spotlight search? Extract the whole help library to text.
Then use vim or emacs, or use EDT and SEARCH if that's what's available
or if that's what is your preferred tool chain on your OpenVMS box.

As for the future, why the futz would any developer even look to use
anything as completely ill-suited and limited as the librarian? The
existing HELP tool and the librarian support for the help functions is
a wonderful example of the compromises that were appropriate for the
era, and for what was available and expected. Those compromises then
become the norm for OpenVMS users, as we see in each discussion that
arises on this topic. HELP is an old UI design and and old
implementation, and it works well — within the limits of RMS and that
era's text processing norms, and with the utter and complete lack of
links or cached searches or images or the rest. Having used the APIs
in more than a few implementations, the librarian and help library APIs
also have their share of issues. Then there are the dependencies on
tools such as DEC Document to generate the help libraries. These
tools either no longer exist, or are cobbled-together at each site, all
of which leaves folks rolling their own tools to generate help text, or
just ignoring the whole mess and pointing folks at HTML docs.

But for a platform seeking to be competitive in this era and to
encourage folks to learn and use and master an unfamiliar platform,
HELP falls short. The concept of having a split documentations et
with a cut-down reminder — with the sort-of subset contents of the help
libraries, and the full documentation set available "elsewhere" — just
doesn't work very well now. If it ever did work very well. Why not
have all of the material always available, or maybe that hesitation I'm
now hearing from some readers is because the HELP tools... maybe...
just... don't... work... very... well? (That's before we discuss
diagrams and images, faster local caches and doc updates, access to
examples and a whole host of related topics. One being integration of
feedback directly from users as well as indirectly from tracking
activity in the documentation to see where folks are looking, and what
terms they're searching for, You know, terms like like "firewall".)

In this future era OpenVMS is looking to compete and grow, it's likely
going to be HTML-based documentation with links to PDF and examples and
to the VSI web site, with a modern caching search engine and with
hyperlinks, and with Lynx or analogous for those operating at the
command line. With the character-cell viewer probably invoked by the
HELP command. Typically with the full doc set installed onto the
system disk, as we're not dealing with disk capacity issues. Well,
outside of the capacity of optical media and optical media
installations, and that's a whole 'nother discussion and a whole
'nother historical preservation project.

Then there's the discussion of an IDE and integration with the VSI
documentation, and I'd wager that most any IDE developers — LSEDIT or
otherwise — would be really happy to have the HTML available either
directly or from some local data store. Not having to wade through
the librarian, or package and cache the HTML docs. Preferably also
with a Lynx-like or other tool or API or framework to avoid having to
drag along the HTML rendering code and the rest, for those developers
and apps still using character cell interfaces.

As for end-users in the present era, one of the "easiest" ways to deal
with this existing HELP file mess is to extract the help text to text
files and read and search that,

I'm also ignoring discussions of accessibility here too, though that's
certainly also a factor for a number of folks that are looking to use
and learn OpenVMS.

--
Pure Personal Opinion | HoffmanLabs LLC

IanD

2017-06-21 12:05:40 UTC

While we are at it, if we go to something like a notebook style system, then we could have inbuilt syntax correction and preemptive statement completion as well to wow future VMS onlookers with

I'll vote for anything that increased productivity, reduces errors and/or reduces and eliminates silly mistakes

This is where gui's come into their own, simple things like drop down selections help reduce wrong entry etc

Wasn't it vaxsim that has simple command correction years ago?

IanD

2017-06-21 06:15:11 UTC

On Wednesday, June 21, 2017 at 11:12:37 AM UTC+10, ***@gmail.com wrote:

<snip>

Of course the whole thing could be converted to cross-link html and viewed
in a browser, but that would assume that everyone on VMS has a browser
which would be a very bold(?) assumption.
The Help utility could also be made redundant by providing on-screen
(split-screen?) dynamic Help as the user enters input (e.g. enter COPY
and without hitting <Return> you are shown the parameters and all the qualifiers, enter a qualifier and the options are displayed) but would
we really want that?

If one is going to that level, then change VMS to have an interface similar to Jupyter Notebook

You can then unify everything under the one banner and distribute notebooks easily

But this is a long long long way off, if ever

At some point in time the decision will have to be made for various components, do we keep enhancing a dead horse (HELP) or do we transition to something new and what to do to move those caught in no-man's land

if you want to have a look at what it is and how useful it is as an interface, look here...

https://www.datacamp.com/community/tutorials/tutorial-jupyter-notebook#gs.gGU_yu8

The most value i got from VMS HELP was the examples but this has over the years given way to Google searches which can return a lot more information with even more examples

The worlds moved on from VMS HELP imo

m***@gmail.com

2017-06-21 01:12:36 UTC

Simon,

Linux/unix doesn't have decent written documentation with the o/s
so its help contains a lot of supporting information about how to
use utilities and routines. VMS does have detailed written
documentation that's usually much better than Linux/unix.

I'm sure you know all this but I mention it for a reason. VMS Help
is very much just Help with parameters, qualifiers and arguments for
commands, utilities and routines.

I'm not sure why you'd need arrows to go to associated Help items,
in fact I can't see a lot of cross-referencing in Help at all.

One thing that I'd like in Help it's to list each parameter, qualifier
or argument on a separate line with a very brief description (just a
few words) rather than all items listed without description at the
bottom of the page. This would reduce looking at a wrongly guessed
item and having to backtrack and go down another branch to look at a
different item.

I'd also like to see, where relevant, the Help items grouped in a manner
similar to those for "Help backup" because this would make it easier to
find what you're looking for.

Both of these are "nice to have" and are a long way from show-stoppers.
It's just that I thought I'd throw the ideas on the table in case
anyone is thinking about modifying Help.

Of course the whole thing could be converted to cross-link html and viewed
in a browser, but that would assume that everyone on VMS has a browser
which would be a very bold(?) assumption.

The Help utility could also be made redundant by providing on-screen
(split-screen?) dynamic Help as the user enters input (e.g. enter COPY
and without hitting <Return> you are shown the parameters and all the qualifiers, enter a qualifier and the options are displayed) but would
we really want that?

Stephen Hoffman

2017-06-21 20:22:14 UTC

Linux/unix doesn't have decent written documentation with the o/s so
its help contains a lot of supporting information about how to use
utilities and routines. VMS does have detailed written documentation
that's usually much better than Linux/unix.

I'm finding some of the Unix documentation equal or better than OpenVMS
documentation. Whether or not you agree with that however, most
everyone here will agree that the documentation for all products is
getting better, and that depending on the quality of twenty or thirty
year old documentation is problematic.

Some of the BSD doc is quite good, and when I have a question there are
resources and examples available via searches.

OpenVMS, being rather more rare and insular, has far fewer resources
available. There was one rather more, and AskQ (TIMA/STARS) was
disconnected and retired far too long ago. There's more than a little
of the extended OpenVMS documentation set — I can point to a dozen
areas or more of OpenVMS-related documentation that are memorably
painful, and various of these are critical parts of modern environments
— that needs work, too.

There's a massive amount of macOS developer documentation available and
much of it's useful, and it's far better integrated with the
development tools.

I never thought I'd be in the situation were an IDE is preferable to
the command line, but for many tasks I'm faster in an IDE, particularly
because I have (among other features) context-sensitive help and ready
access to example code, and that's before discussing syntax assistance
and surprisingly effective code completion. Yes, there are still
some rough areas in BSD and macOS documentation. And in the OpenVMS
documentation, too — various features were only ever documented in the
release notes or in the patch text, for instance. But as for tools, I
much prefer Xcode to LSEDIT. Because it's better at accessing the doc.

Why do I mention IDEs in the context of improvements around the HELP
utility? Because I'd expect that any VSI or third-party framework or
command-line tool would work with an embedded documentation service
installed on VSI OpenVMS, too.

Why are we still puttering around with help libraries based on the
OpenVMS librarian, too? The librarian is functional for the linker and
some other tasks with some compromises — some of the multi-architecture
support is a little lacking and making changes to the help library
formats is the usual RMS record-format slog-mess — but there are
compromises around documentation.

I'm sure you know all this but I mention it for a reason. VMS Help is
very much just Help with parameters, qualifiers and arguments for
commands, utilities and routines.

Sure, but how much of that was because that was what HELP could do,
what storage was available, the constraints that existed twenty or
thirty years ago, and related details.

Even DEC started to back away from that with the documentation disks,
though the initial efforts there involved a viewing tool (BNU) that was
quickly replaced. http://h41379.www4.hpe.com/wizard/swdev/bnu.html

Put another way, who would take that same "it's only a subset" position
about the integrated OpenVMS documentation, and would make the same
compromises that went into HELP and BNU in this era?

I'm not sure why you'd need arrows to go to associated Help items, in
fact I can't see a lot of cross-referencing in Help at all.

Maybe that's because the tools — HELP, DEC Notes, for that matter —
don't support any sort of links? DEC VTX and some old tools did, but
few OpenVMS folks ever saw that package. HELP never got there, and
HTML and web browsers completely blew past the whole doc design and the
current implementation.

One thing that I'd like in Help it's to list each parameter, qualifier
or argument on a separate line with a very brief description (just a
few words) rather than all items listed without description at the
bottom of the page. This would reduce looking at a wrongly guessed
item and having to backtrack and go down another branch to look at a
different item.
I'd also like to see, where relevant, the Help items grouped in a
manner similar to those for "Help backup" because this would make it
easier to find what you're looking for.
Both of these are "nice to have" and are a long way from show-stoppers.
It's just that I thought I'd throw the ideas on the table in case
anyone is thinking about modifying Help.
Of course the whole thing could be converted to cross-link html and
viewed in a browser, but that would assume that everyone on VMS has a
browser which would be a very bold(?) assumption.

Which six folks don't have a web browser available, and why should
those six folks be considered anything other than a curiosity when
designing a modern documentation access in this era? Sure, if you're
on OpenVMS itself, there are issues, but any solution here — like maybe
serving the doc from an integrated web server or from the VSI web site?
Okay, I'm kidding about the part with VSI having a web site.

The Help utility could also be made redundant by providing on-screen
(split-screen?) dynamic Help as the user enters input (e.g. enter COPY
and without hitting <Return> you are shown the parameters and all the
qualifiers, enter a qualifier and the options are displayed) but would
we really want that?

Donno. Do folks try to multiplex all that stuff into a single
terminal session? Don't most folks open up windows into the
documentation via the local GUI, and only wade into HELP — given its
constraints — as a last resort, and then from a separate session login?
I know I seldom bother with HELP, as its contents are incomplete,
it's frustratingly difficult to navigate, and contain a summary or
intro at best, and are particularly unhelpful when developing software.
DDG for the web server with the documentation, or open the PDF
directory, and either Spotlight search for what's needed or open the
PDF in Preview (the PDF tool) and Spotlight search from there. Or go
access the header files and figure out the calling sequences from
there. Put another way, I only occasionally use command-line HELP
and then only as a reminder and only because that's — on a good day —
all of what HELP is capable of. I'd really prefer to see HELP be
replaced with something more capable, though I fully expect severe
limits to the command line interface and a navigation interface roughly
akin to info or Lynx or pico.

--
Pure Personal Opinion | HoffmanLabs LLC

Scott Dorsey

2017-06-21 21:34:00 UTC

Post by Stephen Hoffman
I'm finding some of the Unix documentation equal or better than OpenVMS
documentation. Whether or not you agree with that however, most
everyone here will agree that the documentation for all products is
getting better, and that depending on the quality of twenty or thirty
year old documentation is problematic.

I would disagree... if anything Unix documentation is getting worse.

Check out the Solaris manual set... it's as complete and detailed as the
grey wall. Check out the 10-volume set that came with SunOS (which was
BSD with bugs added). Hell, check out the Ultrix manual which was mostly
copied from the BSD. You won't find anything anywhere near as good as
any of these for current Linux or OSX.

Post by Stephen Hoffman
There's a massive amount of macOS developer documentation available and
much of it's useful, and it's far better integrated with the
development tools.

This is true. But why are there so many OSX commands that don't have man
pages?
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Stephen Hoffman

2017-06-22 13:21:21 UTC

I would disagree... if anything Unix documentation is getting worse.
Check out the Solaris manual set... it's as complete and detailed as
the grey wall. Check out the 10-volume set that came with SunOS (which
was BSD with bugs added). Hell, check out the Ultrix manual which was
mostly copied from the BSD. You won't find anything anywhere near as
good as any of these for current Linux or OSX.

Post by Stephen Hoffman
There's a massive amount of macOS developer documentation available and
much of it's useful, and it's far better integrated with the
development tools.

This is true. But why are there so many OSX commands that don't have
man pages?

Short answer...

So VSI doesn't copy the bad ideas and the worst of the implementations.
And so VSI does some work to remediate some of the worst areas of
OpenVMS, too. This competitive-comparison for product improvements
isn't really all that hard, after all. Look at both the good ideas
and the bad, and pick what works and avoid what doesn't. Also to see
if there's a way to fix the shared problem areas differently, too.

Long answer...

I'm also of two minds around documentation. Users and even
administrators — another area where OpenVMS terminology diverges from
the norm, but I digress — should need little or no documentation for
common tasks, and what they do need should increasingly be specifically
for their own applications. The user interface is a major part of the
documentation. Developers and administrators still need
documentation of course, but they too should need less documentation on
specific areas even as the scale of what they're working with
increases. Particular efforts should be made toward reducing the
documentation necessary for common tasks, too. Setting the IP address
continues to be an issue for inexperienced OpenVMS folks, but that's
part and parcel of the network dis-integration that arose back when DEC
bet on OSI — and lost at NIH — and the IP implementation never
recovered. Yes, maybe VSI IP fixes this, but the technical fallout
from that early anathema is still deeply ingrained. But I digress,
again. And where there are common tasks, there should be cookbooks.

There's also that documentation is far more difficult to write than
many realize, and where problems in the software or the design make the
documentation worse. OpenVMS started out with really good designs and
really good documentation, and a lot of that is still available. In
more recent years, there have been compromises. The current VSI
documentation is an example of this, where there's way too much wording
here, and there are clearly compromises made in the software that were
then pushed over into the documentation and into the end-user. For
example, checking and resetting system disk root directories. That
could have been detected in software, and maybe ANALYZE /DISK /REPAIR
fixes it. That would have been the classic it-just-works approach,
after all. There's a similar compromise lurking in BACKUP for that
matter, where the internal design of that tool didn't allow for the
automatic detection of corrupt saveset metadata and resolve what it can
without tossing fatal errors, but at least now there is a way to at
least manually repair the saveset with BACKUP /REPAIR without needing
additional arcane and ill-documented-in-this-context DCL commands or
procedures to repair the savesets. There are other gaps in the
OpenVMS tools and docs, and I'd hope VSI doesn't propagate those, much
as they shouldn't copy the lack of documentation found on other
platforms. But I digress yet again.

There's also that macOS has relatively little user documentation, and
that's because it's much easier to use than OpenVMS. Most folks won't
want to know as much nor put up with what Phillip does, after all.
Once into the Unix layers, yes, there should be more documentation with
macOS, but the GUI means that most folks never need the command line.
OpenVMS doesn't have that luxury, being command-line based, and lacking
any sort of GUI installation or configuration tools, and OpenVMS
documentation and tips rather less than ubiquitous in the results of
your average web search. I really should allocate some time to upgrade
and overhaul that web content management system, too. But I digress,
yet anew.

TL;DR: Rounding back to the posting that started off this thread, it's
around improving the online HELP tools and the associated documentation
navigation, and rather less around the documentation content. HELP
does need HELP, too. But HELP isn't going to be a priority for VSI
for a while, and — pragmatically — the documentation backlog and the
need for UI improvements will never end. Not on any operating system
project. Swipe good ideas where they're found, and learn from and
avoid the worst of the mistakes. Deprecate and remove the worst of
your own mistakes, too.

--
Pure Personal Opinion | HoffmanLabs LLC

Jan-Erik Soderholm

2017-06-22 15:54:52 UTC

There's also that macOS has relatively little user documentation, andh
that's because it's much easier to use than OpenVMS.

I don't think one can simply compare VMS and macOS just like that.
They have such different uses, after all. Most macOS users just open
the screen on their Mac laptop and start working in whatever application
they happen to use. Most folks that are actual *users* of VMS are
programmers and system managers. The rest are users of different
applications that has very little with VMS as such to do, they
could have been running on anything and the users doesn't care.

If you want to compare, use macOS and Windows instead. They have
similar profiles in the user base. How much documentation comes
with a standard Windows10 laptop? And for those few that want to
program on Windows, there is MSDN with *a lot* of documentation.

If you want to compare VMS, use AIX, MVS, Solaris or any other
OS that have the same usage profile. That is, backend systems
with no end-users doing anything directly in the OS as such.

Simon Clubley

2017-06-22 17:56:14 UTC

Post by Stephen Hoffman
The current VSI
documentation is an example of this, where there's way too much wording
here, and there are clearly compromises made in the software that were
then pushed over into the documentation and into the end-user.

I installed HP Pascal for the first time ever last night and I noticed
the installation guide was no different from the other installation
guides which require you to do a number of things manually which should
be automated by the installation routine.

For example, in the 1980s, it was ok to require someone to manually
calculate and adjust GBLPAGES and GBLSECTIONS. It is not ok to
require someone new to VMS to do this in 2017. This should be part
of the installation routine and done for you automatically after
the installation routine tells you what it needs to do and asks you
if it is ok to do this.

Ideally however, these values should be large enough that such
adjustments are not necessary for most systems and the installation
routine can carry out a simple check before continuing with the
installation.

Oh, and for those products which require it, if you know the installation
account needs certain minimum values for some quotas, then for goodness
sake, tell the user and then offer to adjust them upwards.

Now to get an overview sometime of how HP Pascal compares to the rest
of the Pascal implementations out there...

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Robert A. Brooks

2017-06-22 18:39:45 UTC

Post by Simon Clubley
For example, in the 1980s, it was ok to require someone to manually
calculate and adjust GBLPAGES and GBLSECTIONS. It is not ok to
require someone new to VMS to do this in 2017. This should be part
of the installation routine and done for you automatically after
the installation routine tells you what it needs to do and asks you
if it is ok to do this.
Ideally however, these values should be large enough that such
adjustments are not necessary for most systems and the installation
routine can carry out a simple check before continuing with the
installation.

The entire SYSGEN param mechanism annoys me; we shouldn't need to change that
many knobs. It may have made sense 40 years ago, but with systems whose minimum
memories are now 1GB (the IA64 minimum), we don't need to worry about every
byte. Yeah, I know that Alphas can have much smaller memories, so that would
have be dealt with somehow.

I think that we should completely redo the default values, and remove many
parameters, pinning them at preset values that don't need to change.

Perhaps for V9 . . .

--
-- Rob

Scott Dorsey

2017-06-22 18:48:09 UTC

Post by Robert A. Brooks
The entire SYSGEN param mechanism annoys me; we shouldn't need to change that
many knobs. It may have made sense 40 years ago, but with systems whose minimum
memories are now 1GB (the IA64 minimum), we don't need to worry about every
byte. Yeah, I know that Alphas can have much smaller memories, so that would
have be dealt with somehow.

I like the mechanism a lot, because I _can_ control things and when I change
them, they stay set the way I want them to be set. Dynamic stuff can make
debugging much more difficult.

Post by Robert A. Brooks
I think that we should completely redo the default values, and remove many
parameters, pinning them at preset values that don't need to change.

Now this, I absolutely, absolutely agree with. The defaults should be
reasonable so that you should only have to go in and make changes under very
rare circumstances.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

j***@yahoo.co.uk

2017-06-22 19:59:47 UTC

Post by Robert A. Brooks

The entire SYSGEN param mechanism annoys me; we shouldn't need to change that
many knobs. It may have made sense 40 years ago, but with systems whose minimum
memories are now 1GB (the IA64 minimum), we don't need to worry about every
byte. Yeah, I know that Alphas can have much smaller memories, so that would
have be dealt with somehow.
I think that we should completely redo the default values, and remove many
parameters, pinning them at preset values that don't need to change.
Perhaps for V9 . . .
--
-- Rob

Fair enough, be annoyed by the entire SYSGEN parameter thing.
There are definitely opportunities there, if there is time
and money to invest.

But also know thine enemy, know what the reality is out there
(as well as the view through rose pink spectacles). Windows
boxes (and to a lesser extent Linux systems) have a gazillion
barely-documented system parameters too, though fortunately
most of them don't need to be touched much (if at all).

On a Window box they're in the delight called the registry;
who knows where they'll be in any given Linux box (but if
you don't know, the source will help, eventually).

And who knows what they affect, and how, if there's no
access to the source?

In fact MS themselves sometimes don't know (or much care)
what their own parameters are for and what the values do.

I remember sometime in the last decade playing with a high
speed serial driver which was unable to keep up under Windows
(this is my standard example). Somewhere there's a barely
documented binary valued registry key that specifies whether
driver code is pageable or not.

MS's own websites couldn't agree whether 0 meant pageable or
1 meant pageable.

For my purposes, changing the value didn't change my problem
symptoms so maybe it had no real effect anyway.

But documentation doesn't matter, and nor does accuracy,
and nor do capabilities, and nor does performance, because
it's Windows and every IT department loves Windows (love
all those helldesk jobs for trainee admins, never mind the
actual TCO).

If civil engineers built bridges the way MS built OSes,
that used to be the standard joke... can't find the quote
though :(

David Froble

2017-06-22 22:23:29 UTC

Post by Robert A. Brooks

The entire SYSGEN param mechanism annoys me; we shouldn't need to change
that many knobs. It may have made sense 40 years ago, but with systems
whose minimum memories are now 1GB (the IA64 minimum), we don't need to
worry about every byte. Yeah, I know that Alphas can have much smaller
memories, so that would
have be dealt with somehow.
I think that we should completely redo the default values, and remove
many parameters, pinning them at preset values that don't need to change.
Perhaps for V9 . . .

+1

Gone are the days when resources were scarce. There may still be some reasons
for some of the limits, but many could go away.

Scott Dorsey

2017-06-21 13:36:13 UTC

Post by Simon Clubley
Are there any plans to enhance or replace the current version of
the HELP command ? Trying to use the current HELP interface is
very, very, frustrating.

Here is the thing: HELP is the absolute best that it can be for what it was
designed for. But it wasn't designed for what people today want.

HELP is not a reference manual, it's not a tutorial, it's a reference card.
It fulfills that function very well, and it does so better than just about
any other help system on any other OS.

The problem is that HELP was written in an age when people were expected to
have the reference manuals and the tutorials on paper in front of them in
the terminal room, whereas today people expect the online manuals to replace
those rather than supplant them.

If you had ordered 4.2BSD instead of VMS, instead of getting a huge grey or
orange wall you would have got two volumes of perhaps two inches each with
your distribution tape. One manual consisted of the man pages printed out,
manuals for every command. The other manual consisted of tutorials for the
shell, for the C and fortran compilers, for awk and printing and so forth.
And the 4.2BSD online manuals were a duplication of the first volume of the
paper manuals, available online.

The VMS help system isn't like that... it does not duplicate the information
in the paper manuals, it a quick reference to supplant it.

So the question then becomes: do people want online reference manuals with
VMS? More than that, do they possibly want online tutorials? And do they
want these to replace the existing HELP sytem or do they want them in addition
to the existing HELP system?

I'd love to have the manuals online in .pdf format to be browsed and searched
either on a VMS machine or on a desktop system. But I wouldn't want anything
like that to replace HELP, I'd want it in addition to HELP.

Post by Simon Clubley
For example, it would be nice to be able to search the HELP database
for various keywords.
It would also be _really_ nice if we could have a HELP UI which doesn't
assume it's being run on a teletype. Something like GNU info or a
character cell browser interface is the kind of thing I am thinking
about.

I think these things could be arranged, but I don't think they really make
substantive changes to HELP. If you don't know where to be looking, maybe
HELP is not what you should be using in the first place.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Jan-Erik Soderholm

2017-06-21 13:49:39 UTC

Post by Simon Clubley
Are there any plans to enhance or replace the current version of
the HELP command ? Trying to use the current HELP interface is
very, very, frustrating.

Here is the thing: HELP is the absolute best that it can be for what it was
designed for. But it wasn't designed for what people today want.
HELP is not a reference manual, it's not a tutorial, it's a reference card.
It fulfills that function very well, and it does so better than just about
any other help system on any other OS.
The problem is that HELP was written in an age when people were expected to
have the reference manuals and the tutorials on paper in front of them in
the terminal room, whereas today people expect the online manuals to replace
those rather than supplant them.
If you had ordered 4.2BSD instead of VMS, instead of getting a huge grey or
orange wall you would have got two volumes of perhaps two inches each with
your distribution tape. One manual consisted of the man pages printed out,
manuals for every command. The other manual consisted of tutorials for the
shell, for the C and fortran compilers, for awk and printing and so forth.
And the 4.2BSD online manuals were a duplication of the first volume of the
paper manuals, available online.
The VMS help system isn't like that... it does not duplicate the information
in the paper manuals, it a quick reference to supplant it.
So the question then becomes: do people want online reference manuals with
VMS? More than that, do they possibly want online tutorials? And do they
want these to replace the existing HELP sytem or do they want them in addition
to the existing HELP system?
I'd love to have the manuals online in .pdf format to be browsed and searched
either on a VMS machine or on a desktop system. But I wouldn't want anything
like that to replace HELP, I'd want it in addition to HELP.

But you have both today, right? You can use HELP for a quick lookup of
a specific switch or paramater and use the PDF docs for the details.

No, HELP is not the area in VMS that is the most urgent to change
or update, IMHO.

Scott Dorsey

2017-06-21 14:11:23 UTC

Post by Scott Dorsey
I'd love to have the manuals online in .pdf format to be browsed and searched
either on a VMS machine or on a desktop system. But I wouldn't want anything
like that to replace HELP, I'd want it in addition to HELP.

But you have both today, right? You can use HELP for a quick lookup of
a specific switch or paramater and use the PDF docs for the details.

You do, although it would sure be nice if you could search through the pdf
docs more easily and if they were somehow hyperlinked to one another.

Post by Jan-Erik Soderholm
No, HELP is not the area in VMS that is the most urgent to change
or update, IMHO.

I'd like to see better access to online manuals. But HELP isn't really even
related to online manuals.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Jan-Erik Soderholm

2017-06-21 14:48:22 UTC

But you have both today, right? You can use HELP for a quick lookup of
a specific switch or paramater and use the PDF docs for the details.

You do, although it would sure be nice if you could search through the pdf
docs more easily and if they were somehow hyperlinked to one another.

Yes, they do not use the index features and such very well. Agree there.

Post by Jan-Erik Soderholm
No, HELP is not the area in VMS that is the most urgent to change
or update, IMHO.

I'd like to see better access to online manuals.

You mean to be able to access them *at all*? :-)
He, yes. We are very close to finishing the Alpha
agreement with VSI, we'll see if that opens up any
new "hidden door" to the docs... :-)

Post by Scott Dorsey
But HELP isn't really even related to online manuals.
--scott

Robert A. Brooks

2017-06-21 15:43:48 UTC

Post by Scott Dorsey
I'd like to see better access to online manuals.

You mean to be able to access them *at all*? :-)
He, yes. We are very close to finishing the Alpha
agreement with VSI, we'll see if that opens up any
new "hidden door" to the docs... :-)

Sorry; there's no hidden door.

Yes, our website is a bit less-than-stellar.

--
-- Rob

Simon Clubley

2017-06-21 17:41:02 UTC

Post by Scott Dorsey
I'd like to see better access to online manuals.

You mean to be able to access them *at all*? :-)
He, yes. We are very close to finishing the Alpha
agreement with VSI, we'll see if that opens up any
new "hidden door" to the docs... :-)

I think Scott meant in the context of having multiple formats for the
documentation so you could choose which format was better for you.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Simon Clubley

2017-06-21 18:29:43 UTC

Post by Scott Dorsey
So the question then becomes: do people want online reference manuals with
VMS? More than that, do they possibly want online tutorials? And do they
want these to replace the existing HELP sytem or do they want them in addition
to the existing HELP system?
I'd love to have the manuals online in .pdf format to be browsed and searched
either on a VMS machine or on a desktop system. But I wouldn't want anything
like that to replace HELP, I'd want it in addition to HELP.

I forgot to answer this bit.

A modern version of the HELP system needs to stay and some way to
read the manuals from DCL needs to be added.

There's a place for both in exactly the same way that there's a place
for both man and info in 2017.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Baldrick

2017-07-04 13:29:41 UTC

Many years ago on a DECUS tape before there was even a GALAXY or
an Alpha, there was a bit of software called (if I remember rightly)
SHELP which was an SMG interface into HELPLIB.HLB. We're going back
to mid 80's and I think it was written in PASCAL. I will dig out the
references and post here. It came off a reel to reel DECUS library
tape.

Basically it threw up a screen of all the topics and you used the
cursor to navigate it, page up / page down and so on.

I'll extract the source code [content of the program etc.] and maybe
someone can look at porting it to IA64?

Baldrick

Arne Vajhøj

2017-07-05 00:29:52 UTC

Post by Baldrick
Many years ago on a DECUS tape before there was even a GALAXY or
an Alpha, there was a bit of software called (if I remember rightly)
SHELP which was an SMG interface into HELPLIB.HLB. We're going back
to mid 80's and I think it was written in PASCAL. I will dig out the
references and post here. It came off a reel to reel DECUS library
tape.
Basically it threw up a screen of all the topics and you used the
cursor to navigate it, page up / page down and so on.
I'll extract the source code [content of the program etc.] and maybe
someone can look at porting it to IA64?

I think there is a fair chance that it will just build and
run on VMS I64.

I don't think VMS Pascal or SMG$ or LBR$ has made many
non-backwards-compatible changes the last 25 years.

Arne

Simon Clubley

2017-07-12 20:33:30 UTC

I've found it Nic and yes it is written in Pascal. It's at Brian's site:

http://decuslib.com/decus/vs0174/shelp/

The documentation says bug reports should be directed to some guy
by the name of Hunter Goatley. :-)

Post by Baldrick
Basically it threw up a screen of all the topics and you used the
cursor to navigate it, page up / page down and so on.

It's better than VMS help but it's still limited however. For example,
there's no searching a tree or navigation of topics using the cursor keys.

I've still got a new help prototype on my outstanding list to look
at some time but right now other things are taking priority.

Simon.

--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

s***@gmail.com

2017-07-13 10:40:38 UTC

Do you know about FSHELP. https://www.oooovms.dyndns.org/fshelp
It does have search capability Even over multiple help files) and smg full screen (hence the FS) display

Simon Clubley

2017-07-14 00:39:54 UTC