|
View previous topic :: View next topic
|
| Author |
Message |
Raghuraman_New
New User
Joined: 03 Oct 2008
Posts: 43
Location: Chennai,India.
|
|
|
|
Hi,
ProgA - defined as Quasirentrant
ProgB - defined as Threadsafe
ProgA Links/XCTLs ProgB.
Even though ProgB is threadsafe, it will run as a Quasirentrant only, because the calling program's TCB affinity takes precedence.
Now my question is,
if ProgA 'starts' a transaction TRNB, which invokes ProgB. Then will ProgB run as Threadsafe ?
I have searched for information in the 'Threasafe Considerations' redbook, but i couldn't find any info on started transactions.
So pls help. |
|
| Back to top |
|
 |
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
If PROGB is accessed via a LINK-API from PROGA and PROGB is defined as Threadsafe in the PPT, then it will execute on an L8 TCB. However, if PROGB contains non-Threadsafe CICS API's, then each time they are invoked, control is returned to the QR for execution and once the API has completed, control is then returned back to the L8. A round-trip TCB switch is about 4,000 instructions, but you would want to limit these switches as much as possible. Ideally, if PROGB is fully Threadsafe compliant, then it should start and end on an L8. Regardless, when PROGB issues a RETURN, control is returned to PROGA, executing on the QR.
These same rules hold true for an XCTL-API but control goes to the Next program or a RETURN is issued, whatever the case may be.
If PROGA were to CALL PROGB (not a LINK-API), then yes, PROGB takes on the PPT characteristics of PROGA and will execute in the QR.
If PROGA were defined as Threadsafe (executes on an L8) and PROGA CALLS PROGB and PROGB is not Threadsafe compliant, then you might raise some "opportunities" for yourself. 
What version/release of CICS are you running?
Bill |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
| Back to top |
|
|
MBabu
Active User
Joined: 03 Aug 2008
Posts: 400
Location: Mumbai
|
|
|
|
| Hey Bill... hope you don't mind an "out fo the blue" thanks... your answers are always interesting and helpful |
|
| Back to top |
|
|
Raghuraman_New
New User
Joined: 03 Oct 2008
Posts: 43
Location: Chennai,India.
|
|
|
|
Bill,
Thanks for the reply.
I have verified that my program has only threadsafe CICS commands and the program logic is threadsafe too. I have changed the concurrency to Threadsafe, but still it performs a TCB switch to the QR TCB at the end of each EXEC SQL, instead of staying in the L8 TCB. I suspect that there is a non-threadsafe DB2 user exit ( TRUEs ). I will have to switch on the AUX trace and see the what really happens.
Raj |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
In your DB2CONN definition, what's the PLANEXITNAME you're using? IBM furnishes two different versions; DFHD2PXT (Threadsafe) and DSNCUEXT (Quasireentrant), with DSNCUEXT being the IBM default.
Unless you need customization done to your exit, either one can be used as-is without modifications. However, DFHD2PXT is the one you should use for Threadsafe and it's defined as such in its PPT entry.
Bill |
|
| Back to top |
|
|
Raghuraman_New
New User
Joined: 03 Oct 2008
Posts: 43
Location: Chennai,India.
|
|
|
|
Bill,
The Planexitname is blank which means a default exit must be used. But in the AUX trace I couldn't find a call to either of the programs you had mentioned.
Surprisingly, at the end of the DB2 call, there is a call to a user-exit program belonging to a third party debugging application. This program is non-threadsafe and this has forced the switch to the QR TCB at the end of the DB2 call.
We have analysed the AUX log in a higher Test region where this third party application is not available. The log shows that there is no TCB switch after the DB2 call and the program continues in L8 TCB. 
Thanks a lot for your heads up Bill ! |
|
| Back to top |
|
|
|
|
