Hope IBM DFSMS dev or Support Can Comment on this..... But yes I would be opening a PMR and Hope it might even need an APAR as well.....
On Fri, Dec 7, 2012 at 3:13 PM, Jake anderson <[email protected]>wrote: > "One possible solution would be to change the PROC by adding a step on > each side of the ADRDSSU step:The step prior would be a simple IDCAMS to > create a small dataset onthe volume. " > > Apology for not showing up the entire JCL since we are having 65 volumes > so I guess it would create a huge proc to code IDCAMS step to create on > each volume. Since everytime the failure is happening at different LABELS. > > > " It may be that previous versions of ADRDSSU would create an output file, > even if there were no datasets being backed up. If you can show that this > was the case, IBM might take an APAR to change the action back." > > I tried the same JCL under 1.12 with the same conditional step but it took > the entire dataset sitting on that volume for processing, but how do we > assume that the previous versions of ADRDSSU would create an output file so > that I can open an APAR with IBM. > > > > > On Fri, Dec 7, 2012 at 1:02 PM, Arthur T. <[email protected]> wrote: > >> On 6 Dec 2012 22:05:56 -0800, in bit.listserv.ibm-main (Message-ID:< >> CAHTvvRWwWAXF7tfZ**RhtvZ9gf54-**kxtMh60qB8JHmtBEUyXWE8g@mail.**gmail.com<cahtvvrwwwaxf7tfzrhtvz9gf54-kxtmh60qb8jhmtbeuyxw...@mail.gmail.com>>) >> [email protected] (Jake anderson) wrote: >> >> My question is going to be very general. Our shop has the policy of >>> running >>> daily back up from Mon-friday on a incremental basis(Volume Level). So we >>> have been using this Keyword at sysin control card : DATASET(INCLUDE(**) >>> BY(DSCHA,EQ,YES), which means that the backup would take place only if >>> any >>> changes have been occurred on a specific Volume. Recently in our Z/OS >>> 1.13 >>> Testing box we ended with Below error. >>> >>> ADR049E (001)-STEND(01), 2012.340 15:29:13 DFSMSDSS FUNCTION TASK >>> ABEND RECOVERY ROUTINE WAS ENTERED. SYSTEM ABEND CODE=0A13 REASON >>> CODE=0010 >>> >> <much snippage> >> >> Return Code Explanation: >>> 10 >>> A tape mark was read instead of a HDR1 label while forward spacing to >>> the desired file on an SL or AL tape. Thus, the multifile tape ends >>> before the desired file. When positioning to the end of file 1, this >>> means the vol label is followed by a tape mark. Probable user error. >>> Check the file sequence number and volume serial numbers and that the >>> job that wrote the tape wrote all the files >>> >> <much snippage> >> >> The JCL which we are using like below : >>> >>> //STEP01 EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN' >>> //SYSPRINT DD SYSOUT=* >>> //DASD1 DD UNIT=3390,VOL=SER=&VOL,DISP=**SHR >>> //TAPE1 DD UNIT=890,VOL=(,RETAIN,SER=&**TAPE),DISP=(NEW,KEEP), >>> // DSNAME=BACKUP.INC.&VOL,LABEL=(**&LBL,SL) >>> //SYSIN DD DSN=JAKE.TEST.CNTL(CARD),DISP=**SHR >>> //BACKUP PEND >>> //DASD01 EXEC BACKUP,VOL=TVX3A1,TAPE=TS1IN4,**LBL=01 >>> //DASD02 EXEC BACKUP,VOL=TVX3A2,TAPE=TS1IN4,**LBL=02 >>> //DASD03 EXEC BACKUP,VOL=MTWK05,TAPE=TS1IN4,**LBL=03 >>> >> >> I see three possibilities, one of which *might* be aparable: >> >> 1. The system is now properly checking that file one exists on a tape >> when you're specifying label=2. It seems unlikely to me that it wasn't in >> previous versions. But if this is the problem, you may be out of luck. >> >> 2. It may be that you never before had an occasion when there were no >> updated datasets on any (except maybe your last) disk. This would be >> unrelated to the upgrade, and would have been waiting to bite you. >> >> 3. It may be that previous versions of ADRDSSU would create an output >> file, even if there were no datasets being backed up. If you can show that >> this was the case, IBM might take an APAR to change the action back. >> >> >> -- >> I cannot receive mail at the address this was sent from. >> To reply directly, send to ar23hur "at" pobox "dot" com >> >> >> ------------------------------**------------------------------** >> ---------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [email protected] with the message: INFO IBM-MAIN >> > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
