|
View previous topic :: View next topic
|
| Author |
Message |
ananth86
New User
Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad
|
|
|
|
I have a VSAM file that has to be restored across the system. My target system has a different catalog naming std to the source system . Please see my code .. and suggest me if U an doing anything wrong or missing something .
| Code: |
//JS010 EXEC PGM=ADRDSSU,REGION=4096K,PARM='TYPRUN=NORUN'
//SYSPRINT DD SYSOUT=*
//OU001 DD UNIT=3390,DISP=SHR,VOL=SER=NEWVOL
//INDD1 DD DISP=SHR,DSN=SYS2.A1229801.DUMP,
// UNIT=3390,VOL=SER=(XCFXXX)
//SYSIN DD *
RESTORE DATASET(INCLUDE(VSAM.FILE.**)) -
INDDNAME(INDD1) -
OUTDDNAME(OU001) -
CANCELERROR -
REPLACE -
IMPORT -
SPHERE -
RECATALOG(SYSUCAT.MG) -
ADMINISTRATOR -
WAIT(2,2)
/* |
This is my sysprint of the restore job
| Code: |
TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE '
2013.106 03:03:49 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED
RACF LOGGING OPTION IN EFFECT FOR THIS TASK
2013.106 03:03:49 EXECUTION BEGINS
THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL VOLUME FORMAT AND WAS CREATE
RELEASE 11 MODIFICATION LEVEL 0 ON 2013.088 08:16:18
THE FOLLOWING DATA SETS WERE SELECTED FROM VOLUME MJSMPS
CLUSTER NAME VSAM.FILE.CSI
CATALOG NAME SYSUCAT.MJ.GSES
COMPONENT NAME VSAM.FILE.DATA
COMPONENT NAME VSAM.FILE.INDEX
PROCESSING BYPASSED DUE TO NORUN OPTION
2013.106 03:03:50 EXECUTION ENDS
2013.106 03:03:50 TASK COMPLETED WITH RETURN CODE 0000 |
The job ends with CC00 but it is not cataloging the VSAM file to the SYSUCAT.MG .
Looks like DFDSS is not honoring recatlog(SYSUCAT.MG ) Any idea ??? |
|
| Back to top |
|
 |
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6248
Location: Mumbai, India
|
|
|
|
| ananth86 wrote: |
| I have a VSAM file that has to be restored across the system. My target system has a different catalog naming std to the source system. |
I'm not sure what is this asking/telling? Could you please restate it.
OTOH, you've used PARM='TYPRUN=NORUN' at EXEC -- what do you expect it to do for the Job? Suggest remove it and try again. |
|
| Back to top |
|
|
ananth86
New User
Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad
|
|
|
|
Anuj,
I forgot to mention in the first post , I ran the job without PARM='TYPRUN=NORUN' too . The job ended with CC00 but it did not catalog it .
| Quote: |
ananth86 wrote:
I have a VSAM file that has to be restored across the system. My target system has a different catalog naming std to the source system. |
I mean that the catalog name in the source and target systems are different. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
| I mean that the catalog name in the source and target systems are different. |
if the alias hierarchy has been defined properly, the catalog NAMES are irrelevant
| Quote: |
| The job ended with CC00 but it did not catalog it . |
why did You post the useless sysout then ? |
|
| Back to top |
|
|
ananth86
New User
Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad
|
|
|
|
Enrico,
The sysout that I posted is not useless.. The Sysout is from TYPRUN=NORUN.
Sysout shows the file is getting cataloged to SYSUCAT.MJ.GSES , but my Restore command says RECATALOG(SYSUCAT.MG)
Also on the target system alias is defined properly and it is related to SYSUCAT.MG
[/quote] |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
Your NORUN sysout only shows the characteristics of the dataset to be restored. There is nothing shown about your control statements, being processed.
So if you dont show output of an actual restore run, nobody is going to help you. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
| Quote: |
| or missing something . |
| Code: |
| THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL VOLUME FORMAT |
|
|
| Back to top |
|
|
ananth86
New User
Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad
|
|
|
|
| Code: |
TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE '
2013.106 02:48:43 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED
RACF LOGGING OPTION IN EFFECT FOR THIS TASK
2013.106 02:48:43 EXECUTION BEGINS
THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL VOLUME FORMAT AND WAS CREATE
RELEASE 11 MODIFICATION LEVEL 0 ON 2013.088 08:16:18
THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED FROM VOLUME MJSMPS
VSAM.FILE VSAM.FILE.DATA
VSAM.FILE VSAM.FILE.INDEX
2013.106 02:50:54 EXECUTION ENDS
2013.106 02:50:54 TASK COMPLETED WITH RETURN CODE 0000
2013.106 02:50:54 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0000 |
This is the sysprint of the restore job that ran without TYPRUN=NORUN
Enrico,
Is that not possible to restore the file from full vol dump ? |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
did You run a 3.4 on the <target> volume ?
DFDSS works as designed and documented
from one of Your other posts
| Quote: |
| Being a support person in my site, |
why not look at the manual Yourself
all is clearly explained there
the buzzwords are CATALOG/RECATALOG |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
I still have a nasty feeling i (we) are getting fooled by the TS.
This message "THE FOLLOWING DATA SETS WERE SELECTED FROM VOLUME" indicates that TYPRUN=NORUN was specified.
See message ADR353I.
Now why would the TS supply us with edited output (messages left out, no message id's etc.)? |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8796
Location: Welsh Wales
|
|
|
|
| Perhaps the OP is running the restore on the same LPAR as the dump was taken from. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| expat wrote: |
| Perhaps the OP is running the restore on the same LPAR as the dump was taken from. |
That doesnt answer my doubts. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
my manuals are very clear about it
a PHYSICAL(*) restore just restores the <data> and does not mangle the catalogs
(*) from a full volume dump
so the TS might have run the restore, but still wandering in the fog
 |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
There is nothing the TS has posted that makes sense. Use of undefined terms ("restored across the system" means what -- dumped on one LPAR and restored on a different LPAR? dumped on one SYSPLEX and restored on another SYSPLEX? dumped on one JESPLEX and restored on another JESPLEX? something else?) is just one of the many problems; posting partial output and not clearly specifying what is being shown when posting are other issues. Do the LPAR/SYSPLEX/JESPLEX/whatever share a master catalog? Do they share user catalogs? Do they share DASD?
Apart from that, why use RECATALOG unless VSAM.FILE.DATA and VSAM.FILE.INDEX are both in the catalog of the system being used for the restore? If they are not cataloged on that system then CATALOG should be used instead of RECATALOG; if they are cataloged on that system then a RENAMEUNCONDITIONAL is missing from the restore parameters. If the TS is attempting to catalog the data set in a user catalog other than what the system would use, that would be an issue to bring up with site support not a forum. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10886
Location: italy
|
|
|
|
whatever the TS is doing
the buzzword here is PHYSICAL restore
and the manual is clear ( highlighting is mine)
| Quote: |
Cataloging Data Sets During Physical Restore Processing
If you specify CATALOG on a physical data set restore operation, DFSMSdss creates catalog entries for single-volume, non-VSAM data sets that were allocated by DFSMSdss. The cataloging is done immediately after successful allocation of a data set. Failure in cataloging does not prevent the data set from being restored. A data set that was allocated and cataloged but encountered errors during the restore operation is neither uncataloged nor scratched by DFSMSdss. You must not specify the RECATALOG keyword for physical restore.
The catalog that DFSMSdss uses to catalog a data set is determined as follows:
If the first qualifier of the data set name is an alias for a user catalog, the catalog pointed to is used for that data set.
Otherwise, the master catalog is used.
DFSMSdss does not catalog VSAM data sets during physical restore processing. If the CATALOG keyword is specified, it is ignored when processing VSAM data sets. You should use the IDCAMS DEFINE RECATALOG command to catalog VSAM data sets that were allocated by DFSMSdss (not preallocated). To recatalog and later access the VSAM data set, the volume serial numbers for the target and source volumes must match and the data set must be cataloged in the same catalog from which it was dumped. The volume serial number and the catalog name are printed in message ADR4181 during restore. |
|
|
| Back to top |
|
|
ananth86
New User
Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad
|
|
|
|
Thanks Enrico,
You are right the Physical restore didn't do any cataloging.. The sysprint from Typrun=norun was giving me a false idea (or misleading) abt the cataloging.. I was wondering why I was not seeing any messages regarding the Cataloging when the job ran with out norun.
I had to Define the cluster and Catalog the file with idcams ultimately.
Peter , there was no fooling of the messages. When I copied the sysprint I just forgot to copy the message id from the mainframe.. Thanks again for the suggestions |
|
| Back to top |
|
|
|
|
