TechTip: RSTDSP(*YES/*NO)

[MCWebsite.Staff]

** This thread discusses the article: TechTip: RSTDSP(*YES/*NO) **
** This thread discusses the Content article: TechTip: RSTDSP(*YES/*NO) **
0

[David Abramowitz]

TechTip: RSTDSP(*YES/*NO)

** This thread discusses the article: TechTip: RSTDSP(*YES/*NO) **
A very good explanation of this parameter. It should be pointed out that S/36 displays, and possibly other displays that use the INVITE keyword, should leave RSTDSP set to *NO. Dave

[Guest.Visitor]

TechTip: RSTDSP(*YES/*NO)

** This thread discusses the article: TechTip: RSTDSP(*YES/*NO) **
I would caution against changing the CRTDSPF command to always compile dspfs with RSTDSP(*YES). Most dspfs don't have a problem with RSTDSP(*NO). Those that do should be caught in testing and changed. A problem with this approach is that the next programmer may not realize the file needs to be compiled a certain way. Even if documented in the source, it can be missed. But, then, it should come up in the testing. It's a nice tip, though. It may be just an opinion, but, it's MY opinion.

[htemikecad]

TechTip: RSTDSP(*YES/*NO)

** This thread discusses the article: TechTip: RSTDSP(*YES/*NO) **
The one exception to making RSTDSP(*yes) for all display files is if the display file only contains Windows or partial screens using SLNO. If you use a common program to provide table lookups or selections and this program's display file is only a window, what will happen is the first time you display the window, all is okay. Everytime after the first time, the background around the window will change to the way it looked on the first call. It can be quite unnerving to a user to see data they just typed change then change back when the window is removed.

[Guest.Visitor]

TechTip: RSTDSP(*YES/*NO)

** This thread discusses the article: TechTip: RSTDSP(*YES/*NO) **
You mentioned that the next programmer would not realize that the display file has to be compiled with "RSTDSP (*YES)", and then he or she would miss it. There is a command called "Change Command Default (CHGCMDDFT)" which could change that default from "NO" to "YES". So everyone would use the "YES" as the default. No need to change that every time the display file is compiling. Romulus.

[B.Bardini]

TechTip: RSTDSP(*YES/*NO)

** This thread discusses the article: TechTip: RSTDSP(*YES/*NO) **
I'm thinking that the only time RSTDSP *YES is necessary, is when the PUTOVR keyword is active. Back in my early days on the System/38, I can remember John Sears, et al, telling us to use the PUTOVR (record format level) keyword to minimize the amount of line traffic associated with display files. However, we failed to properly apply the OVRDTA and the OVRATR keywords on the fields in the display format, and if another program was called, when we returned from the called program, part of the display was gone! To fix this, we then used the RSTDSP *YES, which did work. But then we learned the RSTDSP *YES keyword negated any gain we got with the PUTOVR keyword. When we finally got the PUTOVR and OVRDTA/OVRATR keywords working correctly, we no longer needed the RSTDSP *YES. And on the System/38, you could actually see a difference with the PUTOVER/OVRDTA/OVRATR keywords. Without those keywords, a screen would actually "blink" when some key was hit that caused the program to loop on the EXFMT, whether any actual work was done or not. But with the keywords, the screen was super-smooth, no "blink". If you were just looping on the EXMFT, the only thing that you could see change was the time. It was actually pretty neat. On the AS/400, many of us have abandoned, I think, the PUTOVER/OVRDTA/OVRATR keywords, because the machine is plenty fast. Of course, I might just have "Old Timers Disease", and not remember it correctly. Bruce

[David Abramowitz]

TechTip: RSTDSP(*YES/*NO)

** This thread discusses the article: TechTip: RSTDSP(*YES/*NO) **
If you code for 5250 windows, you will probably have to use either the RSTDSP(*YES) parameter, or the USRDSPMGT DDS keyword. Dave