We have an application that rarely bombs with RNX1251 (major return code 80
and minor return code C0). ("rarely" = once per week with the program
being called hundreds of times daily.) Several of us have interrogated the
dumps, and have never found any non-displayable characters (x'00' - x'3F' &
x'FF'). Today, I went so far as to write an RPG program in which I
copied/pasted the hex representation (i.e., 'C4C8C5C8D9C5D9404040'X) of all
of the screen's variables from the dump and used the CVTCH MI function to
convert them to character:

HexVal = 'C4C8C5C8D9C5D9404040';
FromHex( USERNAME : HexVal : %len( HexVal ));
(where FromHex is the prototype used to call CVTCH.)

After all of the screen variables are "filled", an EXFMT on the record
format is executed. When I call this test program, it displays the record
format with no errors, with all the data as we expected it.

The display file has only one record format and specifies DSPSIZ(27 132
*DS4), just like all of our application display files. There is an OVERLAY
keyword in the record format. Other than that, it's all run of the mill

The description for RNX1251 says that "If the major return code is 80 then
a system or file error occurred and programmer action is required to fix
the problem." It gives no indication of what minor return code C0 means.

Is it possible that splitting the EXFMT into WRITE and READ operations
might help? (A question for Barbara?) If for no other reason, I'd encase
each of them in a MONITOR block. Maybe retry 3 times to see if it resolves

This thread ...


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

This mailing list archive is Copyright 1997-2020 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].