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 remote data.

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 *SQLPKG fails.

Ideas?

Steve Needles

________________________________
This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies.

TRVDiscDefault::1201

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].