RE: Negative response code... RNX1251 -- MIDRANGE-L

Hi John - I hear you - sounds like a fairly unsolvable mystery - Iwent back to V3R2 docs (1995) and find that the default for RSTDSPwas *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. Ialso 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 thinkpertinent 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-