we are just upgrading from CTS 320 to 520 and our customer faced with a strange issue. The old VS COBOL II applications are failing, but only the 24 bit versions, others with 31 bit not. Those old programs were compiled before LE, during migration not re-compiled.
We have analyzed a bit in the problem, on one single incident – one transaction involving more modules.
Bind options Result Symptom
Original problem AMODE(24), RMODE(24) Fails 16.03.59 STC00082 +DFHAC2236 BRTMCICS 067
067 09/03/2015 16:03:59 BRTMCICS Transaction AI00 abend ASRA in
067 LI0100I term MAAB. Updates to local recoverable resources wi
067 backed out.
MAABAI00 20150309160359 CEE3200S The system detected a program interruption.
MAABAI00 20150309160359 From compile unit LI0100I at entry point LI010
MAABAI00 20150309160359 000ECCBA.
DFHDU0203I 09/03/2015 16:03:59 BRTMCICS A transaction dump was taken for dumpcod
00000272, Program: LI0100I.
DFHAC2236 09/03/2015 16:03:59 BRTMCICS Transaction AI00 abend ASRA in program LI
resources will be backed out.
DFHPG0209 09/03/2015 16:03:59 BRTMCICS MAAB HBE SC19 Resource definition for SC1
00272 09.03.15 16.03.59 ======== TASK ABEND INFO DISPLAY ======================
00272 CICS TERMINAL ID ......... MAAB VTAM NODE NAME ........... BRFV502
00272 TRANSACTION ID ........... AI00 ABEND CODE ............... ASRA
00272 ORIGINAL USER ID ......... HBE
00272 PROGRAM INTERRUPT CODE ... 0000 NO INTERRUPT CODE FOUND
00272 IN PROGRAM ............... LI0100I AT OFFSET ................ 00000D80
Later version of load module AMODE(31), RMODE(ANY) Succeeds No problems.
Original load module, rebinded with options AMODE(31), RMODE(ANY) Fails
14.29.38 STC53537 +DFHAC2236 BRTMCICS 421
421 09/03/2015 14:29:38 BRTMCICS Transaction AI00 abend APCW in
421 LI0100I term MAAA. Updates to local recoverable resources w
421 backed out.
DFHDU0203I 09/03/2015 14:29:38 BRTMCICS A transaction dump was taken for dumpco
00002129, Program: AI1000C.
DFHAC2236 09/03/2015 14:29:38 BRTMCICS Transaction AI00 abend APCW in program L
resources will be backed out.
02129 09.03.15 14.29.37 ======== TASK ABEND INFO DISPLAY ======================
02129 CICS TERMINAL ID ......... MAAA VTAM NODE NAME ........... BRFV501
02129 TRANSACTION ID ........... AI00 ABEND CODE ............... APCW
02129 ORIGINAL USER ID ......... ABS
02129 FAILED RESOURCE .......... LI0100I AIWA
Explanation: The program language is defined as COBOL but the level of the compiler under which it was originally compiled cannot be determined. Most
probably, the program was compiled under an OS/VS COBOL II compiler but the required level of support for that compiler is not present in the system.
The programs are running as 3270-applications under control of one program (AI0000C) and therefore one transaction (AI00), which is in fact regarding this, is the only transaction in the CICS, and in RACF.
This means that we are accessing the module in error, through this interface, and as far as I know through an 'EXEC CICS LINK'. The main module (AI0000C) is a 31-bit program (AMODE = 31, RMODE = ANY - placed). The underlying module in error is LI0100I which is a 24-bit program (AMODE = 24, RMODE = 24).
If the solution is very simple, please for give me. I'm new in CICS...
Thank you for your time!
Even if the 31-bit programs don't immediately fail, I don't think it is good to assume that they "work". If they do work, and later fail, you will not be able to get assistance from IBM, because it is not supported.
How this was missed as a pre-requisite for your using 5.2 I don't know.
I think all the COBOL II programs will need to be recompiled under your release of Enterprise COBOL. Try it with the example you have shown.