Hi John, Any Program in CICS defined as Threadsafe will run on the OPEN TCBs (L8/L9 TCB). If the program makes a DB2 Call then it will run on the L8 TCB as the CICS/DB2 Exit is defined as CICSKey. If the Program makes a File Control call then it will run on the L9 TCB.
The switching of TCBs L8/L9 to QR is as you say dependent on the program issuing a Non-Threadsafe call such as a Transient Data WriteQ command. Be careful as a DISPLAY statement issued out of COBOL will cause a switch from the Open TCB to the QR TCB, as this has a EXEC CICS WRITEQ TD command inside it, writing the message to CEEMSG. How it gets back to the Open TCB (L8/L9) from the QR, is dependent on how the program is defined. If it is defined as OPENAPI = YES, then CICS will switch back to the L9 TCB before resuming execution of the program. If the Program has OPENAPI = NO, then CICS will keep the Program on the QR TCB until a command is issued that forces it to the OPENAPI. OPENAPI = YES has another significant thing, in that any Program defined this way will begin on the L9 TCB. The problem arises in that if the program issues an EXEC CICS RECEIVE it will switch to the QR TCB to execute this. If the first command encountered is a DB2 Call, then CICS will switch this program to the L8 TCB. So unnecessary switching will take place. It is also worth recognizing that some LE functions cause a switch from the Open TCB to the QR TCB Colin Pearce -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of McKown, John Sent: Monday, March 21, 2011 8:20 PM To: [email protected] Subject: Re: fopen and CICS Very true about the automatic switch to the QR TCB for a non-threadsafe CICS function. I guess I should have said that doing that switch is relatively expensive and so really needs to be avoided as much as possible. And I cannot remember exactly when the code switches back to the L8/L9 TCB from the QR TCB. You really don't want to do any "nasty" UNIX code on the QR TCB as it can greatly impact CICS responsiveness. I think the QR and L8/9 switching logic varies depending on the CICS release level and maybe even maintenance. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * [email protected] * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM > -----Original Message----- > From: IBM Mainframe Discussion List > [mailto:[email protected]] On Behalf Of Jan MOEYERSONS > Sent: Monday, March 21, 2011 7:04 AM > To: [email protected] > Subject: Re: fopen and CICS > > On Sat, 19 Mar 2011 06:09:31 -0500, John McKown <[email protected]> > wrote: > > >I'm not a expert, but I'd look at two possibilities. > Neither am I, but I did a few experiments a couple of years ago. > > > >Another possibility, but more difficult to implement, is to > continue to > >use your UNIX code. This can be done in CICS, but only in > what is called > >an Open Transaction Environment (OTE) or OPENAPI. This > environment runs > >the code on a separate TCB from the normal quasi-reentrant > TCB (QR) that > >most CICS programmers are used to. This requires the program to be > >written to be threadsafe, which restricts which EXEC CICS > functions can > >be used. > I do believe this is not true. One can use any EXEC CICS command, > threadsafe or not, in a threadsafe program. CICS will switch back to > the QR TCB when it needs to execute a non-threadsafe command. > > > And requires more careful coding of the program. > Now, this is true. One has indeed to write threadsafe code. > Just declaring a > module threadsafe in the PCT will definitely not make it so... > > This being said, one can use the fopen, fread and fwrite functions in > a CICS program. And one can do so on regular MVS datasets as well as > on files in the hierarchical file system. > > There is however an issue when it comes to serialization... > Indeed, any access > to a given file by any given task may and will interfere with any > access from any other task that wants to access the same file. And it > is up to the developer to include the proper serialization within the > application program. > > Now, if today you are using this technique in an MPP, then the > serialization issue may already (partly) have been solved. Indeed, an > MPP will also serve multiple transaction for different users, > although, if my memory serves me right, it does this in a different > way than CICS does. CICS dispatches work for different transactions > running in parallel to a number of TCBs within the same region, where > IMS will serially assign an MPP region to a transaction and complete > that transaction before assigning the MPP to the next one. > (Someone with a more fresh recollection than my 20+ years old > experience with IMS can confirm this, please? Thanks!) > > > Cheers, > > Jantje. > > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. ---------------------------------------------------------------------- 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
