Hi Don Thanks for the reference from the manual. BTW this confirms rather than contradict my understanding that DB2 work never ran on main (QR) TCB. Before OTE exploitation DB2 work used to run on subtask thread TCBs, now it runs on L8 TCBs. There was always this much concurrency for applications using DB2. If you want to quantify the benefits of OTE you will have find what ADDITIONAL work is running on L8 TCBs rather than running serially on QR TCB. Regards Mohammad
On Thu, 20 Aug 2009 11:25:38 -0400, Don Deese <don_de...@cpexpert.org> wrote: >Hi >Mohammad, > > >I hope that the following (snipped from the CICS DB2 Guide) will >help: > ><snip> > >The CICS DB2 attachment facility includes a CICS DB2 task-related user exit, >DFHD2EX1, that is invoked when an application program makes an SQL request. It >manages the process of acquiring a thread connection into DB2, and of returning >control to the application program when the DB2 processing is >complete. > >When CICS is connected to DB2 Version 5 or earlier, the CICS DB2 >task-related user >exit operates as a quasi-reentrant task-related user exit program. It runs >on the CICS >main TCB (the QR TCB) and uses its own subtask thread TCBs to run threads, >switching to and from the subtask thread TCBs for each DB2 request. >However, when >CICS is connected to DB2 Version 6 or later, the CICS DB2 attachment >facility exploits >the open transaction environment (OTE), to enable the CICS DB2 task-related >user exit >to invoke and return from DB2 without switching TCBs. In the open transaction >environment, the CICS DB2 task-related user exit operates as a threadsafe >and open >API task-related user exit program--it is automatically enabled using the >OPENAPI >option on the ENABLE PROGRAM command during connection processing. This >enables it to receive control on an open L8 mode TCB. Requests to DB2 are also >issued on the L8 TCB, so it acts as the thread TCB, and no switch to a >subtask TCB is >needed. For full details of the CICS DB2 configuration needed to support >the open >transaction environment, see "Migrating to a different release of DB2" in >topic 2.3. > >In the open transaction environment, if the user application program that >invoked the >task-related user exit conforms to threadsafe coding conventions and is >defined to >CICS as threadsafe, it can also run on the L8 TCB. Before its first SQL >request, the ap >plication program runs on the CICS main TCB, the QR TCB. When it makes an SQL >request and invokes the task-related user exit, control passes to the L8 >TCB, and DB2 >processing is carried out. On return from DB2, if the application program >is threadsafe, >it now continues to run on the L8 TCB. Where the correct conditions are >met, the use >of open TCBs for CICS DB2 applications decreases usage of the QR TCB, and >avoids >TCB switching. An ideal CICS DB2 application program for the open transaction >environment is a threadsafe program, containing only threadsafe EXEC CICS >commands, and using only threadsafe user exit programs. An application like >this will >move to an L8 TCB when it makes its first SQL request, and then continue to >run on the >L8 TCB through any amount of DB2 requests and application code, requiring >no TCB >switching. This situation produces a significant performance improvement >where an >application program issues multiple SQL calls. The gains are also >significant when >using an enterprise bean, because when enterprise beans make DB2 requests, they >require additional TCB switches to and from the enterprise bean's own TCB >(see "Using >JDBC and SQLJ in enterprise beans: special considerations" in topic 8.9). >If the >application program does not issue many SQL calls, the performance benefits >might not >be as significant. ></snip> > >Regards, > > >Don > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
