Systemstart analysieren

[Chris.jan]

Ich muß unseren Systemstart analysieren.
Unser BRMS beendet die Subsysteme (*ALL) und hat in der Steuerungsbeschreibung Restart auf *YES stehen. Entsprechend wird (wenn ich das richtig verstehe) QCTL (bzw. das angegebene Subsystem aus dem SYSVAL) gestartet - aber ich finde leider nirgens (jobd, sbsd) den Eintrag für das System-Startscript. Das ist ein eigens geschriebenes CL-Programm.

Ich habe nur in der Jobbeschreibung bei den Anforderungsdaten ein Programm gefunden, was laut OBJD aber nicht mehr benutzt wird.

Kann mir mal jemand helfen?

[Fuerchau]

Siehe Systemwert QSTRUPPGM.

[Chris.jan]

Das Programm ist noch original und wird von uns nicht genutzt.
Es wird ja auch kein ipl gemacht.
Es muss noch was anderes sein.

[Fuerchau]

Wenn da aber eins drinsteht, dann läuft auch dieses.
Ggf. mal mit RTVCLSRC nachsehen.

Wenn das steuernde Subsystem gestartet wird, startet auch das QSTRUPPGM.

[camouflage]

Wenn ich die Aussage richtig verstehe, macht die Maschine kein IPL.

Ich nehme mal an, das ist eher ein terminierter Job. Hast Du mit WRKJOBSCDE schon mal nachgeschaut?

Vielleicht findet sich ja da was.

[Pikachu]

QBASE und QCTL besitzen jeweils einen Autostartjob, der seinerseits das im Systemwert QSTRUPPGM hinterlegte Programm aufruft, wenn das entsprechende Subsystem startet. Vielleicht ist da auch noch ein weiterer Autostartjob vorhanden. Oder ein zusätzlicher Autostartjob beim Subsystem QSYSWRK.

[Chris.jan]

Ich finde bei den besagten drei Subs nur je eine jobd, aber keine Autostartjobs. Die jobscde habe ich längst geprüft, und weitere Scheduler haben wir erst gar nicht im Einsatz.
Es ist wie verhext. Die Source vom Strup habe ich auch geprüft. Mich wundert auch, daß dessen objd nicht das lastuse Datum unseres letzten ipl hat.vielleicht wird das zu dem frühen Zeitpunkt des ipl noch nicht geschrieben?
Glaubt mir, ich habe seit fünfzehn Jahren Erfahrung mit der I5, aber Sowas hab ich noch nie gehabt.

[Pikachu]

Vielleicht steht in DSPSYSVAL nicht QSTRUP QSYS sondern was anderes, wie zum Beispiel QSTRUP QGPL oder ähnliches.

[Fuerchau]

Das ausführen von QSTRUP hat nichts mit dem IPL direkt zu tun.
Wenn das System im eingeschränkten Zustand ist und man dann QCTL, auch wenn es ja bereits läuft, neu startet, wird QSTRUPPGM ausgeführt.

Was man ggf. noch prüfen kann ist das HST-Log (DSPLOG).
Mit F1 auf der jeweiligen Nachricht kann man sehen, von welchem Programm diese gesendet wurde.
Man muss also die einzelnen Meldungen dahingehend mal prüfen und ggf. per DSPPGMREF die Verwendung der Programme nachverfolgen.

[Chris.jan]

Nein, da steht QSYS/QSTRUP. Hab ja gesagt der ist noch Original.
Den Joblog habe ich geprüft. Genauso alle Einträge unseres QACGJRN, weil der mir ja noch sagt, wann der Job eingegangen ist (und nicht erst, wenn er gestartet wurde).

Aber =====> Es gibt Neuigkeiten!!!
Ich habe eben gesehen, daß die Meldung, daß unser eigener Startjob gestartet wurde zwar NICHT im Joblog auftaucht, aber im Log von BRMS. Ich Bin mir daher sicher, daß der Job vom BRMS aus gestartet wurde. Nur jetzt geht die Sucherei von vorne los.... Wo finde ich jetzt den Eintrag, wo unser programm drin steht?

[Chris.jan]

So, und jetzt habe ich es!

Ich hasse es, wenn man erst F11 drücken muß, damit man die wichtigsten Daten sehen kann. Sonst hätte ich das schon vor Wochen gefunden!

Es ist ein "Sicherungssteuergruppeneintrag"
und mit F11 sieht man die "Exits" bzw. die Befehle zum verlassen.
Und da steht unser Script!

Blöd nur, wenn das Script nicht gestartet wird, wenn am Wochenende die Sicherung ausfällt. Aber zum Glück hab ich das ja nicht programmiert ;-)

[holgerscherer]

Es ist ein "Sicherungssteuergruppeneintrag"

Holla, wer macht denn sowas? Das ist ja fast so kreativ, wie folgendes, was ich bei einem Kunden fand:

- abends ein PWRDWNSYS restart(*yes)
- im QSTRUPPGM eine Sicherungsroutine auf Band, erst danach wird QINTER und co. gestartet...

Blöd, wenn man mal für Servicezwecke die Kiste tagsüber "schnell" runter fahren muss...

-h