Re: TERMINATE greift nicht immer ?

Geschrieben von Gernot Ruban on Dezember 29, 2001 um 15:15:

Als Antwort auf TERMINATE greift nicht immer ? geschrieben von Eva Amschler on Dezember 25, 2001 um 20:27:

Hallo Eva,

ich habe eine REXX Prozedur geschrieben (wenn ich nicht irre, auf der Site abrufbar), die Owner und Name eines DB2 Utility Jobs ermitteln kann - dies sind die (unique) Defaults für die Utility-ID. In der Regel setzen meine Kunden den Aufruf der REXX Prozedur vor den Step mit einem DB2 Utility - dies bereitet einen Job Restart vor.

Theoretisch kann solch ein Step auch einem Utility Step folgen, aber dann muss man auf die Condition Code Steuerung achten. Dies fände ich allerdings gar nicht gut!!! Stattdessen setzen meine Kunden nach einem gescheiterten DB2 Utility einen User Abend Code (beispielsweise U001), der garantiert vom Job Scheduler (z.B. OPC/TME 10) erkannt wird. Im Anschluß folgt eine "Recovery Action", um gezielt den Fehler zu beheben.

Eine Lösung, wie Du sie evtl. anstrebst, ist sehr gefährlich. Natürlich kann man jedem Objekt-Zustand mit einem TERM UTIL() oder START DB() TS() ACCESS(FORCE) begegenen. Das Objekt ist dann unter Umständen auch wieder (teilweise) verfügbar, aber die Konsistenz ist hinüber.

Ein Reorg kann in verschiedenen Phasen abbrechen! Manchmal reicht in der Tat das TERM UTIL(), aber meistens ist ein Indexspace oder der Tablespace hinüber. Sind dann die Unload Datasets noch verfügbar um einen Restart zu fahren? Oder muss ein RECOVER erfolgen?

Ich glaube, obige Lösung (REXX Prozedur mit Term Util Default ID für Job Restart) ist 'ne feine Sache. Nach Analyse des Fehlers einfach Job "re-run" beauftragen!

Gruß
Gernot

Antworten:

Schreibe eine Antwort

Name:
E-Mail:

Thema:

Kommentar:
: Hallo Eva, : ich habe eine REXX Prozedur geschrieben (wenn ich nicht irre, auf der Site abrufbar), die Owner und Name eines DB2 Utility Jobs ermitteln kann - dies sind die (unique) Defaults für die Utility-ID. In der Regel setzen meine Kunden den Aufruf der REXX Prozedur vor den Step mit einem DB2 Utility - dies bereitet einen Job Restart vor. : Theoretisch kann solch ein Step auch einem Utility Step folgen, aber dann muss man auf die Condition Code Steuerung achten. Dies fände ich allerdings gar nicht gut!!! Stattdessen setzen meine Kunden nach einem gescheiterten DB2 Utility einen User Abend Code (beispielsweise U001), der garantiert vom Job Scheduler (z.B. OPC/TME 10) erkannt wird. Im Anschluß folgt eine "Recovery Action", um gezielt den Fehler zu beheben. : Eine Lösung, wie Du sie evtl. anstrebst, ist sehr gefährlich. Natürlich kann man jedem Objekt-Zustand mit einem TERM UTIL() oder START DB() TS() ACCESS(FORCE) begegenen. Das Objekt ist dann unter Umständen auch wieder (teilweise) verfügbar, aber die Konsistenz ist hinüber. : Ein Reorg kann in verschiedenen Phasen abbrechen! Manchmal reicht in der Tat das TERM UTIL(), aber meistens ist ein Indexspace oder der Tablespace hinüber. Sind dann die Unload Datasets noch verfügbar um einen Restart zu fahren? Oder muss ein RECOVER erfolgen? : Ich glaube, obige Lösung (REXX Prozedur mit Term Util Default ID für Job Restart) ist 'ne feine Sache. Nach Analyse des Fehlers einfach Job "re-run" beauftragen! : Gruß : Gernot

Optionale Link URL:
Link Titel:
Optionale Image URL:

[ Antworten ] [ Forum ]