Re: Limit to number of objects that can be allocated by a job?

My thoughts...

If you're exclusively locking ~250 files, you are in fact "restricting" the
system. Just doing so the hard way instead of the easy way by actually
putting the system into a restricted state.

"All or nothing"... is, I suspect, too high a bar. Sure it'd be nice, but
how realistic is it? If you can't go into a restricted state or even
ENDSBS, I assume the system is busy enough that getting a lock on all the
files at once is not going to happen. If by some miracle you do get them,
how are your apps going to handle those object locks?

Personally, if restricted state really isn't an option, then I'd simply
code up something to do them 1 at a time with X number of retries.
A simple CL program or something fancier that you could run multiple copies
of.

At the end, you see what's still left and either free up the objects and
re-run your process or just handle them manually.

I don't know why you need to switch journals, but AFAIK the OS doesn't
require "all or nothing". Having some objects going to new journals while
others go to the old ones, might complicate your restore...but only if you
happen to need to do a restore.

HTH,
Charles

On Fri, Oct 25, 2024 at 5:46 PM Dan Bale <dan.bale@xxxxxxxxxxxxxxxxxxxxx>
wrote:

However, I'd be real curious as to why you need an exclusive lock to

hundreds

of objects at once. That to me seems like a bad idea.

I need to end journaling for ~250 files in several libraries, then start
journaling these same files to new journals. It must be all or nothing,
and I can't take the system to a restricted state or end subsystems. If
there's a better way, I'm all ears (eyes?)

- Dan

*** CONFIDENTIALITY NOTICE: The information contained in this
communication may be confidential, and is intended only for the use of the
recipients named above. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination, distribution, or
copying of this communication, or any of its contents, is strictly
prohibited. If you have received this communication in error, please return
it to the sender immediately and delete the original message and any copy
of it from your computer system. If you have any questions concerning this
message, please contact the sender. ***
--
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.