z/OS DB2 V7.1 S813-04 abend....

Raquel Rodriguez

z/OS DB2 V7.1 S813-04 abend....
For an activity, I am performing the following three
tasks:
1. Take an imagecopy for a tablespace.
2. Copy that imagecopy dataset on to a tape.
3. Restore the imagecopy dataset back to the disk.

The first two steps are executing fine, but the third
step (Restore) is failing with S813-04.

Here are the JCLs that I am using:

Step 1: Imagecopy:

//STEP1 EXEC PGM=DSNUTILB,PARM='DB21,DBATEST'

//TS1 DD DISP=(NEW,CATLG,DELETE),

// DSN=XYA.DSNDB04.TS1.D112405.V03,

// VOL=SER=KORW92,SPACE=(TRK,(1,5),RLSE)

//SYSPRINT DD SYSOUT=*

//SYSIN DD *

COPY TABLESPACE DSNDB04.TS1

COPYDDN(TS1) SHRLEVEL REFERENCE

/*



Step 2: Dump the above imagecopy dataset to tape:

//STEPT006 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//TAPE1 DD DISP=(NEW,CATLG,DELETE),UNIT=TAPEUNT,

// RETPD=3,DSN=XYA.DSNDB04.TS1.D112405.V03.TP
//SYSIN DD *
DUMP DS(INC(XYA.DSNDB04.TS1.D112405.V03)) -
OUTDDNAME (TAPE1)
/*

After the above step, I can see the tape dataset
XYA.DSNDB04.TS1.D112405.V03.TP cataloged on tape
TP2348

Step 3: Restore the dataset back from tape to the
disk:

//STEPT006 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//TAPE1 DD DISP=(OLD,KEEP),VOL=SER=TP2348,UNIT=TAPEUNT
//DISK1 DD DISP=SHR,UNIT=3390,VOL=SER=KORW92
//SYSIN DD *
RESTORE DATASET(INCLUDE(*.*)) -
INDDNAME(TAPE1) OUTDDNAME(DISK1) REPLACE
/*

This dataset fails with S813-04 which means:

AN OPEN MACRO WAS ISSUED FOR A DATASET ON MAGNETIC
TAPE, BUT THE DATASET NAME ON THE HEADER LABEL DID NOT
MATCH THAT IN THE JFCB.
--POSSIBLE CAUSE--

WRONG DSNAME OR VOLUME SERIAL - JCL DISAGREES WITH
LABEL INCORRECT RECORD FORMAT OR BLOCKSIZE THE
REQUESTED DRIVE WAS NOT SWITCHED TO THIS MACHINE

Does anyone know what I might be doing wrong. There is
nothing wrong with the tape/tape drive Afaik.

TIA
Raquel.




__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Avram Friedman

Re: z/OS DB2 V7.1 S813-04 abend....
(in response to Raquel Rodriguez)
I assume when you say
After the above step, I can see the tape dataset
XYA.DSNDB04.TS1.D112405.V03.TP cataloged on tape
TP2348

You mean you see a message in ADRASSU sysprint that indicates the dataset has been written to tape.

The word catalog with respect to z/OS means something diffrent.

I can tell you several options for fixing your problem but I highly recommend that you attend a basic z/OS JCL class and get some z/OS based DBA education. While the solution I can provide may allow your test to work it will not provide the basic fuctionality need for DB2 backup and restore on z/OS


To get your job to work you can do one of the following

in your Step 3 restore image copy to DASD change the
//TAPE1 DD card to
"//TAPE1 DD DISP=(OLD,KEEP),VOL=SER=TP2348,UNIT=TAPEUNT,
// LABEL=(2,BLP,EXPDTE=98000)"

If your system's programing, tape management, and secqurity groups have 1/2 a brain they will of done something to prevent this from working.

a diffrent option which may or may not work depending on the level of skill of your support staff is

Review the output of STEP 2.
The first 3 output listings (depending on system options are
Job Log
JCL
Job Messages

In both the first and third data set you should beable to find the KEEP message for your Tape dataset. Theses messages will contain the actual tape dataset name. I will be something like SYSxxxx.JOBNAME.datestamp.timestamp.tiebreaker

Use the name from the listing to modify the STEP3 //TAPE1 DD card to
"//TAPE1 DD DISP=(OLD,KEEP),VOL=SER=TP2348,UNIT=TAPEUNT,
// LABEL=EXPDTE=98000,DSN=SYSxxxx.JOBNAME.datestamp.timestamp.tiebreaker


I don't want to shound too harsh here but be aware ... If you do get either of these techniques to work you will have down stream problems in DB2 ... The process you discuss is simply conceptually as well as technically wrong. I strongly advise getting some education.







Raquel Rodriguez <[login to unmask email]> wrote:
For an activity, I am performing the following three
tasks:
1. Take an imagecopy for a tablespace.
2. Copy that imagecopy dataset on to a tape.
3. Restore the imagecopy dataset back to the disk.

The first two steps are executing fine, but the third
step (Restore) is failing with S813-04.

Here are the JCLs that I am using:

Step 1: Imagecopy:

//STEP1 EXEC PGM=DSNUTILB,PARM='DB21,DBATEST'

//TS1 DD DISP=(NEW,CATLG,DELETE),

// DSN=XYA.DSNDB04.TS1.D112405.V03,

// VOL=SER=KORW92,SPACE=(TRK,(1,5),RLSE)

//SYSPRINT DD SYSOUT=*

//SYSIN DD *

COPY TABLESPACE DSNDB04.TS1

COPYDDN(TS1) SHRLEVEL REFERENCE

/*



Step 2: Dump the above imagecopy dataset to tape:

//STEPT006 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//TAPE1 DD DISP=(NEW,CATLG,DELETE),UNIT=TAPEUNT,

// RETPD=3,DSN=XYA.DSNDB04.TS1.D112405.V03.TP
//SYSIN DD *
DUMP DS(INC(XYA.DSNDB04.TS1.D112405.V03)) -
OUTDDNAME (TAPE1)
/*

After the above step, I can see the tape dataset
XYA.DSNDB04.TS1.D112405.V03.TP cataloged on tape
TP2348

Step 3: Restore the dataset back from tape to the
disk:

//STEPT006 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//TAPE1 DD DISP=(OLD,KEEP),VOL=SER=TP2348,UNIT=TAPEUNT
//DISK1 DD DISP=SHR,UNIT=3390,VOL=SER=KORW92
//SYSIN DD *
RESTORE DATASET(INCLUDE(*.*)) -
INDDNAME(TAPE1) OUTDDNAME(DISK1) REPLACE
/*

This dataset fails with S813-04 which means:

AN OPEN MACRO WAS ISSUED FOR A DATASET ON MAGNETIC
TAPE, BUT THE DATASET NAME ON THE HEADER LABEL DID NOT
MATCH THAT IN THE JFCB.
--POSSIBLE CAUSE--

WRONG DSNAME OR VOLUME SERIAL - JCL DISAGREES WITH
LABEL INCORRECT RECORD FORMAT OR BLOCKSIZE THE
REQUESTED DRIVE WAS NOT SWITCHED TO THIS MACHINE

Does anyone know what I might be doing wrong. There is
nothing wrong with the tape/tape drive Afaik.

TIA
Raquel.




__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm



Avram Friedman
(877)311-0480 Voice Mail
[login to unmask email]
Http://www.IBMsysProg.com




---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

James Campbell

Re: z/OS DB2 V7.1 S813-04 abend....
(in response to Avram Friedman)
Avram, I presume you missed the fact that step2's TAPE1 had an
explicit DSN coded. Hence in step 3, Raquel should use:
//TAPE1 DD
DSN=XYA.DSNDB04.TS1.D112405.V03.TP,DISP=OLD

Using American date format might be what everyone else does, but
using D051124 will mean that dataset names are sorted by date.

RETPD=3 is a little low. Depending on your tape mangement
product, Monday's backup will be deleted on Wednesday morning.

Personally, I'd ditch this whole imagecopy, backup method. I'd use
a GDG and backup directly to tape. Using LISTDEF and
TEMPLATE makes it real easy to back everything up in one
bundle, using GDGs means that old backups get scratched when
you have enough newer backups (with a suitable RETPD) and you
can always refer to the newest backup using DSN=template(0).

I second Avram's comment about education.

James Campbell



On 25 Nov 2005 at 14:16, Avram Friedman wrote:

>
> I assume when you say
> After the above step, I can see the tape dataset
> XYA.DSNDB04.TS1.D112405.V03.TP cataloged on tape
> TP2348
> You mean you see a message in ADRASSU sysprint that indicates the dataset has been written
> to tape.
>
> The word catalog with respect to z/OS means something diffrent.
>
> I can tell you several options for fixing your problem but I highly recommend that you attend a
> basic z/OS JCL class and get some z/OS based DBA education. While the solution I can
> provide may allow your test to work it will not provide the basic fuctionality need for DB2 backup
> and restore on z/OS
>
>
> To get your job to work you can do one of the following
>
> in your Step 3 restore image copy to DASD change the
> //TAPE1 DD card to
> "//TAPE1 DD DISP=(OLD,KEEP),VOL=SER=TP2348,UNIT=TAPEUNT,
> // LABEL=(2,BLP,EXPDTE=98000)"
>
> If your system's programing, tape management, and secqurity groups have 1/2 a brain they will
> of done something to prevent this from working.
>
> adiffrent option which may or may not work depending on the level of skill of your support staff is
>
> Review the output ofSTEP 2.
> The first 3 output listings (depending on system options are
> Job Log
> JCL
> Job Messages
>
> In both the first and third data set you should beable to find the KEEP message for your Tape
> dataset. Theses messages will contain the actual tape dataset name. I will be something like
> SYSxxxx.JOBNAME.datestamp.timestamp.tiebreaker
>
> Usethe name from the listing to modify the STEP3 //TAPE1 DD card to
> "//TAPE1 DD DISP=(OLD,KEEP),VOL=SER=TP2348,UNIT=TAPEUNT,
> // LABEL=EXPDTE=98000,DSN=SYSxxxx.JOBNAME.datestamp.timestamp.tiebreaker
>
>
> I don't want to shound too harsh here but be aware ... If you do get either of these techniques to
> work you will have down stream problems in DB2 ... The process you discuss is simply
> conceptually as well as technically wrong. I strongly advise getting some education.
>
>
>
>
>
>
> Raquel Rodriguez <[login to unmask email]> wrote:
> For an activity, I am performing the following three
> tasks:
> 1. Take an imagecopy for a tablespace.
> 2. Copy that imagecopy dataset on to a tape.
> 3. Restore the imagecopy dataset back to the disk.
>
> The first two steps are executing fine, but the third
> step (Restore) is failing with S813-04.
>
> Here are the JCLs that I am using:
>
> Step 1: Imagecopy:
>
> //STEP1 EXEC PGM=DSNUTILB,PARM='DB21,DBATEST'
>
> //TS1 DD DISP=(NEW,CATLG,DELETE),
>
> // DSN=XYA.DSNDB04.TS1.D112405.V03,
>
> // VOL=SER=KORW92,SPACE=(TRK,(1,5),RLSE)
>
> //SYSPRINT DD SYSOUT=*
>
> //SYSIN DD *
>
> COPY TABLESPACE DSNDB04.TS1
>
> COPYDDN(TS1) SHRLEVEL REFERENCE
>
> /*
>
>
>
> Step 2: Dump the above imagecopy dataset to tape:
>
> //STEPT006 EXEC PGM=ADRDSSU
> //SYSPRINT DD SYSOUT=*
> //TAPE1 DD DISP=(NEW,CATLG,DELETE),UNIT=TAPEUNT,
>
> // RETPD=3,DSN=XYA.DSNDB04.TS1.D112405.V03.TP
> //SYSIN DD *
> DUMP DS(INC(XYA.DSNDB04.TS1.D112405.V03)) -
> OUTDDNAME (TAPE1)
> /*
>
> After the above step, I can see the tape dataset
> XYA.DSNDB04.TS1.D112405.V03.TP cataloged on tape
> TP2348
>
> Step 3: Restore the dataset back from tape to the
> disk:
>
> //STEPT006 EXEC PGM=ADRDSSU
> //SYSPRINT DD SYSOUT=*
> //TAPE1 DD DISP=(OLD,KEEP),VOL=SER=TP2348,UNIT=TAPEUNT
> //DISK1 DD DISP=SHR,UNIT=3390,VOL=SER=KORW92
> //SYSIN DD *
> RESTORE DATASET(INCLUDE(*.*)) -
> INDDNAME(TAPE1) OUTDDNAME(DISK1) REPLACE
> /*
>
> This dataset fails with S813-04 which means:
>
> AN OPEN MACRO WAS ISSUED FOR A DATASET ON MAGNETIC
> TAPE, BUT THE DATASET NAME ON THE HEADER LABEL DID NOT
> MATCH THAT IN THE JFCB.
> --POSSIBLE CAUSE--
>
> WRONG DSNAME OR VOLUME SERIAL - JCL DISAGREES WITH
> LABEL INCORRECT RECORD FORMAT OR BLOCKSIZE THE
> REQUESTED DRIVE WAS NOT SWITCHED TO THIS MACHINE
>
> Does anyone know what I might be doing wrong. There is
> nothing wrong with the tape/tape drive Afaik.
>
> TIA
> Raquel.
>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Raquel Rodriguez

Re: z/OS DB2 V7.1 S813-04 abend....
(in response to James Campbell)
Thanks James, Avram.

James, when I code the following in my restore JCL (no
other changes being done):

//TAPE1 DD
DSN=XYA.DSNDB04.TS1.D112405.V03.TP,DISP=OLD

The Job finishes with RC=4 and a message: No data was
copied from the input to the output. So, basically
Restore still does not seem to work. Any ideas. I
don't see any RACF or any other error messages in the
output.

Avram, when I say "After the above step, I can see the
tape dataset
XYA.DSNDB04.TS1.D112405.V03.TP cataloged on tape
TP2348", I meant that I can see the dataset
XYA.DSNDB04.TS1.D112405.V03.TP cataloged on TP2348
through ISPF optin 3.4 (in other words, in the MVS
catalog). Guess I should have been more clear in the
mail.

TIA
Raquel.

--- James Campbell <[login to unmask email]> wrote:

> Avram, I presume you missed the fact that step2's
> TAPE1 had an
> explicit DSN coded. Hence in step 3, Raquel should
> use:
> //TAPE1 DD
> DSN=XYA.DSNDB04.TS1.D112405.V03.TP,DISP=OLD
>
> Using American date format might be what everyone
> else does, but
> using D051124 will mean that dataset names are
> sorted by date.
>
> RETPD=3 is a little low. Depending on your tape
> mangement
> product, Monday's backup will be deleted on
> Wednesday morning.
>
> Personally, I'd ditch this whole imagecopy, backup
> method. I'd use
> a GDG and backup directly to tape. Using LISTDEF
> and
> TEMPLATE makes it real easy to back everything up in
> one
> bundle, using GDGs means that old backups get
> scratched when
> you have enough newer backups (with a suitable
> RETPD) and you
> can always refer to the newest backup using
> DSN=template(0).
>
> I second Avram's comment about education.
>
> James Campbell
>
>
>
> On 25 Nov 2005 at 14:16, Avram Friedman wrote:
>
> >
> > I assume when you say
> > After the above step, I can see the tape dataset
> > XYA.DSNDB04.TS1.D112405.V03.TP cataloged on tape
> > TP2348
> > You mean you see a message in ADRASSU sysprint
> that indicates the dataset has been written
> > to tape.
> >
> > The word catalog with respect to z/OS means
> something diffrent.
> >
> > I can tell you several options for fixing your
> problem but I highly recommend that you attend a
> > basic z/OS JCL class and get some z/OS based DBA
> education. While the solution I can
> > provide may allow your test to work it will not
> provide the basic fuctionality need for DB2 backup
> > and restore on z/OS
> >
> >
> > To get your job to work you can do one of the
> following
> >
> > in your Step 3 restore image copy to DASD change
> the
> > //TAPE1 DD card to
> > "//TAPE1 DD
> DISP=(OLD,KEEP),VOL=SER=TP2348,UNIT=TAPEUNT,
> > // LABEL=(2,BLP,EXPDTE=98000)"
> >
> > If your system's programing, tape management, and
> secqurity groups have 1/2 a brain they will
> > of done something to prevent this from working.
> >
> > adiffrent option which may or may not work
> depending on the level of skill of your support
> staff is
> >
> > Review the output ofSTEP 2.
> > The first 3 output listings (depending on system
> options are
> > Job Log
> > JCL
> > Job Messages
> >
> > In both the first and third data set you should
> beable to find the KEEP message for your Tape
> > dataset. Theses messages will contain the actual
> tape dataset name. I will be something like
> > SYSxxxx.JOBNAME.datestamp.timestamp.tiebreaker
> >
> > Usethe name from the listing to modify the STEP3
> //TAPE1 DD card to
> > "//TAPE1 DD
> DISP=(OLD,KEEP),VOL=SER=TP2348,UNIT=TAPEUNT,
> > //
>
LABEL=EXPDTE=98000,DSN=SYSxxxx.JOBNAME.datestamp.timestamp.tiebreaker
> >
> >
> > I don't want to shound too harsh here but be aware
> ... If you do get either of these techniques to
> > work you will have down stream problems in DB2 ...
> The process you discuss is simply
> > conceptually as well as technically wrong. I
> strongly advise getting some education.
> >
> >
> >
> >
> >
> >
> > Raquel Rodriguez <[login to unmask email]>
> wrote:
> > For an activity, I am performing the following
> three
> > tasks:
> > 1. Take an imagecopy for a tablespace.
> > 2. Copy that imagecopy dataset on to a tape.
> > 3. Restore the imagecopy dataset back to the
> disk.
> >
> > The first two steps are executing fine, but
> the third
> > step (Restore) is failing with S813-04.
> >
> > Here are the JCLs that I am using:
> >
> > Step 1: Imagecopy:
> >
> > //STEP1 EXEC PGM=DSNUTILB,PARM='DB21,DBATEST'
> >
> > //TS1 DD DISP=(NEW,CATLG,DELETE),
> >
> > // DSN=XYA.DSNDB04.TS1.D112405.V03,
> >
> > // VOL=SER=KORW92,SPACE=(TRK,(1,5),RLSE)
> >
> > //SYSPRINT DD SYSOUT=*
> >
> > //SYSIN DD *
> >
> > COPY TABLESPACE DSNDB04.TS1
> >
> > COPYDDN(TS1) SHRLEVEL REFERENCE
> >
> > /*
> >
> >
> >
> > Step 2: Dump the above imagecopy dataset to
> tape:
> >
> > //STEPT006 EXEC PGM=ADRDSSU
> > //SYSPRINT DD SYSOUT=*
> > //TAPE1 DD
> DISP=(NEW,CATLG,DELETE),UNIT=TAPEUNT,
> >
> > // RETPD=3,DSN=XYA.DSNDB04.TS1.D112405.V03.TP
> > //SYSIN DD *
> > DUMP DS(INC(XYA.DSNDB04.TS1.D112405.V03)) -
> > OUTDDNAME (TAPE1)
> > /*
> >
> > After the above step, I can see the tape
> dataset
> > XYA.DSNDB04.TS1.D112405.V03.TP cataloged on
> tape
> > TP2348
> >
> > Step 3: Restore the dataset back from tape to
> the
> > disk:
> >
> > //STEPT006 EXEC PGM=ADRDSSU
> > //SYSPRINT DD SYSOUT=*
> > //TAPE1 DD
> DISP=(OLD,KEEP),VOL=SER=TP2348,UNIT=TAPEUNT
> > //DISK1 DD DISP=SHR,UNIT=3390,VOL=SER=KORW92
> > //SYSIN DD *
> > RESTORE DATASET(INCLUDE(*.*)) -
> > INDDNAME(TAPE1) OUTDDNAME(DISK1) REPLACE
> > /*
> >
> > This dataset fails with S813-04 which means:
> >
> > AN OPEN MACRO WAS ISSUED FOR A DATASET ON
> MAGNETIC
> > TAPE, BUT THE DATASET NAME ON THE HEADER LABEL
> DID NOT
> > MATCH THAT IN THE JFCB.
> > --POSSIBLE CAUSE--
> >
> > WRONG DSNAME OR VOLUME SERIAL - JCL DISAGREES
> WITH
> > LABEL INCORRECT RECORD FORMAT OR BLOCKSIZE THE
> > REQUESTED DRIVE WAS NOT SWITCHED TO THIS
> MACHINE
> >
> > Does anyone know what I might be doing wrong.
> There is
> > nothing wrong with the tape/tape drive Afaik.
> >
>
=== message truncated ===





__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Marcel Harleman

Re: z/OS DB2 V7.1 S813-04 abend....
(in response to James Campbell)
> (...)
>James, when I code the following in my restore JCL (no
>other changes being done):
>
>//TAPE1 DD
>DSN=XYA.DSNDB04.TS1.D112405.V03.TP,DISP=OLD
>
>The Job finishes with RC=4 and a message: No data was
>copied from the input to the output. So, basically
>Restore still does not seem to work. Any ideas.
> (...)

Raquel,

I see you mention "RESTORE DATASET(INCLUDE(*.*)) - ". I'm not 100%
sure, but it seems to me RESTORE will look for datasets with two
qualifiers in the dump and your dataset doesn't qualify then. Have you
tried "RESTORE DATASET(INCLUDE(**)) -" (so without the point between
thse asterisks)?

Cheers,

Marcel.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

James Campbell

Re: z/OS DB2 V7.1 S813-04 abend....
(in response to Raquel Rodriguez)
1) are you certain that the DUMP step dumped what you expected? What happens
if you
RESTORE DS(INC(XYA.DSNDB04.TS1.D112405.V03)) ...
2) What ADRxxxy message codes did you get (both DUMP and RESTORE).
3) Can you RESTORE with RENAME? (ie DFSMS doesn't like the REPLACE
option).

As this is becoming a DFSMS issue (rather than a DB2 one) I'd continue the
discussion with your storage people (who, I presume, use it a lot).

To follow a point that Avram raised, if your purpose in using DB2 COPY, followed by
DFSMS DUMP is to get more DB2 copies onto a tape, I suggest you consider:
- to do a recovery you need to know the DFSMS dump that contains a particular
DB2 COPY. Neither the DB2 nor zOS catalogs contain that information. You'd
need to construct your own mechanism for tracking the relationship.
- I am not certain that, with tape compression, DFSMS gets significantly more data
onto a tape than a normal dataset.
- An alternative might be to write the DB2 COPYs as GDGs to disk and then use
HSM's "HMIGRATE dsname ML2 NOWAIT" command. The datasets then exist
within the zOS catalog; HSM does its own compression thing (presumably the same
as DFSMS's); and as datasets are deleted (from the zOS catalog), HSM will (or
rather, can, if the storage admin people have set it up) manage
the tape space to prevent an entire tape being held because there is one dataset
that you want to keep.
- if you are doing this to create an offsite backup, I suggest writing directly to tape
using a dsn hlq dedicated to offsite-backups. Your
storage people should have processes in place to get those taken offsite.

James Campbell

On 28 Nov 2005 at 0:51, Raquel Rodriguez wrote:

> Thanks James, Avram.
>
> James, when I code the following in my restore JCL (no
> other changes being done):
>
> //TAPE1 DD
> DSN=XYA.DSNDB04.TS1.D112405.V03.TP,DISP=OLD
>
> The Job finishes with RC=4 and a message: No data was
> copied from the input to the output. So, basically
> Restore still does not seem to work. Any ideas. I
> don't see any RACF or any other error messages in the
> output.
>
> Avram, when I say "After the above step, I can see the
> tape dataset
> XYA.DSNDB04.TS1.D112405.V03.TP cataloged on tape
> TP2348", I meant that I can see the dataset
> XYA.DSNDB04.TS1.D112405.V03.TP cataloged on TP2348
> through ISPF optin 3.4 (in other words, in the MVS
> catalog). Guess I should have been more clear in the
> mail.
>
> TIA
> Raquel.
>
<rest snipped to fit line limit>

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Max Scarpa

Re: z/OS DB2 V7.1 S813-04 abend....
(in response to Marcel Harleman)
Raquel

to check if the dump has the dataset(s) you need you can do a RESTORE(*.**)
with the option TYPRUN=NORUN.This produce a list of datasets to be restored
without really restoring them (it's a simulation). On the other end it
could be a SMS problem so try to allocate from ISPF 3.2 a dataset with the
same name and characteristics of the dataset to be restored.

HTH

Max Scarpa

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Raquel Rodriguez

Re: z/OS DB2 V7.1 S813-04 abend....
(in response to Max Scarpa)
That IS it Marcel!! A small oversight on my part and a
lot of inconvenience.

Thanks a lot.
Raquel.

--- Marcel Harleman <[login to unmask email]> wrote:

> > (...)
> >James, when I code the following in my restore JCL
> (no
> >other changes being done):
> >
> >//TAPE1 DD
> >DSN=XYA.DSNDB04.TS1.D112405.V03.TP,DISP=OLD
> >
> >The Job finishes with RC=4 and a message: No data
> was
> >copied from the input to the output. So, basically
> >Restore still does not seem to work. Any ideas.
> > (...)
>
> Raquel,
>
> I see you mention "RESTORE DATASET(INCLUDE(*.*)) -
> ". I'm not 100%
> sure, but it seems to me RESTORE will look for
> datasets with two
> qualifiers in the dump and your dataset doesn't
> qualify then. Have you
> tried "RESTORE DATASET(INCLUDE(**)) -" (so without
> the point between
> thse asterisks)?
>
> Cheers,
>
> Marcel.
>
>
---------------------------------------------------------------------------------
> Welcome to the IDUG DB2-L list. To unsubscribe, go
> to the archives and home page at
> http://www.idugdb2-l.org/archives/db2-l.html. From
> that page select "Join or Leave the list". The IDUG
> DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG
> List Admins can be reached at
> [login to unmask email] Find out the latest
> on IDUG conferences at
> http://conferences.idug.org/index.cfm
>


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm