IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Restoring Vsam file across system


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
ananth86

New User


Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad

PostPosted: Tue Apr 16, 2013 9:03 am
Reply with quote

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
View user's profile Send private message
Anuj Dhawan

Superior Member


Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India

PostPosted: Tue Apr 16, 2013 9:52 am
Reply with 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'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
View user's profile Send private message
ananth86

New User


Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad

PostPosted: Tue Apr 16, 2013 10:37 am
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Apr 16, 2013 10:44 am
Reply with quote

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
View user's profile Send private message
ananth86

New User


Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad

PostPosted: Tue Apr 16, 2013 11:18 am
Reply with quote

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
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen

PostPosted: Tue Apr 16, 2013 11:44 am
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Apr 16, 2013 2:03 pm
Reply with quote

Quote:
or missing something .


Code:
THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL VOLUME FORMAT
Back to top
View user's profile Send private message
ananth86

New User


Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad

PostPosted: Tue Apr 16, 2013 2:34 pm
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Apr 16, 2013 2:56 pm
Reply with quote

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
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen

PostPosted: Tue Apr 16, 2013 5:31 pm
Reply with quote

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
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales

PostPosted: Tue Apr 16, 2013 5:47 pm
Reply with quote

Perhaps the OP is running the restore on the same LPAR as the dump was taken from.
Back to top
View user's profile Send private message
PeterHolland

Global Moderator


Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen

PostPosted: Tue Apr 16, 2013 5:49 pm
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Apr 16, 2013 5:59 pm
Reply with quote

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


icon_cool.gif
Back to top
View user's profile Send private message
Robert Sample

Global Moderator


Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA

PostPosted: Tue Apr 16, 2013 6:15 pm
Reply with quote

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
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue Apr 16, 2013 6:37 pm
Reply with quote

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
View user's profile Send private message
ananth86

New User


Joined: 10 Jun 2009
Posts: 59
Location: Hyderabad

PostPosted: Fri Apr 19, 2013 12:22 pm
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts How to split large record length file... DFSORT/ICETOOL 10
No new posts Sysplex System won't IPL at DR site I... All Other Mainframe Topics 2
No new posts Extracting Variable decimal numbers f... DFSORT/ICETOOL 17
No new posts SFTP Issue - destination file record ... All Other Mainframe Topics 2
No new posts Access to non cataloged VSAM file JCL & VSAM 18
Search our Forums:

Back to Top