Re: z/OS 1.13 ADRDSSU ECB WAIT
I'm on the coast that barracks for NSW... Go the Blues! Mwahaha. > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Shane Ginnane > Sent: Thursday, June 19, 2014 6:18 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] z/OS 1.13 ADRDSSU ECB WAIT > > On Thu, 19 Jun 2014 05:47:40 -0700, Ron Hawkins wrote: > > >Gary, > > > >I may be having a senior moment but I think I have seen this when there > are a lot of logical dumps starting that all hit the same catalog. Even your > INCLUDE(**) is going to spend a big hunk of time searching the catalogs and > volumes for datasets before it starts to dump anything. > > Last I tested this, DFDSS was appalling bad at generic includes like that. > But it > was probably around the 1.9 or 1.11 timeframe. > I went around and beat up on all the teams and made them use semi-specific > includes - like: > PROD.ABC.**, > PROD.BBC.** > ... > > Improved things out of sight. > How the hell can't utilities like these compete with the CSI (which left them > in > the dust) ?. > Same old story I suppose - East coast egg-heads not talking to West coast > egg-heads. > BTW, which coast are you on Ron . > > Shane ... > > -- > 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
Re: z/OS 1.13 ADRDSSU ECB WAIT
On Thu, 19 Jun 2014 17:12:47 -0500, Norbert Friemel wrote: >There's a patch to enable the CSI: Thanks Norbert - in a mix of systems that change of default back and forth could have made my testing real interesting. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 ADRDSSU ECB WAIT
On Thu, 19 Jun 2014 08:18:03 -0500, Shane Ginnane wrote: >Improved things out of sight. >How the hell can't utilities like these compete with the CSI (which left them >in the dust) ?. There's a patch to enable the CSI: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dgt2u2b1/1.14.40 http://www-01.ibm.com/support/docview.wss?uid=isg1II14616 http://www-01.ibm.com/support/docview.wss?uid=isg1OA25644 http://www-01.ibm.com/support/docview.wss?uid=isg1OA32120 Norbert Friemel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 ADRDSSU ECB WAIT
On Thu, 19 Jun 2014 13:26:37 +, Chase, John wrote: > Last I heard, the DFSMSdss folks were in the desert, somewhere in Arizona. LOL - now that might be considered by some an appropriate metaphor. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 ADRDSSU ECB WAIT
> -Original Message- > From: IBM Mainframe Discussion List On Behalf Of Shane Ginnane > > On Thu, 19 Jun 2014 05:47:40 -0700, Ron Hawkins wrote: > > >Gary, > > > >I may be having a senior moment but I think I have seen this when there are > >a lot of logical dumps > starting that all hit the same catalog. Even your INCLUDE(**) is going to > spend a big hunk of time > searching the catalogs and volumes for datasets before it starts to dump > anything. > > Last I tested this, DFDSS was appalling bad at generic includes like that. > But it was probably around > the 1.9 or 1.11 timeframe. > I went around and beat up on all the teams and made them use semi-specific > includes - like: > PROD.ABC.**, > PROD.BBC.** > ... > > Improved things out of sight. > How the hell can't utilities like these compete with the CSI (which left them > in the dust) ?. > Same old story I suppose - East coast egg-heads not talking to West coast > egg-heads. > BTW, which coast are you on Ron . Last I heard, the DFSMSdss folks were in the desert, somewhere in Arizona. That's closer to the US "Left Coast" -jc- ** Information contained in this e-mail message and in any attachments thereto is confidential. If you are not the intended recipient, please destroy this message, delete any copies held on your systems, notify the sender immediately, and refrain from using or disclosing all or any part of its content to any other person. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 ADRDSSU ECB WAIT
On Thu, 19 Jun 2014 05:47:40 -0700, Ron Hawkins wrote: >Gary, > >I may be having a senior moment but I think I have seen this when there are a >lot of logical dumps starting that all hit the same catalog. Even your >INCLUDE(**) is going to spend a big hunk of time searching the catalogs and >volumes for datasets before it starts to dump anything. Last I tested this, DFDSS was appalling bad at generic includes like that. But it was probably around the 1.9 or 1.11 timeframe. I went around and beat up on all the teams and made them use semi-specific includes - like: PROD.ABC.**, PROD.BBC.** ... Improved things out of sight. How the hell can't utilities like these compete with the CSI (which left them in the dust) ?. Same old story I suppose - East coast egg-heads not talking to West coast egg-heads. BTW, which coast are you on Ron . Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 ADRDSSU ECB WAIT
Gary, I may be having a senior moment but I think I have seen this when there are a lot of logical dumps starting that all hit the same catalog. Even your INCLUDE(**) is going to spend a big hunk of time searching the catalogs and volumes for datasets before it starts to dump anything. My possibly incorrect memory is that catalog calls wait on an ECB to be posted, and when the catalog is being hit by a lot of concurrent access it will single thread every time something wants exclusive. Better than a WAG, but it may be all it's worth. Start up an RMF background monitor with command SENQR at 5 second intervals to see how much contention is there. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Staller, Allan > Sent: Tuesday, June 17, 2014 8:48 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] z/OS 1.13 ADRDSSU ECB WAIT > > There is an old presentation (I forget whom to attribute to) that shows > relative response times from CPU cache to memory to device cache to > physical io in terms of seconds. > This scale ranges from a few seconds to many years on this scale. > > Your *MINIMUM* response time is to device cache for output. > > I can believe Device Wait is a larger number than Device Active. It depends. > YMMV. > > I am not sure of the ADRDSSU logic, whether the writes to the various > outdd's are in parallel or serial. > In addition to the ECB wait, this leaps out at me from the data below: > > WAITING FOR CPU 27:08 M 26.7|--> . . . . . . . .| > > I suspect that if you review the jobs over the next few days, you will see the > CPU wait vary in proportion to elapsed time, ecb wait, or both. > > My strong suspicion is that the is related to a) the amount of data to be > backed up and b) the other workloads on the system. > > HTH, > > I set PLOTMIN(0) so we can see all the wait reasons (below). Is all the ECB > WAIT time attributable to waiting on I/O to post complete? I still don't > understand why this would be such a large amount of the elapsed time. I > would think disk and tape active would be the larger part. > +-+ > | JOB = P9725451 JES NUMBER = 11741 JOB STEPS = 1 / 1 > | > | JOB CLASS = B ACCT NO = INPUT QUEUE = .51 S > | > | FROM 02:55 TO 04:36 ON 06/14/14 ELAP =1:41 H PROD > | > +-+ > |WAIT_REASON_TIME_%_|0___1___2___3___4___5_ > __6___7___8___9___0| > |USING CPU 4:18 M 4.2|-> . . . . . . . . . > .| > |ECB WAIT 39:14 M 38.6|===>. . . . . . > .| > |WAITING FOR CPU 27:08 M 26.7|--> . . . . . . . > .| > |TAPE 0800 QUE 4:09 M 4.0|-> . . . . . . . . . > .| > |TAPE CM0167 0805 QUE 3:44 M 3.6|-> . . . . . . . . . > .| > |TAPE CM0167 0805 ACT 2:40 M 2.6|-> . . . . . . . . . > .| > |TAPE 0800 ACT 2:12 M 2.1|. . . . . . . . . . > .| > |TAPE MOUNT PENDING 1:08 M 1.1|. . . . . . . . . . > .| > |WAITING FOR MVS LOCK 48.04 S.7|. . . . . . . . . . > .| > |DISK BATP01 2010 ACT 20.59 S.3|. . . . . . . . . . > .| > |DISK BATP02 2110 ACT 18.30 S.3|. . . . . . . . . . > .| > |DISK BSMP00 2208 ACT 13.72 S.2|. . . . . . . . . . > .| > |DISK BATP07 2013 ACT 11.43 S.1|. . . . . . . . . . > .| > |ECB WAIT (W/ STIMER) 11.43 S.1|. . . . . . . . . . > .| > |DISK BATP06 2112 ACT 11.43 S.1|. . . . . . . . . . > .| > |DISK BATP03 2011 ACT 11.43 S.1|. . . . . . . . . . > .| > |DISK BSMP01 2308 ACT 6.86 S.1|. . . . . . . . . . > .| > |DISK BCKP07 200D ACT 6.86 S.1|. . . . . . . . . . > .| > |DISK BATP11 2015 ACT 4.57 S.0|. . . . . . . . . . > .| > |DISK BATP09 2014 ACT 4.57 S.0|. . . . . . . . . . > .| > |DISK BATP04 2111 ACT 2.28 S.0|. . . . . . . . . . > .| > |DISK BATP10 2114 ACT 2.28 S.0|. . . . . . . . . . > .| > |DISK BCKP02 210A ACT 2.28 S.0|. . . . . . . . . . > .| > |DISK BCKP04 210B ACT 2.28 S
Re: z/OS 1.13 ADRDSSU ECB WAIT
There is an old presentation (I forget whom to attribute to) that shows relative response times from CPU cache to memory to device cache to physical io in terms of seconds. This scale ranges from a few seconds to many years on this scale. Your *MINIMUM* response time is to device cache for output. I can believe Device Wait is a larger number than Device Active. It depends. YMMV. I am not sure of the ADRDSSU logic, whether the writes to the various outdd's are in parallel or serial. In addition to the ECB wait, this leaps out at me from the data below: WAITING FOR CPU 27:08 M 26.7|--> . . . . . . . .| I suspect that if you review the jobs over the next few days, you will see the CPU wait vary in proportion to elapsed time, ecb wait, or both. My strong suspicion is that the is related to a) the amount of data to be backed up and b) the other workloads on the system. HTH, I set PLOTMIN(0) so we can see all the wait reasons (below). Is all the ECB WAIT time attributable to waiting on I/O to post complete? I still don't understand why this would be such a large amount of the elapsed time. I would think disk and tape active would be the larger part. +-+ | JOB = P9725451 JES NUMBER = 11741 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .51 S | | FROM 02:55 TO 04:36 ON 06/14/14 ELAP =1:41 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 4:18 M 4.2|-> . . . . . . . . . .| |ECB WAIT 39:14 M 38.6|===>. . . . . . .| |WAITING FOR CPU 27:08 M 26.7|--> . . . . . . . .| |TAPE 0800 QUE 4:09 M 4.0|-> . . . . . . . . . .| |TAPE CM0167 0805 QUE 3:44 M 3.6|-> . . . . . . . . . .| |TAPE CM0167 0805 ACT 2:40 M 2.6|-> . . . . . . . . . .| |TAPE 0800 ACT 2:12 M 2.1|. . . . . . . . . . .| |TAPE MOUNT PENDING 1:08 M 1.1|. . . . . . . . . . .| |WAITING FOR MVS LOCK 48.04 S.7|. . . . . . . . . . .| |DISK BATP01 2010 ACT 20.59 S.3|. . . . . . . . . . .| |DISK BATP02 2110 ACT 18.30 S.3|. . . . . . . . . . .| |DISK BSMP00 2208 ACT 13.72 S.2|. . . . . . . . . . .| |DISK BATP07 2013 ACT 11.43 S.1|. . . . . . . . . . .| |ECB WAIT (W/ STIMER) 11.43 S.1|. . . . . . . . . . .| |DISK BATP06 2112 ACT 11.43 S.1|. . . . . . . . . . .| |DISK BATP03 2011 ACT 11.43 S.1|. . . . . . . . . . .| |DISK BSMP01 2308 ACT 6.86 S.1|. . . . . . . . . . .| |DISK BCKP07 200D ACT 6.86 S.1|. . . . . . . . . . .| |DISK BATP11 2015 ACT 4.57 S.0|. . . . . . . . . . .| |DISK BATP09 2014 ACT 4.57 S.0|. . . . . . . . . . .| |DISK BATP04 2111 ACT 2.28 S.0|. . . . . . . . . . .| |DISK BATP10 2114 ACT 2.28 S.0|. . . . . . . . . . .| |DISK BCKP02 210A ACT 2.28 S.0|. . . . . . . . . . .| |DISK BCKP04 210B ACT 2.28 S.0|. . . . . . . . . . .| |DISK BCKP06 210C ACT 2.28 S.0|. . . . . . . . . . .| |DISK BATP05 2012 ACT 2.28 S.0|. . . . . . . . . . .| |DISK SQPP01 2205 ACT 2.28 S.0|. . . . . . . . . . .| |JOB ELAPSED TIME 1:41 H| +-+ !CANDLE CORP. - REPORT V420 06/17/14 9.44.02 PAGE 2 COPYRIGHT (C) 1982-2009 CANDLE CORPORATION. ALL RIGHTS RESERVED. +-+ | JOB = P9725451 JES NUMBER = 18116 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .81 S | | FROM 04:35 TO 06:03 ON 06/16/14 ELAP =1:28 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 3:00 M 3.4|-> . . . . . . . . . .| |ECB WAIT 53:09 M 60.0|> . . . .| |WAITING FOR CPU 10:42 M 12.1|> . . . . . . . . .| |TAPE 0803 QUE 4:29 M 5.0|--> . . . . . .
Re: z/OS 1.13 ADRDSSU ECB WAIT
I set PLOTMIN(0) so we can see all the wait reasons (below). Is all the ECB WAIT time attributable to waiting on I/O to post complete? I still don't understand why this would be such a large amount of the elapsed time. I would think disk and tape active would be the larger part. +-+ | JOB = P9725451 JES NUMBER = 11741 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .51 S | | FROM 02:55 TO 04:36 ON 06/14/14 ELAP =1:41 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 4:18 M 4.2|-> . . . . . . . . . .| |ECB WAIT 39:14 M 38.6|===>. . . . . . .| |WAITING FOR CPU 27:08 M 26.7|--> . . . . . . . .| |TAPE 0800 QUE 4:09 M 4.0|-> . . . . . . . . . .| |TAPE CM0167 0805 QUE 3:44 M 3.6|-> . . . . . . . . . .| |TAPE CM0167 0805 ACT 2:40 M 2.6|-> . . . . . . . . . .| |TAPE 0800 ACT 2:12 M 2.1|. . . . . . . . . . .| |TAPE MOUNT PENDING 1:08 M 1.1|. . . . . . . . . . .| |WAITING FOR MVS LOCK 48.04 S.7|. . . . . . . . . . .| |DISK BATP01 2010 ACT 20.59 S.3|. . . . . . . . . . .| |DISK BATP02 2110 ACT 18.30 S.3|. . . . . . . . . . .| |DISK BSMP00 2208 ACT 13.72 S.2|. . . . . . . . . . .| |DISK BATP07 2013 ACT 11.43 S.1|. . . . . . . . . . .| |ECB WAIT (W/ STIMER) 11.43 S.1|. . . . . . . . . . .| |DISK BATP06 2112 ACT 11.43 S.1|. . . . . . . . . . .| |DISK BATP03 2011 ACT 11.43 S.1|. . . . . . . . . . .| |DISK BSMP01 2308 ACT 6.86 S.1|. . . . . . . . . . .| |DISK BCKP07 200D ACT 6.86 S.1|. . . . . . . . . . .| |DISK BATP11 2015 ACT 4.57 S.0|. . . . . . . . . . .| |DISK BATP09 2014 ACT 4.57 S.0|. . . . . . . . . . .| |DISK BATP04 2111 ACT 2.28 S.0|. . . . . . . . . . .| |DISK BATP10 2114 ACT 2.28 S.0|. . . . . . . . . . .| |DISK BCKP02 210A ACT 2.28 S.0|. . . . . . . . . . .| |DISK BCKP04 210B ACT 2.28 S.0|. . . . . . . . . . .| |DISK BCKP06 210C ACT 2.28 S.0|. . . . . . . . . . .| |DISK BATP05 2012 ACT 2.28 S.0|. . . . . . . . . . .| |DISK SQPP01 2205 ACT 2.28 S.0|. . . . . . . . . . .| |JOB ELAPSED TIME 1:41 H| +-+ !CANDLE CORP. - REPORT V420 06/17/14 9.44.02 PAGE 2 COPYRIGHT (C) 1982-2009 CANDLE CORPORATION. ALL RIGHTS RESERVED. +-+ | JOB = P9725451 JES NUMBER = 18116 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .81 S | | FROM 04:35 TO 06:03 ON 06/16/14 ELAP =1:28 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 3:00 M 3.4|-> . . . . . . . . . .| |ECB WAIT 53:09 M 60.0|> . . . .| |WAITING FOR CPU 10:42 M 12.1|> . . . . . . . . .| |TAPE 0803 QUE 4:29 M 5.0|--> . . . . . . . . . .| |TAPE CM0425 0806 QUE 4:11 M 4.7|-> . . . . . . . . . .| |TAPE CM0425 0806 ACT 3:16 M 3.7|-> . . . . . . . . . .| |TAPE 0803 ACT 2:49 M 3.1|-> . . . . . . . . . .| |TAPE MOUNT PENDING 1:15 M 1.4|. . . . . . . . . . .| |WAITING FOR MVS LOCK 27.44 S.5|. . . . . . . . . . .| |ECB WAIT (W/ STIMER) 13.72 S.2|. . . . . . . . . . .| |DISK BSMP00 2208 ACT 13.72 S.2|. . . . . . . . . . .| |DISK BATP08 2113 ACT 11.43 S.2|. . . . . . . . . . .| |DISK BATP02 2110 ACT 11.43 S.2|. . . . . . . . . . .| |DISK BATP11 2015 ACT 9.14 S.1|. . . . . . . . . . .| |DISK BATP05 2012 ACT 9.14 S.1|. . . . . . . . . . .| |DISK BATP09 2014 ACT 6.86 S
Re: z/OS 1.13 ADRDSSU ECB WAIT
The 1st and most likely cause is varying amounts of data being dumped. The 2nd most likely cause is competition for resources. To resolve the first case, use the restore command with PARM='TYPRUN=NORUN' to determine the contents of the various tape(s). This will produce a "simulated restore". e.g. //S1 EXEC PGM=ADRDSSU,PARM='TYPRUN=NORUN ...other jcl //SYSIN DD * RESTORE DATASET(INCLUDE(**) - ...other parameters /* One additional clue I see in the provided output is varying amounts of CPU time being used. This would, IMO, indicate varying amounts of data being dumped. To resolve the 2nd case use RMF monitor III or OMEGAMON EPILOG(?) to view system activity during the time periods in question. You did not post your JCL, but it appears you are creating simultaneous disk and tape copies of the output. The ECB wait could be tape delay, input dasd delay or output dasd delay. Cache hit ratios could be "wacked out" by sequential prefetch. IOW there is no simple answer if the difference is not due to the amount of data being dumped. I am trying to determine why our data set dump job (ADRDSSU) runs longer on some days. Here is the type of dump being performed: DUMP DATASET(INCLUDE(**) - EXCLUDE( - SYS1.VVDS.** - SYS1.VTOCIX.** ) - BY((DSCHA,EQ,YES))) - STORGRP(PRDBAT) - OUTDD(OUT01D,OUT01T) - ADMIN OPTIMIZE(4) SPHERE TOL(ENQF) WAIT(0,0) Using Omegamon, I have produced the following report. Which indicates that ECB WAIT is the primary wait reason. I understand this is likely a voluntary wait by the program. Is there a way to determine why these waits would be issued and why they are such a large part of the elapsed time? Waiting on I/O to post? Shouldn't I also see time listed for DISK . ACTIVE? Any input appreciated. +-+ | JOB = P9725451 JES NUMBER = 11741 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .51 S | | FROM 02:55 TO 04:36 ON 06/14/14 ELAP =1:41 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 4:18 M 4.2|-> . . . . . . . . . .| |ECB WAIT 39:14 M 38.6|===>. . . . . . .| |WAITING FOR CPU 27:08 M 26.7|--> . . . . . . . .| |JOB ELAPSED TIME 1:41 H| +-+ +-+ | JOB = P9725451 JES NUMBER = 18116 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .81 S | | FROM 04:35 TO 06:03 ON 06/16/14 ELAP =1:28 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 3:00 M 3.4|-> . . . . . . . . . .| |ECB WAIT 53:09 M 60.0|> . . . .| |WAITING FOR CPU 10:42 M 12.1|> . . . . . . . . .| |TAPE 0803 QUE 4:29 M 5.0|--> . . . . . . . . . .| |JOB ELAPSED TIME 1:28 H| +-+ +-+ | JOB = P9725451 JES NUMBER = 04485 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = 1.45 S | | FROM 04:55 TO 07:11 ON 06/17/14 ELAP =2:16 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 3:34 M 2.6|-> . . . . . . . . . .| |ECB WAIT 1:27 H 64.1|>> . . . .| |WAITING FOR CPU 13:29 M 9.9|--->. . . . . . . . . .| |TAPE 0801 QUE 8:55 M 6.5|--> . . . . . . . . . .| |TAPE 0802 QUE 8:43 M 6.4|--> . . . . . . . . . .| |JOB ELAPSED TIME 2:16 H| +-+ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS 1.13 ADRDSSU ECB WAIT
Hi, I am trying to determine why our data set dump job (ADRDSSU) runs longer on some days. Here is the type of dump being performed: DUMP DATASET(INCLUDE(**) - EXCLUDE( - SYS1.VVDS.** - SYS1.VTOCIX.** ) - BY((DSCHA,EQ,YES))) - STORGRP(PRDBAT) - OUTDD(OUT01D,OUT01T) - ADMIN OPTIMIZE(4) SPHERE TOL(ENQF) WAIT(0,0) Using Omegamon, I have produced the following report. Which indicates that ECB WAIT is the primary wait reason. I understand this is likely a voluntary wait by the program. Is there a way to determine why these waits would be issued and why they are such a large part of the elapsed time? Waiting on I/O to post? Shouldn't I also see time listed for DISK . ACTIVE? Any input appreciated. +-+ | JOB = P9725451 JES NUMBER = 11741 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .51 S | | FROM 02:55 TO 04:36 ON 06/14/14 ELAP =1:41 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 4:18 M 4.2|-> . . . . . . . . . .| |ECB WAIT 39:14 M 38.6|===>. . . . . . .| |WAITING FOR CPU 27:08 M 26.7|--> . . . . . . . .| |JOB ELAPSED TIME 1:41 H| +-+ +-+ | JOB = P9725451 JES NUMBER = 18116 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = .81 S | | FROM 04:35 TO 06:03 ON 06/16/14 ELAP =1:28 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 3:00 M 3.4|-> . . . . . . . . . .| |ECB WAIT 53:09 M 60.0|> . . . .| |WAITING FOR CPU 10:42 M 12.1|> . . . . . . . . .| |TAPE 0803 QUE 4:29 M 5.0|--> . . . . . . . . . .| |JOB ELAPSED TIME 1:28 H| +-+ +-+ | JOB = P9725451 JES NUMBER = 04485 JOB STEPS = 1 / 1 | | JOB CLASS = B ACCT NO = INPUT QUEUE = 1.45 S | | FROM 04:55 TO 07:11 ON 06/17/14 ELAP =2:16 H PROD | +-+ |WAIT_REASON_TIME_%_|0___1___2___3___4___5___6___7___8___9___0| |USING CPU 3:34 M 2.6|-> . . . . . . . . . .| |ECB WAIT 1:27 H 64.1|>> . . . .| |WAITING FOR CPU 13:29 M 9.9|--->. . . . . . . . . .| |TAPE 0801 QUE 8:55 M 6.5|--> . . . . . . . . . .| |TAPE 0802 QUE 8:43 M 6.4|--> . . . . . . . . . .| |JOB ELAPSED TIME 2:16 H| +-+ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
