From the sound of it you are doing function shipping of File Control
requests. If this is common then there could be an issue with the number
of Sessions between the two CICS regions. This can be more of a concern
if the files are being updated. Could you include the Connection and
Session definitions from both CICS regions for a look at the attributes?
--
Regards,
Thomas Dunlap Chief Technology Officer [email protected]
Themis, Inc. http://www.themisinc.com 1 (800) 756-3000
On 3/2/2011 8:27 AM, ?????? wrote:
The ZCIOWAIT Resource Name is not given in Tmon, so I am not sure what is
kind of resource the task waiting.
The task is shipping record to another CICS region. So I guess first maybe the
cics setting have some problem, second the program in another region response
slowly. Is it possible CICS setting problem?
At 2011-03-02 04:05:24??"Pearce, Colin E"<[email protected]> wrote:
Hi,
ZCIOWAIT defines the type of Resource the task is waiting on. There is a
Resource Name which defines what this type of Resource is. For example if the
transaction is in Conversation mode and waiting for a response from the User,
then the Resource Type will be ZCIOWAIT and Resource Name will be DFHZARQ1
which is CICS VTAM Terminal Control Application Request handler. Effectively
the User has issued an E C SEND WAIT
If the Resource Type is ZCIOWAIT and the Resource Name is DFHZARR1 this is a
Receive within LU6.2 protocol, a Receive is waiting on more data to be sent.
If the Resource Type is ZCIOWAIT and the Resource Name is DFHZERH1 this is when
there is a need to handle the sending and receiving of FMH7s (Function
Management Headers) and negative responses within LU6.2. This may have
something to do with a Security failure.
There are other ZCIOWAIT reasons. The Resource Names are given in Omegamon and
Tmon. They can also be found in a CICS Trace as well as a dump.
The CICS/TS Problem Determination Guide has all the Wait reasons for ZCIOWAIT
The CICS/TS Diagnostic Guide lists the Resource Types and Resource Names and
the modules that get invoked when these conditions occur. They will give you
more information about where you are and why your waiting.
Colin Pearce
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of
???
Sent: Tuesday, March 01, 2011 7:10 PM
To: [email protected]
Subject: Re: ZCIOWAIT message
Thomas
Your advice is very useful for me, thanks a lot.
At 2011-02-28 21:04:15??"Thomas Dunlap"<[email protected]> wrote:
Eric,
ZCIOWAIT indicates VTAM terminal control wait. My first guess is that
you are function shipping to another CICS region using VTAM connections
between the regions and you are looking at the front-end transaction.
In this case this is a normal situation. As for optimizing, it is
really dependent upon the function the back-end region. Improve the
task in the back-end region and you will shorten the wait in the front-end.
--
Regards,
Thomas Dunlap Chief Technology Officer [email protected]
Themis, Inc. http://www.themisinc.com 1 (800) 756-3000
On 2/28/2011 5:52 AM, Eric JL wrote:
When I run a CICS trans, it is use for DB2 select update, found it
spend a lot of time on ZCIOWAIT. Is this a problem? How can I optimize it.
The trans dump
DATE TIME JOBNAME TRANID TASK# TERMID RESP CPU PAGING ILEIO
02/24 00:00:01 CICSA TR68 85748 111.097 0.2186 0 727
02/24 00:00:02 CICSA TR68 87201 0.0346 0.0074 0 17
02/24 00:00:29 CICSA TR68 87583 1.1215 0.1548 0 473
02/24 00:00:51 CICSA TR68 85748 50.6486 0.3856 0 1,162
TR68 #85748
RES TYPE RES NAME WT CNT WT TIME % OF RESPONSE
CHANGE PRIOPRITY 60 0.0086 0.00
SWITCH TCB 1,454 0.03320 0.29
WAIT W/O ID 3 0.0039 0.00
WAIT FOR REDSPTCH 1,578 0.3363 0.30
ZCIOWAIT 63 1:50.1226 99.12
1ST DISPATCH 1 0.0001 0.00
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
