SQL7017

[TARASIK]

Hallo Holly,
hast Du Dein Problem mit dieser Meldung schon gelöst und
wenn ja wie. Wir haben den gleichen Fehler.

[holly]

Hallo Holly,
hast Du Dein Problem mit dieser Meldung schon gelöst und
wenn ja wie. Wir haben den gleichen Fehler.

Hallo Tarasik,
das Problem ist bei mir weg, wodurch weiß ich nicht genau.
Ich habe die Bibliothek, die ich eigentlich anlegen wollte (mit Commit [qsqjrn] usw.) von unser Prod.maschine rückgespeichert. Nach einem weiteren IPL ging es dann.
Gruss Holger

[Fuerchau]

Der Unterschied liegt in der Art der Lib:
Um über SQL eine Lib anzulegen (und das macht scheinbar der OpsNav) wird "CREATE COLLECTION" verwendet. Dies setzt aber COMMIT(*CS) als Minimum voraus, da die Lib sonst nicht angelegt werden kann.
SQL erzeugt dann automatisch Journal und Empfänger sowie Sichten der SYSxxx-Files (SYSTABLES, SYSCOLUMNS usw).
Anschließend ist natürlich ein COMMIT erforderlich, sonst wird die Lib gleich wieder gelöscht.
Ich kann dies auch per SQL direkt durchführen.
Wird dann ein CREATE TABLE in dieser Lib durchgeführt, muss auch das Commited werden. Mit Rollback ist die Tabelle wieder weg. Die Tabelle wird dann auch automatisch im Journal der Lib aufgezeichnet.

[TARASIK]

Hallo Fuerchau,
das Problem ist, dass ein Operator den Systemnamen
geändert hat und seitdem bei den Anwendungen
und im OPSNAV dieser SQL7017 mit Commit Verweis
kommt, obwohl kein Commitment benutzt wird.

[Fuerchau]

Vielleicht kommt der OpsNav nicht damit zurecht, wenn der Systemname vom DB-Namen (WRKRDBDIRE) abweicht ?

[BenderD]

Hallo,

das ist definitiv kein Problem. maybe the ipl? nach dem Motto: ein Boot tut gut.

Dieter Bender

Vielleicht kommt der OpsNav nicht damit zurecht, wenn der Systemname vom DB-Namen (WRKRDBDIRE) abweicht ?