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 <[email protected]>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:[email protected]] On
> Behalf
> > Of Jake anderson
> > Sent: Monday, December 10, 2012 5:56 AM
> > To: [email protected]
> > 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 <[email protected]>
> 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 <
> > > [email protected]
> > > > 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:[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.
> > > > :>: >
> > > > :>: >
>
> ----------------------------------------------------------------------
> 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
