Managing and Verifying SMF Processing in Release 7.0 of the Unicenter Mainframe Network Management Suite

Document ID : KB000055970
Last Modified Date : 14/02/2018
Show Technical Document Details

The following tech tip applies to all products within the Unicenter Mainframe Network Management Suite release 7.0 that collects TCP/IP information from SMF.

Several changes were made to Unicenter NetMaster's SMF record handling in release 7.0. The primary change was driven by IBM's introduction of SMF record type 119, which is designed to eventually replace record type 118. Type 119 records introduce IPv6 support which overcomes type 118's structural and capacity limitations in handling 128 bit IP addresses.

In addition, the version 7.0 release now uses CA Common Services to register and load the SMF exits. Prior to release 7.0 the user was required to register the exits manually. An earlier Technical Tip described the mandatory prerequisites and actions required for the activation of SMF processing. This Technical Tip provides additional information to cover the diagnosis and validation that SMF processing is operating normally.

Activation:

Unicenter NetMaster's SMF processing is initiated by the start of the NetMaster SSI address space. The SSI triggers CA Common services which will then load and activate the SMF exits. Activation of SMF processing occurs only if the IPSMF start-up parameter is specified in the NetMaster SSI initialization deck. Product installation will enable this parameter by default.

When the SSI starts, the following functions are performed:

  • The control block structure controlling the interface is created
  • Common SMF exit code is loaded to CSA
  • SMF exit stubs are loaded and activated by CA Common Services
  • SSI command level query and control functions are activated
  • The EPS query service is started

Many functions of Unicenter NetMaster are dependant on SMF records. Fast searching IP connections and IP history are 2 examples of its use. The introduction of CA Common Services to load the exits simplified implementation by taking manual processes out of the picture. However, with any automated process, users often need to verify the function is operating normally. The following sections cover the diagnosis of NetMaster SSI to determine that SMF processing is working as required.

Status Checking:

The first step in validating successful SMF processing is to view the log of the NetMaster SSI.

The following log messages are produced by the NetMaster SSI to indicate SMF support has been activated:

NS0510 SSI BASIC INITIALISATION COMPLETE.
NS1A01 SSI ANCHOR BLOCK CREATED
NS1601 CROSS-MEMORY ENVIRONMENT ESTABLISHED.
NY3001 SMF EXITS REGISTERED SUCCESSFULLY
NS1001 SOLVE SUBSYSTEM INITIALISATION COMPLETE FOR ssid

If the NetMaster SSI was stopped and restarted before a system IPL, subsequent start-up of the SSI will issue the following messages:

NS0510 SSI BASIC INITIALISATION COMPLETE.
NS1201 CLEANUP OF OLD CONTROL BLOCK STRUCTURE FOR SSID: ssid COMPLETE.
NS1A02 SSI ANCHOR BLOCK PRESENT
NS1601 CROSS-MEMORY ENVIRONMENT ESTABLISHED.
NY3002 SMF EXITS REGISTERED ALREADY
NS1001 SOLVE SUBSYSTEM INITIALISATION COMPLETE FOR ssid

It is important to note that, if restarted before an IPL, the NetMaster SSI will only check for the status of SMF processing and report on it. It will not initiate a reload of the SMF exits.

If any other SMF related messages appear on the log, they will indicate problems which will require investigation and corrective action. Messages can be viewed online in Unicenter NetMaster. The message description will describe the problem and recommended action.

Ad-hoc enquiries can be made on SMF status during normal operation of the NetMaster SSI. The user can issue the following modify command to the SSI address space to determine SMF status:

F ssiname,SMF STATUS                                                                
 NY3120 SMF INFORMATION                                                    
 NY3121 SMF PROCESSING ENABLED                                             
 NY3122 PROCESSING SMF RECORD 118                                          
 NY3123 SMF EXIT INFORMATION                                               
 NY3127 EXIT_NME REG_JOB  REG_DATE REG_TIME AT EP       RECV_REC WRTN_REC  
 NY3124 Y7FU83   ssiname  20040111 14300230 98 92E6E570 00000002 00000002  
 NY3124 Y7FU84   ssiname  20040111 14300234 98 92CC0570 0000022A 0000022A  
 NY3124 Y7FU85   ssiname  20040111 14300236 98 92A09570 00000271 00000271  
 NY3129 END OF SMF INFORMATION, LISTED EXITS 3 OUT OF 3 REQUESTED    

Testing SMF processing:

A mode of the standard Unicenter NetMaster or NetSpy Selftest procedure is a check of SMF processing. This test can be performed by running the SELFTEST option, or issuing SELFTEST COLLECT from Unicenter NetMaster's OCS or Command Entry windows:

selftest collect  
IPDI5200 TCP/IP Self Test on region, TCP type is stack_type
IPDI5230 Checking Logging and Data Collection Functions
IPDI5201    Simple Event Services is active via locally connected SSI ssid
IPDI52B0    CA Common Services has been initialized, version=003000
IPDI52A9    SMF Control Block structure OK
IPDI52B1    SMF exits common code has been loaded
IPDI52B2    SMF records processing is enabled
IPDI52B4    SMF record writing is enabled
IPDI52B3    SMF exits are registered
IPDI52B9    SMF is processing record: 119
IPDI52B7    SMF exit: Y7FU83 status: OK
IPDI52B7    SMF exit: Y7FU84 status: OK
IPDI52B7    SMF exit: Y7FU85 status: OK
IPDI5238    System IPSEC    Event Receiver for ID=$IPEVENT is active
IPDI5238    System FTP      Event Receiver for ID=$IPEVENT is active
IPDI5238    System IPCONN   Event Receiver for ID=$IPEVENT is active
IPDI5238    System TELNET   Event Receiver for ID=$IPEVENT is active
IPDI5237    Note: No events will be written to the activity log
IPDI5237    Events saved in Event History dataset: FTP,Telnet,Connections
IPDI5299 TCP/IP Self Test completed with no errors or warnings.

Changing the SMF record type:

The SMF record type being processed (118 or 119) is important to overall Unicenter NetMaster operation. Changing the type can only be done by changing the IPSMF start-up parameter and restarting the NetMaster SSI. There is no capability to dynamically change record type processing from the operator console.

Dynamic exits code reload:

Unicenter NetMaster does allow for dynamic reloading of SMF processing. This is rarely required, but may be undertaken on the advice of Customer Support.

Following is the example of dynamically deregistering and registering the SMF exits.

F DENMSSI,SMF DEREG
NY3520 SMF EXITS DEREGISTERED SUCCESFULLY

F DENMSSI,SMF REG
NY3001 SMF EXITS REGISTERED SUCCESSFULLY

Multiple NetMaster SSI implications:

If your installation has a requirement to run multiple SSI address spaces, it makes sense to dedicate SMF functions to a single NetMaster SSI. NetMaster SSI's running without IPSMF parameter specified will reduce the amount of main storage occupied by the address space.

Common problems:

Current field experience shows the following are the most common problems encountered with Unicenter NetMaster's SMF support:

  • CA Common Services not installed.
    Failing to install CA Common Services or to run the CAS9 program will impact Unicenter NetMaster. Relevant NetMaster SSI messages will be issued.


  • Back-level CA Common Services.
    As indicated in a previous Tech Tip, CA Common Services V2.2 Service Pack 3 (with APAR QO32410), or CA Common Services V3.0 is required. Back-level versions of CA Common Services will not load the SMF exits. Relevant NetMaster SSI messages will be issued.


  • Incomplete NetMaster Load Library (SMF exits code missing).
    If the NetMaster SMF exits code missing/removed from the production load library, SMF initialisation will fail with the relevant SSI message.