Ok... The consensus solution was to explicitly create an *SQLPKG on
the remote LPAR/server. This won't work because the program is never
installed to the remote LPAR/server and an *SQLPKG object apparently
cannot exist unless it is. I need new ideas.
Here's the deal:
I've a process that will run on a local LPAR/server that will consume
data from a remote LPAR/server. The program will only exist and run
on the local LPAR/server, never on the remote.
The program uses 3-part naming in its SQL to identify the remote
server.schema.table. Because of this, the program will normally
implicitly create the *SQLPKG on the remote LPAR/server. In the
compile command (CRTSQLRPGI) of the local program object, this
*SQLPKG is directed to be created in QTEMP. No reason for QTEMP
beyond ease of testing. This will allow the local program to process
As Charles indicted earlier in the thread, the implicitly created
remote *SQLPKG object is created using the object creator, not the
object owner or job current user. It doesn't use the profile used to
establish the CONNECTION either. Because the object creator doesn't
exist on the remote LPAR/server, the implicit creation of the
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.