View previous topic :: View next topic
|
Author |
Message |
valyk
Active User
Joined: 16 Apr 2008 Posts: 104 Location: South Carolina
|
|
|
|
We found a document that explained a way to force an open TCB switch by calling a dummy exit:
Code: |
DMYRMCAL CSECT , Define the module environment
DMYRMCAL AMODE 31
DMYRMCAL RMODE 31
DFHRMCAL TO=DMYTRUE Call the TRUE
LTORG ,
END DMYRMCAL |
Exit:
Code: |
DFHUEXIT TYPE=RM Parmlist is passed in R1
**
**
** ------------------------------ Module entry point.
DMYTRUE CSECT , Define the module environment
DMYTRUE AMODE 31
DMYTRUE RMODE 31
SR 15,15
BR 14 Return to caller
LTORG ,
END DMYTRUE |
Next it describes creating the PPT for DMYTRUE to be OPENAPI and THREADSAFE. Then, enable DMYTRUE with the OPENAPI and START paramters. Whenever we try this method by calling DMYRMCAL (which calls DMYTRUE), we are receiving a S0C1. Does anyone have any experience with this method? |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
I can't say I've ever used this, although it seems simple enough.
I take it that you're attempting to open an L8/L9 for DB2/OPENAPI?
What are your MAXOPENTCB's set to in the SIT?
Have you ENABLED this TRUE (you can do this via CECI, specifying the START keyword in the API).
Ensure your PPT entry specifies -
Bill |
|
Back to top |
|
|
valyk
Active User
Joined: 16 Apr 2008 Posts: 104 Location: South Carolina
|
|
|
|
Our OPENTCBS parameter is set 65. We are good here. Our peak for the region we are testing in is around 30.
The idea is to allow a task that is currently on the QR TCB to dynamically switch itself to the L8 TCB. We are a very heavy DB2 and MQ shop and we are incurring way to many switches since DB2 and MQ are defined as Threadsafe.
After installing the PPT, I enabled the true with START and OPENAPI on the CECI command.
The PPT is defined as CICS key. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Are you using Planexitname "DFHD2PXT" in DB2CONN?
It's the Threadsafe version of "DSNCUEXT" and if you don't require customization, it's usable as-is out of the box.
If you're using "DSNCUEXT", then this could be causing your TCB switches.
A round-trip TCB switch is about 4000 instructions, which can add up if you keep switching back and forth (L8 <---> QR).
Also, any existing GLUE or TRUE must be Threadsafe as well and defined as such in the PPT.
Bill |
|
Back to top |
|
|
valyk
Active User
Joined: 16 Apr 2008 Posts: 104 Location: South Carolina
|
|
|
|
We are using DFHD2PXT. The 4000 instruction switching is what we are trying to avoid every time we do a single fetch. |
|
Back to top |
|
|
valyk
Active User
Joined: 16 Apr 2008 Posts: 104 Location: South Carolina
|
|
|
|
What we are really trying to do is this...
We have a called program that is very CPU intensive. It contains no DB2.
We want existing programs that are running on the QR TCB to be able to LINK to a "threadsafe interface" module what switches the task to the L8 TCB and then switches back when control is returned back to the invoking program.
We have a way of doing this now... We defined the linked to threadsafe interface program as threadsafe and put a dummy DB2 set packageset call in it. This spins the task off to the L8 TCB and any called modules downstream also run on the L8 TCB.
But this seems like a bogus technique... Surely there is some way to call something that will spin you off on the L8 TCB without having to do a dummy DB2 call. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Does the Linked-To program comply to Threadsafe rules?
Are you on TS 3.1 or 3.2 or have you migrated to 4.1?
TS 3.1 introduced a significant number of Threadsafe API's and more were introduced with 3.2 and 4.1.
If the program is issuing non-Threadsafe API's and is running on an L8/L9 at the time the API is invoked, control will be switched to the QR for execution and switched back when complete. Enough of these switches could actually make things worse than they were.
Note that local (not remote) VSAM can be made Threadsafe compliant (via a PTF), in TS 3.2. I believe it became integral with TS 4.1, although I can't swear by it....
Bill |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
Back to top |
|
|
valyk
Active User
Joined: 16 Apr 2008 Posts: 104 Location: South Carolina
|
|
|
|
The linked program is irrelevant. We can create a PPT entry for the program we are linking, and the linked to program will run as Threadsafe. But, after the linked program is complete and returns execution to the linker, CICS will automatically switch back to the QR TCB. This is what we are trying to avoid.
If we can dynamically switch to an open TCB, then the CICS LINK is no longer needed. |
|
Back to top |
|
|
|