Re: iSeries Navigator Permissions issue

On 11 Mar 2013 10:02, Matt Olson wrote:

Anyone seen where you go into iSeries Navigator, right click on a
table and click Permissions and try grant "Use" or any of the other
permissions to the table and get:

"Not able to allocate object 'tablename' in 'libraryname' type
*FILE"

The issue is general, rather than specific to iNav. Presumably the message CPF2211.

I removed all locks on the file to get the permissions change to go
through, but I don't see why *SHRRD, with a status of *HELD would
cause permissions changes to fail.

The reason the lock conflicts with the work is effectively that... The generic *FILE is a /complex object type/ made up of a composite of other object types [or otherwise requires more work than just setting the authority in the object header], for which granting authority [among other things] must be made to appear atomic when performing necessary changes across multiple objects or places. The work is performed by an object-handler rather than directly by the security feature as is done with /simple object types/ that do not require an object handler. While not an entirely accurate explanation, the implementation for effecting the atomicity causes the different *FILE objects to require no locks be held by any other thread than the one thread which is making the change-request.

QZDASOINIT (.NET applications using IBM's .NET DLL) jobs always have
this lock status on all the jobs they execute and they stick around
due to connection pooling I believe.

The message for database files, at least on 5250, is different than the one shown. So the following paragraph may not apply for the scenario described:

If the locks are held due to opens, and those opens are held as pseudo-closed SQL query ODPs, then AFaIK the DFTWAIT() of the job will enable that length of time for the close activity to occur in the jobs that hold those opens. The job that services the iNav request can be reviewed for its Default Wait time to ensure it is not something very small.... and change that timeout to longer wait if the value is small.

How can I make permissions management easier so I don't have to kill
jobs that have the *SHRRD lock status and *HELD status?

The authority can originally be assigned via an Authorization List [*AUTL], and then eventual changes would be made to the authority via the *AUTL object instead of making authority changes to the *FILE object itself.

Otherwise the applications could be made capable of being shutdown or to enabled by an event to drop locks per notification; for the latter, possibly also awaiting a secondary notification that the jobs may since reinitialize or otherwise re-obtain their locks, to ensure that new requests that would re-acquire the locks would not sneak in between the first notification to drop the locks and the performing of the work that requires the locks were dropped by the applications.