Why should I
want to remove locks?
How does this allow
you to recompile things?
Doesnt this go
against system integrity surely the locks are
there for a purpose?
Is it safe to remove locks?
What cant 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 its in-use how can that be possible?
What about record locks?
Can I replace locks once
What if the locking job is
held / disconnected?
Isnt 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 theyre 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 its 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
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.
Doesnt 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
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
What cant it unlock what restrictions
The main restrictions are that it wont 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
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
Depends. If you delete a program while its
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
youll have a damaged object that will require
a RCLRSC to clean up (so dont 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
cant 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 its 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 doesnt 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 theyre 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.
Isnt 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 doesnt
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 doesnt
prevent them from re-entering the locking application
program. LockBuster does not cause any interruption,
and also works on batch jobs which Remote View cant
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