DB2 V7 Z/OS - & CICS 2.2 with 'thread safe'

Missy Case

DB2 V7 Z/OS - & CICS 2.2 with 'thread safe'
All,

DB2 V7, Z/OS

We are looking for anyone with information on the cost savings of using
CICS 2.2 when using the new thread safe technique for DB2 threads. We are
currently CICS1.3 & are looking at trying to give up some numbers on what
the possible savings are for moving to CICS 2.2, but we're having trouble
finding documentation regarding the feature.

Any hints or manual links welcome.

Missy Case
FDR
701-275-6358

---------------------------------------------------------------------------------
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

Dave Nance

Re: DB2 V7 Z/OS - & CICS 2.2 with 'thread safe'
(in response to Missy Case)
Can't really point you to any manuals but the savings are pretty
minimal. Our CICS guys just did this a few months back. The savings are
on the line of a couple minutes per week with about 750,000 transactions
per day. There have been zero issues due to the change as far as the
apps go. It did kind of throw our monitoring a curve ball. We had
processes set up for monitoring and giving us summarizations for a few
transactions and all of a sudden we no longer had a thread for each
transaction. We had to make changes to get our count of transactions
based on the commits per thread. Now we've switched from our DB2
Omegamon stats to the Omegamon CICS stats for this task.

Dave Nance
First Health Services, Corp.
(804)527-6841


>>> [login to unmask email] 1/5/05 3:53:40 PM >>>
All,

DB2 V7, Z/OS

We are looking for anyone with information on the cost savings of
using
CICS 2.2 when using the new thread safe technique for DB2 threads. We
are
currently CICS1.3 & are looking at trying to give up some numbers on
what
the possible savings are for moving to CICS 2.2, but we're having
trouble
finding documentation regarding the feature.

Any hints or manual links welcome.

Missy Case
FDR
701-275-6358

---------------------------------------------------------------------------------
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



"MMS <fhmail.firsthealth.com>" made the following annotations.
------------------------------------------------------------------------------
This message, including any attachments, is intended solely for the use
of the named recipient(s) and may contain confidential and/or
privileged information. Any unauthorized review, use, disclosure or
distribution of this communication(s) is expressly prohibited.
If you are not the intended recipient, please contact the sender by
reply e-mail and destroy any and all copies of the original message.
Thank you.
=====

---------------------------------------------------------------------------------
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

nguyen duc tuan

Re: DB2 V7 Z/OS - & CICS 2.2 with 'thread safe'
(in response to Dave Nance)
Here are the result of my test , a program doing 200 inserts :

without threadsafe : 20ms (CPU time)
threadsafe : 17 ms

15% less , on high rates transactions , it can be very interesting.

There is some restrictions to be threadsafe , of course if your programs
execute a lot of non threadsafe instructions , you will experience TCB
switchings and the result can be worse then "before" .

For example : READ , WRITE, ASKTIME , SEND (map) RECEIVE are non threadsafe
(the list of non threadsafe instructions are in CICS Programming Guide)

CICS TS 2.2 proposes 2 solutions to implement threadsafe : in SIT (our
zparm) , then all your programs are considered to be threadsafe - Or at the
(individual) program declaration level.

---------------------------------------------------------------------------------
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

Joseph Fatula

Re: DB2 V7 Z/OS - & CICS 2.2 with 'thread safe'
(in response to nguyen duc tuan)
I am a CICS sysprog and implemented Threadsafe at our installation.
CPU savings are usually significant. It is definitely a YMWV (Your
Mileage Will Vary) situation based upon your version of CICS and your
application's characteristics and usage patterns. The later versions of
CICS (2.3 and 3.1) offer more Threadsafe improvements than 2.2 because more
CICS commands have been made "Threadsafe".
The key issue here is avoiding TCB switches. One TCB switch is not
expensive (I believe in the sub-millisecond range), but if the application
does significant DB2 I/Os, all of those TCB switches begin to add up.
Using Threadsafe reduces the CPU consumption of most DB2 applications
running in CICS by avoiding many of these collectively expensive TCB
swtiches.
Main factors governing the CPU reduction of a given application:
1) Number of DB2 I/O operations (Without Threadsafe, there are normally two
TCB switches for each DB2 I/O, each of which corresponds to a call of DB2
by CICS. One TCB switch is from the QR TCB to the L8 TCB; after the call
returns, CICS switches the task back to the QR TCB)
2) Amount of CPU consumed by the application. If the application consumes
a lot of CPU and does few DB2 I/Os, the savings will be relatively less; if
the application consumes relatively little CPU and does relatively many DB2
I/Os, the savings will be relatively greater.
3) Proportion of non-Threadsafe commands executed. Certain CICS commands,
depending upon the particular release of CICS, are not Threadsafe. CICS
accomodates them by doing two TCB switches each time they are executed.
Therefore, executing non-Threadsafe commands while running in Threadsafe
mode offsets some of the benefits of running Threadsafe.
4) Running non-Threadsafe exits in CICS, depending upon when they run in
task lifetime and how frequently they are executed, can also offset
Threadsafe benefits by causing extra TCB switches. Because the task always
starts on the QR TCB, even when running in Threadsafe mode, exits which run
early in task lifetime, before the first DB2 I/O, are not an issue.
Not receiving expected benefits from Threadsafe can mean issues with
applications, issues with exits running in CICS, or an application which
has low potential to benefit (either very few DB2 I/Os--not very common, or
high task CPU consumption with relatively fewer DB2 I/O operations).
If you are curious about the potential benefits, turn Threadsafe "on"
in an isolated test region and have one user (one user only) run some
typical applications and check your CICS monitoring product for CPU
consumption and the number of TCB switches compared with running without
Threadsafe. If the benefits are disappointing, a CICS sysprog should
review the exits running in CICS, the results, and the application to
determine why.
It is important to review applications for code which is not
Threadsafe before turning on Threadsafe for a particular application
program. Failure to do so can have "unpredictable" results, which really
means weird application errors. Threadsafe allows programs to execute
simultaneously within a given CICS region, not possible before. Therefore,
using such techniques as shared storage (Getmain Shared), Address CWA, and
others is not permitted because of integrity issues.
I was very pleased with the benefits of Threadsafe, one of the best
features introduced in CICS recently. It was a signficant CPU reduction
for relatively little work. Most tuning changes produce much less CPU
reduction for more work.

Joe Fatula

---------------------------------------------------------------------------------
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