Jobs lassen sich nicht beenden

[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 !

[Fuerchau]

@Jonny

Der Reorg hat ja anscheinend mehrere Tage beansprucht !
Prüfe doch mal ob REUSEDLT(*YES) da nicht besser wäre (von wegen Key und so...)

[Hubert]

@ Fuerchau

Danke für diese Info, da war ich wohl falsch informiert.

Gruss

Hubert

[JonnyRico]

Hi,

REUSEDLT steht sogar auf "YES", aber es handelte sich um wirklich viele gelöschte Sätze und ich brauchte dringend den Speicherplatz. Dann ist doch wirklich der einzige Weg das ich die PF reorganisiere oder nicht? Wenn ich REUSEDLT auf *YES setze, dann wächst die Datei doch für soviele Sätze nicht wie gelöschte vorhanden sind und erst dann wieder. Das sehe ich doch richtig oder?

mfg

Sascha

[BenderD]

Hallo Sascha,

Hi,

REUSEDLT steht sogar auf "YES", aber es handelte sich um wirklich viele gelöschte Sätze und ich brauchte dringend den Speicherplatz. Dann ist doch wirklich der einzige Weg das ich die PF reorganisiere oder nicht? Wenn ich REUSEDLT auf *YES setze, dann wächst die Datei doch für soviele Sätze nicht wie gelöschte vorhanden sind und erst dann wieder. Das sehe ich doch richtig oder?

mfg

Sascha

CREATE TABLE ttt as select * from DateiMitGeloeschten with data

CLRPFM DateiMitG (von OS/400 versteht sich)

INSERT into DateiMitGeloeschten SELECT * from ttt

sollte schneller sein.

Die Datei brauchst Du für den Reorg ja auch exclusive, also am Besten zu Beginn einen ALCOBJ.

Wenn eine Datei auf REUSEDLT *YES steht und zahlreiche gelöschte hat, dann ist entweder in der Applikation was merkwürdig, oder der Reorg bringt nix, weil sie dann morgen wieder genauso groß ist wie heute.

mfg

Dieter Bender

[Fuerchau]

@Dieter

Mit CPYF (halt ohne SQL) gehts genauso schnell, wenn nicht gar schneller !
Allerdings sollte man prüfen (DSPFD) ob FRCRATION auf *NONE steht.
Sowohl der SQL-Insert als auch der CPYF können dadurch um Faktor >100 verlangsamt werden falls das nicht der Fall ist.

@Sascha

Das siehst du richtig, aber ich stimme Dieter zu, dass da etwas mit der Anwendung nicht stimmt. Ich kenne das auch von diversen BRAIN-Dateien, die sich temporäre Daten für den Job merken. Wenn der Job weg (erledigt) ist, wird zwar gelöscht aber ich habe große gelöschte Bereiche.
Für diese Dateien machen wir beim IPL einen CLRPFM, da ja dann keine Job's von BRAIN mehr aktiv sein können.
Vielleicht ist das bei dir ja ähnlich ?

PS:
FRCRATIO könnte auch der Grund für den ultralangen Reorg sein !

[BenderD]

@Baldur

CPYF hatte ich wohl verdrängt
was das schneller angeht: it depends; Du hast sicher für die meisten Installationen recht (CPYF hat wenig Overhead), aber SQL kann mehrere Prozessoren nutzen (mit parallel Database Feature) und da kann sich das auch rumdrehen.

Dieter Bender