Re: unexpected tape issue with RETAIN
Tony, I remember some behavior like this from the days of real tape. Was the behavior that RETAIN would rewind but not dismount the tape, even at the end of the step, and it was AVR that found the tape if an ensuing step needed it. If there was another mount request before the ensuing step went into allocation and no empty drives were available, an unallocated drive with tape on it is selected for the allocation. RETAIN does not retain the allocation, just the tape. We got around this problem by using the Mount command to keep the tape mounted between jobs and jobs steps. Ron -Original Message- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Allan Staller Sent: Sunday, May 6, 2018 12:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] unexpected tape issue with RETAIN Swaps? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: 04 May 2018 17:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: unexpected tape issue with RETAIN 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.,DISP=(NEW,KEEP,DELETE), >>> // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP), >>> // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) >>> //SYSINDD * >>> 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.,DISP=(NEW,KEEP,DELETE), >>> // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP), >>> // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) >>> //SYSINDD * >>> 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 fil
Re: unexpected tape issue with RETAIN
Swaps? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: 04 May 2018 17:47 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: unexpected tape issue with RETAIN 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.,DISP=(NEW,KEEP,DELETE), >>> // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP), >>> // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) >>> //SYSINDD * >>> 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.,DISP=(NEW,KEEP,DELETE), >>> // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP), >>> // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) >>> //SYSINDD * >>> 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 ::DISCLAIMER:: -
Re: unexpected tape issue with RETAIN
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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP), // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP), // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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
Re: unexpected tape issue with RETAIN
I usually use UNIT=AFF=SMFIN - Maybe you can try that instead. Not sure of the syntax but it always works for me. Thank You -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: Friday, May 04, 2018 2:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP), // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP), // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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 *** Disclaimer *** This communication (including all attachments) is solely for the use of the person to whom it is addressed and is a confidential AAA communication. If you are not the intended recipient, any use, distribution, printing, or copying is prohibited. If you received this email in error, please immediately delete it and notify the sender. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: unexpected tape issue with RETAIN
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.,DISP=(NEW,KEEP,DELETE), > > // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP), > > // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) > > //SYSINDD * > >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.,DISP=(NEW,KEEP,DELETE), > > // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP), > > // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) > > //SYSINDD * > >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
Re: unexpected tape issue with RETAIN
Is it possible there is some competing "service" that forces drive maintenance (head cleaning?) every xxx tape mounts? An RMM feature? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Thigpen Sent: May 4, 2018 12:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: 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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP), // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP), // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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
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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP), // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP), // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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 The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, age, disability or sex. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, age, disability or sex. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- 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
Re: unexpected tape issue with RETAIN
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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP), // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP), // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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 The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, age, disability or sex. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, age, disability or sex. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO 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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP048.BACKUP), // LABEL=(49,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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.,DISP=(NEW,KEEP,DELETE), // UNIT=3590,VOL=(,RETAIN,REF=*.STEP049.BACKUP), // LABEL=(50,SL,RETPD=),DCB=(MODEL.DSCB,BLKSIZE=0) //SYSINDD * 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
