RE: Negative response code... RNX1251

I have been a programmer here for over 9 years.  The screen that has the
problem has been here longer then I have. We have literally hundreds of
programs that work the same way.  Neither I nor anyone else here has
ever seen that error and none of us have ever had to change the RSTDSP
parm.  In fact none of us generally use the option 14-CRTDSPF command,
we normally have been use to using option 17-Change using SDA and upon
exiting SDA compiling the display file.  Even though I am using WDSCi
and Code to work on my display files I still compile them this way out
of habit.  There is no way that I can figure out to even get to the
RSTDSP parm from the "Save DDS - Create Display file" screen that you
get upon exiting SDA.

I've looked around and our existing display file objects have RSTDSP set
to *YES.  I went ahead and asked all the programmers if anyone had
happened to change the default on the CRTDSPF parm RSTDSP to *NO just to
be sure and of course no one has but the default on it is *NO never the
less and appears to have always been.

Does the "Save DDS - Create Display file" when exiting SDA use the
CRTDSPF command?

I understand your reply Vern but I'm pretty sure something has change in
the system behavior somehow at least on our system and I'd like to know
what.

John.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
vhamberg@xxxxxxxxxxx
Sent: Tuesday, April 25, 2006 4:10 PM
To: Midrange Systems Technical Discussion
Subject: 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. 
>