Re: Access rights to system files

On 6/3/2011 4:38 PM, CRPence wrote:

2. What does this setting mean? I can't even do a DSPPFM on the file.
So why give the data read rights as all? This isn't the only file
like this - other physical files in QSYS have similar settings.
(Although interestingly enough logicals over those same physicals
are accessible.)

Lacking any object rights, users lacking the special authority
*ALLOBJ can not access any data directly from the physical file [so
DSPPFM is not an option for such users], nor create any VIEW or any
INDEX over one of those PF QADB* in QSYS. With that implementation
[effectively enabling row and column security], only the specific data
that should be visible to the general *PUBLIC is manifest via a logical
view of the specific columns and rows. However AFaIK there are still no
columns in any of those PF which are not exposed via one of the logical
files; I believe each physical still has at least one logical which
shares the record format of the physical. If ever there were to be some
data protected in that manner, not exposed via a logical, the underlying
authorities of the existing physical files would not have to be changed.
In other words, the implementation reflects a design which intended to
avoid an incompatible change in the future.

Interesting. Now that I understand the concept, it makes a lot of sense. I ran a few tests, and the data read rights allow access via logical view, while the lack of operational rights DISALLOWS the creation of additional views or logicals (unless you are QSYS or have *ALLOBJ).

Which makes it all the more annoying that it's IBM requesting access to this file. They ought to know better.

Any references to the physical files must either be run with or adopt
the authority from a user with the SPCAUT(*ALLOBJ).

Because you can't submit a job as QSYS, and I would guess that you can't get a profile handle to QSYS either.

Joe