Re: Speed of objects unlocking and subsequent CLRLIB failing

since the OP never defined what steps were running prior to the CLRLIB, we
have no view of what's locking objects or if threadsafe. Also there's no
way of knowing if IBM's CLRLIB command uses default timing in the
allocation of the objects. I only spoke to my experiences with resources
not being 100% available when certain commands end and next step attempts
to use the resource. It may only happen in 1 in 10,000 attempts, and coded
the retry only after a failure, trying to build for "lights out" operations
- no one is watching for halts. Jim's mention of disk cache writing is
something heavily dependent on hardware resources. I fully agree with your
comment on logging to see what is going on. I've changed many of the ibm
job descriptions for better logging, to understand what's going on.
Jim Franz

On Mon, Mar 31, 2025 at 8:26 AM Michael Quigley <MichaelQuigley@xxxxxxxxxx>
wrote:

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

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.