[Info-vax] Logging systartup_vms.com progress to operator.log VMS 7.3-2

[Dave Froble]

On 10/26/2020 12:38 PM, Stephen Hoffman wrote:
> On 2020-10-26 04:37:08 +0000, geze... at rlgsc.com said:
>
>> 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 ...

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

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

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

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

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

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

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

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

> 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: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486