Thanks for posting your results.
Paul
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of James Lampert
Sent: Monday, November 19, 2012 11:46 AM
To: RPG programming on the IBM i / System i
Subject: 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.
midrange.com
