TESTCASE, Re: This is strange: an RNQ1011 for no apparent reason -- apparent bug in runtime and/or compiler

All right, here's the test case:

RPG program TEST19NV12:

FTEST19NV12IF E K DISK C *ENTRY PLIST C PARM PWIN 2 C PWIN DSPLY C ENTITYR DSPLY C SETON LR
C *INZSR BEGSR C PWIN CHAIN TEST19NV12 C ENDSR

And the file it accesses (also called TEST19NV12):

A UNIQUE A R FOO A ENTITY 2A COLHDG('Entity') A ENTITYR 2A COLHDG('Referenced Entity') A K ENTITY A K ENTITYR

Compile both (under the same conditions I did), don't bother to put any records into the file, and when you call it with any arbitrary record key (note that it's a partial key, as in the real program, but THAT shouldn't matter)

CALL TEST19NV12 '01'

Undefined record type is found in file TEST19NV12. Undefined record type is found in file TEST19NV12 (C G D F). ? C Undefined record type is found in file TEST19NV12 (C G D F). ? C Application error. RNX1011 unmonitored by TEST19NV12 at statement
0000000004, instruction X'0000'.

And if you dump it, the INFDS dump looks like:

INFDS FILE FEEDBACK File . . . . . . . . . . . . . . . . . : TEST19NV File Open . . . . . . . . . . . . . . : YES File at EOF . . . . . . . . . . . . . : NO File Status . . . . . . . . . . . . . : 01011 Undefined record type is found in file (C G D F). File Operation . . . . . . . . . . . . : CHAINF File Routine . . . . . . . . . . . . . : *INZSR Statement Number . . . . . . . . . . . : 00000011 Record Name . . . . . . . . . . . . . : Message Identifier . . . . . . . . . . : CPF5006 Record not found in file .

This was done on a V4R4 system, using the V4R2 compiler (long story). And I know, from experience, that if I take the file and program to a V6 box and run it there (re-encapsulating, of course, but not recompiling), the same runtime error occurs.

But if I *compile* it *from source* on the V6 box, it works just fine. That tells me that IBM has already fixed the problem from the compiler end, that a PMR would be pointless, and that if I want to continue using an antiquated compiler (in order to maintain a higher level of backward compatibility than anybody in the real world is ever likely to need), then I need to deal with it myself (which would still be the case even if the problem still existed in a current compiler, and I *did* file a PMR; we're not in the habit of requiring customers to install obscure PTFs for things we can deal with ourselves).

Like Gus said, THE HATCH JUST BLEW!

--
JHHL