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

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.

On Nov 2, 2023, at 11:04 AM, Dan <dan27649@xxxxxxxxx> wrote:

I'm not sure I follow the purpose of "granularity" in this scenario. Are
you advocating for the WAITRCD(800) override to replace the existing
looping logic? The two advantages I see are that 1) the looping logic is
eliminated and, 2) the 20 second "sleep" time is eliminated, allowing
processing to continue as soon as the record is unlocked by the other job.

If the lock still exists after WAITRCD(800) expires, I'd still process the
error.

- Dan

On Wed, Nov 1, 2023 at 5:36 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:

I can only think that you get more granularity of control with a wait. I
would use the sleep() or usleep() functions rather than wasting machine
respource on a loop.

In the past, I used this approach when the norm was a small delay for the
lock but we would increase the wait time on each iteration until a sanity
limit was reached at which point we worked out who had the lock and shouted
at them!

Jon P

On Nov 1, 2023, at 12:48 PM, Dan <dan27649@xxxxxxxxx> wrote:

I’m reviewing an old RPGLE batch program that has logic to retry a CHAIN

on

an update file whenever the CHAIN fails because the record is locked by
another job. It uses a loop to wait 20 seconds and retry the CHAIN, and

it

loops ten times. And I’m left wondering why one wouldn’t just override

the

WAITRCD value for the file before opening it. We use the system default
WAITRCD(60), so the logic currently waits 80 seconds in total (60+20)
between each attempt, and gives up after 800 seconds. Is there a good
reason why overriding with WAITRCD(800) and doing away with the current
loop logic wouldn’t be a better option? I’m going to guess that the
original developer wasn’t aware of files’ WAITRCD attribute.

(And, yes, the logic does process the error after exiting the loop.)

- Dan

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