Conference tape::infoserver

2195.0. "VMS ESS Client HALTs production system" by BLAZE::CHAINIKOV (Kirill Chainikov - IS Moscow) Wed Feb 12 1997 04:14

Hi,

 I have OpenVMS VAX V6.1 cluster with DECnet OSI V6.2 ECO01, 
 and just installed UCX V4.0.

 After UCX 4.0 installation and reboot ESS$STARTUP.COM crashes the system.
 There were no any other changes/upgrades applied to the system.

 Could anybody advise how to restore ESS client functionality?
 What can be the cause of crash?

 I am not sure this is a right place now to ask so
 any other pointers for ESS support?

 Many thanks, 
 Kirill.

 

  $ @ESS$STARTUP.COM CLIENT

  .
  .
  .

  $ if CONTROLLERS_QUAL     .nes. "" then -
  write ess$last_file CONTROLLERS_QUAL
  $ if NODE_NAME_QUAL       .nes. "" then -
  write ess$last_file NODE_NAME_QUAL
  $ if f$trnlnm ("ess$last_file") .nes "" then close ess$last_file
  $ @sys$startup:ess$last_startup.tmp
  $LASTCP := $ESS$LASTCP
  $ LASTCP START TRANS -
  /ALL_CONTROLLERS -
  /CIRCUIT_MAXIMUM=128 -
  SNODE_NAME = MOS01
  %LAT-F-CONLOST, connection to MOS01 terminated
  -LAT-F-TIMEOUT, no response within timeout period
  .
  .
  .

  Here is the SDA> SHOW CRASH info:

   System crash information
   ------------------------
Time of system crash: 12-FEB-1997 10:57:49.85

Version of system: VAX/VMS VERSION V6.1

System Version Major ID/Minor ID: 1/0

VAXcluster node: MOS01, a VAX 4000-300

Crash CPU ID/Primary CPU ID:  00/00

Bitmask of CPUs active/available:  00000001/00000001


CPU bugcheck codes:
        CPU 00 -- HALT, Halt instruction restart

CPU 00 Processor crash information
----------------------------------

CPU 00 reason for Bugcheck: HALT, Halt instruction restart

Process currently executing on this CPU: _VTA61:

Current image file: DSA100:[SYS0.SYSCOMMON.][SYSEXE]ESS$LASTCP.EXE;1

Current IPL: 31  (decimal)

CPU database address:  8A58E000

General registers:

        PC  = 86D6138C   PSL = 0C042000

        Remaining registers not available -- wiped out by console

Processor registers:

        SID    = 0B000006
        SBR    = 07C62400
        SLR    = 000E2700
        SCBB   = 07C4F000
        ISP    = 8A58E800
        KSP    = 7FFE77A0
        ESP    = 7FFE9800
        SSP    = 7FFECA44
        USP    = 7FDE86B8

No spinlocks currently owned by CPU 00

--> End of Log <--

Kirill,

OpenVMS ESS Client support is currently handled by VMS Engineering. You
might want to perform a comets search and/or submit an IPMT/QAR against
OpenVMS containing this problem.

Charlie

	This looks suspicious.  First thing I'd do is compare ESS$LASTCP on the
disk with one from either another system at the same rev or the kit or from
backup.  They did take a backup before installing UCX, didn't they?.  The file
may be corrupt - of course it could be ESS$LASTDRIVER that's corrupt as well.
A HALT in kernel mode usually means something is pretty well hosed.

	But Charlie is right, if it's not a corrupt image (installing
CSCPAT_1128 will replace all the associated images and might be something to
try) then it's VMS sustaining engineering's problem.  If one of the images *is*
corrupt, then the question is how it got that way...

						--Doug

 Hello again, 

 Doug, you was right - ESS$LASTDRIVER was corrupted - last half of 
 block 8 was zeroed. I copied ESS drivers from working 6.1 VMS and
 now it's okay.

 Further investigation showed that after new product was installed on 
 one of the cluster machines dir structure was not in sync while
 previous versions of the files were purged, and analize/disk/rep was
 issued .. So silly things happened. It's a good reason for loadable
 image to become corrupted. 

 Well, 
 I'll look if it will be stable..
 many thanks for support and
 Best Regards,
 Kirill