DB2 image copy that is no longer in SYSCOPY on zOS operating system

5 pts.
Tags:
IBM DB2
z/OS
We have a tablespace that needs to be restored from an image copy which we have the problem is the image copy is not recorded in SYSCOPY. We also tried doing a UNLOAD FROMCOPY thinking if we got the data out of the image copy we would be able to load it back into the table. That also failed with message DSNU1227I DSNUULCB - THE CONTENT OF THE IMAGE COPY DATA SET IS INCONSISTENT WIH TABLE SPACE PRODDATA.CAC2006S. The backup was of the table we are trying to recovery but the entry in the SYSCOPY was removed I beleive this happened when we dropped above tablespace during a rerun of one of our batch jobs. I am wondering if there is a way to record the image copy so DB2 will allow us to do the UNLOAD FROMCOPY or a RESTORE on the original tablespace.

Answer Wiki

Thanks. We'll let you know when a new response is added.

Use the DSN1COPY Utility to copy the data back into the original tablespace. No translation required

or

Use the DSN1COPY utility to copy the data into a new tablespace from the Image Copy. You must know the old and new DBID, PSID and OBID

The Index Rebuild utility can be used to reconstruct the indexes.

To obtain the names, DBIDs, PSIDs, ISOBIDs, and OBIDs, run the DSNTEP2 sample application on both the source and target systems.
The following SQL statements yield the above information:
Note: The example for indexes yields the above information, along with an additional column of data.
Product-sensitive Programming Interface For table spaces:

SELECT DBID, PSID FROM SYSIBM.SYSTABLESPACE
WHERE NAME=’tablespace_name’
AND DBNAME=’database_name’;

SELECT NAME, OBID FROM SYSIBM.SYSTABLES
WHERE TSNAME=’tablespace_name’
AND CREATOR=’creator_name’;

|
|
For index spaces:
SELECT DBID, ISOBID, OBID FROM SYSIBM.SYSINDEXES
WHERE NAME=’index_name’
AND CREATOR=’creator_name’;

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Kpkannan20007
    what my problem is that when i drop the tablespace,its syscopy datasets also deleted but actually dropped tablespace’s syscopy dataset should not deleted. please can you make the answer for that? if so please send to my email id/
    20 pointsBadges:
    report
  • Fisherwu
    but how to write the JCL ? Is DB2 DBA has the sample JCL?
    10 pointsBadges:
    report
  • Meandyou
    When you DROP the tablespace all info in SYSIBM.SYSCOPY for that tablespace goes away. Yes, it does. it always has. The dataset that is the Image Copy may still exist. It may be catalogued. If the Image Copy dataset still exists, you can use DSN1COPY to put the data into a newly defined table and tablespace. The new objects will have different OBIDs and so you will have to use the XLAT (translate) parms of DSN1COPY.
    //**   COPY  AN IMAGE COPY DATA SET                             *       
    //**         TO A DIFFERENT TABLESPACE THAN THE ONE IT CAME     *       
    //**         FROM.  TABLES LOOK THE SAME, BUT DB, TS, AND TBLS  *       
    //**         MUST ALL BE TRANSLATED.                                    
    //**------------------------------------------------------------*       
    //**                                                                    
    //DSN1COPY EXEC PGM=DSN1COPY,                                           
    //         PARM='CHECK,NUMPARTS(0),OBIDXLAT,FULLCOPY,RESET'             
    //**   PARM='CHECK,FULLCOPY,NUMPARTS(10),OBIDXLAT,RESET' <-- CHANGE     
    //SYSPRINT DD  SYSOUT=*                                   * O/P REPORT  
    //SYSABEND DD  SYSOUT=*                                                 
    //SYSUDUMP DD  SYSOUT=*                                                 
    //SYSUT1   DD  DSN=DB2T.IC1.DSNDB06.SYSDBASE.G0239V00,       * I/P      
    //             DISP=OLD                                                 
    //SYSUT2   DD  DSN=DB2T.DSNDBD.DSNDB04.TABAUTH.I0001.A001,   * O/P      
    //             DISP=OLD                                                 
    //SYSXLAT  DD  *                                                        
     6,4     
     9,177   
     32,267  
     20,250  
     21,255  
     25,264  
     23,253  
     26,265  
     27,266  
     24,256  
     22,251  
     33,252  
     28,254  
     18,191  
     19,193  
     17,192  
     /*      
    Now that is a *real* old sample. I have not done this in years. My recollection is that you can execute DSN1COPY without the XLAT and the utility will yell, scream and fail; but it will tell you that you need to XLAT from this number to that. Or, you can use DSN1PRNT to print parts of the Image Copy dataset to see what the OBIDs are on the tape or disk file. For this you will have to dig to find the layout of the header pages for each object. My memory just cannot locate that information right now. Some info is in the Utility Guide. Maybe in the Admin Guide. Maybe in the Diagnostic Guide? Sorry I cannot help more.
    5,220 pointsBadges:
    report
  • Meandyou
    When a tablespace is dropped, all info about that tablespace is removed from SYSIBM.SYSCOPY. Always has been. If you have the dataset that is the Image Copy from the old tablespace, you can use DSN1COPY to put the data into a new tablespace. The new tablespace and the new tables will have different OBIDs (Object Identifiers). The DSN1COPY utility will have to be told to translate (XLAT) the OBIDs on the Image Copy dataset to the OBIDs of the new objects. My recollection is that you can run DSN1COPY without specifying the XLAT inpout and the utility will tell you what the OBIDs are - something like "you are trying to load (old number) into (new number)" - and with that info you can then populate the XLAT. Here is an OLD sample of DSN1COPY.
    //**   COPY  AN IMAGE COPY DATA SET                             *       
    //**         TO A DIFFERENT TABLESPACE THAN THE ONE IT CAME     *       
    //**         FROM.  TABLES LOOK THE SAME, BUT DB, TS, AND TBLS  *       
    //**         MUST ALL BE TRANSLATED.                                    
    //**------------------------------------------------------------*       
    //**                                                                    
    //DSN1COPY EXEC PGM=DSN1COPY,                                           
    //         PARM='CHECK,NUMPARTS(0),OBIDXLAT,FULLCOPY,RESET'             
    //**   PARM='CHECK,FULLCOPY,NUMPARTS(10),OBIDXLAT,RESET' <-- CHANGE     
    //SYSPRINT DD  SYSOUT=*                                   * O/P REPORT  
    //SYSABEND DD  SYSOUT=*                                                 
    //SYSUDUMP DD  SYSOUT=*                                                 
    //SYSUT1   DD  DSN=DB2T.IC1.DSNDB06.SYSDBASE.G0239V00,       * I/P      
    //             DISP=OLD                                                 
    //SYSUT2   DD  DSN=DB2T.DSNDBD.DSNDB04.TABAUTH.I0001.A001,   * O/P      
    //             DISP=OLD                                                 
    //SYSXLAT  DD  *                                                        
    6,4    
    9,177  
    32,267 
    20,250 
    /*
    
    What happens with the SYSXLAT data is the first set of numbers ("6,4") says change the DBID from 6 to 4, the second set says change the tablespace id from 9 on the Image Copy to 177, and the rest are for the tables within the tablespace. It has been a long time since I ran anything like this. Some experimentation will be needed. Good luck.
    5,220 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following