RMS-W-TIMEOUT: how to determine cause of timeout

[Layne Burleson_1]

I have a programmer that is getting a RMS-W-TIMEOUT message when trying to access a record in an RMS indexed file. The code is in Fortran and I don't have access to it. Does anyone have any suggestions on how to determine the root cause of this issue?

The disk is not badly fragmented, the disk i/o values are not high, cpu does not appear to be an issue.

[Ian Miller.]

Hi Layne, recovered from the bootcamp yet?

I would guess its a timeout waiting for a lock however that message can be for any operation so it depends on what the program is doing.

Do you know what the program is doing when it get that error?

[Layne Burleson_1]

Ian,
I think I'm fully recovered. I thought this bootcamp was much better than those in the past.

The program is trying to read a record and lock it for write. I would think if it was locked by another process that the status code would reflect that. I know they retry for up to 2 seconds before logging the rms timeout message. Do you think there's a status code being generated that the programmer is missing?

[Ian Miller.]

See attached. Is the anything in the RMS secondary status field RAB$L_STV?

[Hein van den Heuvel]

For RMS to return this error the applicaton must have requested RAB$V_WAT = "wait for record lock" in combination with RAB$V_TMO = "use timeout" and had a timeout value spacified in RAB$B_TMO.
Without all that RMS would just return RLK = "record locked".
With just RAB$V_WAT set it will be willing to wait forever.

So the root cause is application design. The application choose to ask RMS to do this for a reason. Your mission, should you accept it is to find out whether the target record was locked legitimatly or not.

http://h71000.www7.hp.com/wizard/wiz_3677.html

[Hein van den Heuvel]

(whoops.... meant to hit 'browse' but picked 'submit' :-)

My rms_locks and/or blocking programs may help you with finding who folds the lock and why.

I made all my tools available at the bootcamp in the share as a zip file.
I'll attach the rms_locks program.

You may also want to check with ANAL/SYSTEM
In particular: SHOW PROC/LOCK
and SHOW PROC/RMS=(RAB)
(other fun RMSSDA options are IRAB, BDBSUM, FSB, GHBSUM,...)

Finally... the program may have chosen to overload the RMS$_TMO status value for its own needs. Not likely, but stranger things have happened.


>>> I would think if it was locked by another process that the status code would reflect that

It does: TIMEOUT! What else did you expect?


>>> I know they retry for up to 2 seconds before logging the rms timeout message

Well there you have it. What else did you want RMS to do? It is the applications choice to do this.
When it signals the error, it would be helpful to identify the targetted record, for example by displaying the key, or the RFA from the prior record.

I don't think we can tell from here whether the lock was justified, wether the program should simply have waited longer, or whether it should have returned a record lock error rightaway.

If the program needs to (re)write/update the record, then it woudl seem clear that it needs a lock for that.

hth,
Hein.

[Layne Burleson_1]

Hein & Ian,

Thanks for your input. The programmer that was working on the issue came over to tell me that he found the issue. It was in fact a locking issue and he is changing the program to handle it.

Hein,
I pulled down your tools at the bootcamp. I already had most of them on file prior to the bootcamp. They help out a great deal. Thanks for writing them for the VMS community.

Layne