Hi Don We seem to differ on how DB2 code USED to execute within CICS applications. To the best of my knowledge and belief DB2 code NEVER executed on the main CICS TCB ( QR ) and always had multiple dedicated TCBs defined for its use via RCT. I'm more than happy to be corrected but that's how I know it at least since I have been working with this stuff. Before OTE enhancements came along, on completing sql execution a task would switch back to main CICS TCB. The use of multiple concurrent CPUs was limited to DB2 code only. With OTE a task may not switch back to QR from L8 if it's thread safe. My point is that the increased concurrency is only incremental, sql execution was always concurrent. Therefore my question about the portion of L8 CPU time that is non-DB2. I hope that clarifies it ( or I get corrected ) Mohammad
On Wed, 19 Aug 2009 10:48:38 -0400, Don Deese <[email protected]> wrote: >Hi Mohammad, > >I don't understand the relevance of your question within the context of Dr. >Merrill's posting. Dr. Merrill was illustrating the concurrent execution >of multiple TCBs (both the QR TCB and L8 TCBs) that would not have been >possible prior to the OTE design. It is somewhat irrelevant as to whether >DB2 CPU time was charged to a QR TCB or to an application TCB in past. The >fact that the DB2 processing would have been executed in series off QR >TCBs, but now executes in parallel with L8 TCBs is the important point that >Dr. Merrill was making. Keep in mind that Dr. Merrill was responding to >the OP query "Can CICS region share more than one processor". > >FWIW, I have data from CPExpert users that show 10, 20, 30 or more L8 TCBs >executing concurrently and using more than 100% of CPU (namely, they are >using multiple CPUs concurrently for more than 100% of the time). This >would not have been possible prior to the OTE design. > >As Dr. Merrill pointed out, there are 22 TCB types with CICS/TS 4.1, and >several of these TCB types can have multiple TCBs executing >concurrently. The number of current TCBs can be controlled by the >MAXxxxTCBS in the SIT or in the JVMPROFILE Resource Definition. There are, >of course, limiting factors inherent in the environment (for example, CICS >monitors the amount of available MVS storage and will not attach new TCBs >from the JVM TCB pool if storage is severely constrained). > >Regards, > >Don ---------------------------------------------------------------------- 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
