Re: unexpected tape issue with RETAIN

[Tony Thigpen]

I currently think it has to do with a combination of a faulty tape and a 
mis-configuration in the IODEF, and a testing environment.

Normally, this CPU has no powered-up real tape drives, just a VTL. For 
some testing of new back-up procedures, they wanted me to use a real 
3590 so as to not add a bunch of data to the VTL that would then have to 
be replicated.

So, I powered-up and varied on some tape drives. The IODEF thinks they 
have auto-loaders, but they do not. So, I have get a configuration error 
when I run the job on just the first file.

And, since we don't have a lot of spare real 3590 tapes, I have been 
using the same two tapes repeatedly.

I have noticed that the errors only occur on one of the tapes. I think 
the recovery process wants to re-index the tape position but without the 
autoloader, it is failing then the operating system is switching to a 
new drive.

Tony Thigpen

Lizette Koehler wrote on 05/04/2018 06:12 PM:
I am not sure if this was covered,

But would the combination of

VOL=REF=*....  and DISP=(,PASS) not work at keeping the tape up?

Lizette


-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Tony Thigpen
Sent: Friday, May 04, 2018 1:32 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: unexpected tape issue with RETAIN

No go. Unit=Aff is only applicable within the same job step.

Tony Thigpen

Chris Hoelscher wrote on 05/04/2018 04:05 PM:
Unit=aff=step.ddname  ???

Chris Hoelscher
Technology Architect, Database Infrastructure Services Technology
Solution Services Humana Inc.
123 East Main Street
Louisville, KY 40202
Humana.com
(502) 476-2538 or 407-7266


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU]
On Behalf Of Tony Thigpen
Sent: Friday, May 4, 2018 3:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [IBM-MAIN] unexpected tape issue with RETAIN

I have a 50+ step backup job (using real 3590s) that has steps like:

//STEP049 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD     DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD4
//BACKUP   DD  DSN=DR.T.DSS.HKYTD4.&SUF,DISP=(NEW,KEEP,DELETE),
//             UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP),
//             LABEL=(49,SL,RETPD=&DAYS),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSIN    DD  *
    DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*
//*
//STEP050 EXEC PGM=ADRDSSU
//SYSPRINT DD  SYSOUT=*
//DASD     DD  DISP=SHR,UNIT=3390,VOL=SER=HKYTD5
//BACKUP   DD  DSN=DR.T.DSS.HKYTD5.&SUF,DISP=(NEW,KEEP,DELETE),
//             UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP),
//             LABEL=(50,SL,RETPD=&DAYS),DCB=(MODEL.DSCB,BLKSIZE=0)
//SYSIN    DD  *
    DUMP FULL INDD(DASD) OUTDD(BACKUP) ALLD(*) ADMIN TOL(IOER) ALLE
/*

This job always worked on OS/390 2.10, but under z/OS 1.13, randomly, when
going to a new step, it wants the current tape mounted on a different 3590.
Additionally, it does not unload the tape from the first drive.

Also: If I have only one drive online, it runs to completion. If I have two
drives, but the other one is busy, it runs to completion.

Info: This system is using RMM as a tape manager, but the files being
created on the tape are not defined in any storage group or RMM.

It is driving me batty. I have to be 'not seeing' something.


--
Tony Thigpen


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN