Authorization list issue
Jonathan Ball
list of objects secured by the authorization list. When I attempted to
use it for an authorization list that secures many (perhaps thousands)
of objects, batch applications started crashing because they couldn't
get needed locks on objects secured by the list.
First, that's simply terrible design by IBM. Any DSP* command should
not require a very strong lock at all, and in this case, it should only
require the lock for a fleeting instant - long enough to get the basic
object data (name, type, library, etc) for inclusion in the resulting
display.
Second, is there a way around this? Is there an API that would retrieve
a list of objects secured by the authorization list in a non-disruptive
way, or would that simply produce the same problem?
CRPence
> On the Display Authorization List (DSPAUTL) screen, F15 will
> display a list of objects secured by the authorization list.
> When I attempted to use it for an authorization list that secures
> many (perhaps thousands) of objects, batch applications started
> crashing because they couldn't get needed locks on objects
> secured by the list.
The DSPAUTLOBJ [Display Authorization List Objects} I believe
implements the F15; perhaps that with the DSPAUTLDLO. FWiW the
MATAL MI instruction holds a seize, not a lock. The implementations
above the LIC is what would hold a lock to prevent [what would be
perceived as] an apparent hang on the seize condition. A lock is
manifest as job status LCKW, but the seize leaves the job in RUN
status with no apparent activity pending resolution of a potentially
long-held seize.
I wonder though... Is the description of the problem as other
jobs being unable to "get needed locks on objects secured by the
list" incorrect? Perhaps that description is used, similar to the
obtuse message CPF3203 issued by the database? Is the problem
really with the ability to assign object authority to that list or
remove an object from the list [likely for cpf3203]?
> First, that's simply terrible design by IBM. Any DSP* command
> should not require a very strong lock at all, and in this case,
> it should only require the lock for a fleeting instant - long
> enough to get the basic object data (name, type, library, etc)
> for inclusion in the resulting display.
For full accuracy, the entire list must be generated after the
last change and before the next. For a "display at a time" feature,
that implementation could get as many entries that fit on a screen,
repeatedly, each from the last known position; difficulties would
arise if one or many entries [esp. the one and surrounding entries
used for positioning] went missing.
Thus given accuracy is relevant, then the "terrible design" may
be instead that the other uses of the *AUTL object will fail versus
waiting [long enough] to complete without an error. If the "wait
time" for what establishes the timeout and resultant allocation
error being signaled, is defined by the DFTWAIT(), be sure the *CLS
for the batch job specifies a sufficiently long default wait value;
batch jobs inherently should have longer wait timeouts due to their
lower priority.
That said, the design is still poor for the reason noted; i.e.
the above does not mean to try to excuse the long-held lock during
the materialize. Since the list can be potentially very large and
there is little reason to materialize the entire list for a
"display" feature when the list is actively being updated, the
feature could be much better implemented, even if to give an error
on the display feature indicating something like "position was lost
due to too many changes".
FWiW a similar problem occurs on database *FILE objects using the
DSPFD *MBRLIST for effectively the same reason; i.e. the list is
accurate to the moment it is generated, by holding out both add and
remove requesters. In both cases the easiest resolution may be
ensuring the number of objects in the list does not become
significantly large.
> Second, is there a way around this? Is there an API that would
> retrieve a list of objects secured by the authorization list in a
> non-disruptive way, or would that simply produce the same
> problem?
The QSYLATLO API will use the same MATAL MI instruction, and
presumably similarly allocates the *AUTL object to prevent the other
activity from waiting on the seize versus the lock.
DSPAUTLOBJ Locks Authorization List KB: 86256EEF00659C5A
http://www.ibm.com/support/docview.wss?uid=nas1e0ff657f8052e06186256eef00659c5a
Regards, Chuck