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

[Stephen Hoffman]

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

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

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

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

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

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