"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
