Re: Record Lock under Commitment Control

You’re welcome, Patrik.

One other thing I forgot to mention and which I think is a flaw: in
subroutine CHGREC you keep the record locked, while the user is looking at
the screen. Or is on the phone with a friend, or is out for lunch, or has
gone home without closing his session. In our code that is a definite nono.

I had it once with a customer of ours (long time ago; was on an S/36). The
whole order entry system had come to a grinding halt; everybody was staring
at a screen with the ‘X’ (input inhibited sign). So I went to the system
manager, who was sitting at his desk, staring at another screen. I told him
of the problem, so we started searching for the problem. After an hour of
research it turned out that all the order entry programs where waiting for
a record in a control file, that contained the last used order number. And
that record was locked. By DFU on the screen of the system manager. We
turned to his screen, pressed Enter and everyone could continue.

So, locking a record in job in status DSPW: don’t do it.

Joep Beckeringh

Op 24 feb. 2022, om 18:31 heeft Patrik Schindler <poc@xxxxxxxxxx> het

volgende geschreven:

Hello Joep,

thanks for taking time to dissect my hobbyist mess! :-D


Am 24.02.2022 um 08:19 schrieb Joep Beckeringh via MIDRANGE-L <

midrange-l@xxxxxxxxxxxxxxxxxx>:

OK, I downloaded, compiled and ran the code. Brings back nightmares

from long ago. MOVEA to set groups of indicators, brrrr!

Using very old programming style is a deliberate decision I took for a

future "port" of the code to compile even on V3. With the P02 and P03 I
acquired recently, my planning-ahead was a good one. :-) Because some BIFS
aren't available, I need to dig into *PSSR error handling, while almost
everything else works out of the box. I'm not yet sure if I'll split the
project in two: One for V4+, and one for V3. And on the horizon, I see V2
coming in for the P02. :-)

Anyway, I commented the UNLOCKS out and saw the (or better: a) problem:

if I select 2, just press enter without changing anything the record is not
updated and not unlocked, so there’s your record lock.

Huh! Okay, this is a clear bug.

In addition, I want to re-test if my finding about a lock being held

even after an UPDATE was a misunderstanding or real.

Basic problem is that you make no distinction in your between database

fields and screen fields.

You mean, because I exploit what a fellow list member was referring to

as easy to use I/O model some time ago? :-) Yes, it's very nice to read
from recfmt 1, and write to recfmt 2 without any intermediate stuff to do.

And thus in subroutine CHGREC you do a CHAIN, then an EXFMT, then some

checks and if all the checks are OK you do the update. But if not all
checks are OK, you leave. And so you leave unfinished business, the locked
record.

You're completely correct. The unlock should happen after returning from

the SR. Will change this, and upload the changed code. Thanks a lot!!

And I thought I had finally caught all corner cases. ;-)

If you would make a distinction between database and screen fields you

could do a CHAIN without lock, move database fields to screen fields, do
the EXFMT and all the checks. And if all the checks are OK, then you do a
CHAIN with lock, move the screen fields to the database fields and then do
the UPDATE. No need for UNLOCK then.

True. But if someone meanwhile updated the database meanwhile, the

screen content does not reflect the database content anymore. Which is
rather important to me.

Yes, there is always a way. Check which field's contents are different,

present the user with the differences between the prior disk record, the
contents of the current disk record, and the user's changes and let him
decide what to do. This is what I'd expect from a well implemented "do not
indefinitely lock records" interactive program. But then, this is *far*
from what started as a "simple" example for newbies to understand about
subfiles. That's what my templates started with — and grew to catch corner
cases. Especially the load-paged variant isn't really simple anymore.

If there appears to be substantial change in the given code to be done,

I most likely will quit using RPG at all and redo the complete application
in C — a language I have much more experience with. Some things are way
more cumbersome (frequent conversion between *ZERO terminated and
space-filled fixed-length strings), others are easier, and even enforced
(separate "qualified" structs for each record format, as you suggest).

Again, thanks. This is the first time I remember to have gotten actual,

hard facts feedback from somebody about my program(s). :-)

:wq! PoC



--
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,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription

related questions.

Help support midrange.com by shopping at amazon.com with our affiliate

link: https://amazon.midrange.com

--
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,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com