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