Post by Stephen HoffmanPost by ***@rlgsc.comSTARTUP 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 HoffmanPost by ***@rlgsc.comAs 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 HoffmanThat 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 HoffmanPost by ***@rlgsc.comA 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 HoffmanOperating 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 HoffmanPackage 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 HoffmanPost by ***@rlgsc.comThat 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 HoffmanThe 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 HoffmanPost by ***@rlgsc.comIs 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.comIn 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 HoffmanI 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