PREPARE Statement Problem -- RPG400-L

I have been writing my first SQLRPGLE program and, while I have usedinteractive SQL for quite awhile, the experience has been, shall we say,illuminating. But I'm puzzled about a few seemingly elementary problems.

The scenario is that there are two systems here. The idea is toprogrammatically push transactions from A to B. Simple enough - I thought.

As I interpreted the SQL manual and Birgitta, et al's Redbook, the bestmethod was to use the PREPARE statement to create the INSERT statement.Below is, I think, the relevant code. It compiles and creates the SQLpackage on System B when compiled on System A.



D DsHeader      E DS                  ExtName(Header)

 HdrString = 'INSERT Into SERVOHOLD/HLTKON Values(:DsHeader)';

C/Exec SQL  Prepare HeaderSQL from :HdrString

C/End-Exec

C/EXEC SQL    EXECUTE HeaderSQL

C/End-Exec

However, nothing got pushed. The job log had: Prepared statement *N notfound.

Lower level message included:

Cause . . . . . : An EXECUTE statement referred to the statement *N.*N isnot a valid prepared statement. The statement has one of thefollowingconditions:-- The statement has never beenprepared.-- The statement identifies a prepared SELECT or DECLAREPROCEDUREstatement.-- The statement was in error at prepare or bindtime.and a few other things, but the error seemed to be the last one.

STRDBG didn't tell me much (if anything) and a DUMP after the PREPAREyielded as much (nada).


After I replaced the EXECUTE statement with the hard-coded INSERT statement:

C/Exec SQLC+ INSERT Into SERVOHOLD/HLTKON Values(:dsheader)C/End-ExecIt worked.

Originally, the HdrString line looked like this:

HdrString = 'INSERT Into ' + %trim(Library) + '/' + %trim(HdrFile) +

' Values(:dsheader)';Which was the whole reason for using the PREPARE statement: To make theprogram variable-driven, not hard-coded.

Any idea what my faux pas is (other than trying to sound classy by usingFrench)?

Another concern I have is with the CONNECT statement. Until I added myuser id and password, the connection failed. Hard-coding, or evenpassing, user ids and passwords is not, in my estimation, goodpractice. I'm working on alternatives, but is there a way to configureSystem B to accept the connection without the user id and password, atleast, in this context?