matheus_mag
New User
Joined: 30 Jun 2006
Posts: 1
Location: brasil, s?o paulo
|
|
|
|
Dear friends,
I have to learn more specifically concepts from OTE. I've just know that OTE worked under CICS, and it's about CICS portability environment
Anybody could help me? I need more informations about OTE...
Thanks.
Matheus, Brazil |
|
UmeySan
Active Member
Joined: 22 Aug 2006
Posts: 771
Location: Germany
|
|
|
|
Hi there !
Open Transaction Environment (OTE).
When CICS was first introduced, it ran as a single operating system task. Once the CICS dispatcher had given control to a user program, that program had complete control of the entire region until it requested a CICS service. If the program issued a command that included an OS wait, the entire region would wait with it. As a result, the CICS documentation included a list of OS (and later, COBOL) commands that could not be used by CICS programs. At the same time, there was a significant advantage to this design in that programs did not have to be re-entrant between CICS commands.
As all activity within the CICS region was single-threaded, it was also restricted to the capacity of one CPU. The introduction of multiprocessor mainframes brought new issues for the CICS systems staff, when the purchase of a faster (and more expensive!) mainframe resulted in a slowdown of CICS because the individual processors were slower. IBM responded by attempting to offload some of the CICS workload to additional MVS TCBs that would be able to run concurrently on a multiprocessing machine. For convenience, IBM labeled the main CICS TCB as the Quasi-Reentrant, or QR TCB.
The most significant implementation of this type of offloading came with the introduction of the DB2 database. Rather than establishing a TCB for all DB2 activity, CICS would create a separate TCB for each concurrent DB2 request. Theoretically, while the application programs for each task in the region still ran single-threaded, each task's DB2 workload could be running simultaneously, limited only by the total capacity of all the processors in a multiprocessor. On a practical level, the DB2 workload seldom approached the CICS workload, meaning that CICS was still constrained by the processing speed of a single processor. In addition, since CICS had to switch the transaction between the QR TCB and the DB2 TCB for each DB2 request, there was measurable overhead for complex DB2 applications.
Open Transaction Environment
To enable CICS to further exploit a multiprocessor and at the same time remove the OS restrictions to which CICS programs are still subject, IBM developed the Open Transaction Environment. Put simply, OTE allows an individual CICS transaction to run under its own MVS TCB instead of sharing the QR TCB. Many transactions, each under their own TCB, can run at the same time within the same CICS region. If a transaction running in the OTE issues an OS WAIT, none of the other transactions in the CICS will be effected.
The drawback of OTE is that more than one occurrence of the same program can run at the same time, leading to concurrency issues. A simple example of the type of problem created is the common practice of maintaining a record counter in the CWA that is used to create a unique key. Under "classic" CICS, as long as the record counter was updated before the next CICS command was issued, the integrity of the counter was assured. With OTE, it is possible for two or more transactions to use the counter at the same time, resulting in duplicate keys.
It was to classify this type of problem that the term Threadsafe was developed. Each OTE TCB is considered a Thread, so Threadsafe simply means that the program is safe to run on an OTE thread.
It is crucial to remember that Threadsafe is not a determination made by CICS, but a promise made by the programmer. By marking a program as threadsafe, the programmer is stating that the program will not cause any damage if it is allowed to run in the OTE.
CICS and DB2
The first (and currently, only) implementation of the Open Transaction Environment is for DB2 applications. Where in prior releases the application task would be switched to a DB2 TCB for DB2 work, and then immediately returned to the QR TCB, tasks will now remain on the DB2 TCB until they either terminate or issue a non-threadsafe command.* IBM has demonstrated significant CPU savings in large DB2 shops from the resulting decrease in TCB switches. This CPU savings is reduced if the application program issues non-Threadsafe commands, and can be completely eliminated (or even turned into a CPU increase) if CICS Global User Exits are not Threadsafe.
CICS and JAVA
CICS Transaction Server Version 1 (1.1, 1.2 and 1.3) put a number of building blocks in place, for future growth of the product and its capabilities. When CICS TS V1 introduced support for the Java programming language, it provided support for the Java Virtual Machine (JVM), a runtime environment for applications written in Java. Because of the nature of Java and the JVM, CICS also introduced the facility known as Open Transaction Environment (OTE). OTE enabled CICS systems to execute code in a context other than under the CICS Quasi-reeentrant TCB, which is where most CICS application code executed.
Java and the JVM utilize UNIX System Services (USS) of the host operating system and in that context both issue requests directly to the operating system that are outside the control of CICS management modules such as CICS Storage Control. If a CICS transaction were initiated to first execute (say) a COBOL program and it in turn linked to a Java program, the Java program would execute under an OTE-allocated TCB, not the CICS QR TCB. If the Java program issued a request for a CICS service, TCB switching would occur to enable the request to be satisfied under the CICS QR TCB, and control returned to the Java OTE TCB. The significance is that applications written in Java could now execute as part of a CICS unit of work in a CICS region.
General Informations
Thanks for listening, Regards, UmeySan |
|
