I change para to ADASAV RESTORE FMOVE=55
but getting error as below
ERROR-158, Incomplete restore tape
DATA RABN 1664179 was not found on the restore tape.
End-Of-File occurred instead.
Possibly a required tape volume is missing.
Supply a complete restore tape and rerun the job.
This is progress… you got past the initial check and the utility allocated space to place the file on the target database.
Now you need to make sure in your JCL that you are supplying the entire backup file. If you didn’t take the backup, please get the information from the person who did what datasets/volumes you need to restore this file.
The information you provided does not explain the abend (I assume it’s the same abend where there were missing blocks from the backup of the file from the source database db161).
The only reason the restore job would fail is because you did not supply all the volumes required for input from the backups.
Did you supply all you needed in DDREST1? Is there a DDREST2 (or more) needed, and if so, do you provide the utility parm (DRIVES=) to have it find it? Do you override the catalog VOL=SER=(xxx) list and leave it short calling for tape mounts?
It’s hard to direct you to a specific answer without detailed knowledge of the job that took the backup and the job you are running for the restore, but this is the area you need to be looking.
Unused storage has Data & asso values as 386643, 243964 respectively,
Maximum blk number assigned to Associator and DATA of ADA225. (Target) are 314986, 529672 respectively.
We need following space for the file 55 (from 161, source)
Again, you are not using FMOVE, so you can have millions of free blocks
and it still won’t help when the blocks originally allocated to the file are not available,
in fact a single block not available will cause it to fail.
DATA RABN 1664179 was not found on the restore tap
End-Of-File occurred instead.
Possibly a required tape volume is missing.
Supply a complete restore tape and rerun the job.
I notice you specify three DDRESTn DD cards, but don’t have DRIVES=3, so it will only look at DDREST1 but ignore the others. Either DDREST2 and DDREST3 are irrelevant, or you need to add DRIVES=3.
I notice that the three datasets for the three DDRESTn DD cards are sequential members of a GDG. That’s not typical and I find it suspicious. Usually those would be three consecutive backups, not three drives for the same backup.
I notice you specify VOL=SER=(tape1,tape2,…). Are you certain that your volser list for DDREST1 is all-inclusive? If you take this off, will the catalog call for all tapes in the list?
To me, number 3 is the most likely area that will fix your restore job. Try again with ADASAV RESTORE FMOVE without the VOL=SER= parm on your DDREST1 DD card.
P) I notice you specify three DDRESTn DD cards, but don’t have DRIVES=3, so it will only look at DDREST1 but ignore the others. Either DDREST2 and DDREST3 are irrelevant, or you need to add DRIVES=3.
So it is ADASAV we are looking at here and not ADALOD as I had mistakenly assumed yesterday. I was half way through a reply suggesting trying the DRIVES parameter when I noticed the GDG generation issue. In the mean time Wolfgang & Brian have chipped in to answer that one.
Would I be right in assuming that you want to use the latest backup from prod?
I am nearly 100% certain ADASAV would [edited but means abend] if you tried to restore a file from backups taken at different times on three different drives with DRIVES=3.
RESTORE FILES: Restore Files to Original RABNs from Offline Source
RESTORE FMOVE: Restore Files to Any RABNs from Offline Source
In my case I was restoring production database file, TAPPS161, file 55, to ADA225
We used the database backup files created on Mar 5, Monday. The backup job was ADSAV161. If we used RESTORE FILES, Restore Files to Original RABNs (from 161) but RESTORE FMOVE Restore Files to Any RABNs (at 225).
Basically, FILES= and FMOVE= are for providing the file list that you want to restore from the ADASAV backup into your target database. The difference between the two is:
FILES= requires that the files be restored into the exact RABN ranges they occupied when the ADASAV was taken.
FMOVE= will restore the files anywhere that space exists on the target.
Because you are not restoring from a backup taken of your target database, but another one, and because the RABN ranges used by file 55 on the source database are either occupied by another file or are otherwise not available on the target db, the FILES= option fails.
I was half way through a reply suggesting trying the DRIVES parameter when I noticed the GDG generation issue. In the mean time Wolfgang & Brian have chipped in to answer that one.