Networking on z/OS
Previous topic | Next topic | Contents | Glossary | Contact z/OS | PDF


Debugging CSM

Networking on z/OS

CSM problems generally manifest themselves as a central storage problem: either CSM has consumed too much storage, or else an application cannot get any more storage from CSM. The following sequence of instructions provide a good diagnostic approach to CSM problems.

  1. Issue the following commands to determine how much storage is being used and by what job name or address space ID (ASID):
    D NET,CSM,OWNERID=ALL
    D NET,CSM
  2. Activate CSM VTAM traces:
    MODIFY NET,TRACE,TYPE=VTAM,
    OPTION=(CSM,CIO,SMS,PSS,PIU,MSG,SSCP,API,NRM,XBUF,APPC,CIA)
  3. If the DISPLAY CSM output indicates TCP/IP owns the storage:
    1. Update CTIEZB00 (the TCP/IP internal component trace settings) in the system PARMLIB to specify BUFSIZE(16M). This action provides a 16 M CTRACE buffer. TCP/IP must be recycled after this change.
    2. Restart TCP/IP and issue:
      TRACE CT,ON,COMP=SYSTCPIP,SUB=(tcpip)
      R xx,OPTIONS=(STORAGE,VTAM,VTAMDATA,MESSAGE,INTERNET,TCP),END)

      Note that xx is the reply number for the response message listed on the console.

  4. Obtain console dumps VTAM and TCP/IP.
  5. If display output indicates that CSM storage growth is in one of the CSM dataspace pools, dump the dataspace named in the D net,CSM output in addition to the dump of VTAM and TCP/IP.
    To dump CSM dataspace:
    DUMP COMM=(CMS Dataspace Dump)
    R xx,JOBNAME=(net),DSPNAME=(1.dddddddd),
    STOR=(00000000,7FFFFFFF),SDATA=(NUC,CSA,RGN,LSQA,SQA,TRT)

    Note that dddddddd is the name of the dataspace.

  6. If the DISPLAY CSM output indicates TCP/IP owns the storage, also dump the TCP/IP dataspace because you turned on CTRACE in step 3:
    R xx,SDATA=(CSA,SQA,RGN,TRT,NUC),JOBNAME=(tcpip),CONT
    R yy,DSPNAME=(1.*CSM,'tcpip'.*)




Copyright IBM Corporation 1990, 2010