2009年10月15日 星期四

Collect troubleshooting data for file control (VSAM non-RLS) waits in CICS on z/OS

You receive a file control wait in CICS on z/OS. You would like to know what documentation the CICS support team will need to diagnose your problem. If you gather this documentation before calling support it will expedite the troubleshooting process, and save you time.




Gather the following documentation for a file control wait before calling IBM® support:


Required doc:
(1) CICS message log and the MVS™ system log (SYSLOG).
(2) CICS internal trace that is included in the MVS system dump when tracing is active. The trace should be at least 10240K and when possible level 1 tracing should be on for all CICS components and level 1-2 for the FC component.
(3) An MVS™ system dump of the CICS region taken as soon as you notice the hang or wait. Use the following MVS command followed by the reply to capture the dump:DUMP COMM=(dumpname)R yy,JOBNAME=( cicsjob),SDATA=(ALLNUC,PSA,SQA,CSA,LPA,TRT,LSQA,RGN) where dumpname is the name you want to give the dump, yy is the reply id, and cicsjobis the job name for your CICS region.


Optional doc:
(1) If feasible, save off the dataset by using IDCAMS ALTER NEWNAME to rename the dataset and save it in place (note that the example in the link has a DEFINE before the ALTER). If this is not feasible, run IDCAMS EXAMINE ITEST DTEST against the dataset and any alternate indexes associated with the dataset before continuing.
(2) If you are able to reproduce the problem, consider using CICS auxiliary trace or GTF Trace in combination with the MVS system dump. The dump is unlikely to tell you anything about system activity in the period leading up to the wait. This is because the trace table will probably wrap before you have had a chance to respond.



沒有留言:

張貼留言