× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.