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