If we think back to tubes (CRT's), the original devices were *DS3 (3180 and
3277 came along later IIRC). I'd guess each CRT had a controller to manage
the screen, create characters, etc. and everybody defaulted to 24x80,
including the 3270 crowd (some of the 5250 design probably came from the
3270 product line). Perhaps the System/38 workstation controller queried
the tube's (device) controller--not the workstation controller we all grew
to love)--to see if *DS4 was available.

When a *DS4 datastream hit the workstation, the device controller would
have to reset itself to handle smaller characters; this is why you can't
write a *DS4 display when *DS3 mode is active. In the old days, the
hardware couldn't handle it, and to maintain backward compatibility, that's
never been changed/fixed. When you have a graphics card, you can do just
about anything.

The behavior observed is called out in the explanation of the DSPMOD
keyword in your DDS reference manual; the manual references a "default
display mode" which is our *DS3. Also this:

*"When a record with DSPMOD causes the mode to be changed, all records
currently on the display are deleted."*

Using the API QsnRcvMod, the program can determine what mode the screen is
in, and I'd guess that API talks to the System/38 controller. The display
file InfDS may have a device type/model; the RPG manual isn't much of a
help and I'm not bored enough to root through functional reference manuals.

There is a workaround to this problem: start by setting an indicator from
QsnRtvMod. *IN95 means *DS4.
Add this code to the DSPF header:
A DSPSIZ(*DS3 *DS4)

And add this code to the non-subfile formats at the record level:
A 95 DSPMOD(*DS4)
A *DS3 WINDOW(*DFT 7 49 *NOMSGLIN)
A *DS4 WINDOW(*DFT 7 49 *NOMSGLIN)

If the display is currently in *DS4 mode, this logic merely tells the app
to write the display in *DS4 mode.

Good times...

On Fri, Aug 29, 2025 at 6:24 AM Charles Wilt <charles.wilt@xxxxxxxxx> wrote:

That only tells you the data for the open display file...

Doesn't tell you what size was being used before the DSPF was open (ie for
the OP's case of making the popup window match)

Also doesn't tell you what sizes the display actually supports ahead of
time.

Charles


On Thu, Aug 28, 2025 at 5:29 PM Roger Harman <roger.harman@xxxxxxxxxxx>
wrote:

I've never had to deal with this but is there some reason for not
declaring and using an INFDS for the DSPF? Seems a lot easier than
dealing
with the API.

DEV_TYPE CHAR(1) POS(272); // Device type - *DS3, *DS4, etc.
NUM_ROWS INT(5) POS(282); // Number of rows
NUM_COLS INT(5) POS(284); // Number of cols

Roger Harman
COMMON Certified Application Developer - ILE RPG on IBM i on Power



-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Charles
Wilt
Sent: Thursday, August 28, 2025 12:56 PM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Window in 2nd pgm?

Sorry...been to long and I was mis-reading the API name...

QsnRtvMod - lets you determine if the current screen (last output) is 80
or
132 column
QsnQryModSup - lets you determine if a device is configured to support
132
columns

Details here
https://archive.midrange.com/rpg400-l/200011/msg00361.html

HTH,
Charles


On Thu, Aug 28, 2025 at 7:22 AM Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

Yes the code Mark linked to shows the check being called from the popup
window.

TLDR;
The key to making our popup window display in the correct mode requires
the following steps:


1. The (popup) display file should be user open (UsrOpn on the F
spec)
so that we can set the size mode before the file is opened
2. Detect the current screen mode size by using the
Screen_SizeIs27x132 functio
3. Set the display mode size of our popup window program to the
current mode
4. Open the display file
5. Display the popup screen

Ignore what's being done in the test driver.

The QsnRtvMod API mentioned by another poster won't work, it simply
tells
you if a display supports 27x132.
I've used that to display a message asking the user to call the help
desk
to get their session reconfigured as I had a new application that only
worked on 27x132.

HTH,
Charles




On Thu, Aug 28, 2025 at 6:57 AM Justin Taylor <jtaylor.0ab@xxxxxxxxx>
wrote:

After reading the doc, I'm not sure if that API called from the window
pgm
will detect the screen of the calling program. I'll have to test it
and
see. We may have to add an optional parm to the window pgm to
override
the
default display size.

Thanks



On Wed, Aug 27, 2025 at 5:12 PM Mark Waterbury via RPG400-L <
rpg400-l@xxxxxxxxxxxxxxxxxx> wrote:

Justin,
The QSNRTVMOD will give you that information.
Sample code can be found here:




https://web.archive.org/web/20120116114604/http://provatosys.com/retrieve.html
HTH,
Mark S. Waterbury
--
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.


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

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


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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.