 




<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: DB2 image copy that is no longer in SYSCOPY on zOS operating system</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/db2-image-copy-that-is-no-longer-in-syscopy-on-zos-operating-system/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/db2-image-copy-that-is-no-longer-in-syscopy-on-zos-operating-system/</link>
	<description></description>
	<lastBuildDate>Sat, 18 May 2013 17:13:23 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: meandyou</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/db2-image-copy-that-is-no-longer-in-syscopy-on-zos-operating-system/#comment-76767</link>
		<dc:creator>meandyou</dc:creator>
		<pubDate>Mon, 03 May 2010 19:29:23 +0000</pubDate>
		<guid isPermaLink="false">#comment-76767</guid>
		<description><![CDATA[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 &quot;you are trying to load (old number) into (new number)&quot; - and with that info you can then populate the XLAT.  
  
Here is an OLD sample of DSN1COPY. 
 
&lt;pre&gt;
//**   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=&#039;CHECK,NUMPARTS(0),OBIDXLAT,FULLCOPY,RESET&#039;             
//**   PARM=&#039;CHECK,FULLCOPY,NUMPARTS(10),OBIDXLAT,RESET&#039; &lt;-- 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 
/*
&lt;/pre&gt;

What happens with the SYSXLAT data is the first set of numbers (&quot;6,4&quot;) 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.]]></description>
		<content:encoded><![CDATA[<p>When a tablespace is dropped, all info about that tablespace is removed from SYSIBM.SYSCOPY.  Always has been.  </p>
<p>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.  </p>
<p>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.</p>
<p>My recollection is that you can run DSN1COPY without specifying the XLAT inpout and the utility will tell you what the OBIDs are &#8211; something like &#8220;you are trying to load (old number) into (new number)&#8221; &#8211; and with that info you can then populate the XLAT.  </p>
<p>Here is an OLD sample of DSN1COPY. </p>
<pre>
//**   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' &lt;-- 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 
/*
</pre>
<p>What happens with the SYSXLAT data is the first set of numbers (&#8220;6,4&#8243;) 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. </p>
<p>It has been a long time since I ran anything like this.   Some experimentation will be needed.  </p>
<p>Good luck.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: meandyou</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/db2-image-copy-that-is-no-longer-in-syscopy-on-zos-operating-system/#comment-76765</link>
		<dc:creator>meandyou</dc:creator>
		<pubDate>Mon, 03 May 2010 19:18:47 +0000</pubDate>
		<guid isPermaLink="false">#comment-76765</guid>
		<description><![CDATA[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.
  
&lt;pre&gt;
//**   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=&#039;CHECK,NUMPARTS(0),OBIDXLAT,FULLCOPY,RESET&#039;             
//**   PARM=&#039;CHECK,FULLCOPY,NUMPARTS(10),OBIDXLAT,RESET&#039; &lt;-- 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  
 /*      &lt;/pre&gt;

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.]]></description>
		<content:encoded><![CDATA[<p>When you DROP the tablespace all info in SYSIBM.SYSCOPY for that tablespace goes away.  Yes, it does.  it always has.  </p>
<p>The dataset that is the Image Copy may still exist.  It may be catalogued.  </p>
<p>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.</p>
<pre>
//**   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' &lt;-- 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  
 /*      </pre>
<p>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. </p>
<p>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. </p>
<p>Some info is in the Utility Guide.   Maybe in the Admin Guide.  Maybe in the Diagnostic Guide?  </p>
<p>Sorry I cannot help more.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: fisherwu</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/db2-image-copy-that-is-no-longer-in-syscopy-on-zos-operating-system/#comment-76735</link>
		<dc:creator>fisherwu</dc:creator>
		<pubDate>Mon, 03 May 2010 07:59:06 +0000</pubDate>
		<guid isPermaLink="false">#comment-76735</guid>
		<description><![CDATA[but how to write the JCL ?
Is DB2 DBA has the sample JCL?]]></description>
		<content:encoded><![CDATA[<p>but how to write the JCL ?<br />
Is DB2 DBA has the sample JCL?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kpkannan20007</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/db2-image-copy-that-is-no-longer-in-syscopy-on-zos-operating-system/#comment-71167</link>
		<dc:creator>kpkannan20007</dc:creator>
		<pubDate>Thu, 03 Dec 2009 06:19:02 +0000</pubDate>
		<guid isPermaLink="false">#comment-71167</guid>
		<description><![CDATA[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/]]></description>
		<content:encoded><![CDATA[<p>what my problem is that when i drop the tablespace,its syscopy datasets also deleted<br />
but actually dropped tablespace’s syscopy dataset should not deleted. please<br />
can you make the answer for that? if so please send to my email id/</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 6/9 queries in 0.014 seconds using memcached
Object Caching 310/313 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-05-18 18:51:01 -->