Re: Programs that didn't need to be written - ScreenSaver5250

from: Patrik Schindler <poc@xxxxxxxxxx>
subject: Re: Programs that didn't need to be written - ScreenSaver5250

Hello Scott,

nice read, thanks for that!


Am 17.08.2022 um 06:24 schrieb Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>:

Back in the olden days (generally, the 1980s) software was written with

multiple displays to save memory. Only one copy of the program needed to
be loaded, with one activation, and one set of open database files, etc.
It saved memory. which was very scarce back then. It was also useful when
the different screens needed to share data or coordinate things between
them. For example, we had a setup where only one person could be working
on an order at the same time, and by using a MRT, it could keep track of
which orders were being worked on by whom.

Quite interesting, and understandable.

The memory you save is insignificant by comparison to the memory systems

have these days, and it's much easier to get the code working properly when
it only has to worry about one user at a time.


Hmm. Even the early Bxx models had way more resources to spend compared to
early mainframes. So I still wonder why OS/400 supports display invites for
multiple terminals being connected to the same logical display device, or
screen. Maybe was meant to help in easier porting of CICS applications? But
then, there was CICS/400 for that purpose. Maybe this required that
multi-device feature? What's your opinion on this?

So, hopefully, programs that open multiple displays with ACQ, et al, are

very few and far between today.

Apparently. Few and far enough that I struggle to understand about "why is
this feature there". :-)

The other use of INVITE is to allow the computer to continue to do

processing while the user is able to input to a display. Consider writing
something like a TELNET client where data can arrive over the network, but
the user can also type at the same time. You would accomplish this by
writing the data you have, and displaying the screen with INVITE (and
FRCDTA). Then the user can key stuff, but you can also sit and look for
data on a network. If the data arrives before the user keys anything, you
can update the display with the new data, and so forth. (You would attach
a data queue to the display to get notification when they finish entering
input.)

Understood and also I see real-world scenarios where such applications
make perfect sense.

Another example might be something like a game -- I wrote a game a long

time ago where a spaceship (drawn in 5250 with text characters) flies
across the screen, and you have a gun you can move and shoot at it (again,
the gun and ammo are just text characters.) To allow the ship to move
while still allowing you to use F-keys to move/fire the gun, it uses
INVITE, FRCDTA and data queues.

Nice! Do you still have the source and want to put it on Github, or so? :-)

It's not necessary for 99% of business applications, though.

Maybe, but I see it as one of my personal challenges to think out of the
box and use my 150 for things IBM has probably not dreamed about. :-)
Database-based stuff, yes, but not necessarily business stuff.

:wq! PoC