Re: *DSPF question.

Dean Asmussen (DAsmussen@aol.com) wrote:

>> 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.
>
>Bravo Dave!  Good strategy...

Thanks, Dean, unless there's an ironic overtone there I failed to
detect. :-)  BTW that's another reason I prefer moving objects into
production rather than compiling them. You don't have to jump through
hoops to make sure all the compile time options are the same as they
were in testing.

How about the following strategy? On every transaction always build the
full screen. Use PUTOVR with OVRATR and OVRDTA to avoid sending data
that's already on the screen. Condition the PUTOVR on the off setting of
an indicator. Use the SETOF keyword to turn the indicator off
automatically whenever the final format of the display is written. In
your programs whenever you return from a lower level function that
writes formats from a different display file, set the indicator on.
PUTOVR will now be automatically in effect unless the screen needs
restoring.

This should allow you to use RSTDSP(*NO) with all your display files and
USRRSTDSP with all your windows. Does anyone see any snags with this
approach?

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