Anmelden

View Full Version : CRTSQLPKG schlägt fehl



Seiten : [1] 2

Flappes
23-07-14, 07:08
Hallo,

ich habe ein Programm welches auf eine Remote-DB2 auf einem PC geht.
Vor Aufruf muss hier ja ein SQLPKG erstellt werden.
Mit folgendem Befehl wird er erstellt:
CRTSQLPKG PGM(XYZ) RDB(DATABASE1) USER(DB2ADMIN) PASSWORD()

Auf unserem System mit V5R4 funktioniert es. Bei unserem Kunden mit V7R1 bekam ich erst die Fehlermeldung das das Objekt QAQQINI in QUSRSYS nicht gefunden wurde. Dieses steht normal nur in QSYS.
Dann habe ich diese Datei samt Inhalt einfach in die QUSRSYS kopiert.

Nun bekomme ich beim Erstellen folgende Fehlermeldung:
SQ30104 30 Binde- oder Vorkompilierungsoption FUNCPATH mit Wert
"QSYS","QSYS2","SYSPROC", "USER" nicht
gültig.
SQL5056 SQL-Paketerstellung für Modul XYZ fehlgeschlagen.
Paketname sollte XYZ in LIB in DATABASE sein.

Wie liegt hier mein Problem?

gruss Christian

TARASIK
23-07-14, 07:42
Hallo Christian,
vielleicht hilft Dir dieser Link weiter ?

http://itknowledgeexchange.techtarget.com/itanswers/qaqqini-file/

Flappes
23-07-14, 07:54
Hallo Tarasik,

danke für die schnelle Antwort.
Leider steht da nichts brauchbares für mich drin.

gruss christian

TARASIK
23-07-14, 08:06
Hallo Christian,
eigentlich schon, denn wie kam die QAQQINI in die Qusrsys ? Was steht in den chgqrya ? Was wurde in der QAQQINI angepasst ?

Flappes
23-07-14, 08:37
Hallo,

Die Datei habe ich aufgrund der ersten Fehlermeldung in die QUSRSYS kopiert.
Im CHGQRYA steht bei QRYOPTLIB(QUSRSYS)

Fuerchau
23-07-14, 10:21
Entscheidend ist die Art der Kopie.
Die QAQQINI muss per CRTDUPOBJ kopiert werden!
Ein einfaches CPYF reicht nicht, da bestimmte Trigger aktiviert sein müssen.

Aber ein Fehler der QAQQINI sollte kein Problem darstellen, da dann Defaults gelten.

Das Problem könnte ggf. das QZDAPKG in der QGPL sein, wobei bei DRDA QZDASONIT eigentlich nicht verwendet wird.
Ich vermute eher, dass die Lib, in die das Paket erstellt werden soll nicht vorhanden ist:
Siehe CRTSQLPKG DFTRDBCOL(*PGM).
Gib an dieser Stelle mal gezielt die Ziellib an, dann SQL wählt ansonsten den angemeldeten User für die DB.
Zusätzlich sollte sichergestellt sein, dass das Paket auf dem Zielsystem ersetzbar ist (Berechtigung) oder ggf. vorher gelöscht werden.
Nach der Erstellung des Paketes steht die Berechtigung übrigens auf *PUBLIC *EXCLUDE, so dass außer dem Ersteller/Eigner niemand was damit anfangen kann.

Flappes
23-07-14, 10:54
Die Datei habe per CRTDUPOBJ und Auslöser erstellt.
Auch eine Ziellieb beim Erstellen des Packages bringt keine Änderung.
Es kommt immer noch die Meldung mit der Binde oder Vorkompilierungsoption.

Fuerchau
23-07-14, 11:09
Ggf. verwendest du UDF/Procedures im SQL-Paket, also im Programm, die bei der Erstellung auf dem Zielsystem nicht gefunden werden können (Hinweis FUNCPATH).
Die Frage ist, ob eben die Libs SYSPROCS und USER (ggf. der Anmeldeuser) vorhanden sind.

Dies liegt dann wieder an der Libliste, da hier nur die Defaults der QSYSLIBL und ggf. QUSRLIBL ziehen, falls die SQL-JOBD (ich weiß aber nicht welche) darauf verweist.
Alternativ musst du mal das Porgrammobjekt auf das Zielsystem übertragen und den CRTSQLPKG dann lokal mit der korrekten LIBL durchführen.

Flappes
23-07-14, 11:59
Ich hatte das Programm auf dem Kundensysem erstellt.
Nun habe ich es von unserem Entwicklungssystem als Objekt rüber geschoben.
Und nun geht auch der CRTSQLPKG.

Problem also erstmal gelöst.

Fuerchau
23-07-14, 12:32
Wofür benötigst du das überhaupt?
Das CRTSQLPKG wird ja nur gebraucht, wenn ich per CONNECT mit einer anderen DB2/400 arbeiten muss. Nur in diesem Fall muss das SQLPKG auf dem Zielsystem in einer verfügbaren Lib vorhanden sein.