RE: Hair-saving tip: Use RSTDSP(*YES)

In the way oldie days (before CHGCMDDFT), one of the first things I learned on a System/38 was how to use Display/Alter/Dump(?) to change that very default for CRTDSPF.

So, even in "yestersday's world" it may not have made sense - at least in our environment at the time.

Fun times......


Roger Harman
COMMON Certified Application Developer – ILE RPG on IBM i on Power
OCEAN User Group
<http://www.ocean400.org>






----------------------------------------

Subject: Re: Hair-saving tip: Use RSTDSP(*YES)
From: michaelrtr@xxxxxxxxx
Date: Wed, 8 Apr 2015 16:58:36 -0400
To: midrange-l@xxxxxxxxxxxx

CHGCMDDFT?

Sent from my iPhone

On Apr 8, 2015, at 4:36 PM, Booth Martin <booth@xxxxxxxxxxxx> wrote:

My question has been "In today's world, is RSTDSP(*NO) still useful, ever, in any real world sense? Why isn't the default *YES?"

On 4/8/2015 2:45 PM, John Yeung wrote:
I can't believe how much time I just spent trying to figure out why a
seemingly small change to an interactive program totally screwed it
up. Essentially, my situation was the same as this:

[OPM -> ILE -> OPM and RSTDSP]
http://archive.midrange.com/midrange-l/201503/msg00106.html

But I didn't recognize it. In the linked thread, Joe Pluta was
talking about adding an ILE program which displays a pop-up window.
In my case, I was adding an RPG IV program, but it's full-screen and
it's not what I think of as ILE, because it's a standalone bound
program, called in typical OPM fashion using CALL and a series of PARM
statements.

And the calling program was itself also a standalone bound RPG IV
program. So both programs involved are of type "ILE" according to
DSPPGM, or you could say both are "conceptually" OPM programs.

And nothing was bombing. The calling program sometimes continued to
work fine and sometime had its display really screwed up upon
returning from the called program (depending on the user actions taken
in the called program). But even when the display was screwed up, the
function keys still worked, and eventually you could get yourself back
to a normal-looking state.

The punch line is of course that I finally thought to try recompiling
the (caller's) display file with RSTDSP(*YES), and then everything
magically worked.

Does anyone know if it is even theoretically possible to write an
application which works correctly when one or more of the display
files are created with RSTDSP(*NO), but then *breaks* when you
recompile all the display files to RSTDSP(*YES)?

John Y.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.