CICS PL/I compiler issue

Problem description from Developer:

"Error in CICS PL/I compile"
DFHDUMMY are a variable that the integrated CICS-preprocessor add to the program source.
The declare of DFHDUMMY as STATIC, trigger a warning message in all EXEC CICS statements,
where the translator add DFHDUMMY.

We expect the CICS translator to generate valid and error-free PLI-code.
We use Enterprise PL/I for z/OS V5.R3.M0 (Built:20191127)
Test made with CICS 5.2 and CICS 5.3 compile libraries with same result.


We are well aware, that the CICS programs work as expected, no matter the definition of DFHDUMMY.
The problem are the IBM2671I warnings generated by CICS-preprocess generated code with DFHDUMMY, do hide or overshadow an IBM2671I from the application code, which probably should be changed.
For the same reason, is not a solution to change compile option NONASSIGNABLE.
Many projects treat warnings as seriously as errors (and the rest should do so) and put a lot of effort in program in such a way, that no warnings are the target (Information kept as low as possible).
Old programs (we have many +25 years old) do contain a lot of messages (+100), partly because the compiler were not able to produce when the program were new, partly due slobby programming. Maintain such a program are already a pain and spending time on code, you cannot change anyhow, are both frustrating and waste of time.
This leads pretty fast to the conclusion, that IBM2671I always are an ok messages, which is not the case.
We expect the CICS and SQL preprocessors do generate not only valid code, but also code without “false positive” messages.


Developer comments after 2nd test.
I am sorry that I had not noticed the IBM2671I messages that origin from my code.

On the other hand, that do prove my point: Too many messages you cannot do anything with, make you not notice the important ones.

Changing compiler option from NONASSIGNABLE to ASSIGNABLE is not an option because we want to see this message, and fix it when the application programmer usestatic as variable.

Before PLI 5, then static init (‘value') definition came closest to a named literal, but you had to rely on the programmer not changing the content.

When programmers work on both batch and CICS programs, they sometimes forget the difference between static and automatic storage.

I have done the test you requested and made these 3 compile listings:

XX05100A – original, probably equal to the one you already have.

XX05100B – with compile option DEFAULT(ASGN)

XX05100C – with code changes to avoid message IBM2671I.

Depending of the use in the programs, the code can be changed in two ways, to avoid the message, IE.:

DCL MAPSET CHAR (8) STATIC INIT ('XX00090'); changed to:

DCL MAPSET CHAR (8) VALUE ('XX00090');

DCL SPACES CHAR (80) STATIC INIT (' '); Changed to:

DCL SPACES CHAR (80) STATIC INIT (' ') ASSIGNABLE;

It was an easy fix, but the message did prove its worth, because I have to consider two statements a little further.

They work, but should be written in a more robust way.

The use of VALUE keyword are the recommended and most efficient way to specify named literals, but I tend to believe the option ASSIGNABLE it is the best solution for DFHDUMMY.