QBASE oder doch lieber QCTL?

[Gerd/400]

Was haben wir früher - so gegen Ende der CISC-Rechner Zeit und auch noch danach - für schöne Sachen gemacht wenn wir Kundenrechner eingerichtet haben. Steuerndes Subsystem natürlich QCTL. Batchjobs wurden in einen oder mehrere SHAREPOOLS umgeleitet, an dieser und jener Schraube gedreht. Seit Jahren habe ich nun kaum noch etwas mit Systemsachen zu tun und bin überwiegend am programmieren. Ich sehe in letzter Zeit immer häufiger bei Kunden das als steuerndes Subsystem das QBASE läuft und an manchen dieser schwarzen Kisten hängen durchaus 50 bis 100 PCs. Spielen solche Einstellungen bei den mordernen Maschinen keine Rolle mehr oder ist das einfach Nachlässigkeit?

[BenderD]

... it depends on ...
Die QBASE Musterkonfiguration behandelt im wesentlichen alle Workload als gleichberechtigt, wenn das die Anforderungen abbildet, oder keine Ressourcen Engpässe vorliegen, ist das auch so in Ordnung.
Die QINTER Musterkonfiguration unterscheidet zwischen den Haupttypen interaktiv, batch und Serverworkload und erlaubt für typischen Mix höher Auslastung der vorhandenen Ressourcen mit weniger Engpässen.
Was sich gegenüber früher geändert hat ist, dass die AS/400 heute wesentlich stärker nach oben skalierbar ist (ich kenne derzeit keine Installation, die die maximale Konfiguration nutzt). Man hat also (fast) immer die Wahl Probleme mit Blech, oder mit Verstand zu lösen und je weniger die kaufmännischen Entscheidungsträger von zweitem haben, umso mehr tendieren sie zum ersteren.

D*B

[Fuerchau]

Die Trennung in QCTL/QINTER/QBATCH oder QBASE spielt nur noch dann eine Rolle, wenn man (typisch in der EDV) sog. "Wartungsarbeiten" durchführen muss.
Dann kann man problemlos die Anwender aussperren in dem man die Subsysteme QINTER u.ä. herunterfährt während die IT noch weiter arbeiten kann (entweder in QCTL oder einem eigenen Subsystem).
In QBASE kann man die anderen Anwender nur schwer ausschließen.

Ich kenne auch Anwendunge, die in "Nachtarbeiten" das System für sich alleine benötigen, auch in diesem Fall sind Subsysteme einfacher als alles in QBASE zu steuern.

Aber, wie Dieter schon sagt, es kommt auf die Anforderungen an ...

[TARASIK]

Hallo,
dies als wichtigsten Faktor wurde nicht genannt:

Subsystem Does Not Start after an IPL
Technote

Another possibility is that the controlling subsystem is QBASE -- not QCTL. The system value, QCTLSBSD, is used to determine the controlling subsystem. If QCTL is specified, other subsystems are started after an IPL. These subsystems are QINTER, QBATCH, QCMN, and QSPL. If QBASE is the controlling subsystem, only subsystems QBASE and QSPL are started after an IPL. To determine the controlling subsystem, use the following command: WRKSYSVAL QCTLSBSD

[Fuerchau]

Das liegt aber auch daran, wenn man das QSTRUPPGM nicht anpasst sondern den Standard beläßt.

Wenn man selber anpasst, und das sollte man meistens, hat man eh alles selber unter Kontrolle, egal ob QBASE oder QCTL.

[MMP400]

Ja, ABER
warum sollte man den Standard verändern?

QBASE ist nicht für Produktionsbetrieb gedacht. Fertisch.

[madoxx]

Hallo,

QBASE oder QCTL ?

ich habe mal gelernt, dass die Steuerung des System unter QCTL besser sein soll als unter QBASE.
Unter QCTL soll eine bessere Pool- und Speichereinteilung erfolgen.
In der Regel laufen alle mir bekannten Systeme unter QCTL.

Gruß Madoxx

[Fuerchau]

Normalerweise werden Batch und Dialogressourcen besser verteilt, aber bei großen oder sehr kleinen Systemen nicht so relevant.
Im Standard kann man sowieso nur 1 Batch ausführen.

[TGsoft]

Normalerweise werden Batch und Dialogressourcen besser verteilt, aber bei großen oder sehr kleinen Systemen nicht so relevant.
Im Standard kann man sowieso nur 1 Batch ausführen.

Verstehe ich nicht!

Jobwarteschlangeneinträge anzeigen
System: KCML00A
Subsystembeschreibung: QBATCH Status: ACTIVE

Folg Jobwarte- Max. ------Maximal nach Priorität------
Nr. schlange Bibliothek Aktiv 1 2 3 4 5 6 7 8 9
10 QBATCH QGPL 1 * * * * * * * * *
20 QS36EVOKE QGPL *NOMAX * * * * * * * * *
30 QTXTSRCH QGPL *NOMAX * * * * * * * * *

Im Standart sehe ich hier mindestens 2 JOBQs welche mehr als einen Batchjob ausführen können!

Aus eigner Erfahrung kann ich nur sagen je größer das System um so interessanter wird die Gestaltung der Subsysteme.
Schon allein um die Übersicht über verschiedene Dinge zu behalten.
Die Trennung von Interaktiver- und Batchlast ist immer eine gute Idee, siehe auch "Wartungsarbeiten". Aber auch das gesamte Thema Performance ist leichter zu beherschen wenn man diese Trennung beherzigt. Die Daten die man für die Analyse gewinnt sind deutlich aussagekräftiger.
Die Idee der verschiedenen Subsysteme ist ja Bestandteil des Performancealgorhytmus von i5/OS.

Gruß
Thomas

[Fuerchau]

Wie du siehst, die JOBQ QBATCH erlaubt genau nur 1 Job.
Wenn du nichts explizit angibst, landen alle SBMJOB's genau in dieser.

Ich habe auch hier auf einem Kundensystem viele JOBQ's (je Mandant 1) mit Anzahl Job's je Job-Prio eingerichtet, sowie jede Menge passende JOBD's.
Dadurch läßt sich sehr viel besser die Parallelverarbeitung unterschiedlicher Mandanten und Aufgaben steuer.

Der Standard liefert da halt nichts.

Oder gibst du gezielt z.B. die QTXTSRCH beim SBMJOB an ?
Ich denke nicht.

[BenderD]

... SBMJOB hat im Standard JOBQ(*JOBD) und JOBD(*USRPRF) und hier sitzen die korrekten Einstellschräubchen, sprich beim Usrprf und der jobd

BTW: was das starten der anderen Subsysteme angeht, die QCTL Konfiguration braucht zusätzliche Subsysteme, die logischerweise automatisch mitgestartet werden, sonst würde das ja nicht funzen!

D*B

Wie du siehst, die JOBQ QBATCH erlaubt genau nur 1 Job.
Wenn du nichts explizit angibst, landen alle SBMJOB's genau in dieser.

Ich habe auch hier auf einem Kundensystem viele JOBQ's (je Mandant 1) mit Anzahl Job's je Job-Prio eingerichtet, sowie jede Menge passende JOBD's.
Dadurch läßt sich sehr viel besser die Parallelverarbeitung unterschiedlicher Mandanten und Aufgaben steuer.

Der Standard liefert da halt nichts.

Oder gibst du gezielt z.B. die QTXTSRCH beim SBMJOB an ?
Ich denke nicht.

[holgerscherer]

Ich habe auch hier auf einem Kundensystem viele JOBQ's (je Mandant 1) mit Anzahl Job's je Job-Prio eingerichtet, sowie jede Menge passende JOBD's.
Dadurch läßt sich sehr viel besser die Parallelverarbeitung unterschiedlicher Mandanten und Aufgaben steuer.

Alles eine Frage der Literzahl. Aber einer gewissen Menge ist i5/OS aber mehr mit sich selbst als mit den Jobs beschäftigt. Hier auf einer der öffentlichen Kisten hat jeder User seine eigene JobQ (also etwa 15.000) samt Einträge in die Subsysteme. Das Starten eines Jobs (sprich - suchen des Eintrags in den JOBQE) kann schon mal 500ms brauchen... bei 2000CPW

-h