Troubleshooting
Problem
HSM recall of a data set fails with DSS error message ADR910E RC 500005E3 RSN 000C0063.
Symptom
ADR910E (ttt)-mmmmm(yy), AN ERROR WAS ENCOUNTERED DURING DATA MOVEMENT
PROCESSING. RETURN CODE = 500005E3, REASON CODE = 000C0063
...
ARC1001I datasetname RECALL FAILED, RC=0069, REAS=0910
ARC1169I RECALL/RECOVER FAILED DUE TO AN ERROR IN DFDSS
PROCESSING. RETURN CODE = 500005E3, REASON CODE = 000C0063
...
ARC1001I datasetname RECALL FAILED, RC=0069, REAS=0910
ARC1169I RECALL/RECOVER FAILED DUE TO AN ERROR IN DFDSS
Cause
The data set is failing during I/O processing when DSS tries to RESTORE the data set from the migration volume. There are several possible reasons for this happening, but the most likely cause is that the data set was corrupt when it was migrated. The possible reasons are that:
1) There are times that the dumped data set had been broken. This could be due to incomplete trailer records for a data set. The primary reason has been shown to be that the trailer records were not existing when the data set was dumped.
1) There are times that the dumped data set had been broken. This could be due to incomplete trailer records for a data set. The primary reason has been shown to be that the trailer records were not existing when the data set was dumped.
2) Or that there is a different level of DSS, perhaps an older version, that gets caught up in the overall concatenation for the level that DSS is attempting to restore from.
For example, if the job is being run on a z/OS 2.10 level of code, there could be a mixed 1.10 or 1.12 ADRDSSU LMOD concatenated ahead of the current 2.10 level of ADRDSSU DSS LMOD. Thus the mixed level of code may cause error.
3) Or a PTF on DSS had been applied, but LLA REFRESH had not been performed.
4) Or if DSS dump from a batch job had been run, but then the dump data set had been FTP'd to another system to restore.
DSS does not perform any data set integrity validation prior to dumping it during DSS DUMP or HSM MIGRATE/BACKUP processing.
DSS does not perform any data set integrity validation prior to dumping it during DSS DUMP or HSM MIGRATE/BACKUP processing.
Resolving The Problem
Check the possibility of items 2, 3, and 4 are in play. If so, then see the below information for next actions. If not, then the best course of action is to recover the data set from a known good backup copy.
1) The only way to obtain the original data set is from a previous backup or dump.
2) Check via ISRDDN for possible concatenation of some down level piece of code inadvertently being pointed to. It could be mixed level LINKLIB DSS versions.
3) If DSS LMOD is being loaded into the in-core storage of a product, such as HSM, then after the LLA refresh, the product such as HSM must be bounced to load the new ADRDSSU DSS code into HSM.
4) Be sure that the DSS dump data set was tersed prior to FTP process, and that the system the FTP dump is being sent to has all of the toleration maintenance applied and LLA refresh being done, etc.
Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB56","label":"Z HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG90","label":"z\/OS"},"ARM Category":[{"code":"a8m0z0000000AK3AAM","label":"DFSMS-\u003EHSM-\u003ERecall"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1.10.0;1.11.0;1.12.0;1.9.0;2.3.0;2.4.0;2.5.0;3.1.0;3.2.0"}]
Was this topic helpful?
Document Information
Modified date:
05 June 2025
UID
ibm17235295