Thanks, I'll check into authorization lists as a potential solution to this issue.
-----Original Message-----
From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx]
Sent: Tuesday, March 19, 2013 6:04 AM
To: Midrange Systems Technical Discussion
Subject: Re: iSeries Navigator Permissions issue
I agree, authorization lists are the way to go.
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: CRPence <CRPbottle@xxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx,
Date: 03/18/2013 05:42 PM
Subject: Re: iSeries Navigator Permissions issue
Sent by: midrange-l-bounces@xxxxxxxxxxxx
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.
midrange.com
