7.6 includes a new function that administrators can enable to allow users to “lock” records for editing.

It is enabled in the application designer as described in technote 1698344.

When a user wants to edit a record they can click on a “Edit” button that will prevent other users from editing the record.

If anyone else tries to edit it then they will receive an error message and they will have to wait until the lock is released.

The lock can be released in one of several ways:

• Record is saved (and thus unlocked)
• Lock is released by the user releasing it e.g. by changing to a different record
• Lock is released by a system administrator via the Record Release application (Administration -> Record Release)

I haven't checked it in a while but I think the lock is also released when the user logs out or is timed out.

The locks can be seen in table MAXRECORDLOCK

This new function is very useful and it would have prevented the user from losing an hour’s work as I described in an earlier article.

Unfortunately no log entries are created when the locks are created/released so you won’t be able to use this to track user actions or see if that has contributed to an issue unless you replicate it.

If you want to implement it then be aware that there is an open APAR IV93668 about this functionality. This explains a scenario where the record lock isn’t complete. The APAR has been opened so it should be fixed in a fix pack.

Will this stop all the record refresh errors?

It is important to understand that this functionality won’t completely stop record refresh errors.

The lock doesn’t lock the record against changes made by non-GUI code e.g. crontasks/escalations/BIRT reports and interfaces.

The non-GUI code isn’t aware of the lock so it can’t honour the record locks and that leads to the record refresh errors.

A note about escalations

If your system has an escalation that is modifying records and is scheduled to run in minutes, or quicker, then you should consider using a different solution e.g. Java or Jython.

Vetasi consultancy

If you are experiencing unexpected record refresh errors or you would like to convert a set of escalations into a more sustainable long term solution then Vetasi consultants would be happy to work with you.

We have teams in the UK, Poland and South Africa and we have worked with customers who have users spread around the world.

This blog series

This article is one of a series of articles to help system administrators understand the Maximo logs and the underlying architecture.

Articles are normally posted on a Tuesday.

If you like this article then please share or like it.

If you are finding this series useful then book a place on my "Making BIRT Reports easier to support" webcast on 5th April 5pm BST.