Zugriff über ODBC und MS Access

[BenderD]

Ja, das habe später dann auch noch einen Beitrag mit der QZDAPKG gefunden.
Nur kann ich diese nicht löschen , da da immer ca. 5-n Jobs (QZDAINIT + QZDASOINIT) drauf glucken.
Und das System ist 7*24 Stunden im Zugriff...

- ALCOBJ
- WRKOBJLCK und rausfeuern
- delete SQLPPKG
... und wenn einer anruft und meckert, dass da was nicht geht, sagst Du: "Ich kümmer mich sofort drum" und bist der King, weil Du das so schnell hingekriegt hast

D*B

[andreaspr@aon.at]

... und wenn einer anruft und meckert, dass da was nicht geht, sagst Du: "Ich kümmer mich sofort drum" und bist der King, weil Du das so schnell hingekriegt hast

Den merk ich mir! :-)

[holgerscherer]

Den merk ich mir! :-)

Wie? Der war neu? Das ist seit Jahrzehnten übliche Vorgehensweise.

Im Notfall: mach was kaputt, und nach drei Anrufen reparier es wieder

-h

[KingofKning]

Deswegen bin ich froh das es immer mehr IP-Telefon gibt.
Bei Netzwerkausfall ruft keiner mehr an. Himmlisch diese Ruhe......

GG

[malzusrex]

Hmmm,
alle Pakete aus der QGPL gelöscht.
MS Access angeworfen, und der gleiche Fehler.
Es wurden 2 Pakete angelegt.
MSACCESFBA
QZDAPKG
Jetzt heißt es weiter suchen.
An sonsten sind auf dem System nur noch 2 Pakete in der QSYS.
QSQLPKG2
QSQXDPKG
Dies habe ich mal stehen lassen. Kann man die löschen...??

Gruß
Ronald

[Fuerchau]

IP-Telefon über Mobil? Das mach Sinn...

Durch OS-Wechsel/Updates kommt es schon mal in der QSYS2 und den angehängten Views SYSxxx zu Problemen. Ein Kunde hatte das auch schon mal, dass ganze Bibliotheken oder auch nur einzelne Dateien in den SYSCOLUMNS u.s.w. fehlten. Hierfür dient der RCLDBXREF.
In wie weit der auch fehlende Prozeduren und Funktionen nachregistriert kann ichnicht sagen.
Hier kommt es auf den Versuch an.
Schau mal im funktionierenden System in die SYSPROCS. In Routine:Body und EXTERNAL_NAME sieht man die ausführenden Programme.
Als Installer sieht man den QLPINSTALL, ggf. gibt es auch hierfür noch mal eigenene Aufrufe falls es der RCLDBXREF nicht macht.

Ggf. könnte der OpsNav die DDL für das Create Procedure aus dem funktionierenden System anzeigen, dann brauchst du diese auf dem fehlerhaften System nur aufzurufen.

Besser wäre da schin ein IBM-eigenes Programm, ggf. Fehler bei IBM aufmachen.

[malzusrex]

Das Problem ist weg.
Die Maschine war neu, und ist erst vor wenigen Wochen in Betrieb genommen worden.
Nach der Installaion war alles in Ordnung. Und dann muss irgend wann mal was falsches zurück gespeichert worden sein....
Jedenfalls stand bei der Anzeige der installierten Lizenprogramme bei folgenden Produkten BACKLEVEL

5770SS1 V7R1M0 L00 Bibliothek QGPL
5770SS1 V7R1M0 L00 Bibliothek QUSRSYS
5770SS1 V7R1M0 L00 IBM i

Nachdem diese 3 nocheinmal Insalliert worden sind, klappt es dann auch so, wie es soll.
Danke für eure Mithilfe
Gruß Ronald

[holgerscherer]

Jedenfalls stand bei der Anzeige der installierten Lizenprogramme bei folgenden Produkten BACKLEVEL

Das passiert gern und schnell. Bei QGPL/QUSRSYS reicht es, irgend ein beliebiges Objekt Q* vom Altsystem zu laden und es springt auf Backlevel

Ich vermute, da ist noch mal ein SQL Package zurück geholt worden.

-h