Thank you for taking the time to respond to my posts.
Regarding the handling of a deliberate program termination due to abnormal termination, it all depends on what we want to do.
In our context, we have the simple abnormal termination, which is a paragraph to be PERFORMed, placed at the end of the source code. However, we also have more sophisticated abnormal termination cases, with processing that we don't want to duplicate in each program (for maintenance reasons). Therefore, we use dynamic CALLs for this.
Note that I was able to resolve some cases by workaround (EXEC CICS RETURN, EXEC CICS ABEND), but I am stuck on the case of EXEC CICS HANDLE ABEND LABEL.
Original Message:
Sent: Mon November 17, 2025 09:53 AM
From: Mike Chase
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
I see both sides of this.
Adding a directive (not an option! It'd need to be done in-place) could potentially help the optimizer produce better code in some cases. I do see the benefit in that. If this was brought as an RFE, we might accept it, but given the other things the compiler team has to work on, and that it's just a situational performance boost, I imagine this would be very low priority. If the potential performance gains are a more immediate concern, I wouldn't wait around for this. Even if we chose to implement it, it'd still take a good while before it was released, as we'd work on more significant work first.
On the other hand, coding a GOBACK, which would be needed in every place the terminating program is called, is a less-good fix but can be done immediately.
Another possibility that might situationally work is to refactor the terminating subprogram into a copybook so it's PERFORMed instead of CALLed. Obviously that might not work in the EXEC CICS ABEND case we've been discussing (though again, the compiler team hasn't confirmed yet that there's ALWAYS an EXEC CICS ABEND problem as opposed to it making a difference in your particular program) but it would work for others.
I've seen many client programs that put their abend code in a paragraph, and that too makes it less likely the compiler team will implement a directive, as it wouldn't be of use for many of our clients.
------------------------------
Mike Chase
Lead Developer, watsonx Code Assistant For z Code Optimization Advice
Developer, Enterprise COBOL
mike.chase@ca.ibm.com
Original Message:
Sent: Mon November 17, 2025 08:47 AM
From: Jon Butler
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Denis,
I'm going to stick my nose in here and say BUGGER that. Code the RETURN for all subroutines. Period. Full Stop.
You want to code an Compiler Option rather than coding a RETURN? Do you test your code as you write it? COBOL and CICS have worked this way forever, so what were you doing last year or the year before?
I once had a programmer complain that his subroutine did not return the correct value. When we looked at his code we discovered he forgot the parameter list in the CALL. He then argued the subroutine should have notified him there was no parameter to return! A parameter to indicate there is no parameter?
Cheers,
------------------------------
Jon Butler
Original Message:
Sent: Sun November 16, 2025 02:45 PM
From: Denis FALLAI
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
PS :
@Mike:
The case of calling a subroutine to trigger the end of a process (among other things), and therefore a call without any return after the call, must be quite common in application processing.
We have subroutines dedicated to this type of processing, both in batch and CICS.
I think we should have a COBOL compilation directive to tell the compiler that there will be no return after the call (and the application processing must commit to this), so that it can do its optimization work as effectively as possible, without having to resort to coding tricks like adding GOBACK statements.
This directive could potentially implement an abend handling in the event that there is a return after the call (as, for example, I believe is the case when the process tries to continue after the last instruction in the source code).
------------------------------
Denis FALLAI
BPCE SI, BPCE group.
Original Message:
Sent: Sun November 02, 2025 02:27 PM
From: Denis FALLAI
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Hi Mike,
Please disregard my message about the external subprogram call intended to trigger an abend: it was just a digression to point out that the compiler cannot always know when there will be a break in the processing sequence. This could be a difficulty in inlining Sections/Paragraphs placed after the call instruction because the compiler might think they will be executed sequentially after the call. That's made things confusing, sorry.
My real concern is the inlining of Sections/Paragraphs called by PERFORM, which doesn't occur as expected (despite the OPTIMIZE > 1 and the INLINE options) in the presence of certain CICS commands:
- EXEC CICS RETURN (workaround solution to allow inlining of Sections/Paragraphs called by PERFORM statements placed after this CICS command: add a COBOL GOBACK instruction avec the EXEC CICS RETURN command)
- EXEC CICS HANDLE ABEND LABEL (no identified workaround solution to allow inlining of sections/paragraphs called by PERFORM statements placed after this CICS command)
Let's focus on these.
A case has been opened and it is currently being investigated by IBM.
I have provided two programs for the case to illustrate the problem:
- a program that does not use the EXEC CICS HANDLE ABEND LABEL command but only the EXEC CICS RETURN command
- a program that uses both the EXEC CICS HANDLE ABEND LABEL and EXEC CICS RETURN commands
Both programs are built on the same model, and this is the model that is applied to all our (new) COBOL / CICS programs:
- a program prologue that calls main sections using PERFORM
- an EXEC CICS RETURN command following this prologue
- the sections called by PERFORM, which in turn call other sections using PERFORM.
It seems to me that this is a classic and common construction in structured COBOL (not using GO TO instructions).
In the past, our COBOL CICS programs were produced by a code generator that used a linear code, with GO TO statements, either to return to the beginning of a loop or to skip blocks. The use of PERFORM remained relatively limited, and by design, the Sections/Paragraphs called by PERFORM were placed at the end of the source code. The lack of inlining of PERFORM statements was neither noticeable nor significant.
Thanks.
------------------------------
Denis FALLAI
BPCE SI, BPCE group.
Original Message:
Sent: Sun November 02, 2025 12:24 PM
From: Mike Chase
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Hi Denis,
I don't have the background developing COBOL applications so I won't comment on Jon's suggestion, but I'm confused as to what your actual problem is.
First, to be clear, there are two types of inlining that happen in Enterprise COBOL. We sometimes inline full programs into others; this is most often done for things like the artificial methods the compiler generates (for example, to initialize the WORKING-STORAGE or LOCAL STORAGE sections, or to calculate the address of variably-located data items whose position depends on one or more OCCURS DEPENDING ON clauses). We CAN inline COBOL programs into other programs, provided the programs are nested or possibly within the same source file; we definitely can't inline programs if they exist in different files, as the compiler only knows about one source file (not counting files referenced by COPY statements) at once.
The much more common form of inlining for COBOL, the form governed by the INLINE option and >INLINE directive, is inlining of paragraphs that are PERFORMed.
You mentioned subprograms, but in the rest of this thread, you've been talking about paragraphs and PERFORM inlining, so I'm not sure what case you're specifically talking about in your latest comment. Are you still referring to the fact that the compiler doesn't seem to do what you expect when EXEC CICS RETURN statements are used instead of GOBACK/STOP RUN statements? Wouldn't the solution be for the compiler to treat those as equivalent, as far as optimizations go?
That said, it's only with a proper investigation of specific programs and what the compiler does to them that we can be certain what's actually going on. You've certainly found a program that seems to break inlining, but there are other factors our algorithm considers that you might not have thought about. For one thing, the fact that paragraphs may flow linearly to the next paragraph and may also be PERFORMed isn't, in and of itself, a reason not to inline the paragraphs; I'm sure we DO inline paragraphs sometimes where there's flow to the next paragraph (though certainly a GOBACK would make it MORE likely we'd inline that paragraph since we know we won't have to have an inlined copy plus one to fall through.) The compiler team really needs to look more closely at your case to know what's going on; anything else, even from me at this point, is a bit speculative.
------------------------------
Mike Chase
Lead Developer, watsonx Code Assistant For z Code Optimization Advice
Developer, Enterprise COBOL
mike.chase@ca.ibm.com
Original Message:
Sent: Sat November 01, 2025 02:09 PM
From: Jon Butler
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Dennis,
If I understand your problem, you want an intentional ABEND, not one generated by the hardware.
Let me suggest that at the point in the subroutine you want to force an abend, you set a semaphore to pass back to the invoking program and issue a RETURN at that point. Of course, you could branch to an internal subroutine or paragraph to complete any final work you need to do, then issue the RETURN. You might include other parameters to help debug the problem that led you to think an abend was necessary.
The invoking program could then interrogate the semaphore and issue the ABEND. This could be used recursively if you need to go more than one level deep.
This is also a good time to think about why you want to issue an ABEND and design the system so it is not necessary. I've spent many years trying to convince programmers no to issue an intentional abend, but the answer is invariably..."It's easier"...easier for whom?
Cheers,
Original Message:
Sent: 11/1/2025 12:56:00 PM
From: Denis FALLAI
Subject: RE: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Hi Mike,
I agree that it's not the developer's responsibility to modify the source code to achieve the compiler's expected result regarding code optimization, and specifically the inlining of PERFORM statements.
However, there are cases where the compiler cannot make these decisions on its own. For example, a subprogram call that triggers an abend to terminate execution.
To manage this, we would need a way to tell the compiler that this code will be a sequence break, or a program exit.
Note that in my specific context, I'm developing a COBOL framework based on program skeletons and technical architecture copybooks.
For this reason, I do not have the option of positioning the problematic code (for inlining) at the end of the source code, which could be a way to manage the problem.
Thanks,
------------------------------
Denis FALLAI
BPCE SI, BPCE group.
Original Message:
Sent: Mon October 27, 2025 08:39 AM
From: Mike Chase
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
I don't know CICS enough to verify Denis' most recent solution.
I DO however recommend Enterprise COBOL users don't change their source code to work around issues in the optimizer. A Case has been opened; the compiler team needs time to address it and put out a PTF.
------------------------------
Mike Chase
Lead Developer, watsonx Code Assistant For z Code Optimization Advice
Developer, Enterprise COBOL
mike.chase@ca.ibm.com
Original Message:
Sent: Mon October 27, 2025 08:20 AM
From: Jon Butler
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Dennis,
You are on the right track. I never use HANDLE conditions, and as you have done, always check the EIB block Responses to see if something i ammis with an EXEC CICS command. In fact, in your case, your need to check inside the LINKED TO program for errors, as the test you have coded will only tell you if the LINK itself worked. It's quite possible the LINK worked fine, but the LINKED TO module had errors you don't see..
------------------------------
Jon Butler
Original Message:
Sent: Sun October 26, 2025 12:51 PM
From: Denis FALLAI
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Hi,
I managed to improve the inlining of PERFORM by replacing the HANDLE ABEND protection of a LINK by adding NOHANDLE RESP(xxxx) RESP2(yyyy) options.
Before :
SET NORMAL-TERMINATION TO FALSE
EXEC CICS PUSH HANDLE
EXEC CICS HANDLE ABEND LABEL (PROGRAM-HAS-ABENDED)
EXEC CICS LINK PROGRAM(PROGRAM)
SET NORMAL-TERMINATION TO TRUE.
PROGRAM-HAS-ABENDED.
IF NOT NORMAL-TERMINATION THEN
<do something>
END-IF
After :
SET NORMAL-TERMINATION TO FALSE
EXEC CICS LINK PROGRAM(PROGRAM) NOHANDLE RESP(RESP) RESP2(RESP2)
IF RESP = DFHRESP(NORMAL) THEN
SET NORMAL-TERMINATION TO TRUE
END-IF
IF NOT NORMAL-TERMINATION THEN
<do something>
END-IF
but I'm not sure that the NOHANDLE / RESP / RESP2 option intercepts abends in the called program and ultimately has the same behavior...
------------------------------
Denis FALLAI
BPCE SI, BPCE group.
Original Message:
Sent: Sun October 19, 2025 04:53 AM
From: Denis FALLAI
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Hi,
I discovered another case where PERFORM inlining is disabled: the presence of EXEC CICS HANDLE ABEND LABEL commands (and it must be the same with other EXEC CICS HANDLE commands that generate branching).
If I remove the EXEC CICS HANDLE LABEL commands from the source code, PERFORM inlining is re-enabled.
For the moment, I haven't found a workaround (adding GOBACK in the source code after the target of EXEC CICS HANDLE LABEL commands to force a break in sequence execution doesn't solve the problem).
We use two kinds of EXEC CICS HANDLE ABEND LABEL :
- a « global » handle abend label to catch any abend in the program.
This handle abend label is isolated in a paragraph that is PERFORMed from many point : start of program and after activating a « local » handle abend. The target routine of this handle abend will clean memory (QUEUE TS) and terminate the run by reemitting the abend.
- a « local » handle to protect an EXEC CICS LINK.
This handle abend is an « continue even if abend », activated before the EXEC CICS LINK to branch after it, (in sequence), and the « global » handle is reactivated after the LINK, (PERFORM to the paragraph containing the « global » handle abend label).
Note that EXEC CICS HANDLE are commands evaluated at runtime and not compilation directive evaluated at compilation time, (as EXEC SQL WHENEVER are).
Target of an EXEC CICS HANDLE can be considered as an alternate entry point in program, (and generate a SERVICE LABEL compilation directive).
Perhaps rejecting target of EXEC CICS HANDLE at end of source code would help in code optimisation but at time this is not compatible with our development framework.
Thanks.
------------------------------
Denis FALLAI
BPCE SI, BPCE group.
Original Message:
Sent: Fri October 17, 2025 02:27 PM
From: Denis FALLAI
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Hi,
I found the source of the problem, and it's indeed (indirectly) related to the fact that this is a CICS program:
* Since this is a CICS program, there is no GOBACK: the program exits with an EXEC CICS RETURN
* If I add a goback after the EXEC CICS RETURN (a goback that will never be executed), then the PERFORM inlining is performed as expected (at least more so than without GOBACK).
In fact, without GOBACK, the instructions will falsely appear as executed in sequence in addition to being executed by PERFORM.
In an optimized version for the same CICS program:
* 574 COBOL statements in Procedure Division, including 90 PERFORM instructions
* The complexity index is reduced, so the compiler runs faster and consumes less power.
* The load module size is reduced from 24kB to 13kB.
Thanks.
------------------------------
Denis FALLAI
BPCE SI, BPCE group.
Original Message:
Sent: Tue October 14, 2025 10:42 AM
From: Mike Chase
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Hi Denis,
Thank you for opening the Case. The optimizer team will take a look at this. We have both logging tools for the optimizer that aren't available to clients and an understanding of how the inlining of PERFORMed paragraphs and sections is supposed to be done, so I don't think there's a need for you to analyze further.
Thanks,
Mike
------------------------------
Mike Chase
Lead Developer, watsonx Code Assistant For z Code Optimization Advice
Developer, Enterprise COBOL
mike.chase@ca.ibm.com
Original Message:
Sent: Tue October 14, 2025 10:30 AM
From: Denis FALLAI
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Hi,
By removing the EXEC CICS statements and compiling without the CICS option, I see the same lack of PERFORM inlining.
So it's not the CICS compilation option that disables inlining, but the program structure.
Analysis in progress...
------------------------------
Denis FALLAI
BPCE SI, BPCE group.
Original Message:
Sent: Sun October 12, 2025 11:44 AM
From: Denis FALLAI
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Hi,
I opened a case under the reference TS020510459
Thanks.
------------------------------
Denis FALLAI
BPCE SI, BPCE group.
Original Message:
Sent: Tue October 07, 2025 03:53 PM
From: Mike Chase
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Simply using the CICS option vs. not using it shouldn't have any effect on which optimizations the compiler attempts. The presence of actual CICS calls in a program might have some effect - not in the sense of globally disabling any optimization, but causing optimizations to make different decisions in the presence of differences in the code. But no, I know of no reason why the CICS option would have any impact on the behaviour of paragraphs being inlined or of any of the other numerous optimizations we attempt. Most optimizations are situational, so we certainly can't conclude that NO optimizations are being run without further investigation.
I can't comment in any more detail without seeing the actual program(s) in question, along with compiler options, etc. Can you please open a Case?
------------------------------
Mike Chase
Lead Developer, watsonx Code Assistant For z Code Optimization Advice
Developer, Enterprise COBOL
mike.chase@ca.ibm.com
Original Message:
Sent: Mon October 06, 2025 04:16 PM
From: Denis FALLAI
Subject: IBM Enterprise COBOL V6+ - Disabling optimizations when the CICS option is active
Hi,
I note that the IBM Enterprise COBOL compiler's binary code optimizations seem to be completely disabled when the CICS compiler option is enabled:
- no inlining, despite the INLINE option
- almost identical code in OPTIMIZE(0), OPTIMIZE(1), OPTIMIZE(2) modes
The only effect of the OPTIMIZE(1) / OPTIMIZE(2) options is the removal of unreachable code.
OPTIMIZE(2) reorders certain MOVE / INITIALIZE instructions according to memory addresses.
The CICS options used are:
- CICS("APOST")
- CICS("COBOL3")
- CICS("SP")
Without the CICS compiler option, and same other compilation options, optimizations are indeed enabled by the INLINE and OPTIMIZE(1) or OPTIMIZE(2) options.
I tested with the compiler versions available to me:
- COBOL V6R4 'P230615'
- COBOL V6R4 'P240416'
- COBOL V6R4 'P241216'
- COBOL V6R5 'P250507'
No conflicts or restrictions are indicated regarding the use of the CICS compilation option in the reference documentation...
Is this an oversight?
Is this a compiler flaw?
Do you see the same thing? (Compile with the CICS options, OPTIMIZE(1|2), INLINE, and LIST to get binary code expansion).
Thanks.
------------------------------
Denis FALLAI
BPCE SI, BPCE group.
------------------------------