Why so much Service Task Wait time? - DB2 V7.2 for z/OS

Jay Reavill

Why so much Service Task Wait time? - DB2 V7.2 for z/OS
Hello All,

I'm a bit perplexed as to why we are seeing Omegamon reporting that a
read-only program is consistently spending the majority of it's time in DB2
Service Task Wait time? There are no commits and only one read-only cursor
issued by this program. No datasets are being opened/closed/recalled.
There are other programs involved in this thread, but this is the only one
with a large Service Task Wait time. Any insight would be greatly
appreciated.

Here's the Omegamon info...

+ SQL Request Count = 99292
+
+ In-DB2 Times Total
+ ------------------------------ ------------
+ Elapsed Time 00:12:10.704
+ CPU Time 00:01:08.769
+
+ Waits Count Total
+ ------------------------------ ---------- ------------
+ Synchronous I/O Wait 6970 00:00:27.974
+ Asynchronous Read I/O Wait 330 00:00:06.217
+ Asynchronous Write I/O Wait 0 00:00:00.000
+ Local Lock/Latch Wait 534 00:00:00.170
+ Page Latch Wait 0 00:00:00.000
+ Drain Lock Wait 0 00:00:00.000
+ Drain of Claims Wait 0 00:00:00.000
+ DB2 Service Task Wait 96875 00:09:06.678
+ Archive Log Mode(Quiesce) Wait 0 00:00:00.000
+ Archive Read from Tape Wait 0 00:00:00.000
+ Stored Procedure Schedule Wait 0 00:00:00.000
+ ------------------------------ ---------- ------------
+ 104709 00:09:41.039

> DB2 Service Task Wait
> Waits for DB2 services. Types of DB2 services include
> open/close of dataset, DFHSM recall of a dataset, SYSLGRNG
> update, define/extend/delete of a dataset, and commit phase 2
> for read only threads.

+ Maximum Number of Open Datasets (DSMAX) = 5000
+ Checkpoints to Pseudo-Close (PCLOSEN) = 5
+ Elapsed Time to Pseudo-Close (PCLOSET) = 10
+ Current Number Open Datasets = 1380
+ High Water Mark Open Datasets = 1399
+ High Water Mark Not-in-use Datasets = 1369
+ Current Number Not-in-use Datasets = 1304

Here's the explain info...

+---------+---------+---------+---------+---------+---------+---------+--------
JTYP METHOD CREATOR TBNAME CARD AXS MCOL
AXSNAME
+---------+---------+---------+---------+---------+---------+---------+--------
0 PPMPRD CZ_UNCOMPL_PROCS 1372904 I 2
CZI0091C
1 PPMPRD CZ_UNPRCD_TXN 301359 I 3
CZI0089A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A

Thanks,
Jay


----------------------------------------
Jay Reavill DBA
Certegy Card Services
11601 Roosevelt Blvd.
St. Petersburg, FL. 33716
Office (727) 227-2144
----------------------------------------








------------------------------------------------------------------------------
This message contains information from Certegy, Inc which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e:mail [login to unmask email]
=====

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Ray Williams

Re: Why so much Service Task Wait time? - DB2 V7.2 for z/OS
(in response to Jay Reavill)
Does Omegamon include Other Service Wait time in Service Task Wait Time?
If so you might be CPU constrained. . . . You may be waiting on CPU.
I'm guessing because of your CPU to Elapsed ratio.

Ray Williams - WHQKO
United Airlines
Database Administration
(847) 700-4359

-----Original Message-----
From: [login to unmask email] [SMTP:[login to unmask email]
Sent: Wednesday, June 29, 2005 9:46 AM
To: [login to unmask email]
Cc: [login to unmask email]
Subject: [DB2-L] Why so much Service Task Wait time? - DB2 V7.2
for z/OS

Hello All,

I'm a bit perplexed as to why we are seeing Omegamon reporting that a
read-only program is consistently spending the majority of it's time
in DB2
Service Task Wait time? There are no commits and only one read-only
cursor
issued by this program. No datasets are being
opened/closed/recalled.
There are other programs involved in this thread, but this is the
only one
with a large Service Task Wait time. Any insight would be greatly
appreciated.

Here's the Omegamon info...

+ SQL Request Count = 99292
+
+ In-DB2 Times Total
+ ------------------------------ ------------
+ Elapsed Time 00:12:10.704
+ CPU Time 00:01:08.769
+
+ Waits Count Total
+ ------------------------------ ---------- ------------
+ Synchronous I/O Wait 6970 00:00:27.974
+ Asynchronous Read I/O Wait 330 00:00:06.217
+ Asynchronous Write I/O Wait 0 00:00:00.000
+ Local Lock/Latch Wait 534 00:00:00.170
+ Page Latch Wait 0 00:00:00.000
+ Drain Lock Wait 0 00:00:00.000
+ Drain of Claims Wait 0 00:00:00.000
+ DB2 Service Task Wait 96875 00:09:06.678
+ Archive Log Mode(Quiesce) Wait 0 00:00:00.000
+ Archive Read from Tape Wait 0 00:00:00.000
+ Stored Procedure Schedule Wait 0 00:00:00.000
+ ------------------------------ ---------- ------------
+ 104709 00:09:41.039

> DB2 Service Task Wait
> Waits for DB2 services. Types of DB2 services include
> open/close of dataset, DFHSM recall of a dataset, SYSLGRNG
> update, define/extend/delete of a dataset, and commit phase 2
> for read only threads.

+ Maximum Number of Open Datasets (DSMAX) = 5000
+ Checkpoints to Pseudo-Close (PCLOSEN) = 5
+ Elapsed Time to Pseudo-Close (PCLOSET) = 10
+ Current Number Open Datasets = 1380
+ High Water Mark Open Datasets = 1399
+ High Water Mark Not-in-use Datasets = 1369
+ Current Number Not-in-use Datasets = 1304

Here's the explain info...

+---------+---------+---------+---------+---------+---------+--------
-+--------
JTYP METHOD CREATOR TBNAME CARD AXS MCOL
AXSNAME
+---------+---------+---------+---------+---------+---------+--------
-+--------
0 PPMPRD CZ_UNCOMPL_PROCS 1372904 I 2
CZI0091C
1 PPMPRD CZ_UNPRCD_TXN 301359 I 3
CZI0089A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A

Thanks,
Jay


----------------------------------------
Jay Reavill DBA
Certegy Card Services
11601 Roosevelt Blvd.
St. Petersburg, FL. 33716
Office (727) 227-2144
----------------------------------------








---------------------------------------------------------------------
---------
This message contains information from Certegy, Inc which may be
confidential and privileged. If you are not an intended recipient,
please refrain from any disclosure, copying, distribution or use of
this information and note that such actions are prohibited. If you
have received this transmission in error, please notify by e:mail
[login to unmask email]
=====================
=========

---------------------------------------------------------------------
------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives
and home page at http://www.idugdb2-l.org/archives/db2-l.html. From
that page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG
conferences at http://conferences.idug.org/index.cfm





---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Richard Fazio

Re: Why so much Service Task Wait time? - DB2 V7.2 for z/OS
(in response to Ray Williams)
Are you sure DB2 knows the cursor is "read only". If ambiguous, a "FOR
FETCH ONLY" may help with lock avoidance.
I'm assuming this is a batch process (if CICS, this could easily be
attributed to delays in a task switch).

Also, is this read only job the first process run after a major delete.
If so, you may be going through
the "garbage collection" process to clean up pseudo deletes.

Try using your monitor to set up a few application traces. Accounting
Class 3 trace should give you
the breakdown.

Good luck,
faz

Rich Fazio
DB2 OS390 DBA

TransUnion, LLC
SSG/Data Services Team, 5th Floor
555 West Adams St. Chicago, IL 60661
Phone (312) 985-3270 Fax (312) 466-8398

Talk to teach - Listen to learn


>>> [login to unmask email] 2005-06-29 9:45:46 AM >>>
Hello All,

I'm a bit perplexed as to why we are seeing Omegamon reporting that a
read-only program is consistently spending the majority of it's time in
DB2
Service Task Wait time? There are no commits and only one read-only
cursor
issued by this program. No datasets are being opened/closed/recalled.
There are other programs involved in this thread, but this is the only
one
with a large Service Task Wait time. Any insight would be greatly
appreciated.

Here's the Omegamon info...

+ SQL Request Count = 99292
+
+ In-DB2 Times Total
+ ------------------------------ ------------
+ Elapsed Time 00:12:10.704
+ CPU Time 00:01:08.769
+
+ Waits Count Total
+ ------------------------------ ---------- ------------
+ Synchronous I/O Wait 6970 00:00:27.974
+ Asynchronous Read I/O Wait 330 00:00:06.217
+ Asynchronous Write I/O Wait 0 00:00:00.000
+ Local Lock/Latch Wait 534 00:00:00.170
+ Page Latch Wait 0 00:00:00.000
+ Drain Lock Wait 0 00:00:00.000
+ Drain of Claims Wait 0 00:00:00.000
+ DB2 Service Task Wait 96875 00:09:06.678
+ Archive Log Mode(Quiesce) Wait 0 00:00:00.000
+ Archive Read from Tape Wait 0 00:00:00.000
+ Stored Procedure Schedule Wait 0 00:00:00.000
+ ------------------------------ ---------- ------------
+ 104709 00:09:41.039

> DB2 Service Task Wait
> Waits for DB2 services. Types of DB2 services include
> open/close of dataset, DFHSM recall of a dataset, SYSLGRNG
> update, define/extend/delete of a dataset, and commit phase 2
> for read only threads.

+ Maximum Number of Open Datasets (DSMAX) = 5000
+ Checkpoints to Pseudo-Close (PCLOSEN) = 5
+ Elapsed Time to Pseudo-Close (PCLOSET) = 10
+ Current Number Open Datasets = 1380
+ High Water Mark Open Datasets = 1399
+ High Water Mark Not-in-use Datasets = 1369
+ Current Number Not-in-use Datasets = 1304

Here's the explain info...

+---------+---------+---------+---------+---------+---------+---------+--------
JTYP METHOD CREATOR TBNAME CARD AXS MCOL
AXSNAME
+---------+---------+---------+---------+---------+---------+---------+--------
0 PPMPRD CZ_UNCOMPL_PROCS 1372904 I 2
CZI0091C
1 PPMPRD CZ_UNPRCD_TXN 301359 I 3
CZI0089A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A

Thanks,
Jay


----------------------------------------
Jay Reavill DBA
Certegy Card Services
11601 Roosevelt Blvd.
St. Petersburg, FL. 33716
Office (727) 227-2144
----------------------------------------








------------------------------------------------------------------------------
This message contains information from Certegy, Inc which may be
confidential and privileged. If you are not an intended recipient,
please refrain from any disclosure, copying, distribution or use of this
information and note that such actions are prohibited. If you have
received this transmission in error, please notify by e:mail
[login to unmask email] .
=====

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html . From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org . The IDUG List Admins can be reached at
[login to unmask email] . Find out the latest on IDUG
conferences at http://conferences.idug.org/index.cfm




---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Martin Packer

Re: Why so much Service Task Wait time? - DB2 V7.2 for z/OS
(in response to Richard Fazio)
A (relevant) question on this: Is this a DB2 on z/OS DDF requester?

Martin

Martin Packer, MBCS CITP Martin Packer/UK/IBM
020-8832-5167 in the UK (+44) (MOBX 273643, Internal 7-325167, Mobile
07802-245584)

"Las cosas de palacio van despacio"

External Blog:
http://www-128.ibm.com/developerworks/blogs/dw_blog.jspa?blog=476
Internal Blog:
http://[login to unmask email]



Ray Williams
<[login to unmask email]
TED.COM> To
Sent by: DB2 Data [login to unmask email]
Base Discussion cc
List
<[login to unmask email] Subject
ORG> Re: [DB2-L] Why so much Service
Task Wait time? - DB2 V7.2 for
z/OS
29-06-05 16:19


Please respond to
DB2 Database
Discussion list
at IDUG






Does Omegamon include Other Service Wait time in Service Task Wait Time?
If so you might be CPU constrained. . . . You may be waiting on CPU.
I'm guessing because of your CPU to Elapsed ratio.

Ray Williams - WHQKO
United Airlines
Database Administration
(847) 700-4359

-----Original Message-----
From: [login to unmask email] [SMTP:[login to unmask email]
Sent: Wednesday, June 29, 2005 9:46 AM
To: [login to unmask email]
Cc: [login to unmask email]
Subject: [DB2-L] Why so much Service Task Wait time? - DB2 V7.2
for z/OS

Hello All,

I'm a bit perplexed as to why we are seeing Omegamon reporting that a
read-only program is consistently spending the majority of it's time
in DB2
Service Task Wait time? There are no commits and only one read-only
cursor
issued by this program. No datasets are being
opened/closed/recalled.
There are other programs involved in this thread, but this is the
only one
with a large Service Task Wait time. Any insight would be greatly
appreciated.

Here's the Omegamon info...

+ SQL Request Count = 99292
+
+ In-DB2 Times Total
+ ------------------------------ ------------
+ Elapsed Time 00:12:10.704
+ CPU Time 00:01:08.769
+
+ Waits Count Total
+ ------------------------------ ---------- ------------
+ Synchronous I/O Wait 6970 00:00:27.974
+ Asynchronous Read I/O Wait 330 00:00:06.217
+ Asynchronous Write I/O Wait 0 00:00:00.000
+ Local Lock/Latch Wait 534 00:00:00.170
+ Page Latch Wait 0 00:00:00.000
+ Drain Lock Wait 0 00:00:00.000
+ Drain of Claims Wait 0 00:00:00.000
+ DB2 Service Task Wait 96875 00:09:06.678
+ Archive Log Mode(Quiesce) Wait 0 00:00:00.000
+ Archive Read from Tape Wait 0 00:00:00.000
+ Stored Procedure Schedule Wait 0 00:00:00.000
+ ------------------------------ ---------- ------------
+ 104709 00:09:41.039

> DB2 Service Task Wait
> Waits for DB2 services. Types of DB2 services include
> open/close of dataset, DFHSM recall of a dataset, SYSLGRNG
> update, define/extend/delete of a dataset, and commit phase 2
> for read only threads.

+ Maximum Number of Open Datasets (DSMAX) = 5000
+ Checkpoints to Pseudo-Close (PCLOSEN) = 5
+ Elapsed Time to Pseudo-Close (PCLOSET) = 10
+ Current Number Open Datasets = 1380
+ High Water Mark Open Datasets = 1399
+ High Water Mark Not-in-use Datasets = 1369
+ Current Number Not-in-use Datasets = 1304

Here's the explain info...

+---------+---------+---------+---------+---------+---------+--------
-+--------
JTYP METHOD CREATOR TBNAME CARD AXS MCOL
AXSNAME
+---------+---------+---------+---------+---------+---------+--------
-+--------
0 PPMPRD CZ_UNCOMPL_PROCS 1372904 I 2
CZI0091C
1 PPMPRD CZ_UNPRCD_TXN 301359 I 3
CZI0089A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A

Thanks,
Jay


----------------------------------------
Jay Reavill DBA
Certegy Card Services
11601 Roosevelt Blvd.
St. Petersburg, FL. 33716
Office (727) 227-2144
----------------------------------------








---------------------------------------------------------------------
---------
This message contains information from Certegy, Inc which may be
confidential and privileged. If you are not an intended recipient,
please refrain from any disclosure, copying, distribution or use of
this information and note that such actions are prohibited. If you
have received this transmission in error, please notify by e:mail
[login to unmask email]
=====================
=========

---------------------------------------------------------------------
------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives
and home page at http://www.idugdb2-l.org/archives/db2-l.html. From
that page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG
conferences at http://conferences.idug.org/index.cfm





---------------------------------------------------------------------------------

Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org
. The IDUG List Admins can be reached at [login to unmask email]
Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Jay Reavill

Re: Why so much Service Task Wait time? - DB2 V7.2 for z/OS
(in response to Martin Packer)
No, it is local TSO batch. Also, in reference to the other responses so
far... Yes, we are CPU constrained and yes, there is a considerable
amount of delete activity on the tables involved. So both of these could
be legitimate issues.

----------------------------------------
Jay Reavill DBA
Certegy Card Services
11601 Roosevelt Blvd.
St. Petersburg, FL. 33716
Office (727) 227-2144
----------------------------------------




"Martin Packer"
<martin_packer@U To: [login to unmask email]
K.IBM.COM> cc:
Sent by: "DB2 Subject: Re: [DB2-L] Why so much Service Task Wait time? - DB2 V7.2 for z/OS
Data Base
Discussion List"
<[login to unmask email]
.ORG>


06/29/2005 12:25
PM
Please respond
to "DB2 Database
Discussion list
at IDUG"





A (relevant) question on this: Is this a DB2 on z/OS DDF requester?

Martin

Martin Packer, MBCS CITP Martin Packer/UK/IBM
020-8832-5167 in the UK (+44) (MOBX 273643, Internal 7-325167, Mobile
07802-245584)

"Las cosas de palacio van despacio"

External Blog:
http://www-128.ibm.com/developerworks/blogs/dw_blog.jspa?blog=476
Internal Blog:
http://[login to unmask email]




Ray Williams
<[login to unmask email]
TED.COM> To
Sent by: DB2 Data [login to unmask email]
Base Discussion cc
List
<[login to unmask email] Subject
ORG> Re: [DB2-L] Why so much Service
Task Wait time? - DB2 V7.2 for
z/OS
29-06-05 16:19


Please respond to
DB2 Database
Discussion list
at IDUG






Does Omegamon include Other Service Wait time in Service Task Wait Time?
If so you might be CPU constrained. . . . You may be waiting on CPU.
I'm guessing because of your CPU to Elapsed ratio.

Ray Williams - WHQKO
United Airlines
Database Administration
(847) 700-4359

-----Original Message-----
From: [login to unmask email] [SMTP:[login to unmask email]
Sent: Wednesday, June 29, 2005 9:46 AM
To: [login to unmask email]
Cc: [login to unmask email]
Subject: [DB2-L] Why so much Service Task Wait time? - DB2 V7.2
for z/OS

Hello All,

I'm a bit perplexed as to why we are seeing Omegamon reporting that a
read-only program is consistently spending the majority of it's time
in DB2
Service Task Wait time? There are no commits and only one read-only
cursor
issued by this program. No datasets are being
opened/closed/recalled.
There are other programs involved in this thread, but this is the
only one
with a large Service Task Wait time. Any insight would be greatly
appreciated.

Here's the Omegamon info...

+ SQL Request Count = 99292
+
+ In-DB2 Times Total
+ ------------------------------ ------------
+ Elapsed Time 00:12:10.704
+ CPU Time 00:01:08.769
+
+ Waits Count Total
+ ------------------------------ ---------- ------------
+ Synchronous I/O Wait 6970 00:00:27.974
+ Asynchronous Read I/O Wait 330 00:00:06.217
+ Asynchronous Write I/O Wait 0 00:00:00.000
+ Local Lock/Latch Wait 534 00:00:00.170
+ Page Latch Wait 0 00:00:00.000
+ Drain Lock Wait 0 00:00:00.000
+ Drain of Claims Wait 0 00:00:00.000
+ DB2 Service Task Wait 96875 00:09:06.678
+ Archive Log Mode(Quiesce) Wait 0 00:00:00.000
+ Archive Read from Tape Wait 0 00:00:00.000
+ Stored Procedure Schedule Wait 0 00:00:00.000
+ ------------------------------ ---------- ------------
+ 104709 00:09:41.039

> DB2 Service Task Wait
> Waits for DB2 services. Types of DB2 services include
> open/close of dataset, DFHSM recall of a dataset, SYSLGRNG
> update, define/extend/delete of a dataset, and commit phase 2
> for read only threads.

+ Maximum Number of Open Datasets (DSMAX) = 5000
+ Checkpoints to Pseudo-Close (PCLOSEN) = 5
+ Elapsed Time to Pseudo-Close (PCLOSET) = 10
+ Current Number Open Datasets = 1380
+ High Water Mark Open Datasets = 1399
+ High Water Mark Not-in-use Datasets = 1369
+ Current Number Not-in-use Datasets = 1304

Here's the explain info...

+---------+---------+---------+---------+---------+---------+--------
-+--------
JTYP METHOD CREATOR TBNAME CARD AXS MCOL
AXSNAME
+---------+---------+---------+---------+---------+---------+--------
-+--------
0 PPMPRD CZ_UNCOMPL_PROCS 1372904 I 2
CZI0091C
1 PPMPRD CZ_UNPRCD_TXN 301359 I 3
CZI0089A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A
L 1 PPMPRD CZ_UNPRCD_AMTS 963985 I 4
CZI0090A

Thanks,
Jay


----------------------------------------
Jay Reavill DBA
Certegy Card Services
11601 Roosevelt Blvd.
St. Petersburg, FL. 33716
Office (727) 227-2144
----------------------------------------








---------------------------------------------------------------------
---------
This message contains information from Certegy, Inc which may be
confidential and privileged. If you are not an intended recipient,
please refrain from any disclosure, copying, distribution or use of
this information and note that such actions are prohibited. If you
have received this transmission in error, please notify by e:mail
[login to unmask email]
=====================
=========

---------------------------------------------------------------------
------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives
and home page at http://www.idugdb2-l.org/archives/db2-l.html. From
that page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG
conferences at http://conferences.idug.org/index.cfm





---------------------------------------------------------------------------------


Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org
. The IDUG List Admins can be reached at [login to unmask email]
Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------

Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home
page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select
"Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org
. The IDUG List Admins can be reached at [login to unmask email]
Find out the latest on IDUG conferences at
http://conferences.idug.org/index.cfm









------------------------------------------------------------------------------
This message contains information from Certegy, Inc which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e:mail [login to unmask email]
=====

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Martin Packer

Re: Why so much Service Task Wait time? - DB2 V7.2 for z/OS
(in response to Jay Reavill)
Thanks. If it had been a DDF requester then DB2 Services Wait also includes
time spent waiting for the answer back from the server.

If you subtract the "new" V6 buckets from the "headline" number what's left
is normally 0. I have seen DDF Requester cases where the number is very
significantly > 0 and had it confirmed with the DB2 lab that that's what it
is.

It's a shame that wasn't your case.

Cheers, Martin

Martin Packer, MBCS CITP Martin Packer/UK/IBM
020-8832-5167 in the UK (+44) (MOBX 273643, Internal 7-325167, Mobile
07802-245584)

"Las cosas de palacio van despacio"

External Blog:
http://www-128.ibm.com/developerworks/blogs/dw_blog.jspa?blog=476
Internal Blog:
http://[login to unmask email]

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm