Re: 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 (and if it rewrapped the first time,
maybe this one won't):

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

PS: An (E) extender on the CHAIN doesn't catch it, but indicators do.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.