A little background:
In v5.4 CL doesn't have a special value of *NULL or any way of representing a null value as a literal. (This was for many years one of my bones to pick with our gracious lord Ib'm, but I digress.) To get around this I created a *PTR field named &NULLPTR and I never changed it so that it always contained a null pointer. This way I could compare pointer fields to &NULLPTR to see if they were null.
A CL module of mine contains a &NULLPTR *PTR field. It was compiled last year under v5.4 and hard-linked into a couple of programs. The module has worked fine in both v5.4 and v7.1.
Recently I had to change a couple of modules in one program, so I recompile them. This program also used the CL module, but that module didn't change. When I created the program I simply linked to the existing module object that was still stored in the source library that it was compiled into last year.
The problem:
For some reason when this same old hard-linked CL module is called within this re-created program, the &NULLPTR field isn't null anymore. It now contains a pointer, or at least it contains some kind of errant data. This causes the program to bomb out because when it tests for a null pointer the outcome of course turns out false when it should be true.
If I create the program to run under v5.4 it bombs on v7.1 but not on v5.4. If I re-compile the CL module (to run under v5.4 or v7.1) then the problem goes away almost completely (that is, until you save and restore it to another system, then it start bombing again).
The issue I have is that there are other modules compiled under v5.4 with &NULLPTR *PTR fields that might be re-linked into new programs in the future. I can't be sure the same thing isn't going to happen to them.
I have sent prayers and made sacrifices to the patron saints of support that our lord Ib'm might provide insight as to what is going on. If you're having the same issue in your parish then please say a prayer for me and post a comment and let me know what you think.
Update (10/25/2010): Our lord I'bm issued PTFs for this problem: v7.1: SI41596, v6.1: SI41595, and v5.4: SI41594.
Subscribe to:
Post Comments (Atom)
Posts
This issue has just gotten more complicated. As you know when I recompiled that CL module, and hard linked into the failing program, it resolved the issue, or so I thought.
ReplyDeleteThe system on which I did the CRTPGM hasn't experienced it again. However after I installed the fixed program to another system using SAVRSTOBJ, it promptly started failing with the same problem. Just another bit of evidence the patron saints of support for our Lord Ib'm can use in trying to figure this one out.
I have since bitten the bullet and changed the program to use the CEETSTA API to test the parameter, instead of comparing the address of the parameter to &NULLPTR. When we figure out why this is happening I'll change it back.
I can't help but editorialize that this wouldn't be that much of a problem if there was a way in CL to initialize a pointer to null like we can in RPG and C -OR- if there was a special value or macro to use instead, like *NULL in RPG and NULL in C.
IBM just created APAR SE45175 which will be closed as P.E. (Programming Error).
ReplyDelete