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