The CNM interface provides a means by which a suitably authorized VTAM application program (referred to here as the CNM application) can maintain a session with the System Services Control Point (SSCP) of the VTAM under which the application is executing. A session is established when the application successfully opens its VTAM ACB, enabling it to exchange data with the SSCP.
The CNM application can receive data from an SSCP in one of the following forms:
The following illustration shows how a CNM interface lets a CNM application maintain a session with the VTAM SSCP.
The CNM application can send data to the SSCP for the following reasons:
There following types of NS RUs can be received or sent by an application that is using the CNM interface:
Delivers data to the CNM application, for example, Record Formatted Maintenance Statistics (RECFMS) and Record Maintenance Statistics (RECMS) RUs.
Sent by the CNM application to request data delivery, for example, Request Maintenance Statistics (REQMS) RUs.
Performs delivery and request functions
If an NS RU is solicited, then reply data is always returned to the soliciting application. If the NS RU is unsolicited, then delivery is influenced by the contents of the VTAM CNM Routing Table. Other factors, such as the functional capabilities of the SSCP and the CNM application, also have a bearing on the nature of data exchanged across the CNM interface.
When a CNM application requires an SSCP to perform a particular service, it sends a Forward RU to the SSCP with which the destination network resource is associated. Among other data, this RU contains the node name of the network resource to which the request applies.
Embedded in the Forward RU is the NS RU describing the service required. The following are the most common forms of embedded RUs:
If a REQMS or NMVT is destined for a resource in the network, then the SSCP forwards the NS RU to the destination resource across an SSCP-PU session.
One or more NS RUs can be sent in reply by the network resource. These flow back to the originating SSCP, which in turn presents them, embedded in a Deliver RU, to the soliciting CNM application.
When an SSCP has some data to send to a CNM application on behalf of a network resource, it sends a Deliver RU to that application. The Deliver RU contains the name of the network resource to which the data applies and a resource hierarchy list.
Embedded in this RU is an NS RU, which describes the type of data being made available. The most common forms of RUs are the following:
The following illustration shows the flow of the sessions used by Network Services RUs.
Network Services RUs are used to carry management data for an SSCP-PU session between network PUs and VTAM. The CNM application communicates with VTAM using SSCP-LU sessions, receiving NS RUs embedded in Delivery RUs, and issuing NS RU requests for data embedded in Forward RUs.
The Network Management Vector Transport RU provides a more general structure for carrying requests and replies. It consists of one or more SNA MS major vectors that describe the type of network data contained in the request unit, each of which includes one or more Management Services sub-vectors.
An NMVT RU can be issued by the CNM application as a request for data.
Alternatively, an NMVT RU can be sent to the CNM application under the following circumstances:
Certain devices generate unsolicited records in response to the occurrence of a local event. For example, some operator alerts are produced in the form of an NMVT RU.
A reply to an NMVT RU can be sent in response to a request NMVT RU issued by the host application.
Generic and non-generic (Basic) NMVT alerts can also be sent by a device in the network to report an error or failure. The alert record contains data explaining the type of error or failure, the likely causes of the error or failure, and action that can be taken to remedy the situation.
Host CNM support for the 3x74 uses NMVT RUs to request Response Time Monitor data. An NMVT RU carrying RTM data may be sent by the 3x74 as an unsolicited record following a controller-detected event or as a reply to a solicitation request.
The following is the format of a Generic Alert NMVT:
|
Content |
Length |
|---|---|
|
CNM Header |
8 bytes |
|
NS-RU |
8 bytes |
|
Generic Alert Major Vector |
Varying |
|
Hierarchy information |
Varying |
The REQMS NS RU (embedded in a Forward RU) enables a CNM application to solicit data from a network resource. Six types of data that can be solicited are defined, although not all devices support all data types. Some devices support non-standard types and formats; therefore NEWS lets any format be transmitted.
REQMS can be sent to a resource that is owned by (that is, is in the domain of) the SSCP of the VTAM under which the CNM application is running only, unless ISR is operating.
The following are the defined REQMS data types:
Solicits link test statistics from a Physical Unit (PU). PUs that support this function maintain details of the number of link test frames (from a VTAM Link-Level 2 test) received and the number responded to.
Solicits summary counters from a PU. PUs that support this function maintain three categories of error counters: internal hardware errors, communications adapter errors, and negative responses.
Solicits communications adapter errors from a PU. PUs that support this function maintain various categories of communications adapter error counters.
Solicits PU/LU-dependent data from those PUs that support this type. The type of data sent varies according to the device type involved. For instance, REQMS type 4 RUs are sent to 3600/4700 subsystems to access the system monitor functions of that device type.
Solicits EC-level data. PUs that support this function return data such as their microcode EC level, or part numbers installed. The reply format varies depending on the device type.
Solicits link connection subsystem data. Used in conjunction with some modem types to retrieve link-related data.
The RECFMS RU is sent to a CNM application by an SSCP under the following circumstances:
Network resources always deliver RECFMS RUs to the SSCP that owns them (that is, the SSCP for the local domain).
The types of RECFMS RUs are categorized in the same way as REQMS RUs. This means that a type 1 REQMS receives a type 1 RECFMS in reply (and so on), and that certain devices may generate a RECFMS of one of the types without being requested to do so. For instance, the 3600/4700 subsystem can generate RECFMS type 4 records to inform the host of a variety of conditions.
One additional RECFMS type exists, known as type 0. Because there is no matching REQMS type 0, the RECFMS type 0 is always unsolicited, and is classified as an alert message. Its content is not explicitly defined, so the exact data sent is device-dependent.
NCPs in a network generate RECMS RUs under a variety of conditions, and there are a large number of RECMS types. Some of these types are described in the following examples:
Each time certain counters for a particular node in the NCP reach a set threshold (that is, wrap), the NCP generates a statistical RECMS record, containing such data as traffic counts and temporary error counts. The frequency at which the counters wrap can be adjusted using NCP generation. The records are also forwarded whenever a node or the NCP itself is varied inactive (that is, the device is inoperative as far as the SSCP is concerned).
A variety of error conditions cause the generation of RECMS records. These include permanent link and device failures, and temporary errors. The RECMS records provide an indication of the most likely cause of the error by including a snapshot of various NCP control blocks.
Records can be generated as a result of NCP software failures or abends.
Records can be generated as a result of communications controller hardware errors.
NCP delivers RECMS RUs to the SSCPs that own the resource to which they refer (that is, they are in the local domain of the SSCP).
All the NS RUs discussed previously are concerned with the transportation of network management requests between the host CNM application and network devices. As described, these requests are transported in one of the following ways:
Another class of requests also make use of the CNM interface. These requests contain data relating to the services of the SSCP directly and do not involve the redirection of RUs to other network devices. Such SSCP-related requests are sourced from the SSCP and delivered to the CNM application, or from the CNM application for delivery to the SSCP. In either case, since no further propagation of the request is necessary, these requests are not embedded in a deliver RU (if sourced from the SSCP) or a forward RU (if sourced from the CNM application).
Some important SSCP-related CNM requests are described in the following sections.
NEWS supports the unembedded Translate-Inquiry and Translate-Reply RUs. These request units are used for alias name translation by certain levels of VTAM.
The Translate-Inquiry RU is sent to NEWS from the SSCP and solicits a Translate-Reply RU in response.
The CNM-RU is a control request unit used by the Network Tracking System (NTS) feature. It is also passed unembedded across the CNM interface and is ignored by NEWS.
This section describes how the processing requirements of the record are determined using the Network Services Control File (NSCNTL) and how the requirements are met by the execution of the nominated NCL procedures.
Each record received by NEWS using the CNM interface is an RECMS record, an RECFMS record, or an NMVT record. The record type is further qualified as follows:
Alerts received by NEWS from the APPN network arrive as SNA MSUs containing one or more major vectors. MSUs are processed as if they are NMVTs, which also contain major vectors.
CNMPROC extracts the resource identifier from the record and uses the NSCNTL to identify the device from which the record was sourced. On this basis, the NSCNTL assigns two codes to the record to identify its processing requirements:
NMVT records (and MSUs) normally contain a Product Set ID (PSID) sub-vector field that contains the hardware or software common name or machine type of the resource that sent the record. The PSID is used to obtain, from Category 001 (Product-Set Identification) of the NSCNTL table, a description of the resource and the associated RID and EID to assign to the record.
If no matching PSID exists in the NSCNTL table, the RID and EID are set to UNKNOWN.
RECFMS records contain a block number field that identifies the type of resource that sent the CNM record. The block number is used to obtain from Category 002 (Block Number Identification) of the NSCNTL table a description of the resource, and the associated RID and EID to assign to the record. If no matching block number exists in the NSCNTL table, the RID and EID are set to UNKNOWN.
After the RID and EID have been selected, NEWS uses the NSCNTL to select a processing path for the record. This processing path describes the arrival and display processing requirements for the record, and is represented by a single control code called the PID. The PID is dependent on the following:
The PID is retrieved from Category 003—Record to PID Conversion—of the NSCNTL by CNMPROC. The PIDs (Category 004) then define the processing path for the records. This selection process allows common processing paths for different types of records. The selection process lets a PID be assigned to any record type from any device.
RECMS records have no resource identifier specified; therefore, these codes cannot be assigned. Instead, RECMS records are assigned an Event ID during PID selection, as described in the next section.
Process path definitions detail the processing requirements for the record. Included are the names of several NCL procedures that are used to perform NEWS record arrival processing functions. The procedures are classified into the following groups:
These procedures are all optional. Where a procedure has been nominated and is enabled, it is executed by NEWS during record arrival processing.
Solicited records can be processed by any NCL procedure. The process works as follows:
All unsolicited CNM records received by NEWS are directed to CNMPROC for processing. CNMPROC does the following processing:
The formats of individual records and RUs, and more information about the CNM interface appear in a number of IBM manuals, including the following:
Various product-related manuals may also contain information about record formats that are peculiar to their device types.