He's talking of a curious command:
(From Help for command CHKOUT)
Check Out Object - Help
The Check Out Object (CHKOUT) command checks out an object. The
object is checked out to the user profile associated with the
current user of the job that is running the CHKOUT command.
When an object is checked out, other users can read and copy the
object. Only the user who has the object checked out can change the
object until it is checked in (see the Check In Object (CHKIN)
It's a locking mechanism, I've never really used, so have never experienced its effects as described by OP.
I can see how this could REALLY cause problem with applications needing *RW authority to a "checked out" resource...
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Friday, March 15, 2013 6:19 AM
To: Midrange Systems Technical Discussion
Subject: Re: Find all checked out objects on system
I know this may have me looking totally ignorant but how are they
"checking out" an object? Is it some process in RDP? Is it some
homegrown utility? Is it a function of your change management package (if
Because, when I use our change management package with RDP and I check out
an object it copies it to my work library. If others use the package to
try to modify the object in it's original library they are warned by the
package. If they modify the object outside of the package then all bets
are off. Saves of the original object are completed as if it's never been
"checked out". If I save my work library, then that is saved fine also.
Now, if you're talking about someone with an old 3180 terminal running SEU
leaving it in edit state every night after they've gone home well, now
perhaps I can see how that might cause locking issues. Perhaps you are a
shop where there's round the clock development and there's always some
member open in QRPGLESRC and you're wondering how to get that backed up
Help me to understand what is really going on before we try to solve the