Good day
I would like to know the following.
When experiencing NAT3145 errors, an attempted retry is done I assume to get the record in question and do the necessary processing.
How does the system decide how many retries to do before timing out and are the retries in quick succession or are there small intervals (pause/latency) before the next retry is done after the previous retry has failed to obtain the record.
Well, since this is the second time you’ve asked the same question in as many days, I guess you really would like to know. 
So let me give it a try.
Your assumption is correct, that the RETRY is used to attempt to re-read a record for update that received a 3145 from Adabas because it was already on hold for update by another user (online or batch). An ON ERROR block in the program traps the error from Adabas, checks if *ERROR-NR = 3145 , and if so, issues a RETRY. The RETRY causes Natural to send the original READ or GET command to Adabas again, repositioning to that statement in the program. If this time the READ is successful, execution continues with the next statement following the READ/GET. If the record is still on hold, then Adabas returns another 3145 error, the ON ERROR logic catches it and RETRY’s again.
Within Natural, there is no built in delay before the RETRY that I am aware of. If it’s an online program, some programmers prefer to ask the user in the ON ERROR block if they want to retry or skip the record. If necessary, sometimes I’ve seen delays added within the ON ERROR, either a FOR loop to burn some CPU time, or a CMROLL call to put the program in a wait status for a set number of seconds. Or I think there is now a USR API routine that is preferred over CMROLL. Not sure of the USR #, but you can look it up.
I looked at a really old Adabas book I have that mentioned that Adabas delays for a bit before returning the 3145 error, in case the record frees up, but it didn’t say for how long. That sounds familiar, but my Adabas internal knowledge is weak, and fading fast. You might consider posting just that question under an Adabas forum if it is important .
Note that you must be running with the Natural parameter WH = OFF (default). You could consider changing to WH = ON for the program getting the 3145 and Adabas will wait until the record is released by the other program. Of course, if it’s an online user holding it on a screen, that could take as long as the TT timeout for that user to timeout or finish and release it. And your program might time out first.
I don’t think there is any limit to the number of RETRYs that can be done, although if necessary the ON ERROR logic could count them and ESCAPE or FETCH a different program at the desired limit. If your program is eventually returning a 3009 timeout, then it must have other records on hold itself, and it managed to perform as many RETRYs as it could before the TT time limit was hit. Or maybe some other more complicated reason for 3009, there are a few.
So, hope that helps. If you would like more help, you might describe the problem in a little more detail. More members might weigh in with suggestions. What’s the environment like - all online programs and users, or multiple batch jobs, or a mixture? Do you know what program or user is holding the record originally, and why? If you do a Search on the Natural forums for NAT3145 someone posted a program that can find the program/user. Also, is it always the same record, like some type of control record that everybody is trying to read/update at the same time, or just different random records? If random it could be that the competing program is reading a lot of records on hold before ET’ing them. Lots of possibilities…
Cheers,
George
Many thanks
The response is great and very detailed.
Much appreciated George.