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.

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?

Jonathan Ball wrote:
> 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