[Info-vax] OpenVMS STARTUP Whitepaper

[geze...@rlgsc.com]

On Friday, December 4, 2020 at 11:12:38 AM UTC-5, Stephen Hoffman wrote:
> On 2020-12-03 18:09:25 +0000, geze... at rlgsc.com said: 
> 
> > The OpenVMS STARTUP process is documented, but the information is
> > spread across several different manuals and files... 
> 
> Welcome to OpenVMS, where the doc is commonly and unfortunately quite 
> scattershot and in need of an overhaul, and where the cookbook-style 
> presentation is lacking. 
> 
> Section 11 is missing the "why" for the items listed. That detail might 
> be obvious to the writer, but not to the reader. Some New Features 
> documentation is notorious for this—here's this feature, but omitting 
> why you might want to adopt it. 
> 
> Not much on SYSMAN in that whitepaper, that being an approach you've 
> oft preferred per our previous discussions, and an approach I've become 
> fond of when seeking to "hide" startups. 
> 
> And as for the previous discussions here, this document seems thin in 
> the relevant section for that discussion; section 11. What can be fixed 
> or updated, what's missing. Better app packaging and app isolation and 
> automated means to add and remove app startups has been an ongoing 
> mess. Most apps scatter at least part of themselves into various spots 
> on an OpenVMS boot device, often requiring manual steps by the system 
> manager / app developer / app support team / Jada, the person on staff 
> that keeps that old server going. And the creation of documentation for 
> the end-user, since this presently can't be reliably automated within 
> OpenVMS. 
> 
> As I've commented previously from the earlier thread, hand-editing a 
> file to add a startup is archaic and error-prone and somewhere between 
> silly and stupid, but that's on OpenVMS and not on you. And manually 
> invoking SYSMAN to add a startup isn't appreciably better, and that 
> approach is documented and used used in approximately no layered 
> products. And manually removing those same entries, if/when necessary. 
> And whatever else the installer added. PCSI tries, but there are holes 
> there. 
> 
> And as for cookbook documentation more generally, background and 
> internals are prolly best left in an appendix at most (e.g. first 10 
> sections, here), with a discussion of options and alternatives for 
> developers as the focus. How an end-user or a layered product might use 
> the startups, and what options and alternatives exist. Because I'd 
> really rather not have to know how the OpenVMS startups work, outside 
> of the minimum necessary for an app developer or installation kit 
> author or suchlike to add and to remove the app and the startup. 
> 
> And as for passive voice in technical documentation, I prefer to avoid 
> passive voice in cases where active voice fits. Which is usually. 
> Passive voice is best left for assuaging for or deflecting after some 
> screw-up, for cover-ups and related backside-covering, or variously as 
> part of any efforts toward avoiding having or avoiding stating an 
> opinion. Put differently, encountering passive voice can be inferred to 
> indicate you're dealing with somebody trying to hide something. One can 
> of course have other opinions for oneself, as one often does. 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC
Hoff,

Thank you for taking the time to read my whitepaper.

I appreciate your comments. However, they appear to misconstrue my intent.

The whitepaper was written to be descriptive of the present implementation. Since it is descriptive, passive voice seemed most appropriate, which is admittedly a matter of taste. Section 11 (Improvements), is not meant to be comprehensive. It is a list of quirks in the current implementation which limit the existing implementation, IMHO, needlessly. The first item listed, the requirement that STARTUP.COM be run from SYSTEM, is a complete non-sequitur. Nothing done by STARTUP.COM itself is specific to SYSTEM. Some of the actions in the standard STARTUP databases require privileges, but any account with suitable privileges/quotas would be acceptable. The same appears to apply to the use of Executive mode logical names. These two items appear to be privilege requirements in excess of that which is actually required.

I have received comments privately questioning why I did not include a discussion of the bootstrap and activities done by SWAPPER. Once again, that was not the purpose of this whitepaper. The bootstrap sequence and creation of the initial processes is adequately covered by the various versions of the IDSM, and need not be repeated.

It was not my intent to redesign the STARTUP.COM processing. That is a project with a far wider scope, with many subtleties. 

As I have said in the past, STARTUP.COM can be used to more effect than is common. This is a multi-level failure, from unneeded implementation restrictions to less than adequate documentation. However, even modest changes in code and usage would have beneficial effects. The shortcomings I mentioned in Section 11 are all correctable with a few lines of changes, not a major engineering effort.

- Bob Gezelter, http://www.rlgsc.com