Re: *DSPF question.

Booth Martin (boothm@earth.goddard.edu) wrote:

>Should this answer  *always*  be *YES?   I know that *NO messes up windows
>real bad, but I have not dared do it everywhere everytime because it's
>purpose for existing must be real.

Booth,

No, I think it's a mistake to use RSTDSP(*YES) everywhere, although it
does guarantee that you won't lose data from the screen in certain
situations. IBM obviously think so or they wouldn't have made *NO the
default. Using RSTDSP(*YES) causes the system to save an image of the
screen whenever the display file is suspended, and restore it when the
display file is re-activated. This save/restore is a significant
overhead so you will want to avoid it if you can.

The display file is suspended when a record from another display file is
written to the same device, and restored when a record from the original
display file is written again. Generally you should use RSTPDSP(*YES)
when you call a program that uses displays from  a different display
file and on returning you write a format containing one of the following
keywords.

ERRMSG
ERRMSGID
OVERLAY
PUTOVR
PUTRETAIN
CLRL

If your application always recreates the whole screen after calling a
function that displays another screen it's best to use RSTDSP(*NO), both
to improve performance and to avoid a flash that can occur when the
screen is restored.

>Additionally, is there a way to  change the default from *NO to *YES?

The default for any command can be changed. Whenever you do this it's
good practice to make a copy of the command in a non-IBM library (use
CRTDUPOBJ). This library should be above QSYS in your system library
list and public access to it should be *USE. You can then use the
command CHGCMDDFT CMD(CRTDSPF) NEWDFT('rstdsp(*yes)') to change the
default for the copy.

Personally I usually just compile everything with RSTDSP(*NO) and then
use program testing to discover the places where I need RSTDSP(*YES). If
you test properly it'll soon become apparent. You can change the RSTDSP
value of a display file without recreating it, incidentally; use the
CHGDSPF command.

>
>In <970725235128_582609484@emout03.mail.aol.com>, on 07/25/97
>   at 11:51 PM, DAsmussen@aol.com said:
>
># and the compile-time keyword RSTDSPLY (should be *YES) --
>#or maybe I reversed those...

Dave Kahn - TCO, Tengiz, Kazakstan
=========

e-mail:  kahn@tengizchevroil.com    (until August 5th)
         dkahn@cix.compulink.co.uk  (from  August 6th)

Note new e-mail address in Kazakstan
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *