Hello Frank,
Am 02.02.2020 um 09:50 schrieb Frank Kolmann <frank.kolmann@xxxxxxxxx>:
I agree with Booth. Leaving records locked for a long time can cause you a host of problems.
I am perfectly aware. But there should no "long time" happening in the first place. There's also a 5=View which I expect the users to use if they don't need to make edits. As I wrote, having three users (four including me) is not the same effort educating them as having three or four hundred.
. A user opens a record for update then goes to lunch. In the meantime another job crashes because it needs the record.
. Multiple jobs attempt to open records for update, and each are waiting for the other to complete,
Yes. The first is a good reason to slap the selfish user, the latter the outcome of the first one.
But why should a waiting job crash? If you think about a telnet session being town down for apparent network outage: Sensible configuration to end the job soon or immediately instead of waiting for the user to come back and sign in again is a sensible solution to this scenario.
Or maybe you're talking about the standard inquiry IBM i sends when some error happens? Of course this must be catched in the program. Additionally, to have PFs return immediately with a locked state instead of waiting one minute helps.
It is simple to code logic that detects if a record has been updated (I had an update number field) If you dont have an update number you can have the whole record in a DS.
then, nicely ask the user to refresh the screen data with F5 because the record was changed. (If a change is detected)
Yes, and his own changes are discarded by pressing F5. An apparently frustrating solution for the one who comes second to edit a record, no matter how tiny the edit was. I don't see this as a good way to go. I already wrote about that topic. You even quoted it without referring to my arguments I presented!
For a small program, for a small group, I want to stay reasonable with how much time to spend for catching corner cases in code. And if I do, I'll do it in a way which makes sense. Just discarding user's data because someone else was faster in updating is just rude. Not allowing the user to enter data in the first place saves him frustration seeing his effort to have already entered data nullified.
From my experience, it's often more sensible to provide a read-only view to the user than to entirely deny access. This helps to remember what he wanted to do, besides being constantly distracted by telephone calls, chat, email and coworkers. And if people start to complain, I can still talk to them and try to work out how they expect concurrent edits to be handled.
Constantly remembering users to use 2 only if they really want to make changes reduces chances of parallel edits in the first place.
In my experience this message rarely occurred and when it did happen the recovery was a simple, press F5 and try again. This was a much easier process to manage than to recover crashes.
I don't see where crashes happen through just locked records, see above. See above. And crashes are fatal only if a considerable amount of data will be lost. Since I'm a huge fan of 5250, data to be entered into the screen is limited naturally. And almost always, data will be written back to PFs after hitting enter. I avoid carrying data in memory only between screens for your reason given, and more.
Plus, if your message rarely shows, it is also quite rare for a lock conflict to happen in the first place. Especially if users remembers to be nice to other users and really use 5 if there's no edit to be done.
Adhering to database normalisation and using a sensible match of PF to DSPF also contributes to locks being spread out between PFs and lowering chances of users having to wait for someone else. Of course this applies mostly to new programs or new parts of a greater program collection.
I implemented a system standard on how updates had to be coded. Programmers disagreed with me and then received poor performance reviews which had other more personal consequences.
I had the code changed by a different programmer or changed it myself.
Up to you, of course. Before flat opposing against locked records, please rethink why they have been introduced in the first place. If your solution was universally feasible, it would have been implemented by database vendors everywhere instead of locks, wouldn't it?
This is my opinion, in context with my environment to serve. Of course it's not universally fitting for everyone else. But please grant this view also the other way around. :-)
:wq! PoC
PGP-Key: DDD3 4ABF 6413 38DE -
https://www.pocnet.net/poc-key.asc
midrange.com
