[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Aug 2001
    Beiträge
    237

    CRTSQLPKG schlägt fehl

    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

  2. #2
    Registriert seit
    May 2002
    Beiträge
    2.641
    Hallo Christian,
    vielleicht hilft Dir dieser Link weiter ?

    http://itknowledgeexchange.techtarge.../qaqqini-file/

  3. #3
    Registriert seit
    Aug 2001
    Beiträge
    237
    Hallo Tarasik,

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

    gruss christian

  4. #4
    Registriert seit
    May 2002
    Beiträge
    2.641
    Hallo Christian,
    eigentlich schon, denn wie kam die QAQQINI in die Qusrsys ? Was steht in den chgqrya ? Was wurde in der QAQQINI angepasst ?

  5. #5
    Registriert seit
    Aug 2001
    Beiträge
    237
    Hallo,

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

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Aug 2001
    Beiträge
    237
    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.

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  9. #9
    Registriert seit
    Aug 2001
    Beiträge
    237
    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.

  10. #10
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  11. #11
    Registriert seit
    Aug 2001
    Beiträge
    237
    Genau ...

    Wir haben an unserer Warenwirtschaft auch eine PC-Kasse angebunden.
    Diese arbeitet lokal mit einer DB2-Instanz, also auch Stand-Alone wenn rundum alles abgeraucht ist.
    Wenn man dann mal auf 50 Kassen irgendwelche Datenleichen rausreorganisieren muss oder ähnliches, ist so ein kleines Programm was remote nacheinander auf alle Datenbanken connectet gar nicht so schlecht.

    Erspart einem einiges an Zeit.

  12. #12
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Nur mal so eine Frage: Welches Naming wird den beim Erstellen verwendet?
    Könnte es sein, dass die Erstellung auf dem einen System mit *SQL-Naming und auf dem anderen mit *SYS-Naming erstellt wird bzw. werden soll?

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

Similar Threads

  1. VA RPG Read anweisung schlägt fehl
    By Peter Kosel in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 18-10-01, 13:49

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •