Operator Messages Manual

Chapter 28 DSNM (Distributed Systems Network Management) Messages

The messages in this chapter are sent by the Distributed Systems Network Management (DSNM) product.

NOTE: Negative-numbered messages are common to most subsystems. If you receive a negative-numbered message that is not described in this chapter, see Chapter 15.

Within the Distributed Systems Management Solutions (DSMS) family of products, all operator messages are generated by components of the DSNM services layer; therefore, “DSNM” always appears as the subsystem name in the message header. The variable component is used frequently in DSNM operator messages to identify the DSNM component that issued the message. Table 28-1 lists the possible issuing components.

Table 28-1 Components Issuing DSNM Operator Messages

Component DSNM Component
subsys-ISubsystem interface process for a standard Tandem data communications subsystem (identified by subsys) other than AM3270, Expand, SNAX/XF, SNAX/CDF, TR3271, or X25AM
AUTO-IThe “automation I” subsystem interface process
CDFISubsystem interface process for the SNAX/CDF subsystem
CIPConversational interface process
CMDSVRCommand server process
DBIDatabase interface process
GRDEEvent monitor process for the NonStop Kernel subsystem
NCOMNetCom server
NETSVRNetCommand server
NSTATNetStatus server
OMONObject monitor process
PWEEvent monitor process for the Pathway subsystem
PWISubsystem interface process for the Pathway subsystem
SCPE-AMEvent monitor process for the AM3270 subsystem
SCPE-CDEvent monitor process for the SNAX/CDF subsystem
SCPE-EXEvent monitor process for the Expand subsystem
SCPE-SXEvent monitor process for the SNAX/XF subsystem
SCPE-TREvent monitor process for the TR3271 subsystem
SCPE-X2Event monitor process for the X25AM subsystem
SCPISubsystem interface process for AM3270, Expand, SNAX/XF, TR3271, or X25AM
SPLEEvent monitor process for the spooler
TERMSTARTTERM-START server

 



1

component, Startup { Info | Error }: [ SSID ssid ] [ File file ] [ Error errnum ] [ text ]

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

ssid

is the subsystem ID of the subsystem associated with the message, in the following format:

owner.subsys.versioncomponent
file

is the name of the file associated with the message, in the following format:

[\node.]$volume.subvolume.file-ID
errnum

is an error number.

text

provides additional informational concerning the message. text can have the values shown in Table 28-2, which correspond to the numbered cause and recovery information.

Table 28-2 Startup Message Text for DSNM Message 1

textComponentCause and Recovery
Cannot add subsystem configuration.subsys-I8
Cannot convert SSID: (nn,nn)subsys-I3
Cannot create command interface.subsys-I7
{ CIP can’t continue | Can’t allocate static (#ZSPI) thread }CIP8
Duplicate PATHMON value ( process ) specified. It is ignored.PWE1
Error retrieving parameter for param-name. [ Using default value value. ]any1
Invalid CONFIG value (keyword) for PCLASS class: value [ (default value value substituted) ]any1
Invalid { startup | TESTMODE-ONLY | MYSYSTEM } parameter ignored: [keyword ] valueany3
Invalid { SUBSYSTEM value (keyword) | OBJTYPE config value (RANK) } for subsystem subsys: value any1
Invalid { value | parameter } (value) for param-name. [ Using default value ]any1
Invalid { value in $SYSTEM.SYSTEM.DSNM | parameter } ignored: keyword valueany1
Invalid ZDSN^VAL^DEFAULT^xxx^NAME: value any8
Missing Parameter - COMPONENT.AUTO-I 3
No manager process name defined.subsys-I1
No Subsystems ConfiguredOMON1
Not Configured, Pathway Error: error PWE6
OBJECTDB alternate key inconsistent with Objects Monitor codeOMON5
Parameter error - { NonStop Kernel File Error | SSID Error - DSNM Error }: errnum subsys-I1
pathmon Not Configured, FS Error: errnumPWE6
SSID error - { NonStop Kernel File Error | DSNM Error }: errnum subsys-I3
Startup errors encounteredany I process8
$SYSTEM.SYSTEM.DSNM section name not foundany1
Too many configuration files!any1
Too many CPUS configured for PCLASS pclass: cpu-list any1
Too Many Subsystems to ConfigureOMON1
Unable to load subsystem: subsystem OMON4
Unrecognized keyword in $SYSTEM.SYSTEM.DSNM ignored: keywordany1
Unrecognized OPEN-PARAMS keyword for PCLASS pclass ignored: keyword value any1

 

Cause  Irregularities were encountered during startup processing resulting from one of the situations numbered below or from an internal error. See Table 28-2 for the message text that corresponds to the numbered situations.

Effect  If the message is a warning from the Pathway event monitor process, the process starts but objects in the specified Pathway application cannot be monitored.

If the text of the message indicates that a default value for a configuration parameter is being used, then the reporting component starts with the reported default value.

Otherwise, the component cannot start.

Recovery  No recovery action is required for Startup Info messages; however, the text might notify you of a condition that you should investigate further—for example, if a default value was used for a parameter rather than the expected configured value.

See the numbered cause and recovery actions below that correspond to the error text, as given in Table 28-2.

  1. Cause. The DSNM configuration files either are inaccessible or contain invalid information.

    Recovery.  Stop the DSNM Pathway application, then make sure that the $SYSTEM.SYSTEM.DSNM file contains the name of the correct DSNM configuration file. Make sure that the parameters in the DSNM configuration file are set to the proper values and that the files are properly secured. Then restart the DSNM Pathway application.

    If the reporting component is a subsys-I process, it may be that a manager process other than Subsystem Control Point (SCP) is required for the associated subsystem and none is configured. Add a set of CI-CONFIG class records describing the subsystem control interface to the DSNM configuration file and restart the I process.

    If the reporting component is OMON:

    • Fix a “too many subsystems” error by removing subsystem configuration records from the DSNM configuration file or files until the number is less than or equal to 32.

    • Fix a “no subsystems configured” error by reinstalling the ZDSNCONF file on $SYSTEM.SYSTEM.

    • Fix an “OMON configured not to monitor any subsystem” by adding subsystem records for the subsystems you want to monitor or by removing IGNORE parameters from the DSNM configuration file or files or both.

  2. Cause.  The issuing component cannot get the system name.

    Recovery.  If the component cannot get the system name, this is an internal error. See Item 8 below.

  3. Cause.  The issuing component detected a startup parameter error.

    Recovery.  If the component detected a startup parameter error, examine the DSNM or PATHMON configuration file or files or both and make sure that the parameter values for the issuing component are valid.

    If the text of the message indicates that an I process could not convert a subsystem ID (SSID), see the description of the TEXTTOSSID procedure in the Guardian Procedure Calls Reference Manual for more information on the returned status code (nn,nn).

  4. Cause.  The DSNM object monitor process detected an error while loading its memory-resident database.

    Recovery.  If the object monitor process detected an error while loading its memory-resident database, make sure of the following:

    • The object database file is the correct one for this version of the object monitor process.

    • The MAX-STARTUP-RETRIES parameter for the object monitor process is set to -1 (infinite) or to a large value.

      To fix an “inconsistent alternate key” error, purge the object database and restart OMON and the E processes.

  5. Cause.  The object monitor (OMON) was unable to acquire a subsystem within OMON’s startup interval. Most likely, the corresponding event monitor process failed before it could add the subsystem record to the object database.

    Recovery.Examine the event log for events generated by the subsystem’s event monitor process to determine the cause of failure.

  6. Cause.Either the Pathway event monitor process cannot find a PATHMON process specified in the DSNM configuration file, or the PATHMON process was started but no servers have been configured for it.

    Recovery.If the Pathway event monitor process (PWE) issued a warning that it was unable to find one of the specified PATHMON processes, stop the Pathway event monitor and object monitor processes and check the DSNM configuration file to make sure that the PATHMON process is correctly specified. Make sure that the specified Pathway application has been started. Then restart the Pathway event monitor and object monitor processes.

    If PWE reports that it was unable to configure the Pathway application, configure the Pathway application that you are attempting to monitor; then restart PWE and OMON.

  7. Cause.The subsystem interface process is unable to start a control interface for the subsystem.

    Recovery.If the subsystem requires a manager, add CI-CONFIG.subsystem-CI records to the DSNM configuration file and restart the I process. Otherwise, this is an internal error and you need additional help (see next item).

  8. Cause.If the issuing component is an I process, a “Startup Error: Startup errors encountered” message preceded by a “Startup Info: Startup Mode” message generally results from missing subsystem or subsystem interface configuration information from the DSNM configuration file or files.

    Otherwise, an internal error occurred during process startup.

    Recovery.In the case of an I process reporting a “Startup errors encountered” message preceded by a “Startup Info: Startup Mode” message, add the missing subsystem or subsystem interface configuration information to the DSNM configuration file or files.

    Otherwise, record the complete text of the error message, save the saveabend file, then contact your Global NonStop Solution Center (GNSC) and provide all relevant information as follows:

    • Descriptions of the problem and accompanying symptoms

    • Details from the message or messages generated

    • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

      If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.



2

component, Subsystem Error: [ SSID ssid ] [ File file ] [ Error errnum ] [ text ]

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

ssid

is the subsystem ID of the subsystem associated with the message, in the following format:

owner.subsys.versioncomponent
file

is the name of the file associated with the message, in the following format:

[\node.]$volume.subvolume.file-ID
errnum

is an error number.

Cause  The subsystem identified by ssid reported an error.

Effect  The effect varies, according to the subsystem and the error reported.

Recovery   If the problem is caused by an incorrect configuration of DSNM or the subsystem represented by ssid, consult the appropriate manual (the Distributed Systems Management Solutions (DSMS) System Management Guide or the configuration and management manual for the subsystem) and fix the configuration problem.

If you cannot solve the problem by fixing the configuration, it is an internal error in either DSNM or the subsystem. Record the complete text of the error message, save the saveabend file, then contact your Global NonStop Solution Center (GNSC) and provide all relevant information as follows:

  • Descriptions of the problem and accompanying symptoms

  • Details from the message or messages generated

  • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.



3

component, Component Error: P=%pregister [ Earray err %preg var1 var2 var3 var4 var5 ] [ text ]

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

%pregister

contains the value of the P register, which indicates the location in the object code where the event that caused the message to be generated occurred.

err %preg var1 var2 var3 var4 var5

The Earray field contains an array of integers that report diagnostic data:

err 

Cause  A software internal error occurred. See the numbered “cause” items listed below for some possible causes.

Effect  The issuing component stops. In most cases, DSNM abends.

Recovery  This error most likely requires the attention of the Global Mission Critical Solution Center (GMCSC). However, you may be able to correct the situations listed below. If you cannot correct the problem, contact the Global NonStop Solution Center (GNSC) and provide all relevant information as follows:

  • Descriptions of the problem and accompanying symptoms

  • Details from the message or messages generated

  • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.

  1. Cause.  If the Subsystem Control Point (SCP) event monitor process (SCPE-xx) is the issuing component, the error text may refer to one of the following:

    • The EMS distributor was unable to be restarted (message text is “MONITOR STATUS STOPPED; SERVER ABENDED”).

    • The SCPE process was unable to get a list of objects to monitor (message text is “Unable to recover stats”).

    • The processor number is invalid for the EMS-DISTRIBUTOR.

    • The process priority is invalid, such as a negative number.

      Recovery.  Take the following actions as appropriate:

    • Try to determine the problem with the EMS distributor.

    • Use the Subsystem Control Facility (SCF) to see whether it returns object lists for subsystems. If it does, then there is a problem with the SCPE process. Contact the Global NonStop Solution Center (GNSC) and provide the information described below.

    • Check the value of the EMS-DISTRIBUTOR-CPU parameter in the DSNM configuration file for the monitored subsystem.

    • Check the process priority of the SCPE process and reconfigure it to a valid number.

      If you are unable to resolve the problem, contact the Global NonStop Solution Center (GNSC) and provide all relevant information as follows:

    • Descriptions of the problem and accompanying symptoms

    • Details from the message or messages generated

    • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

      If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.

  2. Cause.  If the object monitor (OMON) is the issuing component and err is -62, either there are too many objects to monitor, or too many subsystem/manager/object type combinations have been configured.

    Recovery.  Reduce the number of objects to be monitored or the number of subsystem/manager/object type combinations in the DSNM configuration file or files.

  3. Cause. If the spooler or NonStop Kernel event monitor process (SPLE or GRDE) reports an unknown subsystem record flag, then the subsystem record in the DSNM object database is incorrect.

    Recovery.  Use the NetCom utility ALTER FLAG command to reset the flag for the spooler or NonStop Kernel subsystem and then restart the SPLE or GRDE process.

  4. Cause.  PWE might report that it encountered an unknown object type. In this case, the Pathway subsystem has been started but no servers have been configured.

    Recovery.  Configure the Pathway application; then restart the PWE and OMON processes.

    If this error occurs, record the complete text of the error message; save the saveabend file; and contact the Global Mission Critical Solution Center (GMCSC), providing all relevant information as follows:

    • Descriptions of the problem and accompanying symptoms

    • Details from the message or messages generated

    • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

      If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.



6

component, No Memory Space Available: [ SSID ssid ] [ File file ] [ Error errnum ] [ text ]

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

ssid

is the subsystem ID of the subsystem associated with the message, in the following format:

owner.subsys.versioncomponent
file

is the name of the file associated with the message, in the following format:

[\node.]$volume.subvolume.file-ID
errnum

is an error number.

Cause  The issuing component ran out of memory space.

Effect  If the issuing component is the TERM-START server (TERMSTART), it continues but is unable to add any more terminals.

In all other cases, the issuing component terminates itself. DSNM may abend.

Recovery  If this error occurs, record the complete text of the error message; save the saveabend file; and contact the Global Mission Critical Solution Center (GMCSC), providing all relevant information as follows:

  • Descriptions of the problem and accompanying symptoms

  • Details from the message or messages generated

  • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.



7

component, Allocate Segment Error: P=%pregister [ SSID ssid ] [ File file ] [ Error errnum ] [ text ]

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

%pregister

contains the value of the P register, which indicates the location in the object code where the event that caused the message to be generated occurred.

ssid

is the subsystem ID of the subsystem associated with the message, in the following format:

owner.subsys.versioncomponent
file

is the name of the file associated with the message, in the following format:

[\node.]$volume.subvolume.file-ID
errnum

is an error number.

Cause  The issuing component was unable to allocate an extended segment.

Effect  The issuing component terminates itself. DSNM may abend.

Recovery  Refer to the discussion of the SEGMENT_ALLOCATE_ procedure in the Guardian Procedure Errors and Messages Manual for a description of the error code reported in errnum.

If you cannot resolve the error, record the complete text of the error message; save the saveabend file; and contact the Global Mission Critical Solution Center (GMCSC), providing all relevant information as follows:

  • Descriptions of the problem and accompanying symptoms

  • Details from the message or messages generated

  • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.



8

component, SPI Error: [ SSID ssid ] [ File file ] [ Error errnum ] [ text ]

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

ssid

is the subsystem ID of the subsystem associated with the message, in the following format:

owner.subsys.versioncomponent
file

is the name of the file associated with the message, in the following format:

[\node.]$volume.subvolume.file-ID
errnum

is an error number.

Cause  The issuing component detected an error from the NonStop Kernel Subsystem Programmatic Interface (SPI) procedure call, with errnum reporting the SPI error.

Effect  The issuing component terminates itself. DSNM may abend.

Recovery  If this error occurs, record the complete text of the error message; save the saveabend file; and contact the Global Mission Critical Solution Center (GMCSC), providing all relevant information as follows:

  • Descriptions of the problem and accompanying symptoms

  • Details from the message or messages generated

  • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.

For information about the particular SPI error, see the Distributed Systems Management (DSM) Programming Manual.



9

component, File System Error: [ SSID ssid ] [ File file ] [ Error errnum ] [ text ]

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

ssid

is the subsystem ID of the subsystem associated with the message, in the following format:

owner.subsys.versioncomponent
file

is the name of the file associated with the message, in the following format:

[\node.]$volume.subvolume.file-ID
errnum

is an error number.

Cause  A file-system error occurred because of one of the situations described in the numbered items below.

Effect  The effect depends on the severity of the error.

Recovery  Recovery depends on the error that occurred. See the numbered item below that corresponds to the error that occurred. See the Guardian Procedure Errors and Messages Manual for detailed information on file‑system errors.

  1. Cause.  The Pathway/TS terminal control process (TCP), $receive, object monitor, or PATHMON process is inaccessible.

    Recovery.  Record the complete text of the error message, contact the Global NonStop Solution Center (GNSC) and provide all relevant information as follows:

    • Descriptions of the problem and accompanying symptoms

    • Details from the message or messages generated

    • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

      If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.

  2. Cause.  The name of the DSNM configuration file specified in the $SYSTEM.SYSTEM.DSNM file is invalid.

    Recovery.  Check the value of the CONFIG parameter in the $SYSTEM.SYSTEM.DSNM file to make sure that it is a valid file name that specifies an existing DSNM configuration file.

  3. Cause.  An error occurred while the issuing component was trying to communicate with a Pathway/TS TCP.

    Recovery.  Check the status of the TCP that reported the error.

  4. Cause.  An error occurred while the issuing component was trying to open or read the alternate key-file for the object database.

    Recovery.  Check the file security settings for the object database and its alternate key file. The object monitor and Pathway event monitor processes must have read and write access to them.

  5. Cause.  A read, write, open, or unlockfile error occurred while the issuing component was trying to access the object database.

    Recovery.  Check the file security settings for the object database and its alternate key file. The object monitor and Pathway event monitor processes must have read and write access to them.

  6. Cause.  The issuing component was unable to open, write to, or read from the Event Management Service (EMS) distributor process.

    Recovery.  Check the status of the object monitor and EMS distributor processes, correct the problem, and restart the issuing component.

  7. Cause.  There is no memory space available for the issuing component to process the command.

    Recovery.  Contact the Global NonStop Solution Center (GNSC) and provide all relevant information as follows:

    • Descriptions of the problem and accompanying symptoms

    • Details from the message or messages generated

    • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

      If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.

  8. Cause.  The issuing component was unable to create an extended segment swap file (accompanying error text will be “Detected by ALLOCATESEGMENT”).

    Recovery.  Make sure that the SWAPVOL specified in the DSNM configuration file has adequate space available.

  9. Cause.  The $SYSTEM.SYSTEM.DSNM and DSNM configuration files are inaccessible.

    Recovery.  Make sure that all DSNM components have read access to the $SYSTEM.SYSTEM.DSNM and DSNM configuration files. Also make sure that the parameters for the database interface (DBI) process in the DSNM configuration file are valid.

  10. Cause.  The issuing component cannot write to the object monitor process.

    Recovery.  Informational message only; no corrective action is needed.

  11. Cause.  The issuing component cannot issue a write command to the Subsystem Control Point (SCP).

    Recovery.  Make sure that the subsystem manager process is correctly specified in the DSNM configuration file.

    If you cannot resolve the error, record the complete text of the error message, save the saveabend file, and follow the standard procedures at your site for contacting the appropriate support personnel.

  12. Cause.  The issuing component cannot read a startup message.

    Recovery.  Record the complete text of the error message; save the saveabend file; and contact the Global Mission Critical Solution Center (GMCSC), providing all relevant information as follows:

    • Descriptions of the problem and accompanying symptoms

    • Details from the message or messages generated

    • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

      If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.

  13. Cause.  The issuing component detects a processor halt.

    Recovery.  Informational message only; no corrective action is needed.

  14. Cause.  An event monitor process encountered an error when a PROCESS_CREATE_ call to create an EMS distributor or Peripheral Utility Program (PUP) process failed (message text is “PROCESS CREATE error ...”).

    Recovery.  Refer to Appendix D, or to Appendix E, for a definition of the specified error. For more detailed information about these errors, refer to the Guardian Procedure Errors and Messages Manual. Correct the problem and restart the E‑process.



10

component, Pathway Error: [ SSID ssid ] [ File file ] [ Error errnum ] [ text ]

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

ssid

is the subsystem ID of the subsystem associated with the message, in the following format:

owner.subsys.versioncomponent
file

is the name of the file associated with the message, in the following format:

[\node.]$volume.subvolume.file-ID
errnum

is an error number.

Cause  A PATHMON process, PATHCOM process, or terminal control process (TCP) issued an INFO, ERROR STATUS, or WARNING message.

Effect  The effect of the PATHMON, PATHCOM, or TCP error depends on its severity.

Recovery  See the NonStop TS/MP and Pathway Management Reference Manual for an explanation of the error reported in errnum.



11

component, Pathway UMPS Error: [ SSID ssid ] [ File file ] [ Error errnum ] [ text ]

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

ssid

is the subsystem ID of the subsystem associated with the message, in the following format:

owner.subsys.versioncomponent
file

is the name of the file associated with the message, in the following format:

[\node.]$volume.subvolume.file-ID
errnum

is an error number.

Cause  A PATHMON process, PATHCOM process, or terminal control process (TCP) issued an INFO, ERROR STATUS, or WARNING message pertaining to unsolicited message processing.

Effect  The effect of the PATHMON, PATHCOM, or TCP error depends on its severity.

Recovery  See the NonStop TS/MP and Pathway Management Reference Manual for an explanation of the error reported in errnum.



12

component, EMS Error: [ SSID ssid ] [ File file ] [ Error errnum ] [ text ]

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

ssid

is the subsystem ID of the subsystem associated with the message, in the following format:

owner.subsys.versioncomponent
file

is the name of the file associated with the message, in the following format:

[\node.]$volume.subvolume.file-ID
errnum

is an error number.

Cause   The issuing component could not process a message received from an Event Management Service (EMS) distributor.

Effect  The effect of the EMS error depends on its severity. DSNM may abend.

Recovery  If this error occurs, record the complete text of the error message; save the saveabend file; and contact the Global Mission Critical Solution Center (GMCSC), providing all relevant information as follows:

  • Descriptions of the problem and accompanying symptoms

  • Details from the message or messages generated

  • Supporting documentation such as Event Management Service (EMS) logs, trace files, and a processor dump, if applicable

If your local operating procedures require contacting the Global Mission Critical Solution Center (GMCSC), supply your system number and the numbers and versions of all related products as well.



14

component, [ SSID ssid ] [ File file ] [ Term term-ID ] [ User user-ID ] [ text ]

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

ssid

is the subsystem ID of the subsystem associated with the message, in the following format:

owner.subsys.versioncomponent
file

is the name of the file associated with the message, in the following format:

[\node.]$volume.subvolume.file-ID
term-ID

is the name of the terminal from which the command that caused the message to be generated was issued. term-ID has the following format:

[\node.]termname 
user-ID

is the name of the user who issued the command that caused the message to be generated. user-ID has the following format:

group.user
text

provides additional information concerning the message. See Table 28-3 for the values for text.

Table 28-3 Message Text for DSNM Message 14 

textComponentCause and Recovery
nn CDF processes done out of total nnSCPE-CD5
ATTEMPTING TO RESTART EMSSCPE-xx3
CDF PROC object-name not configured; will not be monitoredSCPE-CD7
{ Invalid Expand manager name process-name | Long system name not supported by SCP for param-name}any E except SPLE 9
{ Invalid file name filename | Long file name not supported by EMS Distributor for param‑nameany E except SPLE 9
Long system name not supported by EMS Distributor collector-name Using default $0 any E except SPLE 9
Process stopping: No CDF processes runningSCPE-CD4
Process stopping: No SPOOLER supervisors running SPLE8
Process stopping: Nothing to configureSCPE-xx2
TIMEOUT WHEN objname REQUESTS FOR { CONFIG | STATUS }SCPE-xx1
Too many CDF processes to be configuredSCPE-CD6

 

Cause  In most cases, an event occurred that generated an informational message, such as the object monitor process loading a configured subsystem or an event monitor process beginning to monitor events.

For certain event monitor processes, however, situations that require corrective action generate this type of message. See Table 28-3 for the message text that corresponds to the numbered “cause” and “recovery” actions listed below.

Effect  The effect of the event that generated the message depends on its severity. If the message is simply reporting information, there is no effect. However, in some cases, the issuing component stops.

Recovery  In most cases, this is an informational message only; no recovery action is needed. However, if the message contains error text given in Table 28-3, see the numbered recovery action below that corresponds to the text.

  1. Cause.  A request for configuration or status information did not finish; the response was lost.

    Recovery.  Set the class EVENT-MONITOR SUBSYSTEM-TIMEOUT parameter to a larger interval and restart the event monitor and OMON processes.

  2. Cause.  No objects are configured for the subsystem.

    Recovery.  Configure the subsystem you wish to monitor.

  3. Cause.  The Event Management Service (EMS) distributor process stopped or abended.

    Recovery.  Try to determine the cause of the problem; then restart the EMS distributor and the E process.

  4. Cause.  There are no SNAX Cross-Domain Facility (SNAX/CDF) processes running.

    Recovery.  Start the SNAX/CDF processes; then restart the SCPE-CD process.

  5. Cause.  SCPE-CD could only configure, initialize, and monitor nn CDF processes.

    Recovery.  Determine through the Subsystem Control Facility (SCF) whether all CDF processes are returning configuration information.

  6. Cause.  There are too many SNAX/CDF processes running. SCPE-CD can monitor only the first 256; all others are not configured or monitored.

    Recovery.  Contact the Global NonStop Solution Center (GNSC) and ask that a request for enhancement (RFE) be submitted to increase the internal SCPE-CD limit to a number greater than 256.

  7. Cause.  A SNAX/CDF object is not configured.

    Recovery.  Refresh the SNAX/CDF objects in the DSNM object database.

  8. Cause.  No spooler supervisors are running.

    Recovery.  Configure some spoolers and restart the SPLE process.

  9. Cause.  Either an invalid or long file or process name was configured for an EMS distributor, EMS collector, or Expand manager process. EMS and Subsystem Control Point (SCP) do not accept long process or file names.

    Recovery.  Configure an EMS distributor, collector, or Expand manager process with a name that conforms to process-naming and file-naming conventions for the EMS‑DISTRIBUTOR, EMS-COLLECTOR, or Expand-MANAGER parameter in the DSNM configuration file.



15

component, Term: term-ID User: user-ID, command-text

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

term-ID

is the name of the terminal from which the command that caused the message to be generated was issued. term-ID has the following format:

[\node.]termname 
user-ID

is the name of the user who issued the command that caused the message to be generated. user-ID has the following format:

group.user

Cause  A DSNM command was issued.

Effect  None.

Recovery  Informational message only; no corrective action is needed.



16

component, Term: term-ID User: user-ID, response-to-command

component

identifies the DSNM component that issued the message. See Table 28-1 for a description of the component.

term-ID

is the name of the terminal from which the command that caused the message to be generated was issued. term-ID has the following format:

[\node.]termname 
user-ID

is the name of the user who issued the command that caused the message to be generated. user-ID has the following format:

group.user

Cause  A response to a DSNM command was returned.

Effect  None.

Recovery  Informational message only; no corrective action is needed.