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