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. > > :>: > > > :>: > > > :>: > -- > > :>: > 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 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 > > > > > > -- > Thank you and best regards, > *Billy Ashton* > > ---------------------------------------------------------------------- > 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
