Why should I want to remove locks?
How does this allow you to recompile things?
Doesn’t this go against system integrity – surely the locks are there for a purpose?
Is it safe to remove locks?
What can’t it unlock – what restrictions are there?
What can it unlock?
What should it be used for, and what should be avoided?
What happens if I delete an object that had locks against it?
Does removing locks cause the system to be confused?
Recompile a physical file while it’s in-use – how can that be possible?
What about record locks?
Can I replace locks once they’re undone?
What if the locking job is held / disconnected?
Isn’t there an IBM tool that does this?
What about using Remote View to get users out?


Why should I want to remove locks?

To be able to make changes to objects, e.g. to recompile them, while they are in use.  Currently the only way of changing objects while they’re being used is to get all locking users out of applications which hold the locks, or cancel their jobs.  This is often impractical so it results in important changes being delayed for a later date.

How does this allow you to recompile things?

When you compile an object there is normally a REPLACE(*YES) keyword on the command.  That means the old object will be put in the special library QRPLOBJ and renamed.  Using LockBuster you can remove the locks on that object and recompile it with the replace option.  The jobs that were using that object will continue to use it.  They are actually unaware that it’s been moved/renamed because the address of that object in memory has not changed.  Now any new jobs that come along to acquire that object will pick up the new version.

But what about the users that are still running the old version?  That shouldn't be an issue.  When a change is wanted, it is normally required by only a few people - the other users are not concerned.  So once you've made your changes, you can contact those people and tell them to exit and re-enter the program.

Doesn’t this go against system integrity – surely the locks are there for a purpose?

The main purpose of locks is to prevent you from accidentally deleting an object that is in use by another job or to act as warning against modifying it.  However locks can still be removed without going against the integrity of the system:

Suppose a display file was in use by 50 users.  What if each of those users bought up a command line and called a program which removed their lock against that file?  This would be perfectly allowable by the system.  There would now be no locks on that file, and you would be able to make changes to it.  LockBuster achieves the same result but without requiring user assistance.

Is it safe to remove locks?

LockBuster will not allow you to do anything that it considers dangerous (see below question).  However you need to be careful which objects you use it against and what you do after removing the locks.  E.g. you should not delete an object that you have removed locks from.

What can’t it unlock – what restrictions are there?

The main restrictions are that it won’t let you remove locks from system jobs, or from file members locked by Open Data Paths.  Not removing ODP locks on members will prevent them from being accidentally cleared or deleted, but will still allow change / recompile of the files that own them.

What can it unlock?

Most object types are supported, although it is mainly meant for files (DSP, PRT, PF, LF).  See the F4-prompt on the RMVOBJLCK (Remove Object Locks) command for a full list of OS/400 object types that can be unlocked.  The locks can be of any state (*SHRRD, *EXCL etc.) but must be of type HELD.  WAIT locks cannot be removed until they have taken hold.

What should it be used for, and what should be avoided?

You should confine your use of this to user-created (non-system) objects locked by user jobs.  And you should avoid deleting objects that have had their locks removed.  When unsure it is best to test it on a dummy object in a test situation.

What happens if I delete an object that had locks against it?

Depends.  If you delete a program while it’s running that job will fall over.  But you can do that already because called programs are not locked.  If you delete a display or printer file the program will get an error message and fall over, but the job will stay up.  Same with a panel group or menu object.  If you delete a physical or logical file, the header will be deleted, but not the members, and you’ll have a damaged object that will require a RCLRSC to clean up (so don’t do this!).

Does removing locks cause the system to be confused?

When a file is opened a lock is placed on it.  Upon closing the file, the OS expects that the lock is still there and attempts to remove it.  If it can’t find the lock it would get an error message at this point.  However OS/400 programs will always monitor for and ignore such messages because they have to cater for the likelihood that the lock had been manually removed (by the same job) in-between.

Recompile a physical file while it’s in-use – how can that be possible?

Providing that no-one has the file open for update, then you can use this product to build a new copy of the file, e.g. with additional fields.  The old file and its logicals will be moved to another library and the new files moved into its place.  The documentation describes the process more fully and provides a tool to do it (command: RPLPFIL - Replace Physical file with new version).  If you need to change a logical file, e.g. to add new keys, then the process is easier.

What about record locks?

Records locks are entirely different to object locks.  This product doesn’t handle them and there are probably not any situations in which they can be removed without confusing the locking program.

Can I replace locks once they’re undone?

Not currently.  It is planned for a future release of this product to be able to replace and modify the state of locks.  However there does not appear to be much benefit in doing so.

What if the locking job is held / disconnected?

This product operates entirely from your current job and does not require that the jobs holding locks respond to unlock requests.  So it will still work when the target jobs are held, disconnected or otherwise unresponsive.  Note: On V5R3 of OS/400 (i5/OS), it is required that the locking jobs not be held.  This is because the way locks are stored in V5R3 requires that the locking job perform the unlock request.  In this situation it will be necessary to release the held jobs and/or end the locking jobs.

Isn’t there an IBM tool that does this?

There is/was a tool from IBM called ‘lock buster’, which helped vary devices off.  (Go to the Knowledge Base and search on APAR "SA56482" for details).  It had a specific function and doesn’t do what this product does.  Other than that, there isn't any OS/400 function that allows you to remove the object locks of another job.

What about using Remote View to get users out?

Our Remote View tool can also be used to remove locks by transmitting appropriate exit function keys, like F3, to the locking jobs.   This may be suitable when there a few locking users, who have been inactive for some time.  But when there are many users it would be too much work.  It would also interrupt their work and doesn’t prevent them from re-entering the locking application program.  LockBuster does not cause any interruption, and also works on batch jobs which Remote View can’t handle.

However there are situations when Remote View may be more appropriate to properly exit users, e.g. to reorganize a file, or remove update locks on physicals.  For this reason these products are offered jointly at a discount.  See the order page.