TIRTRCE abend S0Cx after COBOL 6.1 upgrade

[Douglas Seaver]

Our z/OS  provider upgraded to COBOL 6.1 compiler from COBOL 4.2 on 9/17/2017.
Now, when we recompile any action block with DEBUG TRACE turned on, if that action block is called by a COBOL external program (non-CA Gen), it abends with a S0Cx abend (S0C4, S0C6). This is regardless of whether we have turned on tracing with DTF or not. Just having DEBUG generated in the code is causing the abend from an external program.
This functionality previously worked with COBOL 4.2; i.e., we could compile with DEBUG TRACE and call the program with a non-CA Gen COBOL program. It would not abend with COBOL 4.2, and we could use DTF to enable tracing, and the trace facility worked as well.

Any ideas for getting this to work in our new COBOL environment are most appreciated.

[GARY DONOGHUE]

Hi Doug,

 

Sorry to hear about your issue. Can I ask what COBOL compiler options you are invoking for the 6.1 calls that appear to result in your S0C4/6s? Also, from the (formatted) dump are you able to ascertain the call trace prior to the abend and what module/object code it actually fails within - system or application? Can you also confirm what z/OS CA runtime level you are presently utilising and the CA Gen maintenance currently applied to these? Note that CA GEn 8.6 runtimes were the first to be compiled with COBOL 5.1, prior to that COBOL 4 had been used for 8.5 and 8.0. 

 

S0C4/6s normally relate to incompatible linkage or mismatched data flows so the error would seem to point to an inconsistency between a called/calling module at some stage in the call flow - it would be interesting to see where. 

[Douglas Seaver]

Gary,

 

Today is the first day I’ve had to really look at the dump. I have discovered a few interesting things, but this one may be the most informative:

 

Here is the first part of the CICS transaction dump, followed by some explanation.

 

CEE3204S The system detected a protection exception (System Completion Code=0C4)

         From compile unit TIRTRCE at entry point TIRTRCE at compile unit offset

         235E7014.

CEE3DMP V2 R1.0: Condition processing resulted in the unhandled condition.

Task Number: 12402   Transaction ID: E3FN

 

CEE3845I CEEDUMP Processing started.

 

Information for enclave J1566567

 

  Information for thread 8000000000000000

 

  Traceback:

    DSA   Entry       E  Offset  Statement   Load Mod             Program Unit

    1     CEEHDSP     +00004A4C                                   CEEHDSP

    2     CEECGEX     +000001F2                                   CEECGEX

    3     CEEPFWSA    +00000072                                   CEEPFWSA

    4     TIRTRCE     +00000094                                   TIRTRCE

    5     J1505116    +000012E2                                   J1505116

    6     IGZXCIC     +00000026

    7     IGZCFCC     +00000392                                   IGZCFCC

    8     J1521407    +00000D6C  957                              J1521407

    9     IGZXFCA1    +0000223E                                   IGZXFCA1

    10    J1566566    +000004E6                                   J1566566

    11    IGZXCIC     +00000026

    12    IGZXFCA1    +0000223E                                   IGZXFCA1

    13    J1566567    +00000A72                                   J1566567

    14    CEECRINV    +00000306                                   CEECRINV

    15    CEECRINI    +00000B62                                   CEECRINI

 

    DSA   DSA Addr   E  Addr    PU Addr    PU Offset  Comp Date  Compile Attribu

    1     21A0FDC8   226BF7B0   226BF7B0   +00004A4C  20150130   CEL

    2     21A0FC60   2267A420   2267A420   +000001F2  20160420   CEL

    3     21A0FBB0   22792AD0   22792AD0   +00000072  20130313   CEL

    4     21A0FAC0   235E6F80   235E6F80   +00000094  20130319   ASM

    5     21A0F840   235D15E0   235D15E0   000012E2  20170606   COBOLV5 EBCDIC

    6     21A0F738   21A0F7F0   21A0F7F0   +00000026  ********

    7     21A0F540   22F5D618   22F5D618   +00000392  20140722   LIBRARY

    8     21A0F430   235BF998   235BF998   +00000D6C  20031011   COBOL

    9     21A0F1E8   22876E80   22876E80   +0000223E  20170206   LIBRARY

    10    21A0EF28   330D9260   330D9260   000004E6  20170926   COBOLV5 EBCDIC

    11    21A0EE20   21A0EED8   21A0EED8   +00000026  ********

    12    21A0EBD8   22876E80   22876E80   +0000223E  20170206   LIBRARY

    13    21A0DFD0   329F86F0   329F86F0   00000A72  20170926   COBOLV5 EBCDIC

    14    21A0DE28   226B8AB8   226B8AB8   +00000306  20130313   CEL

    15    21A0DDA8   2267C030   2267C030   +00000B62  20160420   CEL

 

The failing CICS transaction is defined as an inbound web service to CICS.

 

1.       Transaction E3FN calls COBOL 6.1 program J1566567. This COBOL program is what does the initial container GETs and PUTs to satisfy the web service request.

 

2.       J1566567 then calls J1566566, which is a Gen program,  AB_3RD_WIN_VEH_STYL_REGP_CHECK. This program is also COBOL 6.1.

 

3.       J1566566 then calls Gen AB J1521407, AB_ENV_MAIN_SYSTEM_SUPPORT. This program is quite an old COBOL 1.2.2 program (COOL:Gen 5.1). <== I think this might be where the problem lies (in the COBOL 1.2.2 code).

 

4.       J1521407 than calls J1505116, AB_DOT_LOGN_READ. When this AB is compiled COBOL 6.1 with DEBUG TRACE turned on, it abends with S0C4, whether or not DTF is invoked.

 

5.       If we demote the Changeman package containing the DEBUG TRACE code, production J1505116 reverts back to a Gen 8.0 COBOL 4.2 program, and it works without error.

I am going to try regenerating J1521407 and then see what happens with DEBUG TRACE.

[GARY DONOGHUE]

Hi Doug,

 

Thanks for the additional information and, yes, it is definitely worth looking into the nature of that older module (I think for COBOL 1.2.2 you're referring to COBOL/370) which is still within the COBOL 85 standard. Such a relatively old level of COBOL should, in theory, still be compatible but there are potential traps, albeit mostly to do with the new compiler itself having issues with older COBOL source, so perhaps aim to recompile with the SSRANGE, ZONECHECK and with the OPT(imiser) set to OPT(0) initially and see what is reported and, if nothing untoward, attempt to rerun your trace. If that proves inconclusive revert to the standard settings for CA Gen (NOSSRANGE and OPT(2)). Come back to me if you hit invalid data issues out of the J1521407 compile - but I think that unlikely as we're talking about CA Gen generated code. 

 

However in your original message you'd said that 'if that action block is called by a COBOL external program (non-CA Gen), it abends with a S0Cx abend (S0C4, S0C6)' but, from the above call chain, I could only see CA Gen modules calling other CA Gen modules. Or do you mean that J1566567 (the highest level call mentioned) is the external module that, indirectly, via various CA Gen module calls, ultimately abends within a CA Gen module (J1505116). 

 

Incidentally, can I just be clear that if you run the existing code with no TRACE at all the program runs without problem, even with this mix of COBOL 6.1 and COBOL/370 code within the same load module? Also, if you leave J1505116 in its previous (non-COBOL 6.1) incarnation but with TRACE on (not sure if this is now possible for you given COBOL upgrade) does it also work?

 

More food for thought at least. Keep me posted. Thanks

[Douglas Seaver]

Gary,

 

I agree that in most cases the COBOL 1.2.2 code should coexist with COBOL 6.1 code. But, we have seen other strange things with mixed statically linked code (Gen ABs with triggers) causing failures in COBANAL (Share-ware) utility.

I hppe to try this code out tomorrow, but not sure how early I can get to it.

 

You are right, my original description of the problem was what was described to me. Today, after looking at the traceback, I saw and had to re-describe the problem. The abend is coming several levels down from the initial non-Gen COBOL which calls the first Gen AB. I just think it’s possible that TIRTRCE is not getting all the data it needs since we’ve switched to COBOL 6.1.  By the way, this is only an example; we’re pretty confident that this will always fail if there is no Gen dialog manager or procedure step in the mix. When there is, it works. I’m thinking possibly a too old copy of GLOBDATA that dates back to COOL:Gen 5.1,  c.2003.

 

Unfortunately, I cannot try any mix of TRACE now except for COBOL 6.1.

[GARY DONOGHUE]

Hi Doug,

 

Thanks for the extra elaboration and clarification however were you able to confirm that this routine (J1505116) runs normally (without an S0C4) when trace is not activated and related modules in the call chain, apart from J1521407, are compiled at 6.1. Can you also confirm the nature of the TIRTRCE call out of J1505116 just so you can assess the structure of any linkage into the TIRTRCE code. 

 

I think it worth pursuing a recompile of J1521407 not so much for the use of COBOL 6.1 (suspect the same issue would similarly afflict COBOL 5.1 code) but because it will then be involving the latest CA Gen copybooks, including GLOBDATA. That said, CA tag any changes to the end of GLOBDATA (hence the 'growth room' filler to ensure linkage length is retained) so GLOBDATA linkage should remain backwards compatible. There have been hardly any changes to GLOBDATA in any event - at CA Gen 6 the 'growth room' remaining was 189 bytes and by CA Gen 8.6 it had only reduced down to 145 bytes, all fields tagged to the end of the copybook definition. It would, however, be good to isolate linkage issues as the possible cause so a look at the nature of the TIRTRCE call itself would be useful.  

 

If this proves inconclusive then you may need to regenerate J1521407 to establish if the ancient code itself is, in some way, a factor in the linkage being passed into J1505116 somehow corrupting the TIRTRCE call therein. 

 

Hope this helps with your investigations still further. 

[Douglas Seaver]

Gary,

 

We have confirmed that J1505116 runs normally when the DEBUG TRACE code is removed (by reverting to Gen 8.0 COBOL 4.2 code). J1505116 was actually in TRACE for a completely different reason, so the transaction was only failing because it was in TRACE.

 

Here is the call to TIRTRCE from J1505116:

    DOTDFST.IEFGEN.SRCLIB(J1505116)

===>

PARA-0000000000-TRACE.

    CALL 'TIRTRCE' USING GLOBDATA

              PADTEXT

              LAST-STATEMENT-NUM

              W-IA

              W-OA

              W-LA

              W-EA

              PADVIEW

              TRACE-RET-CD

    IF TRACE-RET-CD = 20

    GOBACK

    END-IF

    .

 

PARA-0000000000-TRACE-EXIT.

    EXIT.

[GARY DONOGHUE]

Hi Doug,

 

Yes. That's the standard CA Gen TIRTRCE call so nothing untoward there. If the regen/recompile check for J1521407 resolves the issue then you may have to contact CA to establish the nature of displacement causing the abend when you attempt to mix older CA Gen code with later CA Gen code compiled with COBOL 6.1. There may ultimately be restrictions regarding the use of TIRTRCE in this way that we are not party to - but, personally, I do not think it specifically an issue with the GLOBDATA linkage for the reasons previously explained. 

 

This may seem daft but some other things to double check are a source code comparison between the DEBUG/non-DEBUG versions of J1505116 as well as a check for any compiler errors/messages issued by the 6.1 compiler for the DEBUG version. 

[Douglas Seaver]

I agree that it’s likely not a GLOBDATA issue.

 

The source code compare between the DEBUG/non-DEBUG versions of J1505116 don’t seem to have any real differences. They were generated from different models, so the names of some of the paragraphs and variables are different, and the some of the statement numbers are different as well. There appear to be some minor code differences when comparing the Gen code comments at the end of the COBOL source. And, of course, the DEBUG version has extra variable for tracing and periodic performs of the -TRACE paragraph.

 

There were no compiler errors in the DEBUG version, only compiler information messages.

[Douglas Seaver]

Update: I have compared the production version (Gen 5.1, COBOL 1.2.2, c.2003) of J1521407 (which calls J1505116) to the test version in our development libraries (Gen 8.5, COBOL 4.2, c.2017). the structure of the call to J1505116 looks the same.

[GARY DONOGHUE]

Hi Doug,

 

Given this I think it best you now approach CA for them to comment on what may be causing the abend with TIRTRCE itself in the context so described - I think you have done all you can to establish it is not overtly an environmental issue specific to your site. I guess you could put some COBOL displays into the Gen code of J1505116 to establish what is being passed into TIRTRCE but, ultimately, only CA, with their ownership of TIRTRCE, will be able to advise you of what may be leading to the S0C4 in their module. 

[Douglas Seaver]

Gary, we are in agreement with this. Thanks for all your assistance. I am pursuing with CA Support.

[Douglas Seaver]

Latest update:

 

We have two separate cases opened with CA support on this issue. Just want to update here that we have now encountered this same issue (abend S0C4) when calling the following CA Gen runtime modules (if we start from a non-Gen COBOL program):

1. TIRTRCE   (if the Gen AB is generated with DEBUG mode turned on.)

2. TIRFTSC   (timestamp conversion)

3 TIRDAT2   (resulting from the following Gen code)

                           6*   ! SET local tmst_work_set db2_tmst TO CURRENT_TIMESTAMP        

In case anyone else has an issue like this, recommend opening a case with CA support ASAP and supplying them with documentation of the problem per their requests. This needs to work or eventually we can't develop, debug or fix anything.

[EYUP YAKAR]

Hi Doug,

i have met 2nd and 3rd abends as you listed. Did you open any case for these abends, and was it closed?

Thanks

Hi,

I have 2nd and 3rd abend issues as you listed. (TIRFTSC, TIRDAT2) Have you opened any case for these abends, and have it been closed?

Thanks

Hi Doug,

i have met 2nd and 3rd abends as you listed. Did you open any case for these abends, and was it closed?

Thanks

Hi Doug,

i have met 2nd and 3rd abends as you listed. Did you open any case for these abends, and was it closed?

Thanks

[Lynn Williams]

Hi @EYUP YAKAR,
This thread is from over 3 years ago.
I checked back on Doug's cases from that time for the above symptoms and they were resolved by installing Gen 8.5 PTFs RO83428 and RO93797​
https://support.broadcom.com/download-center/solution-detail.html?aparNo=RO83428&os=z%2Fos
https://support.broadcom.com/download-center/solution-detail.html?aparNo=RO93797&os=z%2Fos

Are you up to date with your Gen 8.5 or 8.6 maintenance?
The z/OS Maintenance Grid page for CA Gen is here: https://support.broadcom.com/external/content/release-announcements/CA-Gen-Maintenance-Grid/4768
Also here is a KB on Cobol 5.x/6.x support: Using CA Gen with the COBOL V5 or COBOL V6 Compiler

If you still have problems after reviewing above I would suggest to open a support case.

Hope that helps

Regards,

Lynn

​

------------------------------
Lynn Williams
Senior Principal Support Engineer
Broadcom
Australia
------------------------------