Re: SQLGETWHERE and SQLGETINCEXPR

Hi Joe

I'm coming in late - and this is in regard to your original thread - you said IBM, or WebSphere, wanted access to QADBXREF. I hope I didn't miss something here, so please bear with me. Was this on a support call? Or was this some application requirement? It all sounds very strange, as Chuck and others had pointed out.

I remember first looking at QADBXREF maybe 20 years ago - there were some even more Draconian restrictions, as I recall, but I don't remember the details. Civilians were NOT to work with these files directly, as they were critical to system operations. So the READ data right with no operational for *PUBLIC makes some sense - not that I'd have thought to do that!

Some reported no problem - but they probably had *ALLOBJ special authority, so not a good test.

Another question - you expressed reticence at granting "IBM" (whatever context that comprised) *ALLOBJ - would you have allowed a service tech that kind of access, or given them the password for QSECOFR? That would have done it, although, as Chuck said, there are logical files that are efficacious toward seeing everything of interest in these files. And there is a complete set of VIEWs in QSYS2 over these various QADB* files. All those views are usable by *PUBLIC - as an example, I looked at QADBKATR, an LF over QADBKFLD (that one has the same authority setup as QADBXREF). The LF has the single DATA privilege and also had OPER privilege - that was all, but it allowed using SELECT against the LF.

This is interesting - I think the intent of IBM is to limit access directly to the various QADB* PFs - to avoid all manner of dangerous actions, whether intentional or accidental.

Now this does cause me to look at the OA handler I wrote - I use a lot of these cross-reference files - I will need to either make the *SRVPGM adopt QSECOFR authority, or be sure I am using only the LFs.

Thanks
Vern

On 6/6/2011 7:17 AM, Joe Pluta wrote:

Using Chuck's input as guidance, I was doing a little more research on
the QADBXREF file and its associated views. One of those is a view
called SYSINDEXES. For fun and excitement, I tried to duplicate the
view (CRTDUPOBJ) and not surprisingly I can only duplicate it using a
profile with *ALLOBJ authority, not with normal *PUBLIC authority. But
then I saw something interesting. When I created the view with the
right authority and then took a look at the created object with DSPFD,
the associated SQL has an unusual piece to it. You can do it yourself
by doing a CRTDUPOBJ and then doing a DSPFD, but the relevant bit is
this part:

CREATE VIEW SYSINDEXES (INDEX_NAME FOR "NAME" ...
... CASE WHEN IX.DBXIDXSEL<> 'Y' THEN NULL WHEN IX.DBXIDXSELX IS NOT NULL
THEN IX.DBXIDXSELX ELSE TESTLIB.SQLGETWHERE(IX.DBXLIB,IX.DBXFIL) END ...

Note the call to procedure TESTLIB.SQLGETWHERE. I didn't create that
function! It doesn't actually seem to exist; if I try to call it myself
I get SQLGETWHERE in TESTLIB not found. If I call it unqualified I get
results. This works fine:

SELECT SQLGETWHERE(DBXLIB,DBXFIL) from QADBXREF

Which brings me to my primary question. Maybe the function is in the
system library list, but I can't find it on the system anywhere. Where
would I look to find more information about this function? I haven't
been able to find it anywhere. I looked in SYSFUNCS, but no luck. Is
it some sort of undocumented built-in function?

And the minor corollary question is that the generated VIEW in the DSPFD
doesn't seem to be quite right: certainly as written the query wouldn't
seem to work since there is no SQLGETWHERE in TESTLIB. Maybe that's
just an artifact of DSPFD, though.

Joe