RE: Negative response code... RNX1251

To John - the negative response code is exactly what happens when you put up a 
screen, then put another over it, and then come back to the first one. I'm not 
sure of the exact details, but that is working as intended. I think stuff gets 
left from the second screen or something that messes up the first one. The 
RSTDSP parameter takes care of it. I agree with Tim - get the working one 
restored to a different library, maybe, and do a DSPFD on it and see what the 
setting was. BTW, it might not have been done in the compile (14 in PDM 
executes CRTDSPF anyway), this can also be changed with CHGDSPF, so it might 
have happened after a compile when the error appeared the first time (lots of 
assumptions and guesses behind that statement!).

At any rate, glad it is working - I really don't think the system is at fault 
here - this behavior has been around forever. Here is a bit from the Software 
Knowledge Base:

What Can Cause a MSGCPF5192 Message to be Generated? 

In general, most of us may think of message CPF5192 as a defect. There is one 
user error that generates this message. The situation is as follows:

The user has two programs with two display files. The first display file is 
displayed and everything works fine. The second display file is displayed and 
everything is fine. Upon returning to the first display filem message CPF5192 
is issued. This is because the first display file did not have RSTDSP(*YES) 
specified and was using one of the following keywords: CLRL, OVERLAY, PUTOVR, 
PUTRETAIN, ERRMSG, or ERRMSGID. This is documented in the Application Display 
Programming Topic: Restoring the Display . The manual reads:

The RSTDSP(*YES) parameter must be specified for the following keywords. If the 
parameter is not specified, data on the display can be lost if the file is 
suspended. 


Note the words can be . There are times when this works; however, they are not 
documented. RSTDSP(*YES) must be specified.

There is more than one situation that causes the error. However, when you 
return to the first display if you write a record format that has input capable 
fields in it and try to write another format above that record format, you get 
this error (only if you have one of the above 6 keywords and have not specified 
RSTDSP(*YES)).

HTH
Vern

-------------- Original message -------------- 
From: "Hatzenbeler, Tim" <thatzenbeler@xxxxxxxxxxxxx> 

> Did you restore your old display file, and see what the rstdsp value was set 
> to in the previous working version of this file? 
> 
> Just wondering? 
> 
> 
> -----Original Message----- 
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John Wallroff 
> Sent: Tuesday, April 25, 2006 1:01 PM 
> To: Midrange Systems Technical Discussion 
> Subject: RE: Negative response code... RNX1251 
> 
> It's not a data integrity problem. The screen is simply for the most 
> part an entry screen and all the fields are blank when you go into it. 
> It's used to collect data to run a report. I know it's not a data 
> problem because I could go into it in Production without a problem until 
> I simply recompiled the old, unchanged source again then the error 
> started happening there too. 
> 
> It's something to do with the system, either a parm was added or changed 
> on the CRTDSPF or I don't know what. Like I said, I normally simply 
> compile our display files on the way out of SDA without changing any 
> parms. 
> 
> I was given the tip to create the DSPF with the CRTDSPF command and to 
> change the RSTDSP parm to *YES from it's default of *no. That cause the 
> error to go away but I'm thinking that's just a work around and I would 
> like to know what is up with the system. 
> 
> 
> 
> -----Original Message----- 
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Luke Dalton 
> Sent: Monday, April 24, 2006 3:16 PM 
> To: 'Midrange Systems Technical Discussion' 
> Subject: RE: Negative response code... RNX1251 
> 
> Sounds more like a data integrity problem to me. Are you sure you're not 
> sending invalid data (i.e., something below hex 40) to a display field? 
> 
> -----Original Message----- 
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John Wallroff 
> Sent: Monday, April 24, 2006 3:01 PM 
> To: Midrange Systems Technical Discussion 
> Subject: Negative response code... RNX1251 
> 
> I have a very frustrating problem. I am working on a display file that 
> we have had for several years. This display file is now coming up with 
> these errors when it is displayed, another display file is display and 
> this display file is displayed for a 2nd time... 
> 
> 
> 
> Data sent to device FLJOHN1 not valid. Negative response code is 
> 
> 10050126. 
> 
> Permanent I/O error occurred in file IABS423. 
> 
> Function check. RNX1251 unmonitored by IABR423 at statement 0000000797, 
> 
> instruction X'0000'. 
> 
> Permanent I/O error occurred in file IABS423 (C G D F). 
> 
> Permanent I/O error occurred in file IABS423 (C G D F). 
> 
> 
> 
> We have 2 partitions on our iSeries, a Dev side and a Production side. 
> I was making some changes to this display file on the Dev Box and I 
> started getting this error while testing the changes. Well, long story 
> short, I moved the old source files from Production onto the Dev box to 
> try to figure out where the problem really was. I compiled the original 
> display file and it's came up with the same error when I ran it. The 
> production box was working so to test if it was some type of 
> configuration difference between the Production box and the Development 
> box I simply recompiled the existing source on the Production box, now 
> it's coming up with the error. Keep in mind, nothing has changed on the 
> production box other then an old existing Display file was recompiled. 
> 
> 
> 
> Do any of you out there have any idea what the heck is going on? Is 
> there some kind of PTF that I'm missing that addresses this? This 
> Display file has been around and has been used for a long time. I 
> personally made a change to it 4 years ago and it's always worked. On 
> the Production box nothing has changed other then recompiling the source 
> so I don't think there is a problem with the source or RPGLE program 
> that runs it. My gut feeling is that there is a system issue. Doing a 
> Google search on the error RNX1251 even brought up an issue with V5R2 
> and this error and showed a PTF. We are on V5R3 and are pretty up to 
> date other then I've yet to load the latest CUM set. I plan on doing 
> that this week on our Dev box and if everything looks good on the 
> Production box this weekend. 
> 
> 
> 
> Thank you very much for your help in advanced. 
> 
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
> list 
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx 
> To subscribe, unsubscribe, or change list options, 
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l 
> or email: MIDRANGE-L-request@xxxxxxxxxxxx 
> Before posting, please take a moment to review the archives 
> at http://archive.midrange.com/midrange-l. 
> 
> 
> 
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing 
> list 
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx 
> To subscribe, unsubscribe, or change list options, 
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l 
> or email: MIDRANGE-L-request@xxxxxxxxxxxx 
> Before posting, please take a moment to review the archives 
> at http://archive.midrange.com/midrange-l. 
> 
> 
> 
> 
> 
> NOTE: This electronic message and attachment(s), if any, contains 
> information which is intended solely for the designated recipient(s). 
> Unauthorized disclosure, copying, distribution, or other use of the contents 
> of this message or attachment(s), in whole or in part, is prohibited without 
> the express authorization of the sender of this message. 
> 
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list 
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx 
> To subscribe, unsubscribe, or change list options, 
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l 
> or email: MIDRANGE-L-request@xxxxxxxxxxxx 
> Before posting, please take a moment to review the archives 
> at http://archive.midrange.com/midrange-l. 
> 
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list 
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx 
> To subscribe, unsubscribe, or change list options, 
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l 
> or email: MIDRANGE-L-request@xxxxxxxxxxxx 
> Before posting, please take a moment to review the archives 
> at http://archive.midrange.com/midrange-l. 
>