endsbs für Qinter beendet sich nicht

[TARASIK]

Hallo Forum,
vor der Nachtsicherung soll das Qinter beendet werden, was auch generell funktioniert, nur wenn die NC's die über einen
Citrixserver angeschlossen sind nicht korrekt beendet werden
dann lässt sich das Subsystem nicht beenden. Hat jemand eine Idee ?

[Fuerchau]

Dann gibt es immer noch den *IMMED mit max. Wartezeit (z.B. 300 Sekunden).
Das killt auch die anderen Dialog-Job's.

[BenderD]

@Baldur:

war das nicht *CONTROLLED mit DELAY(xxxx)?
im übrigen habe ich schon Subsysteme gesehen, die damit auch nicht totzukriegen waren, da ging nur noch der PWRDWNSYS dran (eins vor dem reset Knopf) allerdings war in denen WebsFear gestorben.

mfg

Dieter Bender

Dann gibt es immer noch den *IMMED mit max. Wartezeit (z.B. 300 Sekunden).
Das killt auch die anderen Dialog-Job's.

[Fuerchau]

Stimmt !
Der Default bei ENDSBS steht nur auf *NOLIMIT und sollte angepasst werden.

[TARASIK]

Hallo Fuerchau und hallo Dieter,
danke für die Antworten. Das mit dem Delay ist schon nicht
schlecht, aber es funktioniert aber nicht da im Qinter diese
Jobs bereits auf end stehen und nicht beendet werden können. Diese "Deadlocks" kommen von Usern die ihre
Arbeit beenden und nach Hause gehen und ihre Sessions nicht
abmelden. Es passiert auch nicht immer und das Problem ist
dann beim Hochfahren da wird das Subsystem nicht korrekt gestartet, da sie ja laut Meldung schon gestartet werden und
dadurch Logs erzeugen. Beendet werden sie nur wenn man *nowrap auswählt, aber wir müssen mit *wrap arbeiten.

[Fuerchau]

Tja, da hilft dann nur ein ENDJOBABN, der allerdings dann wieder 10 Minuten (nicht veränderbar) wartet. Ausserdem benötigt dieser die genaue Jobbezeichnung, die wieder nur per API (List Jobs) abfragbar sind.

Dass das Problem mit *wrap/*nowrap zusammenhängt deutet auf einen IBM-Fehler hin, der mal gemeldet werden sollte !!!

[BenderD]

Hallo,

wo genau gibst du da *nowrap an und wo findet der Neustart statt?
das hört sich für mich nur nach ziemlich großen Joblogs an (was normal
sein kann, oder auf ein Error PingPong im Endlos loop hindeuten kann).

mfg

Dieter Bender

Hallo Fuerchau und hallo Dieter,
danke für die Antworten. Das mit dem Delay ist schon nicht
schlecht, aber es funktioniert aber nicht da im Qinter diese
Jobs bereits auf end stehen und nicht beendet werden können. Diese "Deadlocks" kommen von Usern die ihre
Arbeit beenden und nach Hause gehen und ihre Sessions nicht
abmelden. Es passiert auch nicht immer und das Problem ist
dann beim Hochfahren da wird das Subsystem nicht korrekt gestartet, da sie ja laut Meldung schon gestartet werden und
dadurch Logs erzeugen. Beendet werden sie nur wenn man *nowrap auswählt, aber wir müssen mit *wrap arbeiten.

[Fuerchau]

Ich stimme da Dieter voll zu.
Wieso sind die Joblog's überhaupt so groß ?
Im Gegensatz zu früher (ich glaube V3) werden ja die Nachrichtentexte nicht mehr im Joblog gespeichert sondern nur noch die MSGID's und die Daten dazu. Dies ergibt erheblich mehr Platz.
Prüfe mal, ob du unbedingt einen LOGCLPGM benötigst und was sonst noch so im Joblog auftaucht.

Kein Wunder, dass der ENDSBS dann so lange dauert, da das Joblog ja erst noch gedruckt werden muss (ggf. mehrere 10.000 Seiten). Das kann da schon mal dauern.
Da hilft übrigens auch kein ENDJOBABN mehr, der ja auch ein Joblog produziert.

Vielleicht stehen die Job's ja dann auch auf MSGW, wenn der Spool (Joblog) 10.000 Seiten übersteigt.

Untersuche doch mal eher in diese Richtung.

Mittels RMVMSG kann man mal zwischendurch das Joblog bereinigen (z.B. im Menüprogramm).

Wie steht denn der Systemwert QDEVRCYACN ?
Stelle diesen doch am besten auf *ENDJOB wenn du Wiederanlaufverfahren hast.
Bei *DSCMSG wird der Job zwar getrennt, gilt aber weiterhin als Aktiv.

[BenderD]

Hallo,

mich irritiert immer noch der *NOWRAP
beim ENDSBS kann man als ENDSBSOPT(*NOJOBLOG) angeben, das könnte was bringen, könnte aber auch weniger gut sein, wenn ich wirklich einen aktiven Job umsäge, sind die Spuren weg.
Beim ENDJOB kann ich ein festes Loglimit angeben.
Der ENDJOBABN schert sich m.E. nicht um Joblogs, dafür sind die 10 Minuten Karenz vorher.
Den *WRAP kenne ich eigentlich nur als Job Attribut.

mfg

Dieter Bender

Ich stimme da Dieter voll zu.
Wieso sind die Joblog's überhaupt so groß ?
Im Gegensatz zu früher (ich glaube V3) werden ja die Nachrichtentexte nicht mehr im Joblog gespeichert sondern nur noch die MSGID's und die Daten dazu. Dies ergibt erheblich mehr Platz.
Prüfe mal, ob du unbedingt einen LOGCLPGM benötigst und was sonst noch so im Joblog auftaucht.

Kein Wunder, dass der ENDSBS dann so lange dauert, da das Joblog ja erst noch gedruckt werden muss (ggf. mehrere 10.000 Seiten). Das kann da schon mal dauern.
Da hilft übrigens auch kein ENDJOBABN mehr, der ja auch ein Joblog produziert.

Vielleicht stehen die Job's ja dann auch auf MSGW, wenn der Spool (Joblog) 10.000 Seiten übersteigt.

Untersuche doch mal eher in diese Richtung.

Mittels RMVMSG kann man mal zwischendurch das Joblog bereinigen (z.B. im Menüprogramm).

Wie steht denn der Systemwert QDEVRCYACN ?
Stelle diesen doch am besten auf *ENDJOB wenn du Wiederanlaufverfahren hast.
Bei *DSCMSG wird der Job zwar getrennt, gilt aber weiterhin als Aktiv.

[Fuerchau]

Genau das scheint ja das Problem zu sein. Steht der Job auf *nowrap, hält er irgendwann an (warum gibts auch so viele Einträge) und läßt sich wohl auch beenden.
Bei *wrap hält der Job zwar nicht an, läßt sich aber auch nicht beenden (was ich in diesem Fall absolut nicht verstehe).

Der ENDJOBABN funktioniert leider nicht, wenn die Ausgabe des Joblogs noch nicht fertig ist. Diese Erfahrung hatte ich schon mal.