× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 04-Jun-2011 06:13 , Joe Pluta wrote:
<<SNIP>> 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.

Of course "IBM" is rather nebulous with regard to the definitional and functional aspects of one specific component of the IBM i OS. ;-)

<ed: add>
On 03-Jun-2011 12:57 , Joe Pluta wrote:
It's IBM that requires direct access to the underlying file. First
they wanted *ALLOBJ, and when we balked at that, they refined their
request. I should be more specific: it's the WebSphere folks that
want this information; they evidently haven't gotten the memo on
the "new" access restrictions.

If they believe they need direct access to the physical, then they would need to ship a program that adopts the authority of a user such as QSYS or QSECOFR, just like any other OS component or utility\feature would need to do. Since as I had alluded there is no data that is available in a QADB* PF which is not also available in a QADB* LF, then almost surely anyone [IBM or otherwise] could effect pretty much whatever is required without any special authorities required. While shipping a logical file in the product is also an option, the database discourages that since any logical may be deleted without any warning, and only diagnosed by CPF32D1 to QSYSOPR [thus available in QHST], which means the feature would need to be restored again for recovery, or have a program that adopts to be able to recover... and if they can ship such a program, then they have no limitation to overcome, for which they have any legitimate case for /needing/ authority to any QSYS/QADB* physical file.

I would guess the more likely their "reason" has origins in misunderstanding rather than there being any actual requirement. For example I have seen similar implications made when defects were wrongly inferred to be functionally correct scenarios, for the query of a VIEW over the system database cross-reference physical file which resulted in the message SQL0551 [sqlcode -551]. The misunderstanding was for assuming the error was correctly being issued, when in fact the query should have been able to complete without error. Noting however that such queries should have been coded with the clauses FOR READ ONLY and WITH NC which preclude references to the member.data which might otherwise correctly effect that authority failure; i.e. update is disallowed [not only for authority, but for the ALWUPD attribute of the file.mbr], and isolation may require access to the physical member in order to allow access to the journal.

Regardless, the database component "owns" and maintains those files, and established the authority requirements to those objects, so no other component of the system should ask of the customer to override those rules... esp. since as I had noted, the authority to those objects could be reset by the QDBSRVXR [or other] system jobs at any moment if they were ever modified.

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.

I do not believe so, but the *USRPRF QSECOFR always includes the *ALLOBJ special authority. A handle can be obtained for that user [instead]. As well, though often not done, any other user could be setup to have that special authority as well. Plus the requirement for *ALLOBJ is limited only to the CRTLF or CREATE VIEW, or to the program that performs the OPEN of the physical file instead of a logical view of the data. For the create requests, they need only be sure to specify *OBJOPR object authority and *READ data right to whomever must later access that new logical view without the [adopted] special authority of the user that performed the create.

So why anybody who [WebSphere] thinks they require access would not simply create a program adopting QSYS or QSECOFR, is unfathomable. Somewhat less so, why anyone might think they need the access in the first place given the abundance of logical files that provide most if not all of the physical data, made available generally to the *PUBLIC.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.