Yes, but all of these require the user to press a key, so another
program loop can actually show the "has changed, press F5" message. AFAIK
it cannot be made pop up magically, as long as the *PGM is stuck in
EXFMT or READ. :-)

Not to say I use this approach very often (like not in several years, if
not decades) but
the READ aspect (with EXFMT you are indeed stuck, but WRITE followed by
READ(of the invited DSPF) works).

On Mon, Dec 30, 2019 at 10:29 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello Craig,

Am 29.12.2019 um 14:48 schrieb Craig Richards <craig@xxxxxxxxxxxxxxxx>:

The way this is normally handled is to re-present any changed data back
the user - with a message such as:

"This item has been modified since this screen was loaded - press F5 to

There are two main ways you can recognise that the data has changed:

Yes, but all of these require the user to press a key, so another program
loop can actually show the "has changed, press F5" message. AFAIK it cannot
be made pop up magically, as long as the *PGM is stuck in EXFMT or READ. :-)

This is somehow related to editing data in a detail-record. From a
discussion about annoying record locks which makes other users fail to open
a record R/W… To prevent these, one can read the record in question without
locking. But then two people may edit the same record. Who is supposed to
have the "right" data? The whole topic is inherently complex if you want to
do it right.

Of course it would be very nice to have a semi-automatic merge function.
If two users edited the same record but different fields, that situation
can be resolved comparatively easy. If not, the user should get an overview
which fields have been changed by both parties compared to the original,
allowing further editing or picking which fields from which edit should be
actually written back. To make that easy, it's necessary to create two
side-by-side SFLs with changed values and options on both sides to pick
appropriate values. Together with two CA/CF "Discard my data" and "Write my
data", that would approach the most sophisticated level of support. Of
course, there should be screens for confirmation of CA/CF-Choices. And of
course, it might be possible to make code "guess" which values would be
more appropriate and present a pre-selected SFL to the user, and so on.
This easily can be made recursive, because while picking records to
actually write back, a third one did edits on that record…

This is less problematic with a (usually) readonly SFL which "just" shows
outdated data until reload. One of the reasons, I prefer paged SFLs: The
chance that outdated data is shown is less likely and current data is
shown with every scroll. Yes, they're more cumbersome and I still haven't
come up with a nice idea how to save OPT-selections in a multi-user
friendly way to keep them beyond scrolling.

Maybe I'm just too used to graphical applications where it's somewhat more
easy to track changes on disk, and update a list view without disturbing
the user. A very nice example is Apple Mail on OS X. The list of mails in a
certain folder gets updated in nearly real time (if the IMAP server knows
how to push changes to the client) when new mails come in or get deleted
from another account. This happens without disturbing the already made
selection of entries by the user.
This is one of the limitations of the form-based approach of 5250 and
3270, and pure HTML tables without any fancy JavaScript to refresh on the
fly. The user always needs to either have a "costly" auto-refresh, or
presses F5 for refresh.

Thanks for the hint! Unfortunately, V4R5 doesn't know about qualified DS.

:wq! PoC

PGP-Key: DDD3 4ABF 6413 38DE -

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives

Please contact support@xxxxxxxxxxxx for any subscription related

Help support by shopping at with our affiliate

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2022 by 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.