DMS2974 DSN CURRENTLY BEING RESTORED BY ANOTHER TASK
Article ID: 140141
Updated On:
Products
Disk Backup and Restore - MVS
DISK BACKUP AND RESTORE- ADD-ON OPTIO
DISK BACKUP AND RESTORE
Issue/Introduction
Because of VSM problems DMSAR tasks had been killed using the MAINVIEW KILL command. After the VSM was again up and running attempts to restore these data sets fail with message:
DMS2974 DSN CURRENTLY BEING RESTORED BY ANOTHER TASK
This message DMS2974 DSN CURRENTLY BEING RESTORED BY ANOTHER TASK is normally issues due to a temporary conflict when Disk cannot restore a data set because another Disk task, usually automatic restore (DMSAR), is already restoring it.
If this temporary conflict persists it indicates an unexpected error has occurred.
First check for any active DMSAR's which are actively restoring the data set and see if they are waiting on a tape and resolve those errors.
If no obvious conflicts exist then there may be ENQs unexpectedly held by Disk DMSAR when using Vantage ARM (Automatic Restore Manager)
In one case this occurred because of VSM problems DMSAR tasks had been killed using the MAINVIEW KILL command. After the VSM was again up and running attempts to restore these data sets fail with message:
DMS2974 DSN CURRENTLY BEING RESTORED BY ANOTHER TASK
In other cases there were unknown failures which caused the ENQs to be held by Vantage longer than expected.
Cause
Internally during restore Disk serializes with other restore processes, including automatic restore by checking for special ENQs.
Disk gets ENQs with the major name DMSAUTx where the x will be a value from 1 to 4, the minor name is the data set being restored.
The message: DMS2974 DSN CURRENTLY BEING RESTORED BY ANOTHER TASK
Is issued if Disk detects there is a DMSAUTx ENQ for the data set being restored.
You need to determine which tasks currently hold the ENQ which the Disk restore task is trying to acquire.
Issue the command D GRS,RES=(DMSAUT*,*) to show all of the ENQs for restore and find the data set which is failing to be restored.
If that is too much information then issue the command D GRS,RES=(DMSAUT*,<DSN>) to show all of the Disk automatic restore ENQs only for that data set.
Note that if you are using a GRS ring then you will need to issue the command on each LPAR.
When the command is issued it should show that the Vantage Address space has an outstanding ENQ for Major Name DMSAUTx and Minor Name of the data set being restored.
To allow the data set to be restored you will need to get the ENQ to be released but to help to investigate more if the problem occurs again, please do the following:
1.Add the following DDNAME to your DMSAR task procedure:
ARESDIAG DD SYSOUT=*
This will print for every restore extra diag messages. Feel free to delete it if it would cause any problems. But we run it like this in our environment and it doesn't cause problems in terms of CPU or filling up the space in spool.
2.In case that the deadlock happens again, collect the following:
a) Console dump of Vantage host task + complete log
b) Console dump of any up and running DMSAR tasks + complete log
c) System log few hours before the problem occurred.
3. In addition, we strongly recommend to add SYSMDUMP ddname to you Vantage host task and delete SYSUDUMP DDNAME:
//SYSMDUMP DD DISP=OLD,DSN=&DSNPFX..&SYSNAME..SYSMDUMP,FREE=CLOSE,
// SPACE=(CYL,(1500,150))
Customize it to your needs but make sure that it doesn't go to the spool, don't use SYSMDUMP DD SYSOUT=*. This is not required for this particular problem but it would speed up analysis in case of any abend occurs in the Vantage host task.
4. Note that setting up a SLIP is unfortunately not an option as there is no specific event that would indicate that the deadlock started occurring.
ARESDIAG DD SYSOUT=*
This will print for every restore extra diag messages. Feel free to delete it if it would cause any problems. But we run it like this in our environment and it doesn't cause problems in terms of CPU or filling up the space in spool.
2.In case that the deadlock happens again, collect the following:
a) Console dump of Vantage host task + complete log
b) Console dump of any up and running DMSAR tasks + complete log
c) System log few hours before the problem occurred.
3. In addition, we strongly recommend to add SYSMDUMP ddname to you Vantage host task and delete SYSUDUMP DDNAME:
//SYSMDUMP DD DISP=OLD,DSN=&DSNPFX..&
// SPACE=(CYL,(1500,150))
Customize it to your needs but make sure that it doesn't go to the spool, don't use SYSMDUMP DD SYSOUT=*. This is not required for this particular problem but it would speed up analysis in case of any abend occurs in the Vantage host task.
4. Note that setting up a SLIP is unfortunately not an option as there is no specific event that would indicate that the deadlock started occurring.
To release the ENQ you must get the Vantage to release them, please consider the following:
1) Don't use KILL command against Vantage because recovery routines don't get control and thus outstanding ENQs are not released.
2) If an active DMSAR needs to be stopped try STOP, CANCEL or FORCE with ARM in that order. Using these commands should not result in outstanding ENQs.
3) Use KILL command as lost resort only , if STOP or CANCEL or FORCE did not work for any reason.
4) An alternative to killing the Vantage task is to issue commands.
4) An alternative to killing the Vantage task is to issue commands.
a) To terminate ARM issue the command:
F SAMS,ARM,SUSPEND
a) To restart ARM issue the command
F SAMS,ARM,RESUME
F SAMS,ARM,SUSPEND
a) To restart ARM issue the command
F SAMS,ARM,RESUME
Resolution
To release the outstanding ENQs recycle the Vantage address space.
Ensure to bring Vantage down and up on all systems if not sure what system is holding the enqueue.
Additional Information
Client experienced this problem because of VSM problems DMSAR tasks had been killed using the MAINVIEW KILL command. After the VSM was again up and running attempts to restore these data sets fail with message:
DMS2974 DSN CURRENTLY BEING RESTORED BY ANOTHER TASK
Feedback
Yes
No
Powered by
