Out-of-storage condition leading to an ABEND

If this is the first time you have initialized the NetView® program, storage might be insufficient. Use the formulas from the IBM Z® NetView Tuning Guide to ensure that storage is adequate.

Notes:
  • A NetView internal trace is always necessary for these out-of-storage conditions. Run the NetView internal trace with its default options.
  • The DSI124I message indicates that the NetView program is running out of storage. You can automate this message to create a console memory dump of the NetView program before it abends.
  • The BNH160I message indicates storage loss or problems with the storage accounting in NetView program for global storage.
  • Messages in the range BNH161I—BNH163I give you warnings about storage shortages before they occur. The DSI124I message indicates a more severe storage condition. If you see DSI124I messages, you might be ignoring important early warning messages or have disabled storage limits using the DEFAULTS or OVERRIDE commands. The SMF type 38 subtype 2 data can help you review the storage history for NetView program. You can use the NetView TASKURPT sample to retrieve this data, or use TASKURPT as a guide to writing other SMF reports.

If your system is running successfully and the NetView program begins to run out of storage, you may receive multiple abends. Save the memory dump data set from the first abend. In the system log, look for a message that indicates that a partial memory dump was created. If only a partial memory dump was created, you can re-create the problem with a larger memory dump data set to get a complete memory dump. A complete memory dump is usually required by IBM® Software Support to solve short-of-storage problems.

If your storage calculations are correct, but you still have short-of-storage problems, run the NetView internal trace and gather the following:
  • Storage calculations from IBM Z NetView Tuning Guide for your operating system.
  • The network log after several TASKUTIL or TASKMON, RESOURCE, and SESSMDIS command invocations, and optionally, at least one CMDMON DISPLAY invocation as close to the time of the problem as possible.
  • The first memory dump of the abend, or a console memory dump if you are getting messages indicating an out-of-storage condition. Dump the entire NetView address space.

Out-of-storage memory dump:

Look for queues in an out-of-storage memory dump. Use IPCS to obtain a list of these queues: 
VERBX CNMIPCS 'QUE(ALL)'
  • Each task has a public and private message queue that can build up if you do not process the message event control block (ECB). This might happen if you have AUTOWRAP turned off. You can use the IPCS RUNCHAIN command to find out how many elements exist. The message queues point to an internal function request (IFR) that contains a normal BUFHDR and are chained together at X'18'. To determine how many messages are queued, run the entire chain.

    The NetView program monitors the message queue, counts the number of messages, and places the count in the public queue. You can determine the number of messages on the public queue by checking the TVB X'CC' for 4 bytes. The TVB characters begin with X'F2'.

    The operator station task (OST), NetView-to-NetView task (NNT), and the primary POI task (PPT) have three public and three private queues, as follows:
    • The normal public and private message queues are chained off the TVB, TVB X'24', and X'28'.
    • The high private and public message queues are chained off the TVB, TVB X'DC', and X'D4'.
    • The low private and public message queues are chained off the TVB, TVB X'D8', and X'D0'.

    The optional task (OPT) has one public and one private message queue. The normal public and private message queues are chained off the TVB, TVB X'24', and X'28'.

    The data services task (DST) has one public message queue, one private message queue, and two internal queues. The normal public and private message queues are chained off the TVB, TVB X'24', and X'28'. For DSTs, you can check two internal queues to determine if they are backed up and possibly using more storage. You can find the internal queues in the TID control block. The TID is pointed to by TIB X'70' and begins with F4.

    In the TID, check queues X'AF0' and X'AF8'. These two queues point to a NetView buffer that has a BUFHDR. The chain pointer is at X'18' in the BUFHDR. These two queues represent requests to be processed by the DST. For example, the BNJDSERV task represents hardware events to be recorded to VSAM. The amount of storage used for these buffers is variable, but 400 bytes is the average size.

    If the hardware monitor TID queues are backed up, you might receive abend 778 in VTAM® because of a shortage in CSA SP229. This happens because VTAM expands the buffers into the CSA SP229 subpool.

  • Coding the RATE statement allows you to detect an excessive rate of hardware events and set a blocking filter when the excessive rate is detected.
  • In the session monitor, check a VSAM record queue to determine whether it is backed up. Find the TVB for AAUTSKLP and the TIB pointer at X'8'. The TIB X'6C' points to the AAUTSCT control block. Scan the AAUTSCT, looking for the name AAUTSTRR. The word that follows AAUTSTRR is the address of the AAUTSTRR. The AAUTSTRR X'24' is a pointer to the AAUTSTAT control block. The AAUTSTAT X'84' is a count of the number of records waiting to be written to the session monitor database. The amount of storage used by each of these requests varies, but an average size is 400 bytes.