Jake, The ENTIRE job stream not just some of the messages. The JOBLOG, the expanded JCL, the JES Messages, and so forth.. Without a complete picture I do not think this list can be that helpful.
A partial picture will give you a partial answer. Lizette > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf > Of Jake anderson > Sent: Monday, December 10, 2012 8:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Conditional Statement during Backup - Clarification > > Hi lizette, > > Please find the error log message. The below error message was taken from one of a > job which ended with error. > > > > 1PAGE 0001 5695-DF175 DFSMSDSS V1R13.0 DATA SET SERVICES > > - DUMP LIDD(DASD1) OUTDD(TAPE1) DATASET(INCLUDE(**) BY(DSCHA,EQ,YES)) - > 0001000 > > TOL(ENQF) > 0002000 > > ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'DUMP ' > > ADR109I (R/I)-RI01 (01), 2012.335 11:08:20 INITIAL SCAN OF USER CONTROL > STATEMENTS COMPLETED > > ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK > > 0ADR006I (001)-STEND(01), 2012.335 11:08:20 EXECUTION BEGINS > > 0ADR049E (001)-STEND(01), 2012.335 11:11:58 DFSMSDSS FUNCTION TASK ABEND > RECOVERY ROUTINE WAS ENTERED. SYSTEM ABEND CODE=0A13 REASON > CODE=0010 > > 0ADR415W (001)-DTDSC(04), NO DATA SETS WERE COPIED, DUMPED, OR RESTORED > FROM ANY VOLUME > > 0ADR006I (001)-STEND(02), 2012.335 11:11:58 EXECUTION ENDS > > 0ADR013I (001)-CLTSK(01), 2012.335 11:11:58 TASK COMPLETED WITH RETURN CODE > 0016 > > 0ADR012I (SCH)-DSSU (01), 2012.335 11:11:58 DFSMSDSS PROCESSING COMPLETE. > HIGHEST RETURN CODE IS 0016 FROM: > > TASK > 001 > > > On Mon, Dec 10, 2012 at 7:23 PM, Lizette Koehler <stars...@mindspring.com>wrote: > > > Jake > > > > Not seeing the complete output of the job (joblog, steps, messages, > > etc.) does make it more difficult for us to provide help. We cannot > > see if the volumes were actually dumped by DFDSS. So clearly you > > either need to post complete details or let us know what IBM says > > > > Lizette > > > > > > > -----Original Message----- > > > From: IBM Mainframe Discussion List > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf > > > Of Jake anderson > > > Sent: Monday, December 10, 2012 5:56 AM > > > To: IBM-MAIN@LISTSERV.UA.EDU > > > Subject: Re: Conditional Statement during Backup - Clarification > > > > > > I agree.... but most the labels which failed for us were the tso > > > work > > volumes which > > > gets referred on everyday basis and it abends saying it was not > > referred... Strange.... > > > > > > On Mon, Dec 10, 2012 at 6:16 PM, Bill Ashton > > > <bill00ash...@gmail.com> > > wrote: > > > > > > > Although adding two steps to a one-step proc means you could hit > > > > the > > > > 255 jobstep limit quicker, if that limit is still around. I > > > > haven't written jobs that big in a long time... > > > > > > > > Billy > > > > > > > > On Fri, Dec 7, 2012 at 7:23 PM, retired mainframer < > > > > retired-mainfra...@q.com > > > > > wrote: > > > > > > > > > You showed a one step proc that is invoked once for each DASD volume. > > > > The > > > > > number of volumes is a non-issue. Adding two additional > > > > > miniscule steps for each volume should not make that much of a difference. > > > > > > > > > > :>: -----Original Message----- > > > > > :>: From: IBM Mainframe Discussion List > > > > > [mailto:IBM-MAIN@LISTSERV.UA.EDU > > > > ] > > > > > On > > > > > :>: Behalf Of Jake anderson > > > > > :>: Sent: Friday, December 07, 2012 1:43 AM > > > > > :>: To: IBM-MAIN@LISTSERV.UA.EDU > > > > > :>: Subject: Re: Conditional Statement during Backup - > > > > > Clarification > > > > > :>: > > > > > :>: "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. > > > > > <ibmm...@intergate.com> > > > > > 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>>) > > > > > :>: > justmainfra...@gmail.com (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. > > > > > :>: > > > > > > :>: > > > > > ---------------------------------------------------------------------- > > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
