Re: Window in 2nd pgm?

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 <[email protected]> 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: [email protected]
> To subscribe, unsubscribe, or change list options,
> visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
> or email: [email protected]
> Before posting, please take a moment to review the archives
> at https://archive.midrange.com/rpg400-l.
>
> Please contact [email protected] for any subscription related
> questions.
>
>
-- 
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: [email protected]
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: [email protected]
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact [email protected] for any subscription related questions.