cobol 2, 3, CICS 1.3 and 3.1

dbzTHEdinosauer · Posted: Thu May 29, 2008 3:28 pm Post subject: cobol 2, 3, CICS 1.3 and 3.1

I have load modules with the following attributes:

COBOL2 compiled/linked/bound on os390 cics 1.3 type 1
COBOL2 compiled/linked/bound on z/os cics 3.1 type 2
COBOL3 compiled/linked/bound on z/os cics 3.1 type 3

having a few soc4's.

type 1 links to type 3 always works
type 1 links to type 2 links to type 3 sometimes works.

the type 3 module is the same in both scenarios.
the type 3 module contains XML-PARSE (we are waiting on a compuware ptf to allow xpeditor interactive debugging for the xml-parse).

I remember reading (in forum) about the different type of task control blocks being set up for different types of cobol/cics vsns.

problem is:

1: when the type 3 is linked to directly from the type 1, type 3 always works.
2: when the type 3 is linked to thru type 2's, sometimes works, sometimes not.

normally, if 1 is first run, 2 will work.
but if 2 is run without 1 having first run, 2 will end up with a soc4.

obviously, we have an addressing problem. The link instructions are coded the same way, the commareas are the same. only difference is the combination of cobol types and cics pre-compiled types.

my question: where do I start searching for compatibility problems.
which cics log shows me the task block setup?

Bill O'Boyle · Posted: Thu May 29, 2008 4:42 pm Post subject: Re: cobol 2, 3, CICS 1.3 and 3.1

Dick,

I remember you have said in the past that your shop is primarily DB2.

Could you be experiencing a Threadsafe issue?

Are the programs defined in the PPT as Threadsafe?

Are any of the programs calling a non-Threadsafe program, because the L8 TCB used for DB2/Threadsafe only knows about the Caller being Threadsafe. If the Callee isn't Threadsafe, then this is a problem.

There are different CICS releases which contain Threadsafe CICS API's, with the latter versions containing the greater number of these API's.

Regards,

Bill

dbzTHEdinosauer · Posted: Thu May 29, 2008 5:05 pm Post subject:

Hi Bill,

been waiting for your response.

will check this out. would this cause the sometimes works, sometimes doesn't?

again, thx for your response. dbz

Bill O'Boyle · Posted: Thu May 29, 2008 5:20 pm Post subject: Re: cobol 2, 3, CICS 1.3 and 3.1

Dick,

Yes, results will vary depending on the mix, the number of L8 TCB's, Threadsafe program compliance, etc.

Ensuring Threadsafe compliance is something that the shop informs CICS that they've met, via the PPT entry.

If a program is defined to the PPT as Threadsafe and it's not, then intermittent results will occur.

But, I need to reiterate that if a Threadsafe caller calls (not links to) a non-Threadsafe sub-program then you'll experience intermittent results as well. In a called scenario, because a CALL is outside of the scope of CICS, the PPT entry of the called program is not considered, so if the Threadsafe program is executing in an L8 TCB and it calls a non-Threadsafe sub-program, then this will raise the ever popular "Unpredictable Results May Occur".

CICS only recognizes and considers the PPT entry characteristics, when the program is accessed via a CICS API, such as a LINK or an XCTL.

If the PPT entry indicates non-Threadsafe, the program then executes in the QR TCB and not in an L8 TCB.

Regards,

Bill

dbzTHEdinosauer · Posted: Thu May 29, 2008 5:42 pm Post subject:

autoinstall, will cics make a determination at autoinstall time that the module is/is not threadsafe?

Bill O'Boyle · Posted: Thu May 29, 2008 6:16 pm Post subject: Re: cobol 2, 3, CICS 1.3 and 3.1

Dick,

There should be different groups with templates for Threadsafe and non-Threadsafe.

But, Autoinstall can't determine whether a program is Threadsafe or not.

So, the Threadsafe programs need to use the Threadsafe-Autoinstall group.

Bill

dbzTHEdinosauer · Posted: Thu May 29, 2008 6:23 pm Post subject:

again, thx for the response Bill,

dbz

Bill O'Boyle · Posted: Thu May 29, 2008 8:07 pm Post subject:

Dick,

One other "tidbit". Ensure that any DB2 "GLUE's" that you're running are Threadsafe, especially (if used) your DB2 Dynamic Plan Exit. This alone can be a real nemesis.

The Hursley folks are working on CICS/TS 4.1 as we speak and shops should plan to see to more Threadsafe options/additions (especially CICS API's) to this release. IBM's strategy revolves around this "OPEN API" concept and they'll continue to drive this home. You'll also find less and less addressability to "known" control blocks as IBM doesn't want anyone to touch these.

However, from what I've read, Threadsafe compliance and usage in a non-Threadsafe (non-DB2) environment might be more trouble than it's worth and keeping the application as non-Threadsafe (everything runs off the QR TCB and if defined, a CO/Concurrent TCB for VSAM), is still viable for most non-DB2 shops. Yes, there is a small CPU savings in running as Threadsafe, but the cost to ensure Threadsafe compliance on the given programs might be cost prohibitive.

With the introduction of CICS/TS 3.2, a S0C4 will be raised if you have applications trying to load the TCB address from the CSA, as this address has become protected. But, even if you could get addressability to the TCB (in a previous release) and you're running multiple L8 TCB's for Threadsafe, the TCB address obtained from the CSA may NOT match your task as it may belong to the QR TCB or some other concurrent L8 TCB. With that, IBM recommend's that the DFHKERN macro is used to address the TCB (but only if you have to).

Lastly (FWIW), a PTF is available for CICS/TS 3.2 to allow Threadsafe VSAM access. Unfortunately, it's only for local access. Remote access is still non-Threadsafe, but you may see this in CICS/TS 4.1.

Stay tuned....

Regards,

Bill

Bill O'Boyle · Posted: Thu May 29, 2008 8:40 pm Post subject:

From my previous post -