Re: IBMDA400 connection string to specify library list to use

On 12-Mar-2015 12:59 -0500, Jeff Young wrote:

I have a client that is using .Net with the IBMDA400 OLEDB client to
connect to the IBM i system.
Since the files that they are attempting to update have a trigger
that uses a file not in the default schema as the file being updated,
how should the library list be set?

Likely best, would be to handle the situation in that environment, in the same way that situation would be handled elsewhere; e.g. a CLP that sets up the /application environment/ would be called for\by the client application just as is done if\when instead running directly on the server. If that CLP is an Initial Program (INLPGM) for a user or Routing Program for a subsystem, then the portion of that program that establishes\sets the library may best be separated\decoupled for a CALL from the stored procedure that is called from the client or is called from the client before the [currently failing] request is made from the client. Note: There are client-specific /special registers/ that can be set, and then seen by the server, if the server processing must make decisions based on such input rather than based upon parameters passed on a CALL to a stored procedure that instruct what to perform.

They tried using the JDBC format of Library List =,

Perhaps the relevant portion of the connection string would be composed as the following which should ask to have a library-list including first the library of the Table being updated [called UPDTBLLIB], second the library of the file reference by the Trigger program [called TRGTBLLIB], and last the libraries of the default\original User-portion of the library list established in the server job from the defaulted WM setup:
"Naming=System; LibraryList=UPDTBLLIB, TRGTBLLIB, *USRLIBL;"

but received an error *Message:
System.Data.OleDb.OleDbException: PWS0082: 6 library(s) not added to
the library list.*

Seems an odd consequence for that "Library List =," specification, even if unsupported syntax. Perhaps the effect is due to the intended /replacement/ of the library list for that LibraryList directive, with the server job having tried to re-add the library names from the original *USRLIBL onto the end of the User Library List after adding the specified [though effectively omitted] library name, despite never previously having removed them via a CHGLIBL LIBL(*NONE) due to the effectively empty-string [of comma-separated library names] being misinterpreted; i.e. having never removed the libraries in the defaulted UsrLibl, each ADDLIBLE request would fail because they are already there. If the defaulted WM does not establish six libraries in the UsrLibl, then obviously that speculation is easily debunked.