Diagnosing Allocation Issues

Troubleshooting › Tape Device Allocation Problems › Diagnosing Allocation Issues

Diagnosing Allocation Issues

Allocation delays identified through GTALOCAL enqueue conflicts can be diagnosed by using the following procedures.

Issue the following command to identify the system causing allocation delay.
```
F MIM,DIAGNOSE SYSTEMS
```
Is there a system listed as holding locks?

YES

Go to Step 2.

NO

Have MIM2162W and MIM2165W or MIM2207I messages been issued?
YES
Issue the following z/OS command to determine why the resource is being held:
```
D GRS,RES=(<resource name>,*)
```
Where <resource name> is either SYSIEFSD or SYSZIOS as is shown in the MIM216x message.

If the resource in the message is SYSIEFSD DDRTPUR. Issue the following z/OS command to check for outstanding SWAP WTORs:
```
D R,L,CN=(ALL)
```
Is there an outstanding SWAP WTOR?

YES

Respond to the WTOR and follow swap to completion.

NO

If you cannot determine why the job holding the SYSIEFSD DDRTPUR resource is causing the allocation delay, go to Step 6.

NO

Problem circumstances may have changed. If you come to this point repeatedly and still believe there is a problem, contact CA Technical Support.

Return to Step 1.
On the system holding the locks identified in Step 1 issue the following CA MIA command:
```
F MIM,DIAGNOSE JOB
```
Has any job been given ownership of device group locks?
YES

Go to Step 3.

NO
Is the CA MIA task waiting for device group locks?
YES

Go to Step 3.

NO
a. Issue the following CA MIA command:

SYSDUMP JOBNAMES=(ALLOCAS,IOSAS,GRS) TITLE="ALLOCATION HANG" SYSTEM=ALL

b. Issue the following CA MIA command on this system:

... SHUTDOWN LOCAL

c. Restart CA MIA on this system.
If the problem is not resolved, call CA Technical Support and ask for help with CA MIA.
Issue the following z/OS command:
```
D R,L,CN=(ALL)
```
Are there any outstanding SWAP messages or any outstanding allocation recovery messages?

YES

Reply to the outstanding WTOR.

NO

Go to Step 4.
Issue the following CA MIA command:
```
F MIM,DIAGNOSE VARY
```
Are there any active VARY requests that show a Wait-RSN of “VARY Dev?”
YES
1. Check to see if the devices involved in outstanding VARY processing are functional. If the problem is not resolved, issue the following command:
```
   F MIM,SYSDUMP JOBNAMES=(ALLOCAS,IOSAS,GRS) TITLE="VARY DELAY"
```
2. Issue a the following command to CA MIA:
```
   SHUTDOWN LOCAL
```
If the problem is not resolved, contact CA Technical Support and ask for help with CA MIA.
NO

Go to Step 5.
Do the following:
1. Look in the system log for IOS003A INTERVENTION REQUIRED messages for tape devices. “Ready” any tape device mentioned in these messages. Allocation hangs can occur when jobs perform AVR processing on devices that are experiencing I/O problems.
2. Review the system log for I/O error messages for tape devices. If any have been issued for devices that do not appear to be allocated, VARY those devices OVERGENNED. Allocation hangs can occur when jobs perform AVR processing on devices that are experiencing I/O problems.
3. If I/O errors are not the cause of the allocation delay, go to Step 6.
Issue the following z/OS command to obtain related z/OS allocation enqueue information:
```
D GRS,RES=(SYSIEFSD,*)
```
Retain the information in the resulting display for diagnostic purposes.

Go to Step 7.
Get an SVC dump of problem jobs identified in Step 1 or Step 2 by issuing the following command:
```
F MIM,SYSDUMP JOB=(jobname,ALLOCAS,ISOAS,GRS),TITLE='ALLOCATION DELAY', SYSTEM=ALL
```
Note: When the DIAGNOSE display shows a job ID of MASTER as being 'delayed for' or 'given' a single device group lock, this most likely represents a job that is in the middle of SWAP processing. Look for the MIM2207I message to determine the actual job associated with the SWAP. Then, issue the preceding dump command for two job names - the job name for the MASTER address space and the swapping job name (JOB=(*MASTER*,jobname,ALLOCAS,IOSAS,GRS)).

Can this job be canceled?

YES

Cancel the job.

NO

Issue a SHUTDOWN LOCAL command to CA MIA. If the problem is not resolved, call CA Technical Support and ask for CA MIA.

Go to Step 8.
Gather any dumps taken, SYSLOGs for the problem time period, along with traces and job logs of any canceled jobs, and contact CA Technical Support during normal business hours to receive an incident number for this problem.
Important: If the problem is recurring, then adequate documentation is essential in solving the problem. Technical Support needs GTAF trace information before they can analyze the problem. Follow these steps:
1. Dynamically allocate a MIM trace data set or SYSOUT using the ADDLOG command.
2. To enable internal MIA tracing, issue the following commands:
```
F MIM,SET GTAF RESETTRACE=(LOCKS,MASKS,SWAP,VARY,UNITALOC) 
F MIM,SET GTAF SETTRACE=(LOCKS,MASKS,SWAP,VARY,UNITALOC 
F MIM,SET GTAF RESETPRINT=(LOCKS,MASKS,SWAP,VARY,UNITALOC)
F MIM,SET GTAF SETPRINT=(LOCKS,MASKS,SWAP,VARY,UNITALOC)
F MIM,SET MIM RESETTRACE=TRANSACTION,RESETPRINT=TRANSACTION
F MIM,SET MIM SETT=TRANSACTION=(07,10,14),SETP=TRANSACTION
```
3. Issue the following command to start the traces:
```
F MIM,SET TRACE=ON 
```
4. Allow the TRACEs to run long enough to capture the problem event.
5. Issue the following command to stop the traces:
```
F MIM,SET TRACE=OFF
```
Restart the MIA address space.

Tell Technical Publications how we can improve this information