Re: Record lock question: WAITRCD override or loop w/ nn retries?

Hundreds? Really? In that case, I probably would have issued the override upfront and not within the program at all.

In the cases where I have encountered this requirement, there were basically three scenarios. 1) Record just happens to be locked and will almost certainly be available after a short wait. 2) Record is locked because some idiot programmer allowed a lock to be held while the record was on somebody's screen for update (and that person may have wandered off to the bathroom) 3) Record locked by a failed batch or NEP process that is not handling its errors correctly and is sitting a MSGW state.

The first case normally results in only a single additional CHAIN. The second and third we would retry a couple of times with increasing wait times before reporting the failure and subsequent severe punishment of the guilty party. ;-)

But each to their own - your circumstances are obviously very different from those that I have encountered.


Jon P.

On Nov 2, 2023, at 4:27 PM, Dan <dan27649@xxxxxxxxx> wrote:

Thanks Jon,

I defer to your judgement, but it seems to me that a one-time override
would have far less overhead than multiple CHAIN retries that could occur
for hundreds of different CHAIN attempts. (FWIW, this is a batch program
that runs in the middle of the night.)

We could also vary the WAITRCD value, if desired, depending on run-time
factors.

- Dan

On Thu, Nov 2, 2023 at 3:22 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

For starters, I personally don't like the approach of issuing an override
to the wait time. There is overhead in issuing that command.

But what I meant was that it was easier to vary the wait time this way. In
one case the probability of encountering a lock was higher at certain times
of the day. So at those times, we would increase the sleep time before
retrying and in some cases put out a "retry" message to the user. etc. etc.

Jon P.

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.