PARSEC Technical Information

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.

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