st06rlr
New User
Joined: 16 Mar 2006
Posts: 2
Location: Ohio
|
|
|
|
Greetings,
We have been recieving warning messages in IDCAMS DIAG catalog output. These messages indicate that a file is in a DEFERRED ROLL IN STATE. The problem with this is that the files in question are not GDG. I have attempted to correct this with IDCAMS ALTER ROLLIN. It fails because they are not GDG.
Has any one seen this before? If so, how is it fixed?
Thanks
Example:Error message from IDCAMS diagnose IDFCAT
IDC01380I GENERATION DATA SET FOUND IN DEFERRED ROLL IN STATE
IDC01380I ATM.CHKPOINT.TIMEOUT
Quick reference output for IDC01280I
IDC01380I GENERATION DATA SET FOUND IN DEFERRED ROLL IN STATE
Explanation: It is an informational message only. Comparison of GDs is
deferred and roll in state and catalog recording continues.
Detecting Module: IDCDA01
Information on file.
TSO listc entries('ATM.CHKPOINT.TIMEOUT') all
NONVSAM ------- ATM.CHKPOINT.TIMEOUT
IN-CAT --- CATALOG.ICF1.PROGPROD.DATA
HISTORY
DATASET-OWNER-----(NULL) CREATION--------1996.191
RELEASE----------------2 EXPIRATION------0000.000
ACCOUNT-INFO-----------------------------------(NULL)
STATUS----------DEFERRED
SMSDATA
STORAGECLASS ----STORAGE MANAGEMENTCLASS----MIG45
DATACLASS --------(NULL) LBACKUP ---2006.071.1848
VOLUMES
VOLSER------------STR008 DEVTYPE------X'3010200F'
FSEQN-----------------0
ASSOCIATIONS--------(NULL)
ATTRIBUTES
*** |
|
st06rlr
New User
Joined: 16 Mar 2006
Posts: 2
Location: Ohio
|
|
|
|
Found this information on IBM's web site when I did a search on IDCDA01 the detecting module.
Problem
Prior to the application of the PTFs for OW51458, there is the possibility that NON GDG data sets may be set to DEFERRED ROLLIN STATUS. This is incorrect as only GDG's should have the possibility of being in DEFERRED ROLLIN STATUS. OW51458 corrects a problem with renaming a data set when the rename fails, usually due to a security failure.
Solution
To correct this condition, the data set must be on a dasd volume. If the data set has been migrated, then it needs to be recalled to dasd volume (and not a ML1 volume). If you cannot recall the dataset, then recovering from a backup is required. The following samples assume the data set name that is incorrectly marked as being in deferred rollin status is named IBM.PROD.LOADLIB.
If the data set has been migrated by DFHSM, then try recalling it to a dasd volume. If you are unable to recall the data, then use DFHSM to recover the data set to another name for example IBM.PROD.LOADLIB.RECOVER.
Assuming you were able to recall the data set to a dasd volume, then issue the following IDCAMS commands:
LISTCAT ENT(IBM.PROD.LOADLIB) ALL
**** Note that you will need some of the information from the listcat issued above****
DELETE NONVSAM IBM.PROD.LOADLIB NOSCRATCH
**** Note the above will delete the catalog entry, but leave the data set on the volume ****
DEFINE NONVSAM (NAME(IBM.PROD.LOADLIB) -
RECATALOG VOLUMES(XXXXXX) DEVICETYPES(3390)) **** Replace the value XXXXXX with the volser from the LISTCAT command you issued above. If your dasd type is 3390 then the above is correct. If the device type is 3380 then replace 3390 with 3380, If the device type is 9345 then replace 3390 with 9345. To determine the device type refer to the LISTCAT you issued above. If the DEVTYPE is 3010200F then the devicetype is 3390. If the DEVTYPE is 3010200E then the devicetype is 3380. If the DEVTYPE is 30102004 then the devicetype is 9345. ****
If you cannot use DFHSM recall and will be using DFHSM recover instead to recover the data set to a different name then issue the following IDCAMS commands using the above example data set name:
LISTCAT ENT(IBM.PROD.LOADLIB.RECOVER) ALL
**** Note this command should be issued against the recovered data set with the new name so we what the various attributes are ****
DELETE NONVSAM IBM.PROD.LOADLIB PURGE
**** Note this should be issued against the original data set, not the recovered data set ****
ALTER IBM.PROD.LOADLIB.RECOVER -
NEWNAME(IBM.PROD.LOADLIB) |
|
