The Question is:
In the SYSTARTUP_VMS.COM file on our system, there are a number of
commands/.com files that get executed after all of the critical system startup
is complete. At times, one of these commands will fail, usually because of
some system configuration change.
However, because nothing critical has failed, I may not notice for some time
that some of our non-critical tasks have failed to start.
I have been considering putting a SET NOON command after the critical sections
of SYSTARTUP_VMS.COM complete, so that even if a single non-critical component
fails, the system will continue to load the remainder. Is there any good
reason why I should not
do this? Do you know of a better way to do this?
The Answer is :
The OpenVMS Wizard will assume that you don't have a SET NOON at the
top of the SYSTARTUP_VMS procedure because you want SYSTARTUP_VMS to
fail if any of your critical applications fail to start correctly,
and you have ON or sone sort of other error handling available to
deal with these errors.
One simple solution is to put the SET NOON command after all your
critical applications are started. If any of the non-critical
applications should fail to start up, the startup procedure
will continue to completion, starting everything else it can start.
However, it would be easier to figure out what's going on if you
added a bit more DCL to your startup procedure to catch these other
errors, and, perhaps, send you email. You could put the command:
$ ON ERROR THEN $ GOTO xxxx
$ starting = "name of component"
$ write sys$output "Starting " + starting
before starting each non-critical application, where the error handling
code simply sent you mail and then jumps back into the normal flow.
(The latter case requires the symbol be used in the error handler.
The symbol can also be used -- as shown -- during normal startup.)
This way you have the potential for more extensive error handling,
should you find the time to implement it, and you get a more immediate
indication of what went wrong, which might well save you time and
effort in the long run.
Another alternative is to check the $STATUS value after the commands
which may fail. This is not necessarily as useful, as the product
startup command procedures executed might not return a meaningful
What you ultimately do depends on your needs. A simple SET NOON will
make the procedure execute to the end. You will get little, if any,
indication of what went wrong, in exchange for 10 seconds of effort.
More time spent adding more error handling may make things easier to
debug and fix should things go wrong, potentially saving you lots more
time in the long run.
Verification of the STARTUP_VMS procedure is also available via the
STARTUP_P2 system parameter.