Guest system errors

SETS in the BS2000 guest system

Form

Message in the BS2000 guest system:
'crash-id: SETS; text'

and

Message on the BS2000 console of the monitor system or in the ADMIN dialog of the VM2000 or VM administrator:
VMS2033 'crash-id: SETS; text' FROM VM ((index),(name)) VIA SVP

where

crash-id	Crash ID of the module by which the system was terminated
index	VM index
name	VM name

Cause

Global system error in the guest system

Diagnostic materials

The SLED of the guest system can be created by means of /START-VM ...,DIAGNOSTIC-IPL=*YES

The diagnostic data of the VM2000 hypervisor is also contained in the SLED of the guest system (dump file section VM2HYPVS).

Response

VM2000 operation continues unaffected. The guest system can be restarted.

If an automatic restart has been defined in the guest system (see "Automatic restart after SETS in the monitor system"), the main console (specified by means of the MAIN-CONSOLE operand in /START-VM) and the IPL device (specified by means of the IPL-UNIT operand in /START-VM) of this VM must still be assigned at the restart. Implicitly assigned devices are removed from the VM when the guest system is restarted.

See "Assignment sets, implicit device assignment and release" for details on how to handle implicitly assigned devices in the case of /START-VM.

The VM administrator is informed about the failure of the guest system, depending on the restart option in the guest system, by means of one of the following messages:

• VMS2051 (“Guest system on VM (...) down; reason: crash”)

• VMS2052 (“Guest system on VM (...) not ready. Restart has been initiated”)

The messages are also issued in the monitor system using routing code “9”.

 

SETS in the monitor system

After SETS in the monitor system, the guest systems remain operable and can be operated, for example, using BS2000 consoles, but not in a VC dialog. VM2000 and the virtual machines cannot, however, be addressed using VM2000 commands. Refer to "Automatic restart after SETS in the monitor system" for details on automatic restarting of the monitor system.

During a failure of the monitor system on SU /390 the VM definitions are not updated (e.g. when the VM state changes, in the event of implicit device assignment). All changes are collected and executed subsequently when BCAM is active again in the monitor system (see "Working with VM definitions").

If no automatic restart is set in the monitor system, then the following applies:

	On SU /390, the guests systems can be shut down using /SHUTDOWN and VM2000 initialized again. Alternatively, the monitor system can be restarted (with SLED) via the SVP, see "Restarting the monitor system via SVP (SU /390)".
	On SU x86, first the monitor system’s SLED can be created. Subsequently, the monitor system can be restarted (see below and the manual “Operation and Administration” [19]).

The guest systems are informed about the failure of the monitor system. One of the following messages is also displayed on the guest system BS2000 console, depending on the restart option in the monitor system:

• NRTV001 (“Monitor system failed”)

• NRTV002 (“Monitor system not ready. Restart has been initiated”)

Reaction of the monitor system to SETS (automatic restart deactivated):

Form when automatic restart is deactivated	Messages issued to the monitor system BS2000 console: 'crash-id: SETS; text'
	and (for SU /390): VMS0000 MONITOR SYSTEM TERMINATED. VM2000 TERMINATION or VMS0018 MONITOR SYSTEM TERMINATED. VM2000 ADMINISTRATION IMPOSSIBLE where crash-id is the crash ID of the module by which the system was terminated
Cause	Global system error in the monitor system
Diagnostic materials		VMS0000: SLED of the system as a whole VMS0018: SLED of the system as a whole or the monitor system
		SLED of the monitor system
Response		VMS0000: Initialize VM2000 operation again VMS0018: Restart via SVP if possible, see "Restarting the monitor system via SVP (SU /390)"; otherwise, terminate all guest systems and initialize VM2000 mode again
		Restarting the monitor system

Monitor system deadlock

Problems may occur in the monitor system which prevent a /SHUTDOWN command from being issued, but do not cause a SETS (monitor system is hung up or endless loop occurs, UCON BUSY, no entry possible).

	On SU /390, the monitor system can be restarted (with SLED) via the SVP, see "Restarting the monitor system via SVP (SU /390)".
	On SU x86, first the monitor system’s SLED can be created. Subsequently, the monitor system can be restarted (via the SE manager or the SVP functions of the assigned KVP console, see the manual “Operation and Administration” [19]).

During this process, the guest systems will remain operable, but cannot be addressed using VM2000 commands or via VC dialog when the dump is being generated or while the monitor system is being restarted automatically.

During a failure of the monitor system on SU /390, the VM definitions are not updated (e.g. when the VM state changes, in the event of implicit device assignment). All changes are collected and executed subsequently when BCAM is active again in the monitor system (see "Working with VM definitions").

The guest systems are only informed about the system standstill in the monitor system after start or restart of the monitor system has been initiated. Message NRTV002 (“Monitor system not ready. Restart has been initiated”) is output on the guest system BS2000 console.

If due to an I/O problem in the monitor system only BCAM is restarted, no messages are generated in the guest systems.

BCAM failure in the monitor system (SU /390)

After a BCAM failure in the monitor system on SU /390, VM2000 can (temporarily) no longer work with VM definitions. For the behavior of VM2000 in this case, see "Working with VM definitions".