In this code (retired 25 years ago), you can find the display mode. But is
this the solution to the wrong problem?
I've found that refactoring an application to use *DS4 has immediate user
productivity benefits and often simplifies the programmer's job. Some will
scoff and wave the web-enabled flag but moving to 132 costs nothing out of
pocket (unless you're still using tubes) and it serves as preparation for
eventual web enablement: the 4.8:1 aspect ratio of *DS4 is much "webbier"
than the 3.33:1 in *DS3. As you're laying out a *DS4 screen, you're
creating something that will be much better-looking when it's run through a
web enablement tool. *DS3 (and its sibling CAPITAL FIELD LABELS) *looks*
old-fashioned: it shrieks "legacy" and is digital fingernails on an
electronic chalkboard.
Besides, an API solution like this is just more technical debt. Figuring
out how to mix *DS3 and *DS4 is, IMO, the wrong problem to solve (unless
you're stuck with a 3rd party app).
As long as I'm on the soapbox, let me put in a good word for programming
standards: they cost nothing and pay off forever. I was able to convert
several thousand display files *DS3 to *DS4 in a day because I used a
standard layout for display file headings and help screens. After my tool
finished the source conversion, my 50-character title, system time, and
program description were repositioned (but this step was the tip of the
iceberg--it took a week to optimize the high-impact applications' screens
and it was fun).
Have at it with this code but I encourage you to consider a system-wide
commitment to *DS4.
H/title AAR960-Find display mode
H/copy qcpysrc,xxr000
H bnddir('QSNAPI')
Denv0 s 10i 0
Dmode2427 s 1
DGetMode pr extproc('QsnRtvMod')
D mode 1
D handle 10i 0
D error 116
Dqusec ds
D qusbprv 1 4b 0 inz(116)
D qusbavl 5 8b 0 inz(0)
D qusmsgid 9 15
D $unused01 16 16
D quserror 17 116
C callp GetMode(mode2427:Env0:qusec)
C eval *inlr = *on
C *entry plist
C parm mode2427
One screen answers nearly every shipment status and revenue accounting
question--you can't do this easily with 24x80.
[image: image.png]
On Tue, Aug 26, 2025 at 8:39 AM Justin Taylor <jtaylor.0ab@xxxxxxxxx> wrote:
I have a 5250 program that calls a second program that displays a 5250
window. I want the window from the second program to overlay the screen
from the first program. By default, I get the window on top of an
otherwise black screen. The window program is commonly used and works fine
elsewhere, so I'm convinced the issue is with the first program.
I've done this in the past, and I recall there was some DDS trick to
accomplish this. Can someone please refresh my memory?
Thanks
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.
Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.
midrange.com
