VVDS/VVR/CELL ERRORS ENCOUNTERED FOR CLUSTER
PNGG00.CSPACK.CSDITB.D0.KS250 seems to be the root cause. At others have
suggested run diagnose/examine on the affected vvds's. and catalogs.
Correct any errors found and retry.
It may be that the original backup was invalid.
You might also check OA38052/OA37221/OA34295 depending on the size of
the dataset.
You could also try pre-allocating the target of the restore and use the
replace keyword on the restore command.
HTH,
<snip>
It seems like this is neither a HSM or a VVDS size issue. The space in
the SMS pool is also sufficient to this huge data set. It seems more
like a ADRDSSU issue. A restore with a rename for a similar data set was
attempted, and the results were the same:
RESTORE INDD(TAPEIN) -
DS(INCL( -
PNGG00.CSPACK.CSDITB.**, -
)) -
RENAMEU ( -
(PNGG00.CSPACK.CSDITB.**,QNGG00.WSPACK.CSDITB.**), -
) CATALOG SPHERE
ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND
'RESTORE '
ADR109I (R/I)-RI01 (01), 2012.069 14:38:00 INITIAL SCAN OF USER CONTROL
STATEMENTS COMPLETED
ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK
0ADR006I (001)-STEND(01), 2012.069 14:38:00 EXECUTION BEGINS
0ADR780I (001)-TDDS (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN
LOGICAL DATA SET FORMAT AND WAS CREATED BY DFSMSDSS VERSION
1 RELEASE 12 MODIFICATION LEVEL 0 ON 2012.061
14:10:03
0ADR711I (001)-NEWDS(01), DATA SET PNGG00.CSPACK.CSDITB.D0.KS250 HAS
BEEN ALLOCATED WITH NEWNAME QNGG00.WSPACK.CSDITB.D0.KS250 USING
STORCLAS B2B26, DATACLAS @KS250, AND MGMTCLAS
@939R
0ADR788I (001)-TDUNL(01), PROCESSING COMPLETED FOR CLUSTER
PNGG00.CSPACK.CSDITB.D0.KS250, 30109794 RECORD(S) PROCESSED
0ADR477E (001)-TDRF1(01), VVDS/VVR/CELL ERRORS ENCOUNTERED FOR CLUSTER
PNGG00.CSPACK.CSDITB.D0.KS250
0ADR417W (001)-TDRF1(05), COPY/RESTORE OF DATA SET
PNGG00.CSPACK.CSDITB.D0.KS250 IS INCOMPLETE, 05
0ADR415W (001)-TDLOG(01), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED
FROM ANY VOLUME
0ADR480W (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE NOT PROCESSED
FROM THE LOGICALLY FORMATTED DUMP TAPE DUE TO ERRORS:
0 PNGG00.CSPACK.CSDITB.D0.KS250
0ADR006I (001)-STEND(02), 2012.069 14:50:23 EXECUTION ENDS
0ADR013I (001)-CLTSK(01), 2012.069 14:50:23 TASK COMPLETED WITH RETURN
CODE 0008
0ADR012I (SCH)-DSSU (01), 2012.069 14:50:23 DFSMSDSS PROCESSING
COMPLETE. HIGHEST RETURN CODE IS 0008 FROM:
TASK 001
Any suggestions... :(
</snip>
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On
Behalf Of Lizette Koehler
Sent: 24 February 2012 02:07 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: HSM Recall Failure
>
> Hi There,
>
> I'm trying to recall a data set migrated to ML2. The recall fails due
> to
errors found in
> either the VVDS or VTOC. Is there somebody that would be able to point
> me
in the
> right direction of investigation
>
> PAGE 0001 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES
2012.055
> 11:55
> ADR035I (SCH)-PRIME(06), INSTALLATION EXIT ALTERED BYPASS FAC CLASS
> CHK DEFAULT TO YES RESTORE INDDNAME(SYS79943) CAT SPHERE -
> BYPASSACS(PNGG00.IT3PCK.CSDITB.D0.KS250 ) -
> MGMTCLAS(@959 ) -
> STORCLAS(B2B26 ) -
> DATASET(INCLUDE(PNGG00.IT3PCK.CSDITB.D0.KS250 ))
> ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND
> 'RESTORE
'
> ADR109I (R/I)-RI01 (01), 2012.055 11:55:12 INITIAL SCAN OF USER
> CONTROL STATEME NTS COMPLETED ADR050I (001)-PRIME(01), DFSMSDSS
> INVOKED VIA APPLICATION INTERFACE ADR016I (001)-PRIME(01), RACF
> LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01),
> 2012.055 11:55:12 EXECUTION BEGINS ADR780I (001)-TDDS (01), THE INPUT
> DUMP DATA SET BEING PROCESSED IS IN LOGICAL DATA SET FORMAT AND WAS
> CREATED BY DFSMSDSS VERSION
> 1 RELEASE 12 MODIFICATION LEVEL 0 ON 2011.270
06:45:10
> ADR711I (001)-NEWDS(01), DATA SET PNGG00.IT3PCK.CSDITB.D0.KS250 HAS
> BEEN ALLOCATED USING STORCLAS B2B26, DATACLAS @KS250, AND
> MGMTCLAS @959 ADR788I (001)-TDUNL(01),
> PROCESSING COMPLETED FOR CLUSTER PNGG00.IT3PCK.CSDITB.
> D0.KS250, 16552872 RECORD(S) PROCESSED ADR477E (001)-TDRF1(01),
> VVDS/VVR/CELL ERRORS ENCOUNTERED FOR CLUSTER PNGG00.IT
> 3PCK.CSDITB.D0.KS250
> ADR417W (001)-TDRF1(05), COPY/RESTORE OF DATA SET
> PNGG00.IT3PCK.CSDITB.D0.KS250
> IS INCOMPLETE, 05
> ADR415W (001)-TDLOG(01), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED
> FROM ANY VOLUME ADR480W (001)-TDLOG(01), THE FOLLOWING DATA SETS WERE
> NOT PROCESSED FROM THE LO GICALLY FORMATTED DUMP TAPE DUE TO ERRORS:
> PNGG00.IT3PCK.CSDITB.D0.KS250 ADR006I
> (001)-STEND(02), 2012.055 12:11:00 EXECUTION ENDS ADR013I
> (001)-CLTSK(01), 2012.055 12:11:00 TASK COMPLETED WITH RETURN CODE
> 0008 ADR012I (SCH)-DSSU (01), 2012.055 12:11:00 DFSMSDSS PROCESSING
> COMPLETE. HIGHES T RETURN CODE IS 0008 FROM:
> TASK 001
> ARC1001I PNGG00.IT3PCK.CSDITB.D0.KS250 RECALL FAILED, RC=0069,
> REAS=0477 ARC1169I RECALL/RECOVER FAILED DUE TO AN ERROR IN DFDSS
> ***
>
>
> Hi There,
>
> Please explain why not all VVDSs catalog pointers. When doing a
listcat,
the return is as
> follows:
>
> IDC3012I ENTRY SYS1.VVDS.VAPBPC7 NOT FOUND+
> IDC1566I ** SYS1.VVDS.VAPBPC7 NOT LISTED
> IDC0014I LASTCC=4
> IDC3009I ** VSAM CATALOG RETURN CODE IS 8 - REASON CODE IS IGG0CLEG-42
> ***
> Apparently this is normal.
>
> I want to see the logic here.
>
> BTW, these are sms-managed volumes.
>
First look at the ADR477E message. There are actually 3 reasons why it
could
happen.
An error was encountered processing a VVR. If there was an I/O
error,
message ADR231E precede this message.
An error was encountered on a catalog request. Message ADR497E
precede
this message.
There be insufficient storage for internal processing. Messages
ADR008E,
ADR018I, or ADR376E precede this message.
Looking at your DFDSS output I did not see any of the targeted messages.
However, this seems to be a huge file
ADR788I (001)-TDUNL(01), PROCESSING COMPLETED FOR CLUSTER
PNGG00.IT3PCK.CSDITB.D0.KS250, 16552872 RECORD(S) PROCESSED
So you need to
1) make sure there is sufficient space in the SMS Pool
2) make sure the VVDS and VTOC are large enough for the volumes in your
pool
I am curious as to why you focused on this one volume and the VVDS. I
did
not see any error messages targeting that volume or a vvds issue.
IIRC - VVDS is done with a DEFINE command so should be cataloged.
However,
if there are a dasd moves or renames (volumes clipped), that might be
some
of the issue. Go to Option 3.4 in ISPF and just list the contents of
the
volume. Also do a VTOC list with 3.4. Or use ISMF to review the
information about the volume and VTOC, VVDS and VTOCIX sizes.
See if the volume APBPC7 has a large enough VVDS and that the VVDS
exists on
the volume. If so, you may need to recatalog or recover the VVDS
After recovery, a BCS might not contain entries for all the VVDSs on
volumes
where the BCS has data sets. In this case, you might want to recatalog
the
VVDS so that the BCS contains entries for all connected VVDSs.
If you want to recreate the BCS entry for a VVDS, use the access method
services DEFINE CLUSTER command with the RECATALOG option. Specify the
name,
volume of the VVDS, and NONINDEXED. The BCS entry is rebuilt using
information in the VVDS and the command. A VTOC entry for the VVDS must
also
exist.
Before recovering a VVDS, decide if the VVDS is systematically damaged,
or
if only certain entries in the VVDS are damaged. If you cannot open the
VVDS, for example, when you try to print it or access data sets which
have
entries in it, then the VVDS is probably systematically damaged, and
should
be recovered in its entirety.
If you can open the VVDS, run DIAGNOSE to determine which entries are
damaged. You can then use the access method services DELETE command
followed
by data set recovery to recreate the VVDS entries for the affected data
sets, and avoid a total VVDS recovery.
If you decide you must recover the VVDS in its entirety, then all data
sets
represented in the VVDS must be recovered, either individually or by a
full-volume restore. Use DFSMSdss or DFSMShsm for volume recovery.
If you are not using SMS, then only VSAM data sets are affected.
Otherwise,
all data sets on the volume are affected, and must be recovered.
Before recovering a volume, it is necessary to get the volume offline,
so
that users cannot allocate resources on the volume as you try to restore
it.
Use the following procedure to get the volume offline if it is not
managed
by the Storage Management Subsystem:
Use the VARY command to get the volume offline.
Use the DISPLAY command to determine if the volume has been
successfully
varied offline, or if resources are still allocated on the volume.
Use MODIFY CATALOG to unallocate the VVDS or any catalogs on the
volume
which are allocated. Use the VUNALLOCATE parameter to unallocate the
VVDS.
Use the UNALLOCATE command to unallocate the catalog.
If the volume is SMS-managed, set the SMS VOLUME STATUS to DISALL before
using the VARY command. Then, check for allocations with the DISPLAY
command, and use MODIFY CATALOG if necessary.
In either case, I would probably engage IBM with an ETR to assist in
isolating your issue. My guess would be more of a general size or space
issue in your SMS pool. If so, you might see some IGD messages in
SYSLOG at
the time of the failure that might help. Or you might find other
messages
in DFHSM Jes Messages that might help.
Lizette
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
