× 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.



Yep. The default is FILE(*ALLFILE) which requires the user have authority to all objects [for which an entry is processed, I believe; if for instance the first sixty entries are all authorized, the request may fail only after several page down requests]. That is because the journal could be host to many various database files to which the user should not have any access, to see the data in those files. The DSPJRN allows the user to effectively do just that, for any modified rows. When the user has authority to see the data in the named file [with the matching JID], then intuitively there is little\lesser reason they should be prevented from seeing that data also in the journal. If they should not, the can be excluded from access to the receiver(s).

I believe security rules require not listing [all of] the objects the user is not authorized to, because it is a /generic/ request versus an explicit attempt to access [information about] that object. And even if it did log each, the recovery process could get ugly to resolve by a process of granting authority, repeating failed request, repeat grant, etc.. I think the CPF9802 naming the journal is a generic way to say "you may not do that"; too bad though, there is not also a diagnostic that clarifies the specific nuances about use of *ALL and *ALLFILE [and any other cases that might exist].

The doc fails to clarify the authority requirement for the *ALLFILE single value. And although the *ALL special value _does have_ an authority comment, it like many other places, seems to refer to /file/ rather than /object/; presumably in most cases it is the latter, even for *ALLFILE.

Regards, Chuck

rob@xxxxxxxxx wrote:
Came across an interesting one today. Had a user who tried just:
DSPJRN JRN(#MXJRN/BPCS_GDI) and got
CPF9802 - Not authorized to object BPCS_GDI in #MXJRN.
If, however, they changed the command to: DSPJRN JRN(#MXJRN/BPCS_gdi) FILE((GDIDIVF/ECL)) No problem
12 entries converted from journal BPCS_GDI in #MXJRN.

So, apparently there is some security under the covers that says:
Hey, I don't know if you're dupa enough to journal the EmployeeRate
table to the same journal as the OrderLine file, so, unless I know
that you have access to the particular file that you are trying to
see, you are SOL.

Which, is probably as it should be. Although that message had me scrambling all over DSPOBJAUT of the journal itself before a coworker
stumbled over the other item.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.