RE: Negative response code... RNX1251

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

Hi John - I hear you - sounds like a fairly unsolvable mystery - I 
went back to V3R2 docs (1995) and find that the default for RSTDSP 
was *NO back then - makes sense, because it does affect performance a bit.

There are a set of libraries QIN* that keep changed system objects - 
I don't remember whether commands end up there, SBSDs and JOBDs do. I 
also don't remember whether the results of CHGCMDDFT show up in QHST, 
but I doubt it, and you prolly don't have the history anyway. I think 
pertinent messages are in the realm of CPD62xx, CPF62xx, and CPI62XX.

I'm not sure of the default behavior coming our of SDA.

Sigh!

Regards
Vern

At 04:14 PM 4/26/2006, you wrote:

> 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:

-snip-