===== How To Capture and Review VMS Boot Startup Scripts =====
Like that old existential joke about the tree falling in the forest with nobody around to hear it, have you ever wondered what's happening on your OpenVMS system's console terminal during a system reboot when you're not there to look at it?
By default -- and the reason for this stretches back to the earliest days of VMS and LA120 hardcopy terminals used as the OPA0:/console device -- when VMS (re)boots, all output from the reboot SYSTEM process is printed on OPA0:, the system's console terminal.
This includes all output from:
* The VMS bootstrap program sequence
* The SYSTEM bootstrap process running VMS's own base-level SYS$SYSTEM:STARTUP.COM
* The system's site-specific startup command files SYS$MANAGER:SY*.COM
* Any startup com-files or programs contained in the SYSMAN STARTUP database
In the ancient days of the LA120 console, you at least had about 100-feet of printed text to wade through to find any startup problems. On a VT100 or graphics console head, abandon all hope of finding problems, as the startup output scrolls by so fast that you'll likely never see it.
Verify your own system's console-startup setting with:
$ MCR SYSMAN STARTUP SHOW OPTIONS
Current startup options on node CLASS8:
DCL verification mode is: OFF
Startup log will be written to console terminal
Checkpointing messages are disabled
If your output looks like the above, it confirms that the system is writing all startup output to the console terminal OPA0:.
In particular, the system's site-specific command files (like SYS$MANAGER:SYSTARTUP_VMS.COM and the others) must execute correctly in order to get disk volumes mounted, define system/cluster-wide logical names, and to start up things like batch and printer queues, layered products (network stuff, compilers, print supervisors and more), and the business application components and support.
Sometimes, it's necessary to edit one or more of these command files, to add new functionality, or to remove obsolete stuff, like a layered product startup command file that's no longer used. Make your text edit(s), change the file, save your changes... and hope it works next time you reboot?
So, in order to determine if everything is executing okay in your system's startup command files, seems like you've got no choice but to be right there at your OPA0:/console terminal to watch all that text fly by, eh? Standing right there in that freezing-cold air-conditioned server room, with all that fan noise, watching lines and lines of text fly by on that console terminal screen.
Must be a better way, right?
Wouldn't it be great if all this output could just be captured in a text file, a log-file, for permanence and later review? It can... Read on.
==== Configuring VMS Startup Logging ====
It's easy to change VMS startup output from the console terminal to a log-file. It's done with SYSMAN:
$ MCR SYSMAN
SYSMAN> SET ENVIRONMENT /NODE
SYSMAN> STARTUP SET OPTIONS /VERIFY=PARTIAL /OUTPUT=FILE /CHECKPOINTING
SYSMAN> STARTUP SHOW OPTIONS
Current startup options on node CLASS8:
DCL verification mode is: PARTIAL
Startup log will be written to SYS$SYSTEM:STARTUP.LOG
Checkpointing messages are enabled
Ah, that's much better. The output filename for the boot/startup sequence will //always// be SYS$MANAGER:STARTUP.LOG (there is no choice in this). You could set the verification to ''FULL'', but that's likely too much output.
This modification changes the value of the VMS Startup Parameter ''STARTUP_P2'' -- if you check it in SYSGEN or SYSMAN, you'll see this:
$ MCR SYSMAN PARAMETER SHOW STARTUP_P2
Node CLASS8: Parameters in use: ACTIVE
Parameter Name Current Default Minimum Maximum Unit Dynamic
-------------- ------- ------- ------- ------- ---- -------
STARTUP_P2 "PDC " " " " " "zzzz" Ascii
That parameter value ''"PDC "'' encodes the ''/VERIFY=PARTIAL /OUTPUT=FILE /CHECKPOINTING'' stuff.
You're all set, at least on this system... Next time it reboots, you'll have a nice, shiny new STARTUP.LOG file to admire. After that next reboot, you might want to make that file self-purge:
$ SET FILE /VERSION_LIMIT=4 SYS$SYSTEM:STARTUP.LOG
as there's little need to keep very many versions of this log-file around -- you'll likely never look at the older ones, the current reboot will be what's of interest.
==== Finding Lurking Problems and Errors in the VMS Startup Log-File ====
But how do you use this startup log-file effectively? Maybe you've suspected for a while that "something's not quite right with this VMS startup...", but could never "catch it on the console." How do you check for problems?
CLASS8$ directory /size /date /prot sys$system:startup.log
Directory SYS$SYSROOT:[SYSEXE]
STARTUP.LOG;823 1837 22-OCT-2018 13:59:43.73 (RWED,RWED,RE,)
STARTUP.LOG;822 1810 20-OCT-2018 06:41:05.68 (RWED,RWED,RE,)
Total of 2 files, 3647 blocks.
These startup log-files are fairly large -- do you need to read the whole thing? Probably best to start with this SEARCH command:
$ SEARCH SYS$SYSTEM:STARTUP.LOG "-E-","-F-" /MATCH=OR /WINDOW=(1,3)
This SEARCH turns up the lines with either Error or Fatal class error messages (note that the quote-marks around ''"-E-"'' and ''"-F-"'' are required), including the DCL command line that caused the error will give you grouped-lines of output (the ''/WINDOW=(1,3)'' qualifier; increase the "''1,''" to a larger value if you need to wee more previous lines) -- outputting, for example:
******************************
$ SEARCH SYS$SYSTEM:STARTUP.LOG "-E-","-F-" /MATCH=OR /WINDOW=(1,3)
$ mount $82$dka0: yippiesys yippie_disk
%MOUNT-F-NOSUCHDEV, no such device available
$!
******************************
@sys$startup:gnv$startup.com
%DCL-E-OPENIN, error opening SYS$SYSROOT:[SYS$STARTUP]GNV$STARTUP.COM; as input
-RMS-E-FNF, file not found
$ ENDIF
$!
******************************
SEARCH-displays like this will get you "within the ballpark" of the actual DCL command line(s) which are causing errors. Armed with this, you will be able to zoom in on these with your favorite Text Editor, and with some careful thought and even more careful editing, you can fix these problems.
So, armed now with your system's STARTUP.LOG file, and with careful text editing, your next and future VMS system reboots can be error-free and fully correct.