Dear Rob
>>>> Which basically forces me to rebuild the sql package on each target machine. Heck I'm not even calling a stored procedure on each target system so why do I need the package? <<<<
Based on what I find in this article : Enable Programmatic Access to Remote DB2 Data Using DRDA at https://www.itjungle.com/2008/11/19/fhg111908-story02/ , it seems that your wish is not granted. I guess the answer is that this is the way DRDA is designed and you are using DRDA whenever you acces remote DB2 database.
Since your procedure accesses remote DB (DRDA), it appears you cannot avoid the use of SQL package in all systems involved in DRDA. If you use embedded SQL, you can create the remote SQL package automatically using a parameter in CRTSQLRPI command. But for a stored procedure that uses DRDA, you must manually recreate SQL packages in all systems involved whenever you change the procedure code with CRTSQLPKG PGM(ROB/PROPA00001) and then save the SQL package into a save file and send it to be restored in all the remote systems involved.
------------------------------
Chance favors only the prepared mind.
-- Louis Pasteur
------------------------------
Satid S.
------------------------------
Original Message:
Sent: Tue October 17, 2023 08:37 AM
From: Robert Berendt
Subject: How to create a sql procedure which doesn't propagate a sql package to the remote system?
I have a sql stored procedure which basically looks like the following:
CREATE PROCEDURE robxyz.PROPAGATE_QLNKOMT()
LANGUAGE SQL MODIFIES SQL DATA
SET OPTION DATFMT = *ISO
P1 : BEGIN
DECLARE OMIT_LIST CHARACTER VARYING ( 32000 ) ;
SELECT FSXCMD INTO OMIT_LIST
FROM QUSRBRM . QA1AFS
WHERE FSNAME = 'QLNKOMT'
;
UPDATE GDI . QUSRBRM . QA1AFS
SET FSXCMD = OMIT_LIST
WHERE FSNAME = 'QLNKOMT' ;
...
...
...
The problem is, when I make a change to it and call it again the UPDATE GDI ..... statement fails to do the desired updating and I get:
SQL0818 - Consistency tokens do not match -
Cause . . . . . : Package PROPA00001 in ROB on application server GDIHQ cannot be run with the current application program because either the application program has been recompiled without rebuilding the package or the package has been restored from a back level version. Recovery . . . : Rebuild the package by using the CRTSQLPKG command or by using a CRTSQLxxx command specifying the correct relational database. Otherwise, restore the package from a version which matches the application program being run.
Which basically forces me to rebuild the sql package on each target machine. Heck I'm not even calling a stored procedure on each target system so why do I need the package? Is there some option on CREATE PROCEDURE to it not to need a target sql package? Like a SET OPTION statement or some such thing?
I didn't see an option on the CALL to handle this
------------------------------
Robert Berendt IBMChampion
------------------------------