HP OpenVMS Systems

Handling errors in SYSTARTUP_VMS?

» close window

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?
 
Thanks,
 
Michael
 

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
     $ COMMAND
 
     or
 
     $ starting = "name of component"
     $ write sys$output "Starting " + starting
     $ COMMAND
 
  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
  return status.
 
  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.
 

  

     

     
answer written or last revised on ( 23-MAY-2000 )
     
» close window