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
