Portal | Manuals | References | Downloads | Info | Programs | JCLs | Mainframe wiki | Quick Ref
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Profile Log in to check your private messages Log in
 
cobol 2, 3, CICS 1.3 and 3.1

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS
View previous topic :: :: View next topic  
Author Message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6968
Location: porcelain throne

PostPosted: Thu May 29, 2008 3:28 pm    Post subject: cobol 2, 3, CICS 1.3 and 3.1
Reply with quote

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?
Back to top
View user's profile Send private message

Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2504
Location: Atlanta, Georgia, USA

PostPosted: Thu May 29, 2008 4:42 pm    Post subject: Re: cobol 2, 3, CICS 1.3 and 3.1
Reply with quote

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
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6968
Location: porcelain throne

PostPosted: Thu May 29, 2008 5:05 pm    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2504
Location: Atlanta, Georgia, USA

PostPosted: Thu May 29, 2008 5:20 pm    Post subject: Re: cobol 2, 3, CICS 1.3 and 3.1
Reply with quote

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
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6968
Location: porcelain throne

PostPosted: Thu May 29, 2008 5:42 pm    Post subject:
Reply with quote

autoinstall, will cics make a determination at autoinstall time that the module is/is not threadsafe?
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2504
Location: Atlanta, Georgia, USA

PostPosted: Thu May 29, 2008 6:16 pm    Post subject: Re: cobol 2, 3, CICS 1.3 and 3.1
Reply with quote

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
Back to top
View user's profile Send private message
dbzTHEdinosauer

Global Moderator


Joined: 20 Oct 2006
Posts: 6968
Location: porcelain throne

PostPosted: Thu May 29, 2008 6:23 pm    Post subject:
Reply with quote

again, thx for the response Bill,

dbz
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2504
Location: Atlanta, Georgia, USA

PostPosted: Thu May 29, 2008 8:07 pm    Post subject:
Reply with quote

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
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2504
Location: Atlanta, Georgia, USA

PostPosted: Thu May 29, 2008 8:40 pm    Post subject:
Reply with quote

From my previous post -

Quote:
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).

Dick (et al),

A small correction.

Instead of attempting to obtain TCB addressability from the CSA or via the DFHKERN macro, it should be TCA addressability. icon_wink.gif

Bill
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> CICS All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts ASP3 ABEND IN CICS Vedant CICS 0 Fri Oct 20, 2017 3:18 pm
No new posts Identifying Interfaces in CICS/mainframe Ashishpanpaliya CICS 5 Fri Oct 13, 2017 3:21 pm
No new posts IEW2456E error when link-editing a C ... Senthilraj JCL & VSAM 0 Fri Oct 13, 2017 3:12 pm
No new posts Accessing CICS tran with map from JCL... navdeepaggarwal CICS 5 Tue Oct 03, 2017 6:15 pm
No new posts Partial color change of a field in CI... waseem0424 CICS 5 Fri Sep 29, 2017 7:56 pm

Facebook
Back to Top
 
Job Vacancies | Forum Rules | Bookmarks | Subscriptions | FAQ | Polls | Contact Us