Anonym.
Liebe Gemeinde,
ich möchte einen Tablespace mit DSN1COPY auf einen anderen TS kopieren. Tabellenstruktur und Tablespaces sind natürlich gleich, sollte also mit OBIDXLAT möglich sein.
Allerdings ist der Ausgangs-TS > 2 GB und damit schon im 2. Dataset.
Habe es wie folgt versucht:
SYSUT1 – Source-TS 1. Dataset
SYSUT2 – Target-TS Dataset
Paramter – PAGESIZE(4K),SEGMENT,OBIDXLAT,RESET
Dabei wurden nur die Pages des ersten Datasets kopiert.
Kann/muss man den 2. Dataset allokieren oder macht DSN1COPY das selbst? Oder muss man für den 2. Dataset mit einem eigenen DSN1COPY kopieren?
Gibt es einen Parameter der mir noch fehlt (TS ist nicht Large, auch nicht mit DSSIZE angelegt).
Mit sportlichem Gruss
Rolf
Also diesen Fall hatte ich noch nicht ( obwohl ich viel mit DSN1COPY experimentiert habe ).
Ich gehe mal davon aus, dass DSN1COPY in diesem Fall nicht erkennen kann, dass der Tablespace in Wirklichkeit aus mehreren VSAM-Clustern besteht und demnach nicht automatisch die *.A002 – Bestände nachallokiert. Ich würde erstmal versuchen, einen zweiten DSN1COPY-Job aufzubauen und die A002-Bestände separat kopieren.
Einen speziellen Parameter dafür kenne ich nicht.
Hallo,
sollte eigentlich auch mit einem UNLOAD aus einer
Image-Copy funktionieren.
Bei mir ging dies jedenfalls. Der Tablespace war aber kleiner.
Mit den Loadstatements die erzeugt werden, kann anschl. der Datenbestand (Tabellen-Namen aber aendern), in eine Tabelle mit gleicher Structur geladen werden, ohne OBIDXLAT
Servus
Karl
Hallo,
habe gerade letzte Woche das gleiche Problem mit einem NON-Partitioned TS (11DS a´4GB) gehabt.
Die zusätzlichen DS müssen mit Define-Cluster explizit angelegt werden. Der DSN1COPY hat daraufhin funktioniert. Nur konnte ich mit dem, auf diese Art aufgebauten TS im DB2 nichts anfangen (Reason 00C90101). Also den TS gesichert und auf diese Sicherung eine Recovery gemacht. Danach lies sich der TS im DB2 verwenden.
Gruß
rollo
hallo,
wir haben einen 3GB großen tablespace von einer
full image copy mit PARM=’RESET,OBIDXLAT,PAGESIZE(4K),DSSIZE(4G),FULLCOPY‘ und folgenden dd-statements
erfolgreich zurückgeladen:
//SYSUT1 DD DISP=OLD,DSN=FICP10A.A130XCDK.JEST.IC001894
//SYSUT2 DD DISP=OLD,DSN=SAPP10A.DSNDBC.A130XCRM.ZKXXJES.I0001.A001
es wurde also nur der 1. 2gb dataset in der jcl spezifiziert. beide vsam-cluster wurden vorher mit
idcams "define cluster" leer angelegt. output:
DSN1998I INPUT DSNAME = FICP10A.A130XCDK.JEST.IC001894 , SEQ
DSN1997I OUTPUT DSNAME = SAPP10A.DSNDBC.A130XCRM.ZKXXJES.I0001.A001 , VSAM
DSN1997I OUTPUT DSNAME = SAPP10A.DSNDBC.A130XCRM.ZKXXJES.I0001.A002 , VSAM
DSN1994I DSN1COPY COMPLETED SUCCESSFULLY, 00570521 PAGES PROCESSED
mfg werner mueller email: [email]ed.na1695675729m.orm1695675729@rell1695675729eum_r1695675729enrew1695675729[/email] 🙂
hallo werner,
das hört sich ja gut an! Wie ist der zweite DS (also der A002) entstanden? Hast du ihn selbst per IDCAMS angelegt, ist er erst durch den DSN1COPY-Job entstanden oder existierte der A002 bereits vorher?
MfG Rolf
hallo rolf,
beide output-dateien wurden durch idcams "define cluster …." manuell leer erzeugt. hintergrund: das sind db2 tablespaces in einem sap-r3-system. ein
anwender will sich die table JEST (im ts JEST) zum stichtag 05.11.2005 anschauen. im sap-system wurde also eine kopie des ts names ZZJESTX angelegt und die daten von der original-full-image-
copy per DSN1COPY mit OBIDXLAT dort hinein-kopiert.
mfg werner mueller. 😉
You must be logged in to reply to this topic.
