Re: iSeries Navigator

On 27-Apr-2015 15:00 -0500, Glenn Gundermann wrote:

On 27 April 2015 at 15:55, Englander, Douglas wrote:

I tried the call to QCMDEXE and it worked, so that is good.

Presumably that is a typo, and QCMDEXC [in QSYS2; or even QSYS] was meant.

I have been told by many that a SQL Schema = IBMi Library. I am
not clear why, when changing the Schema list, the Library list does
not get changed, and I have to change that manually, outside of the
Schema list.

That could depend on, to what the term "Schema list" refers. If the so-called "Schema list" is documented to effect the establishment of the library-list of the server job, then surely that should be the expected effect.

Is that a bug in iSeries Navigator, or is that the way it is
supposed to work?

What does the /help/ behind the "Schema list" describe as the effect for whatever names that are specified there [and possibly also for the order of specification]?

If it is supposed to work that way, then what is the difference
between a Schema and a Library?

The Library (*LIB) object is an object that implements the SQL SCHEMA. When a CREATE SCHEMA is performed, the library object is created and then other effects such as a possible change of ownership and granting of authorities, plus creation of other objects such as [schema-specific] SQL catalogs, a receiver and a journal [and optionally, although hopefully nobody still does request creation of, a DATA DICTIONARY].

We are on V7R1.

Yes, SQL Schema = IBM i Library.

If I change the Schema List and execute
SELECT * FROM LIBRARY_LIST_INFO
, I see the change in my library list.

This doesn't mean your SQL code will use the library list though.

In order for the SQL code to use the library list, you must ensure
one other setting:

JDBC Settings-> Format tab-> Naming convention: System (*SYS)

Even with *SYStem naming in effect [instead of *SQL naming], unless the CURRENT PATH and CURRENT SCHEMA special registers remain DEFAULT, what is the library list of the job would remain moot; i.e. when not DEFAULT, the respective name-resolution is via the name(s) in the register, rather than via the Library List. Restated, the SQL work for which those registers are referenced, to resolve _unqualified_ name references, is effected without any reference being made to the *LIBL whenever the register is not DEFAULT. Of course control of the library list may still be required for any non-SQL work that might be invoked via the SQL.
<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/db2/rbafzqualun.htm>
_Qualification of unqualified object names_
"Unqualified object names are implicitly qualified. The rules for qualifying a name differ depending on the type of object that the name identifies.
..."

Thus for example if a term "Schema list" were to refer to the SQL PATH, then the Library List (LIBL) and that PATH as a "Schema list" need not be reflective; once the PATH is not a redirection to the *LIBL, any change reflected as an addition to the PATH would not be reflected as an entry in the *LIBL. If the term "Schema list" intends to imply the establishment of the User portion the Library List (USRLIBL), then that should be the visible effect; i.e. manifest as a change to the Library List attribute of the job, a decidedly non-SQL attribute despite the capability of the SQL to effect reference to objects via the Library List [when the DEFAULT is unchanged for the PATH and\or SCHEMA and the Naming Option is *SYS].

If the "Schema list" is reflective of the JDBC Librarylist property, then here is some docs specific to that; including description of the how the DEFAULT I noted above plays a role:
<http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/rzahh/jdbcliblistproperty.htm>