 |
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.
- 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
- Activate CSM VTAM traces:
MODIFY NET,TRACE,TYPE=VTAM,
OPTION=(CSM,CIO,SMS,PSS,PIU,MSG,SSCP,API,NRM,XBUF,APPC,CIA)
- If the DISPLAY CSM output indicates TCP/IP
owns the storage:
- 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.
- 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.
- Obtain console dumps VTAM and TCP/IP.
- 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.
- 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'.*)
|