Threadsafe is one of the ways to achieve a positive change in response time, throughput, and cost for programs that use CICS and Db2. This is useful to know even in the age of Java and Distributed applications because Db2 applications have a long life, and many of them were written to use CICS as their Teleprocessing Monitor (TPM) and to use BMS Maps as their User Interface. Although these all began as “green screen” applications, many have been dressed up with an HTML interface from vendors such as IBM and Jacada. For these workhorse programs, CICS Threadsafe can be very helpful in improving response time, throughput, and cost.
We began implementing Threadsafe slightly more than a decade after we first heard Dave Raiman explain its benefits. I’m a little embarrassed to admit that, and this admission leads to the obvious question: Why wait? In brief, we weren't sure we could take the risk. We had older programs written in Assembler that were involved in initializing storage (memory) and we were uncertain about how they interacted. Perhaps we needed the extra overhead of switching from the QR to the L8 TCB because it would guarantee the data. Because we didn’t complete our investigation due to time constraints for other projects, we made no changes for years.
Increasing workloads and resource constraints in our z/OS hardware encouraged us to reopen our research. Investigation assured us that our Assembler modules were DSECTs that were dedicated to storing data initialized as the system came up, and as certain processes were completed, such as orders and invoices. There were no CSECTs, or Control Sections, that were running and modifying data. We concluded that we could safely invoke Threadsafe.
To be sure we were correct in our analysis and conclusion, we began with just one program, and then another, and then groups of 10, and then finally enabled Threadsafe for all of our CICS regions. The beneficial effects were quite impressive. Please note below some observations taken in 4 weeks, two weeks before Threadsafe and two weeks afterwards.
Before Threadsafe (2 weeks) and After Threadsafe (2 weeks)
Avg. CICS TCB Switches Per Transaction Before Threadsafe: 53-54 After: 7
Avg. CICS Application Response Times Before Threadsafe: .10 - .12 secs After: .05 - .0513 secs
TCB Total Switch Time Before Threadsafe: 16.5-20.7 CPU Hours After: 2.4-3.6 CPU Hours
Interested in learning more? Research CICS Threadsafe. IDUG NA 2001 has an excellent presentation from Dave Raiman, and he has many other articles and presentations. Excellent newer articles and presentations by a variety of authors are also available.
About Bernie O’Connor
Bernie O’Connor is an IBM Champion and a Director of IT whose other roles included Application Developer, Development Manager, DBA, DBA Manager, Technical Architecture, BI/DW/Analytics, Pricing Analytics, Computer OPS, System Programmers and Admins, Web Services, M&A and Divestitures. Bernie is a member of the IDUG Speaker Hall of Fame, and served as IDUG North America Conference Chair (2005 – Denver), IDUG Board Member (2004-2009), and IDUG President (2007-2008). Bernie is active in the Midwest Db2 Users Group (mwdug.org), and with the Evanta CDO conference. Bernie’s industry experience includes Insurance, Banking, Publishing, Education, Manufacturing and Distribution.
#Db2