Re: JDBC question

Thanks for your response, Dan.

Both the web user and group profiles are set with USRCLS *USER and SPCAUT
*NONE. When I connect to the system and then look for a profile object
lock as you suggested, I do find a QZDASOINIT job which lists QUSER as the
user for the job. The QUSER profile is also USRCLS *USER, SPCAUT *NONE and
GRPPRF *NONE. The job log lists the correct connected user and IP address:
"User <user name> from client <IP address> connected to server." It then
lists a number of libraries, though not all, that are restricted: "Not
authorized to library <library>..." For those libraries listed, I can
still see each library and its files, including file structure. It does
seem that the JDBC connection is working under QUSER authority because if
I set one of my dev libraries to *PUBLIC *EXCLUDE, then it can't query a
file in the library for its contents, though it can still see the file and
its structure. If I change the library to *PUBLIC *USE, then it can read
the file. If I change the library to <group profile> *EXCLUDE, then it can
also read the file. So that is an issue, but regardless of the user
profile, it does seem that I can see the list of system libraries and
their contents even though file data is inaccessible. My understanding is
that you have to at least have *EXECUTE authority on the library to access
one of its objects. You have to have *OBJOPR authority to search a library
and *READ authority to access object descriptions. So given a library
being set to *PUBLIC *EXCLUDE I am not sure how I can see it or its
contents.

As for how the SQL clients (DbVisualizer and Squirrel SQL) are using the
JTOpen driver to connect, I can't say for sure, only that they do connect,
and I am able to perform queries against the system. If I need to somehow
configure the system such that the QZDASOINIT job switches to the correct
user or refuses a connection, I hope that is something I can configure on
the server side.

Thanks again,
Blake