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:[email protected]] On :>: Behalf Of Jake anderson :>: Sent: Friday, December 07, 2012 1:43 AM :>: To: [email protected] :>: 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. <[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- :>: [email protected]>>) :>: > [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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
