implied CRTSQLPKG weirdness - uses creator of program as RDB user in creating SQLPKG?

We are at V7R2M0 on all referenced IBMi's.

I've a process (RPG with imbedded SQL) that will read data from a remote IBMi DB, process it, persist it to the local IBMi DB, delete the remote row and move to the next in a loop.

This thing works just fine in the development environments. When the need for an SQLPKG arises, the package is automatically created on the remote as needed. The program object is created using a profile that is available on both the remote and local machines. As weird as this seems to me, this will become important.

As we move to the next level of testing, the creator is that of the move coordinator, who does not have a valid user profile on the remote machine. This seems to be causing an issue.

As the programs runs, the need to create the SQLPKG on the remote arises. Rather than use the profile that is running the process as the RDB user ID, it is retrieving the move coordinator profile that created the program to create the SQLPKG. Because this profile does not exist on the remote machine, the package creation fails. Which causes the process to fail.

5770SS1 V7R2M0 140418 Create SQL package 09/16/15 09:25:05 Page 1
Record *...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 SEQNBR Last change
Program name..............Library/PROGRAM_NAME
Relational database.......S0000000
User .....................Current_User
Replace...................*YES
Default collection........*PGM
Generation level..........31
Printer file..............*LIBL/QSYSPRT
Object type...............*PGM
Module list...............*ALL
Text......................*PGMTXT
Source file...............temp_lib_used_by_src_ctl/QRPGLESRC
Member.................... PROGRAM_NAME

MSG ID SEV RECORD TEXT
SQL0204 30 THE_MOVE_COORDINATOR in QSYS type *USRPRF not found.
SQL5056 SQL package creation for module PROGRAM_NAME failed.
Package name was to be PROGRAM_NAME in QTEMP at REMOTE_SYSTEM.

Not sure how to proceed. While it appears that the SQL0204 error is the killer, I can't even find SQL5056 on IBM's website. I expect that I'll have to ask IBM about it, but thought I would share this with you all.

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