RE: Speed of objects unlocking and subsequent CLRLIB failing

I'm not convinced. The default wait time for an object lock is 30 seconds. If it's taking your system that long to write the cache out and release locks, you need to talk to your business partner about upgrading for more horsepower. If you have the joblog, it will detail why the object couldn't be deleted. If you're not seeing the details, I would put a CHGJOB LOG(4 0 *SECLVL) in to be sure the joblog is saved with all the details. I would probably also make sure the program doing the processing has LOG(*YES) so that you can be sure what commands are happening when in the joblog. Then you won't be just guessing why an object can't be deleted.

Also, for the record. Every job should have full authority to its own QTEMP--this is regardless of having *ALLBOJ or not. (I guess you could adopt authority, create an object, then drop the adopted authority. But I don't see that as likely. It's a moot point since the process runs with *ALLOBJ.)

Thanks,
Michael Quigley
Computer Services
www.TheWay.org

-----Original Message-----
------------------------------

message: 2
date: Sat, 29 Mar 2025 10:10:50 -0500
from: Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>
subject: Re: Speed of objects unlocking and subsequent CLRLIB failing

Jim raises a good point that IBM i may not have finished writing cache to
storage and therefore had a lock on the object. I?ve never seen that
behavior before, then again the number of times I?ve done that is fewer
than 5 in 40 years.
Jim Oberholtzer
Agile Technology Architects

On Mar 29, 2025, at 8:29?AM, Jim Franz <franz9000@xxxxxxxxx> wrote:

?Dan,

What was running prior to the CLRLIB? Something was taking its time
finishing, releasing locks. I doubt (without really knowing) this is
because it's QTEMP...but have had multiple instances of other
operations still completing but the program has moved to the next step.
You could monmsg the clrlib and retry (after 1 second delay). What
pieces of a various commands, especially releasing resources, are
asynch we don't really know.,, Most of my issues involved spooling
resources using non-IBM spool conversion software, and ifs files (from
ftp, sftp), and use something like retry up to 5 times with dlyjob(1)
between each retry. Don't make the retry infinite times - don't want
to hang your own job.
In the above 2 cases I had to adjust the code across the system...
especially if processing many files in a loop.
Jim Franz