Jordi Bornay
New User
Joined: 19 Oct 2022
Posts: 1
Location: Spain
|
|
|
|
hello all,
The development team at a client has asked me for a favor, I have investigated but I don't see any other solution than the hardest.
They exposed the following to me: they have often had problems where uninitialized fields have been used (application programs).
For example:
WORKING-STORAGE SECTION.
01 FIRST-FLAG PIC X.
PROCEDURE DIVISION.
IF FIRST-FLAG EQUAL SPACE
MOVE ‘N’ to FIRST-FLAG
PERFORM SOMETHING.
The IBM manual clearly states that data items without a value clause have an “unpredictable” value.
This has been the case for IBM Cobol since Cobol was first introduced. Programmers always initialized fields prior to use and/or used a VALUE clause.
The customer have unfortunately found several cases where programmers have not followed IBM guidelines. To overcome this the customer have amended programs (manual work) to either use a VALUE clause, MOVE SPACES to the item or use the INITIALIZE statement at the beginning of the PROCEDURE DIVISION.
In almost all cases they found this type of problem on conversion of IDMS DC programs to DB2 CICS. This got us thinking of how we could avoid having to identify and fix programs manually.
What I found is that there is an option in the Language Environment that can set a default for ALL uninitialized fields. This is the STORAGE option.
Checking with they we found that the default at LPAR has been changed (for CICS only – not IDMS DC) to initialize fields to low-values via the STORAGE(00,NONE,NONE,0) setting in the CEECOPT IPL parameter.
We tested this at the customer and it created too many regressions. What we found is that by using STORAGE(40,NONE,NONE,0) to initialize fields to spaces, we had no regressions and in fact improved some of our existing scenarios (where we had not yet identified the cause of differences).
Discussions here at the customer gave us the thought that IDMS DC (not CICS) has its own default that initializes fields to spaces. I can’t confirm this (and I'm not an IDMS specialist either). There is nothing in the IDMS manuals about it. I think, it is, however, a good hypothesis. The fact that programs work on the IDMS reference environment and failed on our (before using STORAGE) CICS environment, seems to prove the case.
If any of you have been in a similar situation, can confirm that they DO rely on IDMS DC uninitialized fields having a value of spaces, it would be appreciated.
having said that, So what to do:
1 Continue to manually fix programs by using VALUE clause, MOVE SPACE or INITIALIZE.
2 Set the default STORAGE option for CICS to X’40 (spaces).
The problem with using “1” above is that it is time consuming and only fixes programs that are in our test case and that go through the erroneous code. It could be that when the new system is in production, other programs (or not tested code) could fail.
To use option 2 above, we could run converted IDMS applications in a separate CICS region and only set the default STORAGE setting for that region to x’40’. This is possible because the STORAGE option can be set just for a specific CICS at run time. This is done by adding the following PARM statement to the CICS exec:
PARM='/STORAGE(40,NONE,NONE,00)''
--> www.ibm.com/docs/en/zos/2.3.0?topic=ulero-storage#clstora
Does anyone have any ideas that shed some light on this issue? I appreciate it.
I would add that my knowledge of OS and CICS is surely inferior to yours. |
|
