Discussion:
Logging systartup_vms.com progress to operator.log VMS 7.3-2
Add Reply
Frank Gribbin
2020-10-14 15:14:41 UTC
Reply
Permalink
VMS 7.2-2
I would like to log the progress of the system boot. It would be neat to do this to operator.log

I've seen examples where at the end of systartup_vms.com there is a command at the end along the lines of

REPLY/ALL/BELL "SYSTEM UP"

I was hoping to do something similar and have the messages recorded in the operator.log

The background is a recent incident where a boot didn't fully complete. A script invoked from systartup_vms.com bombed because of nameserver problems (the 3 nameservers are external systems). I'll add SET NOON to this script to make it more robust, but would still like to record progress.
Jilly
2020-10-14 16:33:44 UTC
Reply
Permalink
Have you tried setting STARTUP_P2 to TRUE to see if that meets your needs?

Jilly
VMS 7.2-2=20
I would like to log the progress of the system boot. It would be neat to do=
this to operator.log=20
I've seen examples where at the end of systartup_vms.com there is a command=
at the end along the lines of=20
REPLY/ALL/BELL "SYSTEM UP"=20
I was hoping to do something similar and have the messages recorded in the =
operator.log
The background is a recent incident where a boot didn't fully complete. A s=
cript invoked from systartup_vms.com bombed because of nameserver problems =
(the 3 nameservers are external systems). I'll add SET NOON to this script =
to make it more robust, but would still like to record progress.
Jeffrey H. Coffield
2020-10-14 16:43:14 UTC
Reply
Permalink
Post by Frank Gribbin
VMS 7.2-2
I would like to log the progress of the system boot. It would be neat to do this to operator.log
I've seen examples where at the end of systartup_vms.com there is a command at the end along the lines of
REPLY/ALL/BELL "SYSTEM UP"
I was hoping to do something similar and have the messages recorded in the operator.log
The background is a recent incident where a boot didn't fully complete. A script invoked from systartup_vms.com bombed because of nameserver problems (the 3 nameservers are external systems). I'll add SET NOON to this script to make it more robust, but would still like to record progress.
I add the following to the start of SYS$MANAGER:SYSTARTUP_VMS.COM:

$ SET NOON
$ OPEN/WRITE START_LOG STARTUP.LOG
$ DEFINE SYS$OUTPUT START_LOG
$ SHOW TIME

and this to the end:

$ DEASSIGN SYS$OUTPUT
$ CLOSE START_LOG
$
$ MAIL STARTUP.LOG JEFFREY/SUBJ="System Startup"
$ EXIT

realizing that the effect of "SET NOON" needs to be considered.
Volker Halle
2020-10-14 18:17:09 UTC
Reply
Permalink
Frank,

the official and supported method to log the messages occuring during system startup to a file (SYS$SYSTEM:STARTUP.LOG) is:

STARTUP_P2 = "D"

Volker.
Tony Nicholson
2020-10-15 01:05:13 UTC
Reply
Permalink
Post by Volker Halle
Frank,
STARTUP_P2 = "D"
Volker.
STARTUP_P2 changed sometime around the OpenVMS 7 timeframe to support additional options.

I place a

STARTUP_P2 = "VDC"

in my SYS$SYSTEM:MODPARAMS.DAT to permanently enable full _Verification with logfile _Dump to SYS$SPECIFIC:[SYSEXE]STARTUP.LOG with full DCP _Verification.

Also place a "$ PURGE/Keep=5 SYS$SPECIFIC:[SYSEXE]STARTUP.LOG" at the end of SYSTARTUP_VMS.COM to prune them back. When something spits out a message during boot-up then it's easy to do the detective work.

"$ MCR SYSMAN HELP Sys_Parameters STARTUP" on recent versions of OpenVMS has the details.

Tony
Bill Gunshannon
2020-10-15 13:31:57 UTC
Reply
Permalink
Post by Tony Nicholson
Post by Volker Halle
Frank,
STARTUP_P2 = "D"
Volker.
STARTUP_P2 changed sometime around the OpenVMS 7 timeframe to support additional options.
I place a
STARTUP_P2 = "VDC"
What was it we used to hear all the time about Unix being arcane
while VMS was just plain English? :-)

bill
Dave Froble
2020-10-14 18:26:39 UTC
Reply
Permalink
Post by Frank Gribbin
VMS 7.2-2
I would like to log the progress of the system boot. It would be neat to do this to operator.log
I've seen examples where at the end of systartup_vms.com there is a command at the end along the lines of
REPLY/ALL/BELL "SYSTEM UP"
I was hoping to do something similar and have the messages recorded in the operator.log
The background is a recent incident where a boot didn't fully complete. A script invoked from systartup_vms.com bombed because of nameserver problems (the 3 nameservers are external systems). I'll add SET NOON to this script to make it more robust, but would still like to record progress.
I'll just mention my practice.

SYSTARTUP_VMS.COM does the minimum necessary, then, one or more batch
jobs are run to do the rest of the startup. Network startup and such.
Additional queues. Terminal setup. Application startup(s). Most
things that are not required in SYSTARTUP_VMS.COM.

Of course, the batch jobs produce logs.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Marc Van Dyck
2020-10-15 15:26:22 UTC
Reply
Permalink
Post by Dave Froble
I'll just mention my practice.
SYSTARTUP_VMS.COM does the minimum necessary, then, one or more batch jobs
are run to do the rest of the startup. Network startup and such. Additional
queues. Terminal setup. Application startup(s). Most things that are not
required in SYSTARTUP_VMS.COM.
Of course, the batch jobs produce logs.
Same here.

In addition to producing logs, it also runs faster because running in
processes that can have much larger quota than those of the startup
process.

It also frees up the console faster, allowing sysadmins to login while
startup batch jobs are still executing, which can be useful for
troubleshooting. Of course SET LOGIN/INTER=xxx is only executed after
all startup jobs are finished, so normal users can't login before the
startup is complete.

The startup jobs execute in a dedicated queue with job limit=1.
--
Marc Van Dyck
j***@yahoo.co.uk
2020-10-15 15:42:18 UTC
Reply
Permalink
Post by Marc Van Dyck
Post by Dave Froble
I'll just mention my practice.
SYSTARTUP_VMS.COM does the minimum necessary, then, one or more batch jobs
are run to do the rest of the startup. Network startup and such. Additional
queues. Terminal setup. Application startup(s). Most things that are not
required in SYSTARTUP_VMS.COM.
Of course, the batch jobs produce logs.
Same here.
In addition to producing logs, it also runs faster because running in
processes that can have much larger quota than those of the startup
process.
It also frees up the console faster, allowing sysadmins to login while
startup batch jobs are still executing, which can be useful for
troubleshooting. Of course SET LOGIN/INTER=xxx is only executed after
all startup jobs are finished, so normal users can't login before the
startup is complete.
The startup jobs execute in a dedicated queue with job limit=1.
--
Marc Van Dyck
Same here too, for many happy years on many systems.

But I guess some folk thrive on unnecessary complexity - it
seems to have become the way of the IT department in many places.
Dave Froble
2020-10-15 20:52:54 UTC
Reply
Permalink
Post by Marc Van Dyck
Post by Dave Froble
I'll just mention my practice.
SYSTARTUP_VMS.COM does the minimum necessary, then, one or more batch
jobs are run to do the rest of the startup. Network startup and such.
Additional queues. Terminal setup. Application startup(s). Most
things that are not required in SYSTARTUP_VMS.COM.
Of course, the batch jobs produce logs.
Same here.
In addition to producing logs, it also runs faster because running in
processes that can have much larger quota than those of the startup
process.
It also frees up the console faster, allowing sysadmins to login while
startup batch jobs are still executing, which can be useful for
troubleshooting. Of course SET LOGIN/INTER=xxx is only executed after
all startup jobs are finished, so normal users can't login before the
startup is complete.
The startup jobs execute in a dedicated queue with job limit=1.
All of that. However, I allowed logins as soon as possible. Some
functions didn't need the background processes, and if they did, they
checked first. After the death of attached terminals, didn't matter,
users weren't getting on until the network was running.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
geze...@rlgsc.com
2020-10-14 18:53:37 UTC
Reply
Permalink
Post by Frank Gribbin
VMS 7.2-2
I would like to log the progress of the system boot. It would be neat to do this to operator.log
I've seen examples where at the end of systartup_vms.com there is a command at the end along the lines of
REPLY/ALL/BELL "SYSTEM UP"
I was hoping to do something similar and have the messages recorded in the operator.log
The background is a recent incident where a boot didn't fully complete. A script invoked from systartup_vms.com bombed because of nameserver problems (the 3 nameservers are external systems). I'll add SET NOON to this script to make it more robust, but would still like to record progress.
Frank,

STARTUP_P2 is indeed the supported way to get startup output written to a log. One can set it from SYSMAN, SYSGEN, or from a conversational boot. As a routine matter, I often enable it by default. When something goes wrong, the evidence is thus readily available.

There is admittedly a divergence of opinion on my next point. I am an advocate of fairly aggressive use of the STARTUP database, which is in SYS$SPECIFIC and SYS$COMMON as opposed to inserting additional code in SYSTARTUP_VMS. The STARTUP database is maintained using the SYSMAN utility. I did a session at the 2015 OpenVMS Bootcamp on a related topic. The slides are at: http://www.rlgsc.com/openvms-bootcamp/2015/sysman-for-improved-restarts.html

- Bob Gezelter, http://www.rlgsc.com
Robert A. Brooks
2020-10-14 19:31:21 UTC
Reply
Permalink
Post by ***@rlgsc.com
There is admittedly a divergence of opinion on my next point. I am an
advocate of fairly aggressive use of the STARTUP database, which is
in SYS$SPECIFIC and SYS$COMMON as opposed to inserting additional
code in SYSTARTUP_VMS.
I have no opinion on this subject, but what is the benefit of using the SYSMAN database vs.
making changes to SYSTARTUP_VMS?
--
-- Rob
Phillip Helbig (undress to reply)
2020-10-14 19:50:50 UTC
Reply
Permalink
Post by Robert A. Brooks
Post by ***@rlgsc.com
There is admittedly a divergence of opinion on my next point. I am an
advocate of fairly aggressive use of the STARTUP database, which is
in SYS$SPECIFIC and SYS$COMMON as opposed to inserting additional
code in SYSTARTUP_VMS.
I have no opinion on this subject, but what is the benefit of using the SYSMAN database vs.
making changes to SYSTARTUP_VMS?
The STARTUP database provides more flexibility with fewer keys to press
for the desired change. On the other hand, one big startup file,
whether a procedure or a log file, is arguably easier to debug.
Stephen Hoffman
2020-10-14 20:14:45 UTC
Reply
Permalink
Post by Robert A. Brooks
Post by ***@rlgsc.com
There is admittedly a divergence of opinion on my next point. I am an
advocate of fairly aggressive use of the STARTUP database, which is in
SYS$SPECIFIC and SYS$COMMON as opposed to inserting additional code in
SYSTARTUP_VMS.
I have no opinion on this subject, but what is the benefit of using the
SYSMAN database vs. making changes to SYSTARTUP_VMS?
I routinely use SYSMAN STARTUP when I want to hide code. Very few
folks know to or think to look there.

There was a big push for the use of SYSMAN back around V5 IIRC and near
the end of the DEC EMA era, though the enthusiasm for the SYSMAN tool
has waned from there.

SYSMAN had issues around properly sequencing startup dependencies, that
was never resolved, and the integration with the kit installers was
never supported.
--
Pure Personal Opinion | HoffmanLabs LLC
Phillip Helbig (undress to reply)
2020-10-14 21:00:26 UTC
Reply
Permalink
Post by Stephen Hoffman
There was a big push for the use of SYSMAN back around V5 IIRC and near
the end of the DEC EMA era, though the enthusiasm for the SYSMAN tool
has waned from there.
I like SYSMAN, but not in connection with the startup database.
Post by Stephen Hoffman
SYSMAN had issues around properly sequencing startup dependencies, that
was never resolved, and the integration with the kit installers was
never supported.
What I really want to know is why there is no rapper called MC Sysman or
MC Authorize. :-)
Bob Eager
2020-10-14 21:12:19 UTC
Reply
Permalink
On Wed, 14 Oct 2020 21:00:26 +0000, Phillip Helbig (undress to reply)
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
There was a big push for the use of SYSMAN back around V5 IIRC and near
the end of the DEC EMA era, though the enthusiasm for the SYSMAN tool
has waned from there.
I like SYSMAN, but not in connection with the startup database.
Post by Stephen Hoffman
SYSMAN had issues around properly sequencing startup dependencies, that
was never resolved, and the integration with the kit installers was
never supported.
What I really want to know is why there is no rapper called MC Sysman or
MC Authorize. :-)
Going back to TOPS-10, at least there wqas a BATMAN!
--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor
Stephen Hoffman
2020-10-14 21:19:34 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
What I really want to know is why there is no rapper called MC Sysman
or MC Authorize. :-)
The MCR command exists in a nebulous region of OpenVMS.

I tried to get rid of all references to the MCR command in the docs.

The choice was to either fully document and support it, or to remove
the existing references to MCR from the documentation, while leaving it
working.

But without opening up all the manuals, that expungement was doomed.

Another case of tribal knowledge.

Slightly less seriously: "Did you know that the DEC VAX was originally
developed to control a fleet of distributed vacbeds at major
educational and military institutions, and that the VAX/VMS (Vacbed
Management System) was written by a team of professional dominatrices
that moonlit as OS developers?" — @thugcrowd
--
Pure Personal Opinion | HoffmanLabs LLC
John Reagan
2020-10-14 21:37:32 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Stephen Hoffman
There was a big push for the use of SYSMAN back around V5 IIRC and near
the end of the DEC EMA era, though the enthusiasm for the SYSMAN tool
has waned from there.
I like SYSMAN, but not in connection with the startup database.
Post by Stephen Hoffman
SYSMAN had issues around properly sequencing startup dependencies, that
was never resolved, and the integration with the kit installers was
never supported.
What I really want to know is why there is no rapper called MC Sysman or
MC Authorize. :-)
SYSMAN reminds of JOAT. Lots of useful stuff all under one disjoint/tilted umbrella.

SYSMAN STARTUP was a great concept that fell short of the needs for some of the layered products while being just fine for others. We got the "see figure one" from VMS engineering saying "SYSMAN STARTUP is great and if you just keep repeating that yourself, you'll eventually believe it". Feh. We stood together in solidarity and walked away.
Simon Clubley
2020-10-15 12:17:11 UTC
Reply
Permalink
Post by John Reagan
SYSMAN STARTUP was a great concept that fell short of the needs for some of the layered products while being just fine for others. We got the "see figure one" from VMS engineering saying "SYSMAN STARTUP is great and if you just keep repeating that yourself, you'll eventually believe it". Feh. We stood together in solidarity and walked away.
It could always be replaced with something much more universally loved
and respected such as a port of systemd. :-)

Actually, the VMS startup procedures _could_ benefit from a much more
modular approach. Even the Unix init scripts approach is much more
modular and maintainable than what VMS currently offers.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
geze...@rlgsc.com
2020-10-15 00:27:21 UTC
Reply
Permalink
Post by Robert A. Brooks
Post by ***@rlgsc.com
There is admittedly a divergence of opinion on my next point. I am an
advocate of fairly aggressive use of the STARTUP database, which is
in SYS$SPECIFIC and SYS$COMMON as opposed to inserting additional
code in SYSTARTUP_VMS.
I have no opinion on this subject, but what is the benefit of using the SYSMAN database vs.
making changes to SYSTARTUP_VMS?
--
-- Rob
Rob,

There are several advantages to the STARTUP database/

- enable/disable works quite well for STARTUP database entries;
- database entries in the same phase are effectively executed in parallel

The dependency problem can be managed. Enabling/disabling things in STARTUP_VMS.COM is often the source of problems when people make editing errors.

Some of the granularity problems with the supplied phase structure can be ameliorated by modifying the supplied phase list to include additional phases. The base system comes with eight phases (INITIAL, DEVICES, PRECONFIG, CONFIG, BASEENVIRON, LPBEGIN, LPMAIN, and LPBETA. For ease, I often just add the rest of the Greek alphabet (DELTA, GAMMA, etc.).

SYSTARTUP_VMS.COM is executed indirectly by SYS$STARTUP:VMS$LPBEGIN-050_STARTUP.COM.s

- Bob Gezelter, http://www.rlgsc.com
Stephen Hoffman
2020-10-15 00:39:49 UTC
Reply
Permalink
Post by ***@rlgsc.com
The dependency problem can be managed. Enabling/disabling things in
STARTUP_VMS.COM is often the source of problems when people make
editing errors.
The dependency problem I'm referring to and that we've discussed some
years ago was with sequencing the startups among various products
automatically adding their own startups during product installations,
as the scheme as originally architected was found less than entirely
workable.
--
Pure Personal Opinion | HoffmanLabs LLC
geze...@rlgsc.com
2020-10-15 02:55:21 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by ***@rlgsc.com
The dependency problem can be managed. Enabling/disabling things in
STARTUP_VMS.COM is often the source of problems when people make
editing errors.
The dependency problem I'm referring to and that we've discussed some
years ago was with sequencing the startups among various products
automatically adding their own startups during product installations,
as the scheme as originally architected was found less than entirely
workable.
--
Pure Personal Opinion | HoffmanLabs LLC
Hoff,

Yes, that is a conversation that we have had. STARTUP.COM has a number of shortcomings. Could certain choices have been advantageous? Certainly. Could it have been documented better? Without a doubt.

WADR to those who worked on it, I would love to hear the rationale for certain choices. Why was network startup special cased, rather than being added to one of the existing, or a new, phase.

In the enhancement category, the use of the filename to identify a database entry was poor,. The filename should have been an overridable default (e.g., one might need to execute the same basic files with different parameters on the same node).

Those shortcomings noted, one can work around the deficiencies without an excessive amount of effort. I have done so on many occasions.

Being able to automatically spawn several tasks in parallel has been a great benefit on more than a few occasions. Being able to start a batch job from the startup sequence is also an advantage. The lack of automatic dependency mechanism is a problem, but it is not difficult to create a workable interlock (using a logical name table). The number of phases is easily corrected, as I mentioned earlier in this thread. Startup sequences are not normally high entropy, so the lack of tooling is not an excessive nuisance.

Could STARTUP be more friendly? Certainly. However, IMHO, it is better than manually hacking the SYSTARTUP_VMS.COM file.

- Bob Gezelter, http://www.rlgsc.com
David Jones
2020-10-15 12:56:26 UTC
Reply
Permalink
Post by ***@rlgsc.com
Being able to automatically spawn several tasks in parallel has been a great benefit on more than a few occasions.
I wasn't aware the startup driver spawned its procedure invocations. Good to know, buy systartup_vms is still the
supported way for sysadmins to modify startup.

As an exercise, I wrote a startup driver for my little cluster that was driven by a relational database. The schema has
a components tables that describes the startup items(including their phase), a startup table that organizes component
by node or node group alias (e.g. 'ALL'), and view for each node that extracts and sorts the components that node
needs to run at boot. The startup driver spawns multiple components to run in parallel with a barrier between each
phase.

The main purpose of this startup driver, though, was that the output of the spawned components was a mailbox that
the driver read to produce the boot log. The log tagged each line with the component that generated it, greatly helping
you track down otherwise mysterious warning messages that may occur. The tag also included a timestamp relative
to the spawn time of the component so you could determine the critical path for the startup.
geze...@rlgsc.com
2020-10-15 13:57:24 UTC
Reply
Permalink
Post by David Jones
Post by ***@rlgsc.com
Being able to automatically spawn several tasks in parallel has been a great benefit on more than a few occasions.
I wasn't aware the startup driver spawned its procedure invocations. Good to know, buy systartup_vms is still the
supported way for sysadmins to modify startup.
David,

Au contraire. The use of the STARTUP database is completely supported, if not well-documented. The commands to manipulate database entries are in the manual for SYSMAN and the HELP text.

The "modify SYSTARTUP_VMS.COM" way of doing things was the ONLY way to do things pre-V5, when STARTUP.COM was re-written as database driven and SYSMAN was added to manage things including the STARTUP database. The problem is that the change was not emphasized. The STARTUP database is a far better alternative, although far from perfect.

At various times, I considered writing a replacement with improvements, but could never justify the time.

- Bob Gezelter, http://www.rlgsc.com
Stephen Hoffman
2020-10-15 14:34:15 UTC
Reply
Permalink
Post by ***@rlgsc.com
Could STARTUP be more friendly? Certainly. However, IMHO, it is better
than manually hacking the SYSTARTUP_VMS.COM file.
Yeah; given the doc for approximately everything shows hacking on
SYSTARTUP.COM, SYSTARTUP_V5.COM, or SYSTARTUP_VMS.COM, and another
little joyous adventure, that, I have tended to stay with the DCL-based
approach.

As we've discussed.

From the far side of 2020, I see little reason and little motivation
and little incentive to change from the current morass.

Not until app packages or app bundles or app containers are also
present, and the SYSMAN STARTUP remediation or replacement can deal
with all that.

Then maybe a port of the nix package manager or whatever and a PCSI
overhaul or replacement, and integrated with SYSMAN, and providing
support for jails / sandboxes / containers.

With app bundles and ilk and the resultant more modular app packaging,
the system really has to manage the app sequencing and app dependencies
without resorting to human-edited text files.

I'd prefer an easier migration path from SYSTARTUP_VMS.COM into
whatever might replace it too and SYSMAN never offered this, but that
migration likely also means callable DCL to assist with the migration,
and that ain't happening in this decade.

Put differently: It's 2020. We have computers. I don't want to be
dinking around in startup files or in SYSMAN STARTUP. At all. I'm quite
accustomed to not dinking in those files on other platforms, and I'm
not alone there.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2020-10-15 14:56:12 UTC
Reply
Permalink
(no quote as this is not really a reply to a specific post)

WTF are people doing in their SYSTARTUP_VMS.COM ??

To me it needs 5-10 lines for VMS stuff and 5-20 lines
for application stuff.

And it is mostly just lines like:

$ @somedisk:[somedir]something_startup.com

I don't see a need for a database or anything else
advanced.

These lines are easy to find and easy to read/modify
using a plain editor.

Why complicate something that can be simple.

Sure - if you run a cluster with a lot of nodes then
a more advanced approach may be beneficial.

But how many are running VMS clusters with more
than 3 nodes?

KISS

Arne
Dave Froble
2020-10-15 15:24:50 UTC
Reply
Permalink
Post by Arne Vajhøj
(no quote as this is not really a reply to a specific post)
WTF are people doing in their SYSTARTUP_VMS.COM ??
To me it needs 5-10 lines for VMS stuff and 5-20 lines
for application stuff.
I don't see a need for a database or anything else
advanced.
These lines are easy to find and easy to read/modify
using a plain editor.
Why complicate something that can be simple.
Sure - if you run a cluster with a lot of nodes then
a more advanced approach may be beneficial.
But how many are running VMS clusters with more
than 3 nodes?
KISS
Arne
OMG! My heart won't survive the surprise! A highly unanticipated voice
of reason!
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2020-10-15 17:49:23 UTC
Reply
Permalink
Post by Arne Vajhøj
(no quote as this is not really a reply to a specific post)
WTF are people doing in their SYSTARTUP_VMS.COM ??
To me it needs 5-10 lines for VMS stuff and 5-20 lines
for application stuff.
What happens when something is uninstalled and someone has to remember
to reverse the manual changes ?

Or what if you would like a way to disable a service at startup without
having to manually edit the startup files ?
Post by Arne Vajhøj
I don't see a need for a database or anything else
advanced.
You need it when you start thinking in terms of package management.

In addition to the above examples, what about dependency management
where one package depends on another ?
Post by Arne Vajhøj
These lines are easy to find and easy to read/modify
using a plain editor.
Why complicate something that can be simple.
Because it's not as simple as it looks.

That's why every other normal operating system still around (including
Windows) has a proper package manager built into it.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2020-10-15 18:37:47 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
(no quote as this is not really a reply to a specific post)
WTF are people doing in their SYSTARTUP_VMS.COM ??
To me it needs 5-10 lines for VMS stuff and 5-20 lines
for application stuff.
What happens when something is uninstalled and someone has to remember
to reverse the manual changes ?
If somethings gets uninstalled then it need to be removed from
where ever the startup was defined.

I do not see why removing it from systartup_vms.com
should be more difficult than removing it from somewhere
else.

BTW, I would expect it to be removed from startup before
being uninstalled.
Post by Simon Clubley
Or what if you would like a way to disable a service at startup without
having to manually edit the startup files ?
Same. If one has to prevent something from starting up then one
has to do something.

If one has a religious belief that modifying systartup_vms.com
is worse than modifying something else, then one do need another
mechanism.
Post by Simon Clubley
Post by Arne Vajhøj
I don't see a need for a database or anything else
advanced.
You need it when you start thinking in terms of package management.
In addition to the above examples, what about dependency management
where one package depends on another ?
That is not really a problem on VMS today.

If VMS decided to go with the 10-25 year old approach
of installing thousands of packages system wide, then
VMS may indeed need a new way to handle startup.

Hopefully VMS does not go that route, but go the
modern route of isolated self contained installations.
Post by Simon Clubley
Post by Arne Vajhøj
These lines are easy to find and easy to read/modify
using a plain editor.
Why complicate something that can be simple.
Because it's not as simple as it looks.
That's why every other normal operating system still around (including
Windows) has a proper package manager built into it.
What is the package manager for Windows??

MSI is not a package manager.

Arne
Stephen Hoffman
2020-10-15 19:47:16 UTC
Reply
Permalink
If somethings gets uninstalled then it need to be removed from where
ever the startup was defined.
I do not see why removing it from systartup_vms.com should be more
difficult than removing it from somewhere else.
BTW, I would expect it to be removed from startup before being uninstalled.
When managing one or two systems, and with an experienced team familiar
with these tasks, and with the necessary time available, sure.

And we'll still see testing skipped, errors made, dangling dependencies
left, and cases where folks didn't unwind required system parameter
changes. And those parameter settings skew over time.

I know about all of these and other cases, having either made these
mistakes myself, or having identified and resolved these cases created
by other system managers or by product-related developers.

I can't count the number of support calls I've fielded from folks that
thought they could install or uninstall a package, and, well, failed.

Which gets back to better product and better system automation.

Which OpenVMS just isn't good at.

We're discussing this in a thread about debugging startup errors.

Which ~every experienced OpenVMS system manager has stories about.

And which is something that even experienced OpenVMS system managers
should not need nor have to deal with.



ps: https://chocolatey.org
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2020-10-16 01:00:33 UTC
Reply
Permalink
Post by Stephen Hoffman
If somethings gets uninstalled then it need to be removed from where
ever the startup was defined.
I do not see why removing it from systartup_vms.com should be more
difficult than removing it from somewhere else.
BTW, I would expect it to be removed from startup before being uninstalled.
When managing one or two systems, and with an experienced team familiar
with these tasks, and with the necessary time available, sure.
And we'll still see testing skipped, errors made, dangling dependencies
left, and cases where folks didn't unwind required system parameter
changes. And those parameter settings skew over time.
I know about all of these and other cases, having either made these
mistakes myself, or having identified and resolved these cases created
by other system managers or by product-related developers.
I can't count the number of support calls I've fielded from folks that
thought they could install or uninstall a package, and, well, failed.
I believe that.

But I am pretty confident that removing a line in systartup_vms.com
is not what was causing the problems.

Arne
Simon Clubley
2020-10-16 12:40:44 UTC
Reply
Permalink
Post by Arne Vajhøj
Post by Simon Clubley
What happens when something is uninstalled and someone has to remember
to reverse the manual changes ?
If somethings gets uninstalled then it need to be removed from
where ever the startup was defined.
I do not see why removing it from systartup_vms.com
should be more difficult than removing it from somewhere
else.
Because the whole point is that you should _not_ be removing it manually.

What you should be doing is issuing a command to remove something and
that command is only carried out after dependency checks are performed
and then an automatic removal is carried out using a predefined sequence
of steps without any manual involvement required.
Post by Arne Vajhøj
Post by Simon Clubley
Because it's not as simple as it looks.
That's why every other normal operating system still around (including
Windows) has a proper package manager built into it.
What is the package manager for Windows??
MSI is not a package manager.
Windows update and the Windows tools to allow you to install optional
Windows components. It only applies to Microsoft products, but it's
still a package manager. Full integrity and dependency checking. Full
support for automatic detection and downloading of updates. Full support
for adding component management tools in a standard way. Etc.

MSI also has many package manager features as it is the Windows version
of RPM. You can't use it to directly scan for 1000s of applications to
install but like the raw rpm command, it does much of what the rest of
a package manager does when it comes to configuring the system to support
a package and managing dependencies. Also, there's no need to manually
edit startup files.

I don't know if you have ever created any MSI install kits, but if you
have not, you should have a look at what you can do with WiX. You might
be surprised.

VMS really needs something with similar functionality to Windows update
or the Linux equivalents.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Arne Vajhøj
2020-10-16 15:31:06 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
What happens when something is uninstalled and someone has to remember
to reverse the manual changes ?
If somethings gets uninstalled then it need to be removed from
where ever the startup was defined.
I do not see why removing it from systartup_vms.com
should be more difficult than removing it from somewhere
else.
Because the whole point is that you should _not_ be removing it manually.
What you should be doing is issuing a command to remove something and
that command is only carried out after dependency checks are performed
and then an automatic removal is carried out using a predefined sequence
of steps without any manual involvement required.
You are confusing two independent topics:
* should the startup info be in a database or be a line
in systartup_vms.com?
* should the startup be removed automatically or manually?

Nothing prevents a deinstall to remove a line from
systartup_vms.com.

But note that I would expect most system managers
to want to remove startup before deinstall.

Disable startup, reboot and wait X weeks to see if
somebody need it before actual deleting it is
good practice IMHO.
Post by Simon Clubley
Post by Arne Vajhøj
Post by Simon Clubley
Because it's not as simple as it looks.
That's why every other normal operating system still around (including
Windows) has a proper package manager built into it.
What is the package manager for Windows??
MSI is not a package manager.
Windows update and the Windows tools to allow you to install optional
Windows components. It only applies to Microsoft products, but it's
still a package manager. Full integrity and dependency checking. Full
support for automatic detection and downloading of updates. Full support
for adding component management tools in a standard way. Etc.
MSI also has many package manager features as it is the Windows version
of RPM. You can't use it to directly scan for 1000s of applications to
install but like the raw rpm command, it does much of what the rest of
a package manager does when it comes to configuring the system to support
a package and managing dependencies. Also, there's no need to manually
edit startup files.
I don't know if you have ever created any MSI install kits, but if you
have not, you should have a look at what you can do with WiX. You might
be surprised.
VMS really needs something with similar functionality to Windows update
or the Linux equivalents.
MSI is more like PCSI.

MSI tries to install and checks kit and environment and if
prerequisites are not there then it aborts.

So does PCSI.

MSI obviously does not modify startup scripts as Windows does
not use such. It updates a startup database.

But try do a search on how many addon products that exists to help
do a really complete deinstall on Windows.

It is a good example of how not to do it.

Arne
Stephen Hoffman
2020-10-16 16:15:57 UTC
Reply
Permalink
Post by Simon Clubley
Post by Simon Clubley
What happens when something is uninstalled and someone has to remember
to reverse the manual changes ?
If somethings gets uninstalled then it need to be removed from where
ever the startup was defined.
I do not see why removing it from systartup_vms.com should be more
difficult than removing it from somewhere else.
Because the whole point is that you should _not_ be removing it manually.
What you should be doing is issuing a command to remove something and
that command is only carried out after dependency checks are performed
and then an automatic removal is carried out using a predefined
sequence of steps without any manual involvement required.
* should the startup info be in a database or be a line in systartup_vms.com?
* should the startup be removed automatically or manually?
Those two topics are far less independent than you seem to believe.

Put differently, go create a design for installing products which
entails automating the required system changes, and you'll find those
two topics are very much related.

How many other computers still require users to go much with startups
when installing apps? Is continuing that tradition the direction that
we're headed?
MSI is more like PCSI.
MSI tries to install and checks kit and environment and if
prerequisites are not there then it aborts.
So does PCSI.
MSI obviously does not modify startup scripts as Windows does not use
such. It updates a startup database.
But try do a search on how many addon products that exists to help do a
really complete deinstall on Windows.
It is a good example of how not to do it.
We don't need to look to Microsoft Windows to see how to create this
de-installation mess, as we have OpenVMS to provide a salient example
of the mess.

Which is what we're discussing.

And there's the related discussion around various OpenVMS updates too,
with walls of install-time text and documentation for the manual edits
required for the upgrades.

And for not the first time I've had to state this here, borrowing good
ideas does not require also borrowing the bad ones.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2020-10-19 12:29:39 UTC
Reply
Permalink
Post by Arne Vajhøj
* should the startup info be in a database or be a line
in systartup_vms.com?
* should the startup be removed automatically or manually?
In the 1970s/1980s, manually was acceptable. In the 21st century,
automatically is expected.
Post by Arne Vajhøj
Nothing prevents a deinstall to remove a line from
systartup_vms.com.
Good luck with getting that right 100% of the time in a file
which is also manually edited.
Post by Arne Vajhøj
MSI obviously does not modify startup scripts as Windows does
not use such. It updates a startup database.
True, but they are used on Linux.

On Linux, init scripts are startup scripts. Even the init scripts
architecture is still a _LOT_ cleaner than what exists in VMS.
Post by Arne Vajhøj
But try do a search on how many addon products that exists to help
do a really complete deinstall on Windows.
It is a good example of how not to do it.
I am not using Windows as an example of how things should be done but
as an example of how even Windows has update and package management
functionality that VMS is missing.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2020-10-15 20:57:02 UTC
Reply
Permalink
Post by Simon Clubley
Post by Arne Vajhøj
(no quote as this is not really a reply to a specific post)
WTF are people doing in their SYSTARTUP_VMS.COM ??
To me it needs 5-10 lines for VMS stuff and 5-20 lines
for application stuff.
What happens when something is uninstalled and someone has to remember
to reverse the manual changes ?
Or what if you would like a way to disable a service at startup without
having to manually edit the startup files ?
Perhaps one might queue up a message telling a particular service what
to do?
Post by Simon Clubley
Post by Arne Vajhøj
I don't see a need for a database or anything else
advanced.
You need it when you start thinking in terms of package management.
In addition to the above examples, what about dependency management
where one package depends on another ?
If a function is dependent on something, should not it check to see if
the required service is available?
Post by Simon Clubley
Post by Arne Vajhøj
These lines are easy to find and easy to read/modify
using a plain editor.
Why complicate something that can be simple.
Because it's not as simple as it looks.
Actually, in a decent design, yes it is just that simple.
Post by Simon Clubley
That's why every other normal operating system still around (including
Windows) has a proper package manager built into it.
Perhaps because they need them?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2020-10-16 12:45:23 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
You need it when you start thinking in terms of package management.
In addition to the above examples, what about dependency management
where one package depends on another ?
If a function is dependent on something, should not it check to see if
the required service is available?
That's the whole point of a package manager so that you don't have to code
the same checks over and over again in every application you write.

List what you need in your install script and let the package manager take
care of the details.

And don't forget that dependency requirements can be nested, which a
package manager takes care of for you.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2020-10-16 19:12:57 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
You need it when you start thinking in terms of package management.
In addition to the above examples, what about dependency management
where one package depends on another ?
If a function is dependent on something, should not it check to see if
the required service is available?
That's the whole point of a package manager so that you don't have to code
the same checks over and over again in every application you write.
List what you need in your install script and let the package manager take
care of the details.
And don't forget that dependency requirements can be nested, which a
package manager takes care of for you.
Just to clear up my confusion, are we discussing installing software,
or, starting VMS?

Regardless, applications should be complete enough to observe their
environment.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2020-10-16 20:56:24 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
That's the whole point of a package manager so that you don't have to
code the same checks over and over again in every application you write.
List what you need in your install script and let the package manager
take care of the details.
And don't forget that dependency requirements can be nested, which a
package manager takes care of for you.
Just to clear up my confusion, are we discussing installing software,
or, starting VMS?
Apps requiring startups are a subset of apps installed, and something
any new package manager will be expected to provide.

Well more than zero and somewhat less than all apps installed will have
an associated startup procedure, and various of those will also have a
shutdown procedure.

Efforts to extend both VMSINSTAL and PCSI to transparently manage app
startups failed.

I doubt that any package manager design will involve automated editing
within a DCL command procedure that is also human-edited.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2020-10-16 22:03:15 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Dave Froble
Post by Simon Clubley
That's the whole point of a package manager so that you don't have to
code the same checks over and over again in every application you write.
List what you need in your install script and let the package manager
take care of the details.
And don't forget that dependency requirements can be nested, which a
package manager takes care of for you.
Just to clear up my confusion, are we discussing installing software,
or, starting VMS?
Apps requiring startups are a subset of apps installed, and something
any new package manager will be expected to provide.
Well, I don't have any idea what a package manager is. Maybe it's
semantics? My apps do have background functions that are normally
started shortly after VMS starts, and that is triggered by the VMS startup.
Post by Stephen Hoffman
Well more than zero and somewhat less than all apps installed will have
an associated startup procedure, and various of those will also have a
shutdown procedure.
Yep, startup and shutdown, and messaging to manage the detached
functions. Been doing that for over 30 years. Got to wonder why it's
an issue now.
Post by Stephen Hoffman
Efforts to extend both VMSINSTAL and PCSI to transparently manage app
startups failed.
Would not want anything not part of the apps to have anything to do with
the apps.
Post by Stephen Hoffman
I doubt that any package manager design will involve automated editing
within a DCL command procedure that is also human-edited.
Would not do such. Too much hands-on. Much better to have messaging to
manage things.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2020-10-17 15:39:24 UTC
Reply
Permalink
Post by Dave Froble
Post by Stephen Hoffman
Apps requiring startups are a subset of apps installed, and something
any new package manager will be expected to provide.
Well, I don't have any idea what a package manager is. Maybe it's
semantics? My apps do have background functions that are normally
started shortly after VMS starts, and that is triggered by the VMS startup.
PCSI and VMSINSTAL are the two package managers encountered on OpenVMS.
PCSI is an old package manager, and with its share of issues and
limits. VMSINSTAL... suffers from its own flexibility.
Post by Dave Froble
Post by Stephen Hoffman
Well more than zero and somewhat less than all apps installed will have
an associated startup procedure, and various of those will also have a
shutdown procedure.
Yep, startup and shutdown, and messaging to manage the detached
functions. Been doing that for over 30 years. Got to wonder why it's
an issue now.
Tools increasingly automate common and error-prone tasks.

On other systems, it's quite rare to have to manage startups.

For app developers, many will automate their own deployments. That
might be DCL, or it might be using a package manager such as PCSI. Past
a handful of deployments, a package manager is usually preferable to a
manual process.
Post by Dave Froble
Post by Stephen Hoffman
Efforts to extend both VMSINSTAL and PCSI to transparently manage app
startups failed.
Would not want anything not part of the apps to have anything to do
with the apps.
The startups are part of the apps.
Post by Dave Froble
Post by Stephen Hoffman
I doubt that any package manager design will involve automated editing
within a DCL command procedure that is also human-edited.
Would not do such. Too much hands-on. Much better to have messaging
to manage things.
I'd disagree. Much prefer automated deployments. Far more reproducible results.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2020-10-19 12:35:03 UTC
Reply
Permalink
Post by Dave Froble
Well, I don't have any idea what a package manager is. Maybe it's
semantics?
https://en.wikipedia.org/wiki/Package_manager

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Simon Clubley
2020-10-19 12:31:56 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
That's the whole point of a package manager so that you don't have to code
the same checks over and over again in every application you write.
List what you need in your install script and let the package manager take
care of the details.
And don't forget that dependency requirements can be nested, which a
package manager takes care of for you.
Just to clear up my confusion, are we discussing installing software,
or, starting VMS?
They are both part of the same thing. Think about it.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Dave Froble
2020-10-19 18:01:55 UTC
Reply
Permalink
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
That's the whole point of a package manager so that you don't have to code
the same checks over and over again in every application you write.
List what you need in your install script and let the package manager take
care of the details.
And don't forget that dependency requirements can be nested, which a
package manager takes care of for you.
Just to clear up my confusion, are we discussing installing software,
or, starting VMS?
They are both part of the same thing. Think about it.
It hurts my brain to attempt to think about that. The way I see things,
those are two very different things.

Installation: loading software onto system and preparing it for
operations. A one time operation.

System startup: uh, like it reads, starting VMS. Can happen quite often.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Chris Townley
2020-10-19 20:09:39 UTC
Reply
Permalink
On 19/10/2020 19:01, Dave Froble wrote:

<snip>
Post by Simon Clubley
They are both part of the same thing. Think about it.
It hurts my brain to attempt to think about that.  The way I see things,
those are two very different things.
Installation: loading software onto system and preparing it for
operations.  A one time operation.
System startup: uh, like it reads, starting VMS.  Can happen quite often.
Not that often with VMS...

Chris
Simon Clubley
2020-10-20 12:37:16 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
That's the whole point of a package manager so that you don't have to code
the same checks over and over again in every application you write.
List what you need in your install script and let the package manager take
care of the details.
And don't forget that dependency requirements can be nested, which a
package manager takes care of for you.
Just to clear up my confusion, are we discussing installing software,
or, starting VMS?
They are both part of the same thing. Think about it.
It hurts my brain to attempt to think about that. The way I see things,
those are two very different things.
Installation: loading software onto system and preparing it for
operations. A one time operation.
It most certainly absolutely is _NOT_ a one time operation. No way.

On top of the initial installation, you have updated versions and
patches, both of which may bring along new dependencies and new versions
of existing dependencies. They may also require system level configuration
changes.

Those modified dependencies may also require upgrades in other unrelated
products.
Post by Dave Froble
System startup: uh, like it reads, starting VMS. Can happen quite often.
And what is one of the main purposes of the system startup ?

It's about starting those applications you just installed or updated
and starting them in the right order. The information and files provided
by the installation and updates are directly used by the system startup.

Like I said, installing software and starting VMS are part of the same thing.

Oh, and in case anyone thinks none of the above matters on VMS, I have
one thing to say:

HP/HPE SSL

Linux and the package managers handled that a _lot_ better than VMS did.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2020-10-20 19:12:58 UTC
Reply
Permalink
Post by Dave Froble
Post by Simon Clubley
Post by Dave Froble
Post by Simon Clubley
That's the whole point of a package manager so that you don't have to
code the same checks over and over again in every application you write.
List what you need in your install script and let the package manager
take care of the details.
And don't forget that dependency requirements can be nested, which a
package manager takes care of for you.
Just to clear up my confusion, are we discussing installing software,
or, starting VMS?
They are both part of the same thing. Think about it.
It hurts my brain to attempt to think about that. The way I see
things, those are two very different things.
Installation: loading software onto system and preparing it for
operations. A one time operation.
System startup: uh, like it reads, starting VMS. Can happen quite often.
The difference here is whether the inclusion of the startup procedure
for the app being installed is performed manually based on reading
app-provided documentation, or is automated.

The automated approach involves a request by the app developer creating
the installer package—invoking a PCSI directive or VMSINSTAL callback,
in the case of OpenVMS—in conjunction with the developers of the
package manager itself.

The automated inclusion of app-specific startup scripts into the system
startup is common on other platforms.

And no, the automated scripts aren't appended onto a human-edited file.
Other means are used to locate and sequence and invoke the startup
scripts.
--
Pure Personal Opinion | HoffmanLabs LLC
geze...@rlgsc.com
2020-10-26 04:37:08 UTC
Reply
Permalink
All,

STARTUP is a multi-faceted topic, and a fuller discussion is not appropriate for the forum of a newsgroup. I will consider writing something for my OpenVMS Consultant blog (http://www.rlgsc.com/blog/openvms-consultant/openvms-consultant.html ), unless someone at VSI reanimates the OpenVMS Technical Journal.

As I have observed elsewhere, STARTUP is not a package manager. A package manager is something else, and it would certainly be useful, although probably more complicated than it might first appear.

That said, the STARTUP mechanism is quite flexible, when used properly. Is it a perfect design? Hardly. Was the design implemented optimally? "Could have been done better" is the only fair answer. But that is besides the point. In its present form, with the existing imperfections in conception and execution, STARTUP is still a powerful tool when used properly.

In the simplest cases, STARTUP can be used as if it were the pre-Version 5 SYSTARTUP_V5.COM file, seemingly renamed SYSTARTUP_VMS.COM. In more complex cases, STARTUP can be used more as intended, to startup phases of parallel-executing tasks, with SYSTARTUP_VMS.COM being one of the individual tasks in one of the phases. Workstations and other small systems fit into the first category; larger more complex environments can benefit from the parallelization facilitated by STARTUP.COM. In one case, I was able to reduce an over 30 minute restart to mere handful of minutes.

- Boib Gezelter, http://www.rlgsc.com
Simon Clubley
2020-10-26 13:39:47 UTC
Reply
Permalink
Post by ***@rlgsc.com
All,
STARTUP is a multi-faceted topic, and a fuller discussion is not
appropriate for the forum of a newsgroup.
Why not ?
Post by ***@rlgsc.com
As I have observed elsewhere, STARTUP is not a package manager.
Nobody ever said it was or even implied that. What a startup utility
should be capable of doing OTOH is to properly sequence the startup
using information supplied with the installed packages (and installed
to the correct place by the package manager) and without the user having
to manually edit startup scripts.
Post by ***@rlgsc.com
A package
manager is something else, and it would certainly be useful, although
probably more complicated than it might first appear.
Other people have managed it and it is something VMS needs especially
as VMS moves more towards using third-party libraries. Does VMS really
need another HPE SSL fiasco ? Linux handled that situation massively
better than VMS did.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
geze...@rlgsc.com
2020-10-27 03:49:25 UTC
Reply
Permalink
Post by Simon Clubley
Post by ***@rlgsc.com
All,
STARTUP is a multi-faceted topic, and a fuller discussion is not
appropriate for the forum of a newsgroup.
Why not ?
Post by ***@rlgsc.com
As I have observed elsewhere, STARTUP is not a package manager.
Nobody ever said it was or even implied that. What a startup utility
should be capable of doing OTOH is to properly sequence the startup
using information supplied with the installed packages (and installed
to the correct place by the package manager) and without the user having
to manually edit startup scripts.
Post by ***@rlgsc.com
A package
manager is something else, and it would certainly be useful, although
probably more complicated than it might first appear.
Other people have managed it and it is something VMS needs especially
as VMS moves more towards using third-party libraries. Does VMS really
need another HPE SSL fiasco ? Linux handled that situation massively
better than VMS did.
Simon.
--
Walking destinations on a map are further away than they appear.
Simon,

I endeavor to keep newgroup postings fairly short. Covering this particularly topic is not really feasible in a very short format.

It is probably too long for a single entry in my OpenVMS blog. A better forum would be the presently-on-pause OpenVMS Technical Journal. Indeed, such an article was on my list to write when I had free time. Unfortunately, life intervened and the Journal paused before I wrote the actual article.

I have put it back on my queue.

- Bob Gezelter, http://www.rlgsc.com
Stephen Hoffman
2020-10-26 16:38:51 UTC
Reply
Permalink
Post by ***@rlgsc.com
STARTUP is a multi-faceted topic, and a fuller discussion is not
appropriate for the forum of a newsgroup.
That's hilarious. Adorable, even. 🤣
Post by ***@rlgsc.com
As I have observed elsewhere, STARTUP is not a package manager.
No one here stated it was. That written, mechanisms allowing app
startup at login and app startup at system startup and app startup at
incoming network network connections are inherent parts of a modern
package management environment, as starting up installed software is a
fundamental and inherent part of installing software. Mechanisms for
removing same at product removal, too. Either directly from a startup
database at app removal (avoiding dangling references), or implicitly
removed by the removal of the app bundle (avoiding the need for a
SYSMAN STARTUP- or SYSTARTUP*.COM-like central app startup database).
I'd tend to prefer the latter, as a simplistic bundle/directory delete
can then be used as the product removal—not none, but fewer dangling
references.
Post by ***@rlgsc.com
A package manager is something else, and it would certainly be useful,
although probably more complicated than it might first appear.
Operating systems are bigger and more complicated than many might
realize, and with whole forests of compromises and trade-offs.

And where older concepts and designs and limits are necessarily
revisited and then adapted or replaced as needed, as trade-offs and
assumptions and expectations change.

Package management, app startup, system startup, OPCOM operator
communications, system and app and security logging, job and process
control, server and configuration (increasingly remote) management,
there are many areas that need revisiting, rework, redesign, or
replacement.
Post by ***@rlgsc.com
That said, the STARTUP mechanism is quite flexible, when used properly.
The SYSMAN STARTUP stuff works, yes. Works within some exceptions and
limitations, such as the package management interface that never became
available supported.

The existing SYSMAN STARTUP interface are limited by present standards.
But then app bundles and app isolation and app security wasn't
something as commonly discussed twenty and thirty years ago, either.

Servers back then were far more isolated, and the
servers-to-administrators ratio differed.
Post by ***@rlgsc.com
Is it a perfect design? Hardly. Was the design implemented optimally?
"Could have been done better" is the only fair answer. But that is
besides the point. In its present form, with the existing imperfections
in conception and execution, STARTUP is still a powerful tool when used
properly.
Alas, ~none of the layered products and third-party products chose to
adopt SYSMAN STARTUP.

Why is that? I'd posit the failure of the package management interface.

Had the VMSINSTAL and PCSI package managers made the manual at-login
and at-startup modifications unnecessary, there'd be no need to
reference either the editing the startup files and login procedures, or
SYSMAN STARTUP commands.
Post by ***@rlgsc.com
In the simplest cases, STARTUP can be used as if it were the
pre-Version 5 SYSTARTUP_V5.COM file, seemingly renamed
SYSTARTUP_VMS.COM. In more complex cases, STARTUP can be used more as
intended, to startup phases of parallel-executing tasks, with
SYSTARTUP_VMS.COM being one of the individual tasks in one of the
phases. Workstations and other small systems fit into the first
category; larger more complex environments can benefit from the
parallelization facilitated by STARTUP.COM. In one case, I was able to
reduce an over 30 minute restart to mere handful of minutes.
I and others have achieved the same with (for instance) submitted batch
processes. But then beyond logging and communications and error
reporting and related tasks, this whole discussion is also skirting
discussions of the lack of job control and process management, because
batch is certainly not that. All of this stuff is possible on OpenVMS,
manually, or with bespoke code, or in some cases with purchased
add-ons. I've written more than a few startups, as have other folks
around here. And have ported and have written other tools to fill these
and other feature gaps.

Apropos of this whole topic, the queue manager can hang a typical
OpenVMS startup when the host name changes. The whole host name morass
is another area that needs work.

I don't expect any of this work from VSI, as they've far larger issues
to address, after the x86-64 port is completed. And before the Arm port
starts up. 😉
--
Pure Personal Opinion | HoffmanLabs LLC
Robert A. Brooks
2020-10-26 16:50:18 UTC
Reply
Permalink
And before the Arm port starts up. 😉
Wait -- who told you about that?
--
-- Rob
Simon Clubley
2020-10-26 19:11:18 UTC
Reply
Permalink
Post by Robert A. Brooks
And before the Arm port starts up. ?
Wait -- who told you about that?
You should port VMS to z/Architecture instead and sell it as a replacement
for z/OS. :-)

Simon.

PS: $ set response/mode=good_natured just in case it wasn't obvious. :-)
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Bill Gunshannon
2020-10-27 00:05:50 UTC
Reply
Permalink
Post by Simon Clubley
Post by Robert A. Brooks
And before the Arm port starts up. ?
Wait -- who told you about that?
You should port VMS to z/Architecture instead and sell it as a replacement
for z/OS. :-)
Simon.
PS: $ set response/mode=good_natured just in case it wasn't obvious. :-)
And a good thing, too. Because z/OS people are more fanatic than even
VMS people.

bill
Dave Froble
2020-10-26 18:41:25 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by ***@rlgsc.com
STARTUP is a multi-faceted topic, and a fuller discussion is not
appropriate for the forum of a newsgroup.
That's hilarious. Adorable, even. 🤣
Well, yes, I can agree with that ...
Post by Stephen Hoffman
Post by ***@rlgsc.com
As I have observed elsewhere, STARTUP is not a package manager.
No one here stated it was.
Now, maybe it's just me, and my antiquated and fossilized brain, but
that's how "I" understood the discussion, when I even thought I had a clue.

Specifically, system startup and package managers were the "same thing".
Post by Stephen Hoffman
That written, mechanisms allowing app
startup at login and app startup at system startup and app startup at
incoming network network connections are inherent parts of a modern
package management environment, as starting up installed software is a
fundamental and inherent part of installing software. Mechanisms for
removing same at product removal, too. Either directly from a startup
database at app removal (avoiding dangling references), or implicitly
removed by the removal of the app bundle (avoiding the need for a SYSMAN
STARTUP- or SYSTARTUP*.COM-like central app startup database). I'd tend
to prefer the latter, as a simplistic bundle/directory delete can then
be used as the product removal—not none, but fewer dangling references.
Well, Ok, let's look at this a bit.

Does VMS need instructions on what to do to prepare the system for
operations? Of course it does.

Do apps need instructions on what to do to prepare the apps for
operations? Sometimes. Those instructions could be applied at VMS
startup, or, at other times.

Now, I could envision some database with entries for VMS startup where
VMS reads the database entries and does whatever necessary, such as
executing an app specific set of startup instructions, just as the VMS
startup does.

But, after imagining such a database, I then have to ask, ISN'T THAT
EXACTLY WHAT SYSTARTUP_VMS.COM is? What is the real difference between
EDT and some other database editor? I will suggest the main difference
is prejudice. Is what's in place the best it could possibly be? Tell
me what in this world is. But, it does the job.
Post by Stephen Hoffman
Post by ***@rlgsc.com
A package manager is something else, and it would certainly be
useful, although probably more complicated than it might first appear.
Is such a thing attempting to cause all pegs to be square, just because
it's holes are square?

What VMS requires sure isn't done in the same manner as WEENDOZE, or any
other OS.

What my apps require will most likely not be what someone else's apps
require.
Post by Stephen Hoffman
Operating systems are bigger and more complicated than many might
realize, and with whole forests of compromises and trade-offs.
And where older concepts and designs and limits are necessarily
revisited and then adapted or replaced as needed, as trade-offs and
assumptions and expectations change.
Yep.

AUTOGEN is an example.

Network access instead of serial lines is an example.

Universal browser user interface is an example.
Post by Stephen Hoffman
Package management, app startup, system startup, OPCOM operator
communications, system and app and security logging, job and process
control, server and configuration (increasingly remote) management,
there are many areas that need revisiting, rework, redesign, or
replacement.
Always room for improvement and new ideas. Picking your tasks is also
important. Sometimes "if it ain't broke don't fix it" is reasonable,
when more important tasks exist.
Post by Stephen Hoffman
Post by ***@rlgsc.com
That said, the STARTUP mechanism is quite flexible, when used properly.
HA HA HA! Define "used properly". Perhaps that's what drives Steve's
opinion.
Post by Stephen Hoffman
The SYSMAN STARTUP stuff works, yes. Works within some exceptions and
limitations, such as the package management interface that never became
available supported.
The existing SYSMAN STARTUP interface are limited by present standards.
But then app bundles and app isolation and app security wasn't something
as commonly discussed twenty and thirty years ago, either.
Servers back then were far more isolated, and the
servers-to-administrators ratio differed.
Want to bet?
Post by Stephen Hoffman
Post by ***@rlgsc.com
Is it a perfect design? Hardly. Was the design implemented optimally?
"Could have been done better" is the only fair answer. But that is
besides the point. In its present form, with the existing
imperfections in conception and execution, STARTUP is still a powerful
tool when used properly.
Alas, ~none of the layered products and third-party products chose to
adopt SYSMAN STARTUP.
Why is that? I'd posit the failure of the package management interface.
Had the VMSINSTAL and PCSI package managers made the manual at-login and
at-startup modifications unnecessary, there'd be no need to reference
either the editing the startup files and login procedures, or SYSMAN
STARTUP commands.
Post by ***@rlgsc.com
In the simplest cases, STARTUP can be used as if it were the
pre-Version 5 SYSTARTUP_V5.COM file, seemingly renamed
SYSTARTUP_VMS.COM. In more complex cases, STARTUP can be used more as
intended, to startup phases of parallel-executing tasks, with
SYSTARTUP_VMS.COM being one of the individual tasks in one of the
phases. Workstations and other small systems fit into the first
category; larger more complex environments can benefit from the
parallelization facilitated by STARTUP.COM. In one case, I was able to
reduce an over 30 minute restart to mere handful of minutes.
I and others have achieved the same with (for instance) submitted batch
processes. But then beyond logging and communications and error
reporting and related tasks, this whole discussion is also skirting
discussions of the lack of job control and process management, because
batch is certainly not that. All of this stuff is possible on OpenVMS,
manually, or with bespoke code, or in some cases with purchased add-ons.
I've written more than a few startups, as have other folks around here.
And have ported and have written other tools to fill these and other
feature gaps.
Apropos of this whole topic, the queue manager can hang a typical
OpenVMS startup when the host name changes. The whole host name morass
is another area that needs work.
Just did that last week on an old AlphaStation 200. Yeah, I enjoy pain.
But, the system name and IP address and queue changes were not too
hard. Just not easily known. If there was one place for all that it
sure would be easier. There SHOULD be a single location for such things.

Until and if that, at least some good documentation on the task would be
a good thing. A simple method for deleting all the old queue stuff so
proper new stuff would be nice.
Post by Stephen Hoffman
I don't expect any of this work from VSI, as they've far larger issues
to address, after the x86-64 port is completed. And before the Arm port
starts up. 😉
Yeah, we're just using up bandwidth ....
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2020-10-26 19:04:12 UTC
Reply
Permalink
Post by Dave Froble
Post by Stephen Hoffman
Post by ***@rlgsc.com
As I have observed elsewhere, STARTUP is not a package manager.
No one here stated it was.
Now, maybe it's just me, and my antiquated and fossilized brain, but
that's how "I" understood the discussion, when I even thought I had a clue.
Specifically, system startup and package managers were the "same thing".
No. They are distinct in their own right, but they are also part of
the same bigger something, namely the management and making available of
packages for use.

That's what I getting at with my previous comments to you. Installation
is not a one-off process as you previously thought it was but is part of
an ongoing process of updates and patches with changing requirements and
changing dependencies. These dependencies can be nested and shared
across unrelated packages.

The package manager manages the installation and dependency management
and the startup manages the package startup sequencing using the
information provided to it by the package and the package manager.
Post by Dave Froble
Post by Stephen Hoffman
That written, mechanisms allowing app
startup at login and app startup at system startup and app startup at
incoming network network connections are inherent parts of a modern
package management environment, as starting up installed software is a
fundamental and inherent part of installing software. Mechanisms for
removing same at product removal, too. Either directly from a startup
database at app removal (avoiding dangling references), or implicitly
removed by the removal of the app bundle (avoiding the need for a SYSMAN
STARTUP- or SYSTARTUP*.COM-like central app startup database). I'd tend
to prefer the latter, as a simplistic bundle/directory delete can then
be used as the product removal?not none, but fewer dangling references.
Well, Ok, let's look at this a bit.
Does VMS need instructions on what to do to prepare the system for
operations? Of course it does.
Do apps need instructions on what to do to prepare the apps for
operations? Sometimes. Those instructions could be applied at VMS
startup, or, at other times.
Now, I could envision some database with entries for VMS startup where
VMS reads the database entries and does whatever necessary, such as
executing an app specific set of startup instructions, just as the VMS
startup does.
But, after imagining such a database, I then have to ask, ISN'T THAT
EXACTLY WHAT SYSTARTUP_VMS.COM is? What is the real difference between
EDT and some other database editor? I will suggest the main difference
is prejudice. Is what's in place the best it could possibly be? Tell
me what in this world is. But, it does the job.
EDT is manual startup management and you are on your own when making
sure that dependencies are started in the right sequence and when
applying changes after things change on updates or patches.

Everyone else does automatic startup sequencing based on the information
provided in the package.
Post by Dave Froble
Post by Stephen Hoffman
Post by ***@rlgsc.com
That said, the STARTUP mechanism is quite flexible, when used properly.
HA HA HA! Define "used properly". Perhaps that's what drives Steve's
opinion.
"Used properly": something that complies with the standards expected in
the 21st century, not what was acceptable in the 1980s.

The VMS way currently fails that definition.
Post by Dave Froble
Post by Stephen Hoffman
The SYSMAN STARTUP stuff works, yes. Works within some exceptions and
limitations, such as the package management interface that never became
available supported.
The existing SYSMAN STARTUP interface are limited by present standards.
But then app bundles and app isolation and app security wasn't something
as commonly discussed twenty and thirty years ago, either.
Servers back then were far more isolated, and the
servers-to-administrators ratio differed.
Want to bet?
I wouldn't go down that path if I were you David. Expectations have
changed in that area even if you are not aware of that.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2020-10-26 19:39:53 UTC
Reply
Permalink
Post by Dave Froble
Post by Stephen Hoffman
Post by ***@rlgsc.com
As I have observed elsewhere, STARTUP is not a package manager.
No one here stated it was.
Now, maybe it's just me, and my antiquated and fossilized brain, but
that's how "I" understood the discussion, when I even thought I had a clue.
Specifically, system startup and package managers were the "same thing".
SYSMAN STARTUP can't install apps. Therefore it is not a particularly
functional package manager.

SYSMAN STARTUP is something that is a *component* of and/or is a
*dependency* of a modern package manager.

OpenVMS has its startup-related entries, and so too do added apps.
Currently, those startup entries are hand-edited into SYSMAN STARTUP
both as installed from VSI and as modified by end-users, and are
hand-edited in SYSTARTUP_VMS.COM mostly by end-users.

VSI pre-populates the startup database, and then the app installers
provide the rest for those apps with installers, and those folks that
are not yet using their own package installers then continue to use
either SYSTARTUP_VMS.COM or SYSMAN STARTUP commands or migrate to
package installers. Once a site is doing more than a couple of installs
of its own site-local apps, package installers generally make things
faster and more repeatable—break-even is prolly around three or five
servers. And for those using their own home-grown installation scripts,
they can add SYSMAN STARTUP commands to register their app-specific
startups. (Though not for login-specific startups, as SYLOGIN and LOGIN
maintenance remains a gap within what OpenVMS offers.)

And I'm not a proponent of requiring hand edits. Not when automated
means can replace that, and can replace the need for
app-install-related SYSTARTUP_VMS.COM documentation. Which is why PCSI
and VMSINSTAL and SYSMAN STARTUP can all be improved.
Post by Dave Froble
Does VMS need instructions on what to do to prepare the system for
operations? Of course it does.
Why? Why do we need to make those startup changes?

Why do I as an end-user even need that documentation?

Why does that documentation need to exist?

Because we've always done it that way?

Or maybe because maybe the apps haven't had a way to register their
startups and their logins at install time?

I find this whole discussion interesting, even given many of the
readers here routinely use systems that register their startups at
install.

When was the last time y'all edited a system startup file on Microsoft
Windows or Apple macOS systems, or with Apple iPhone or iPad apps, or
Google Android apps, or whatever else you've recently installed apps?

(And yes, Microsoft Windows has historically had serious problems with
app removals and the resulting app debris. macOS too accretes debris.
Including this acknowledgement here because somebody will then "but
Windows stinks when doing $whatever" and necessitating me to again
state "but there's no need to preserve bad ideas such as $whatever".
Borrowing good ideas does not necessitate also borrowing or preserving
the bad ideas.)
Post by Dave Froble
If there was one place for all that it sure would be easier. There
SHOULD be a single location for such things.
That host name stuff gets embedded ~everywhere. Fifty different spots
with definitions wouldn't surprise. ~24 wasn't too difficult to hit
with OpenVMS itself and common LPs, and I've met additional entries in
more recent times.
Post by Dave Froble
Until and if that, at least some good documentation on the task would
be a good thing. A simple method for deleting all the old queue stuff
so proper new stuff would be nice.
Documentation that's not needed—much like source code that's not
needed, and that can be removed—is the best documentation.
Automatically registering startups would simplify the app-specific
installation documentation.






RB: Your now-former VP told a room full of folks about that ~six years ago.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2020-10-26 22:25:02 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Dave Froble
Post by Stephen Hoffman
Post by ***@rlgsc.com
As I have observed elsewhere, STARTUP is not a package manager.
No one here stated it was.
Now, maybe it's just me, and my antiquated and fossilized brain, but
that's how "I" understood the discussion, when I even thought I had a clue.
Specifically, system startup and package managers were the "same thing".
SYSMAN STARTUP can't install apps. Therefore it is not a particularly
functional package manager.
SYSMAN STARTUP is something that is a *component* of and/or is a
*dependency* of a modern package manager.
Just to clarify, I don't use SYSMAN unless necessary ....
Post by Stephen Hoffman
OpenVMS has its startup-related entries, and so too do added apps.
Currently, those startup entries are hand-edited into SYSMAN STARTUP
both as installed from VSI and as modified by end-users, and are
hand-edited in SYSTARTUP_VMS.COM mostly by end-users.
And if they are to be put into something else, how does that happen?
Magic hand waving? Wishful thinking? Or, perhaps you run some function
which allows you to "by hand" make the entries?
Post by Stephen Hoffman
VSI pre-populates the startup database, and then the app installers
provide the rest for those apps with installers, and those folks that
are not yet using their own package installers then continue to use
either SYSTARTUP_VMS.COM or SYSMAN STARTUP commands or migrate to
package installers. Once a site is doing more than a couple of installs
of its own site-local apps, package installers generally make things
faster and more repeatable—break-even is prolly around three or five
servers.
I've never run 5 servers at any customer site, so maybe that's why I'm
so "ill informed".
Post by Stephen Hoffman
And for those using their own home-grown installation scripts,
they can add SYSMAN STARTUP commands to register their app-specific
startups. (Though not for login-specific startups, as SYLOGIN and LOGIN
maintenance remains a gap within what OpenVMS offers.)
And I'm not a proponent of requiring hand edits. Not when automated
means can replace that, and can replace the need for app-install-related
SYSTARTUP_VMS.COM documentation. Which is why PCSI and VMSINSTAL and
SYSMAN STARTUP can all be improved.
I do agree on the possibility of improvements.
Post by Stephen Hoffman
Post by Dave Froble
Does VMS need instructions on what to do to prepare the system for
operations? Of course it does.
Why? Why do we need to make those startup changes?
I don't need to make any startup changes, once I do the initial system
set-up, unless something fundamentally changes.

But I do need to perform some initial set-up.
Post by Stephen Hoffman
Why do I as an end-user even need that documentation?
An end user doesn't. Someone who sets up systems sure does. Someone
who is going to make serious changes to a system set-up sure does.
Post by Stephen Hoffman
Why does that documentation need to exist?
So someone who needs it can access it. And there will always be someone
who needs it.
Post by Stephen Hoffman
Because we've always done it that way?
Or maybe because maybe the apps haven't had a way to register their
startups and their logins at install time?
Some things require specific knowledge.
Post by Stephen Hoffman
I find this whole discussion interesting, even given many of the readers
here routinely use systems that register their startups at install.
You mean systems where "one size fits all"? I don't think such exist.
Post by Stephen Hoffman
When was the last time y'all edited a system startup file on Microsoft
Windows or Apple macOS systems, or with Apple iPhone or iPad apps, or
Google Android apps, or whatever else you've recently installed apps?
Every time I installed something new.

I still get the impression we're not talking about the same things ..
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Craig A. Berry
2020-10-26 23:13:55 UTC
Reply
Permalink
Post by Dave Froble
Post by Stephen Hoffman
Why do I as an end-user even need that documentation?
An end user doesn't. Someone who sets up systems sure does. Someone
who is going to make serious changes to a system set-up sure does.
From the point of view of installing software, the person traditionally
known in VMS-land as the "system manager" *is* the end user. In
VMS-land, that person typically has more "post-installation tasks" (as
PCSI euphemistically calls the dangerous hand-editing of low-level
configuration scripts) than the analogous person would have on other
systems.
Post by Dave Froble
Why does that documentation need to exist?
So someone who needs it can access it.  And there will always be someone
who needs it.
But the details of how the installer interacts with the system startup
should only need to be referenced by people building installers, and
hopefully they have a nice API and don't have to know *all* the details.
The person installing software should not need to know how to implement
what the installer should be doing automatically.
Post by Dave Froble
Because we've always done it that way?
Or maybe because maybe the apps haven't had a way to register their
startups and their logins at install time?
Some things require specific knowledge.
Post by Dave Froble
I find this whole discussion interesting, even given many of the readers
here routinely use systems that register their startups at install.
You mean systems where "one size fits all"?  I don't think such exist.
Most installers on other operating system offer lots of options, so no,
one size does not fit all. But once you've answered all the
pre-installation questions, the installer just does them all rather than
listing them out for you to do manually as "post-installation tasks."
Phillip Helbig (undress to reply)
2020-10-27 06:02:57 UTC
Reply
Permalink
Post by Craig A. Berry
From the point of view of installing software, the person traditionally
known in VMS-land as the "system manager" *is* the end user.
It depends. Certainly some places have one group of people for
hardware, one group for networks, one group for system management, one
group for application support, and several groups of users of those
applications. A hobbyist typically wears all 5 hats. Small shops are
somewhere in-between.
Stephen Hoffman
2020-10-27 16:07:54 UTC
Reply
Permalink
Post by Phillip Helbig (undress to reply)
Post by Craig A. Berry
From the point of view of installing software, the person traditionally
known in VMS-land as the "system manager" *is* the end user.
It depends. Certainly some places have one group of people for
hardware, one group for networks, one group for system management, one
group for application support, and several groups of users of those
applications. A hobbyist typically wears all 5 hats. Small shops are
somewhere in-between.
You're the person that must manually edit or manually configure SYSMAN
STARTUP for the product startup, as archaic as that manual install-time
requirement might seem.

So, "From the point of view of installing software", you're the
end-user system manager here.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2020-10-28 22:44:33 UTC
Reply
Permalink
Post by Stephen Hoffman
Post by Phillip Helbig (undress to reply)
Post by Craig A. Berry
From the point of view of installing software, the person
traditionally known in VMS-land as the "system manager" *is* the end
user.
It depends. Certainly some places have one group of people for
hardware, one group for networks, one group for system management,
one group for application support, and several groups of users of
those applications. A hobbyist typically wears all 5 hats. Small
shops are somewhere in-between.
You're the person that must manually edit or manually configure SYSMAN
STARTUP for the product startup, as archaic as that manual install-time
requirement might seem.
So, "From the point of view of installing software", you're the end-user
system manager here.
When there is flexibility, there is always a cost.

I don't get out much, but, I don't know of any method to have private
disks on say, WEENDOZE. Perhaps such might exist.

If I wish to mirror (RAID1) a set of disks, doesn't that require some
set-up?

If I want to have backups, don't I need to specify what and how?

Perhaps I'm out of touch, but, it is my impression that some are
comparing "personal", ie; it is what it is, with flexible systems that
allow a lot of options.

Systems that just work out of the box are most likely less flexible.

Systems that allow many options will require some additional work.

Not saying that set-up cannot be easier and better, anything can be
easier and better. There is a cost vs benefit consideration.

Just the way I see things ..
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Stephen Hoffman
2020-10-29 14:41:29 UTC
Reply
Permalink
Post by Dave Froble
When there is flexibility, there is always a cost.
Absolutely. Testing gets more expensive and more involved, as does
compatibility, and changes are increasingly difficult, too.
Post by Dave Froble
I don't get out much, but, I don't know of any method to have private
disks on say, WEENDOZE. Perhaps such might exist.
I'm not particularly familiar with these details of Microsoft Windows
or Windows Server volume processing, nor related volume management.

macOS, Linux, and other systems allow full-device encryption. OpenVMS does not.

macOS mounts detected devices at boot, unless configured not to;
there's volume management.

Apple automatically encrypts the volume contents for internal storage
on current hardware.

OpenVMS mounts nothing past the system device. Volume management is
manual. And no full-device encryption, absent features (potentially)
offered by an external storage controller.

Volume management is another area that gets messy on OpenVMS,
particularly as the numbers of volumes increase.
Post by Dave Froble
If I wish to mirror (RAID1) a set of disks, doesn't that require some set-up?
Yes. It does. Having just gone through this sequence, setting up
RAID-1 on a NAS involves connecting to the web-based interface,
selecting the disks, and clicking the desired RAID level.

Same for configuring an external RAID array, though that required
scrounging the vendor's setup tool for the RAID array.

macOS does offer host-based RAID-1, but few folks use that. Older Apple
systems offered hardware RAID. Both hardware and software RAID can be
configured via the macOS GUI.

Setting up host-based RAID-1 on OpenVMS is more involved and arguably
more hazardous, command-line based, and part of which involves editing
the commands into the startup files.

Setting up add-on hardware RAID can scrounging the proper keyboard and
running a console-level tool, or scrounging an add-on for whatever
other hardware RAID is in use. Most of which are just awful to use—and
I know how the tools work, too.

I find the FC SAN user interface difficult, and I'm familiar with
it—the folks got it to work, and then seemingly decided "good enough".
Post by Dave Froble
If I want to have backups, don't I need to specify what and how?
With macOS, select the target device, and off it goes. The
hourly-to-daily-to-longer-term backup scheme is less flexible than some
might prefer, but trivial to configure and use.

The macOS backup strategy would be sufficient for many (most?) OpenVMS
configurations. It'll be more backups than some OpenVMS systems are
currently getting.
Post by Dave Froble
Perhaps I'm out of touch, but, it is my impression that some are
comparing "personal", ie; it is what it is, with flexible systems that
allow a lot of options.
That's an interesting discussion around user interfaces and designs;
with what's called progressive disclosure.

OpenVMS throws the whole box of parts and options and pieces at the end
user, and forces us to figure it out.

e.g. SYSMAN PARAMS
Post by Dave Froble
Systems that just work out of the box are most likely less flexible.
Are there trade-offs here? Absolutely. Dumb defaults and new user traps
should not be part of that flexibility.
Post by Dave Froble
Systems that allow many options will require some additional work.
And whether that additional work is of benefit, too.
Post by Dave Froble
Not saying that set-up cannot be easier and better, anything can be
easier and better. There is a cost vs benefit consideration.
As always. There's also always a cost-competitive consideration. Other
vendors are investing in their offerings, as well.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2020-10-27 13:24:10 UTC
Reply
Permalink
Post by Dave Froble
Post by Stephen Hoffman
OpenVMS has its startup-related entries, and so too do added apps.
Currently, those startup entries are hand-edited into SYSMAN STARTUP
both as installed from VSI and as modified by end-users, and are
hand-edited in SYSTARTUP_VMS.COM mostly by end-users.
And if they are to be put into something else, how does that happen?
Magic hand waving? Wishful thinking? Or, perhaps you run some function
which allows you to "by hand" make the entries?
You just don't get it David.

_You_ don't do anything on Linux (for example) to either install something
for startup or remove it afterwards when uninstalling the package. You tell
the package manager to install or remove the package and it does it for you.

The package managers have the ability to automatically alter the system
startup to include your newly installed package at the correct point in
the system startup. They do this by supplying the system startup with
enough information to allow it to automatically sequence the newly installed
package correctly.

What you have on Linux and elsewhere is as big an improvement over the VMS
way of doing things as (for example) the VT320 was over the ASR33. What you
are talking about simply doesn't need to happen elsewhere these days.
Post by Dave Froble
Post by Stephen Hoffman
When was the last time y'all edited a system startup file on Microsoft
Windows or Apple macOS systems, or with Apple iPhone or iPad apps, or
Google Android apps, or whatever else you've recently installed apps?
Every time I installed something new.
No you didn't. Those changes were done for you during installation (and
reverted for you automatically if you remove the package).
Post by Dave Froble
I still get the impression we're not talking about the same things ..
How would you manage 100s or even 1000s of physical servers or VM instances
using your approach ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2020-10-27 16:50:59 UTC
Reply
Permalink
Post by Dave Froble
Post by Stephen Hoffman
SYSMAN STARTUP is something that is a *component* of and/or is a
*dependency* of a modern package manager.
Just to clarify, I don't use SYSMAN unless necessary ....
Post by Stephen Hoffman
OpenVMS has its startup-related entries, and so too do added apps.
Currently, those startup entries are hand-edited into SYSMAN STARTUP
both as installed from VSI and as modified by end-users, and are
hand-edited in SYSTARTUP_VMS.COM mostly by end-users.
And if they are to be put into something else, how does that happen?
Magic hand waving? Wishful thinking? Or, perhaps you run some
function which allows you to "by hand" make the entries?
The installer registers the startup procedure in the startup procedure
database.

There's already a startup database underneath SYSMAN STARTUP, too.

The existing startup database contains entries for various existing
startup operations, including those entries configured by
VSI/HPE/HP/Compaq/DEC with OpenVMS, and those added locally.

While you might not add entries and while Bob G does and while I use
SYSMAN STARTUP to "hide" startup entries, the existing SYSMAN STARTUP
database already drives the entire system startup procedure, including
invoking SYLOGICALS.COM, SYSTARTUP_VMS.COM, and other commonly-edited
command procedures.

What's missing is the installer callbacks, or the usage of same.

For VMSINSTAL, here's the relevant callback:
VMI$CALLBACK SET STARTUP FACILITY_STARTUP.COM "VMSINSTAL DOALL"

PCSI (IIRC) had a similar mechanism, but dropped back to displaying
messages related to the EXECUTE START . . . STOP . . . statement. After
that statement is processed, PCSI then displays a message "at the end
of the operation telling users to add these commands to their
SYSTARTUP_VMS.COM file."

One of the larger issues found with the V5.0-era SYSMAN STARTUP design
was sequencing the related startups; of contending with the product
interdependencies.

Inter-dependencies are also arguably an artifact of the era of not
having enough disk space, which means we're headed for fewer kits and
fewer install-time options. There are various apps around which have
complex installers and seemingly for little added value too, such as
TCP/IP Services and DECset. But then OpenVMS is still limited to 2 TiB
storage addressing, so not quite as much room as might be found on the
boot devices of other operating systems. While I'm thinking about it,
neither PCSI nor VMSINSTAL is particularly good at installing apps off
of the system disk—having just tussled with that again. But I digress.

And again, VSI already has ♾ other pending projects in their queue,
most or all ahead of these and similar remediations.
--
Pure Personal Opinion | HoffmanLabs LLC
Volker Halle
2020-10-15 06:24:39 UTC
Reply
Permalink
Post by Frank Gribbin
VMS 7.2-2
I would like to log the progress of the system boot. It would be neat to do this to operator.log
I've seen examples where at the end of systartup_vms.com there is a command at the end along the lines of
REPLY/ALL/BELL "SYSTEM UP"
I was hoping to do something similar and have the messages recorded in the operator.log
The background is a recent incident where a boot didn't fully complete. A script invoked from systartup_vms.com bombed because of nameserver problems (the 3 nameservers are external systems). I'll add SET NOON to this script to make it more robust, but would still like to record progress.
Frank,

note that - when using STARTUP_P2="D" - all output will go to SYS$SYSTEM:STARTUP.LOG instead of to the console terminal. When you're using $ WRITE SYS$OUTPUT ... to document the progress of your system startup, you might want to add $ WRITE SYS$ERROR ... for all of these. This will make sure, that you see some progress indications on your console terminal during startup.

I've also typically added $ WRITE SYS$ERROR "For startup messages see SYS$SYSTEM:STARTUP.LOG..." at the end of SYSTARTUP_VMS.COM to remind the user where to check for startup messages.

Volker.
Frank Gribbin
2020-10-15 08:40:23 UTC
Reply
Permalink
Thankyou everyone for the helpful replies.

I will try STARTUP_P2 = "D" and like the advice to write to sys$error to get some console output.

I will have a chance to make changes next week.
Edgar Ulloa
2020-10-16 02:27:13 UTC
Reply
Permalink
Post by Frank Gribbin
VMS 7.2-2
I would like to log the progress of the system boot. It would be neat to do this to operator.log
I've seen examples where at the end of systartup_vms.com there is a command at the end along the lines of
REPLY/ALL/BELL "SYSTEM UP"
I was hoping to do something similar and have the messages recorded in the operator.log
The background is a recent incident where a boot didn't fully complete. A script invoked from systartup_vms.com bombed because of nameserver problems (the 3 nameservers are external systems). I'll add SET NOON to this script to make it more robust, but would still like to record progress.
Hi Frank try this

$mcr sysman
sysman>startup set options/verify=full/output=file/checkpointing or only partial /verify=partial
sysman>startup show options .........must be show sys$system:startup.log here keep all the log

cheers
Loading...