Jobs lassen sich nicht beenden

[JonnyRico]

Hi,

ich habe da ein Problem mit Sitzungen in QINTER die sich einfach nicht beenden lassen. Das Problem ist das eine Datenbank auf unserer Maschine gerade reorganisiert wird. Wenn ich nun versucht in die PF zu schreiben bleibt die Session hängen und lässt sich nicht mehr beenden. Auch mit ENDJOB OPTION(*IMMED) tut sich nichts. Der Status ist END aber die Einheit wird nicht wieder frei, da der Job sich nicht entgültig schließt. Kann mir jemand vielleicht einen Tip geben was ich machen kann??

mfg

Sascha

[TARASIK]

Hallo Sascha,
probiere es doch mit "endjobabn" und F4 und F10

[Pikachu]

Hallo Sascha !

Da hilft vermutlich nur abwarten.

Im Hilfetext zum RGZPFM steht folgendes:

Während der Reorganisation einer physischen Teildatei ist die betreffende Datei für die Dauer des Befehls RGZPFM gesperrt (entspricht einer *EXCL-Sperre ohne Zeitlimit), so daß kein Zugriff möglich ist. Gleichzeitige Versuche eines anderen Jobs, eine Funktion zu benutzen, die auf die Datei verweist, können zu einer "Sperre" der betreffenden Datenstation führen", bis die Ausführung des Befehls RGZPFM beendet ist.

Viele Grüße
Jürgen

[JonnyRico]

Danke für die schnellen Antworten. Pikachu ich fürchte du hast recht. ENDJOBABN hat auch nichts geändert. Ob es vielleicht was bringt wenn ich QINTER heute abend mal beende oder meint ihr das verschlimmert die Sache noch??

[TARASIK]

Hallo,
ich habe zu dem endjobabn noch folgendes:

ENDJOBABN has been known to take down jobs that are too stubborn for ENDJOB. But it has a few limitations that you need to be aware of. Specifically, the following things affect ENDJOBABN use:
ENDJOBABN cannot be run against a job before you've attempted to end the job through the ENDJOB command, with *IMMED specified in the "how to end" parameter. OS/400 is also hard-coded to ignore an ENDJOBABN statement until 10 minutes have passed since you ran an ENDJOB *IMMED command on the same job. So not only do you have to run ENDJOB for a problem job before using ENDJOBABN, you also have to give ENDJOB time to work.

ENDJOBABN is shipped with *PUBLIC *EXCLUDE authority. And to run ENDJOBABN, you need job control (*JOBCTL) authority in your user profile.

ENDJOBABN can be run against a job only once. Additional ENDJOBABN commands can't be run.
So if you keep these restrictions in mind, ENDJOBABN can be a powerful addition to your OS/400 system administrator toolkit, and be the thing you reach for when you can't end a job any other way.

[Pikachu]

Hallo Sascha !

Das ENDJOBABN geht frühestens 10 Minuten nach Beginn einer sofortigen Beendigung des entsprechenden Jobs (siehe Hilfetext zum ENDJOBABN).

Das Subsystem QINTER solltest du unter KEINEN Umständen beenden! (Außer ihr habt noch andere Subsysteme für interaktive Arbeiten) Hierdurch wird auch nur ein ENDJOB *CNTRLD oder *IMMED für die enthaltenen Jobs sowie das Subsystem durchgeführt. Zusätzlich bleibt dann auch das Subsystem im Status END stehen. Dann kann sich aber niemand mehr in diesem Subsystem anmelden bis es wieder gestartet wurde !!!

Kannst du die Reorganisation nicht irgendwie abbrechen? Aber Vorsicht: Lies unbedingt den Hifetext zum RGZPFM durch, eventuell musst du nach dem Beenden einige Zugriffspfade neu aufbauen.

Viele Grüße
Jürgen

[Fuerchau]

Das mit den Reorgs im laufenden Betrieb ist halt so eine Sache.
Es stimmt schon, solange ein RGZPFM läuft wird alles angehalten was diese Resource benötigt und ist NICHT killbar.
Also auch ein ENDSBS ändert nichts daran, da der auch nur ENDJOB an seine Job's weiterleitet. Da hilft nur eins: warten !

Übrigens: mittels "CHGPF FILE(MYFILE) REUSEDLT(*YES)" spart man sich die Reorgs !

[Pikachu]

Hallo Sascha !

Wenn du die Sitzungen für andere Arbeiten brauchst und ihr Client Access (iSeries Access) oder sonst eine Telnet 5250 Terminalemulation habt, kannst du eventuell diesen Sitzungen (vorübergehend) einen anderen Sitzungsnamen geben. Dann entstehen neue Sitzungen an denen wieder normal gearbeitet werden kann.

Und dann sollten natürlich die Dateien, die gerade reorganisiert werden, gemieden werden.

Die anderen beendeten Sitzungen fallen dann irgendwann von selbst raus wenn die Reorganisation fertig ist ...

Viele Grüße
Jürgen

[JonnyRico]

Hi,

nochmals vielen Dank. Ich werde also QINTER nicht beenden. Am PC ist's ja kein Problem mal eben ne andere Sitzung zu nehmen nur an den Terminals gestalltet sich das natürlich schwieriger. Ich habe jetzt erst mal ein PF mit dem selben Namen in einer anderen LIB angelegt, sodass die Anwendung auf diese Datei zugreift. Nach der Reorganisation muss ich die Daten dann nur noch mal in der anderen neu erstellen lassen.

mfg

Sascha

[Hubert]

Hallo Fuerchau,

Übrigens: mittels "CHGPF FILE(MYFILE) REUSEDLT(*YES)" spart man sich die Reorgs !

Damit handelt man sich aber Probleme beim Journalisieren bzw. Rollback ein. Daher würde ich das nicht machen.

Hubert

[JonnyRico]

Jetzt ist aber wieder alles im Lot. Nachdem er mit dem Reorg fertig war haben sich alles Jobs die hingen und bereichts auf "End" standen sofort beendet.

[Fuerchau]

@Hubert

Tut mir Leid das sagen zu müssen, aber diese Aussage ist GRUNDFALSCH !!!
Wenn du per SQL einen CREATE TABLE erstellst, wird diese PF IMMER mit REUSEDLT(*YES) erzeugt, da SQL keinen Reorg kennt !

Die Journalisierung funktioniert sogar sehr gut und damit auch COMMIT/ROLLBACK !

Ich habe allen meinen Kunden bisher immer empfohlen REUSEDLT(*YES) auf alle Dateien (auch Fremdanwendungen) anzwenden um die stundenlangen Reorgs (manchmal auch tagelangen) zu vergessen !
Je nach Anwendung entfällt auch die ständige Erweiterung der Datei da häufig in sog. Arbeitsdateien nur 1000de Sätze erstellt und wieder gelöscht werden.
Ich habe bereits Dateien gefunden, die mehrere Millionen gelöschte Sätze enthielten aber keinen echten Satz mehr.
Eine Sortierung nach Eingangsfolge wird eigentlich nicht mehr verwendet, da man doch immer über Schlüssel und damit sortiert auf die Daten zugreift.

Im Gegenteil:
RGZPFM stellt ein Problem bei der Journalisierung dar, da diese Anweisung nicht repliziert werden kann.
Also, wenn ich e.g. meine DB wiederherstellen muss um anschließend per Journal meine Daten wiederherstelle funktioniert das nur bis zum RGZPFM. Alle nachfolgenden Journaleinträge kann ich nicht mehr verwenden !

Dazu muss man verstehen, dass die Journaleinträge mit ihrer RRN auf die Datei verweisen um Sätze wiederherstellen zu können. Nach einem RGZPFM stimmen aber die RRN's nicht mehr.
Verschärft wird das Problem noch, wenn man beim RGZPFM eine LF für die Sortierfolge angibt. Dies wird im Journal nicht aufgezeichnet ! Zumal wenn die LF auch noch temporär angelegt wurde.

Fazit:
Mit REUSEDLT(*YES) spart man nicht nur Platz sondern auch jede Menge Zeit !