Das Entire Operations-System basiert auf Adabas, Natural und dem Entire System Server. Deshalb beziehen sich die nachfolgenden Performance-Überlegungen speziell auf diese Komponenten bzw. auf Entire Operations selbst.
Folgende Themen werden behandelt:
Wenn der Entire Operations-Monitor als Subtask des Entire System Server
läuft, geben die Startup-Parameter BPSIZE und
BPDIRS die Größe des Natural Buffer Pool an. Je größer
der verfügbare Speicherplatz und je größer die Anzahl der Verzeichniseinträge
in diesem Buffer sind, um so weniger Adabas-Aufrufe müssen erfolgen, um die vom
Monitor verwendeten Natural-Objekte zu laden.
Falls der Monitor als separater Batch Job oder Task läuft, gelten für den Natural Batch Buffer Pool ebenfalls die zum Entire System Server gegebenen Hinweise.
Definieren Sie den benötigten Software AG Editor Buffer Pool so groß, dass eine Auslagerung auf den EDTWORK Dataset vermieden wird. Weitere Informationen siehe Software AG Editor Buffer Pool.
Prüfen Sie die Adabas-Statistik, ob die Pools voll laufen, prüfen Sie die Anzahl an Throwbacks, Anzahl an Formatüberschreitungen und die Thread-Nutzung, und passen Sie die erforderlichen Parameter an.
Erhöhen Sie den Adabas Buffer LBP, um das Verhältnis zwischen Anzahl an Adabas-Aufrufen und der dafür benötigten Anzahl an physischen Ein-/Ausgaben zu verbessern. Verringern Sie die Adabas WORK IO, indem Sie den NSISN-Parameter verkleinern (evtl. müssen Sie auch den Wert des LI-Parameters erhöhen).
Nehmen Sie die Nutzung der Entire Operations-Systemdatei(en) gründlich unter die Lupe:
Wo befinden sich diese Dateien (AC,UI/NI/MI,DS)?
Wie schnell reagieren diese Platten auf Ein-/Ausgabeanforderungen?
Wie steht es um die ISN- und DSN-Parameter-Wiederverwendung?
Verteilen Sie ASSO und DATA auf ungefähr so viele Platten, wie Adabas Threads aktiv sind. WORK und PLOG sollten auf separaten Platten liegen.
Ordnen Sie die Entire Operations-Systemdatei(en) physisch neu, und führen Sie diese Maßnahme regelmäßig durch. Dadurch werden die Datensätze in der ISN-Reihenfolge angeordnet, was die Verarbeitung einiger häufig benutzter Lesevorgänge beschleunigt.
Beachten Sie, dass der Entire Operations Monitor mit der
Natural-Profilparametereinstellung WH=ON (Warten auf
Datensatz im Hold-Status) arbeitet. Falls ein Adabas-Datensatz in
einer oder mehreren Entire Operations-Systemdateien durch einen Benutzer
gesperrt ist (Hold-Status) und der Monitor ihn aktualisieren muss, muss der
Monitor auf die Freigabe dieses Datensatzes warten. Prüfen Sie in einem solchen
Fall den Inhalt der Adabas-Hold-Warteschlange auf Einträge, die auf die
Systemdateien zeigen. Passen Sie die Adabas-Zeitparameter
TNAx und
TT so an, dass Ressourcen auch im Falle von Benutzern,
die nicht mehr anwesend sind, freigegeben werden.
Anmerkung:
Der Adabas-Parameter LFIOP bei Großrechnerplattformen
ist äquivalent zum Parameter BFIO_PARALLEL_LIMIT in
Adabas für UNIX und Windows.
Passen Sie die Wartezeit (Wait Interval) des Entire Operations Monitors und des Monitor Task den Erfordernissen an. Weitere Informationen siehe Profil der Monitor-Tasks in der Systemverwaltung-Dokumentation.
Tagsüber während der Online-Zeit braucht der Monitor sich nur alle paar Minuten zu aktivieren, wenn es nicht allzu viele Jobs gibt, die ausgeführt werden müssen.
Falls Sie überwiegend große Batch-Jobs haben, dann erhöhen Sie die Wartezeit des Monitors ebenfalls. Es besteht auch die Möglichkeit, die Wartezeit innerhalb eines Natural-Programms über eine Anwendungsprogrammierungsschnittstelle (API) zu ändern und dieses Programm über Entire Operations selbst aufzurufen.
Um den System-Mehraufwand bei der Verwaltung der einzelnen Monitor-Tasks in vernünftigen Grenzen zu halten, sollten Sie den Monitor nicht auf zu viele unnötige Tasks verteilen. Empfohlen werden zwei bis vier Tasks. Hinsichtlich der empfohlenen Verteilung siehe Profil der Monitor-Tasks in der Systemverwaltung-Dokumentation.
Anstelle von komplexen Netzwerken mit vielen Jobs sollten Sie
Unternetzwerke verwenden. Diese Unternetzwerke können in Jobs des
Typs NET
definiert werden. Das verkleinert die Warteschlangen, und die Aktivierung
erfolgt nur dann, wenn alle notwendigen Bedingungen erfüllt sind.
Benutzen Sie Natural-Bibliotheken anstelle von sonstigen JCL-Medien. Dadurch verringert sich die Anzahl der Anforderungen an den Entire System Server. Darüber hinaus können Sie den gesamten Zugriff auf diese JCL Members mit Natural Security kontrollieren.
Versuchen Sie, die Zeit, während der die Netzwerke in der aktiven Warteschlange stehen, so kurz wie möglich zu halten. Das heißt, aktivieren Sie die Netzwerke in zeitlicher Nähe zu ihrer Startzeit. Das verringert die Anzahl der vom Monitor zu prüfenden Bedingungen.
Geben Sie, falls möglich, zu jedem Netzwerk eine früheste Startzeit an. Die Prüfung der Bedingungen erfolgt dann erst nach dieser Zeit. Andernfalls wird das Netzwerk um Mitternacht (Beginn des geplanten Tages) aktiviert.
Spezielle Aktionen während der Prüfung der Eingabebedingung sind komfortabel, können aber Mehraufwand zur Folge haben. Dazu zählen:
Eingabebedingungen, die von Dateien, Jobvariablen usw. abhängen.
Eingabebedingungs-User Exits, die übermäßig viele Adabas-Aufrufe machen.
Vermeiden Sie redundante Prüfungen solcher Bedingungen. Es ist viel effizienter, Dummy Jobs auf solche Bedingungen warten zu lassen, die Vorgänger von mehreren anderen Jobs sind.
Vermeiden Sie möglichst, Referenzen auf andere Eingabebedingungen als
RUN zu benutzen, weil diese eine Bedingungsprüfung während eines
Zeitintervalls verursachen und weil dies weniger effizient ist als eine direkte
RUN-Prüfung.
Anmerkung:
RUN-Prüfungen sind nicht anwendbar, wenn Sie eine
Verbindung zwischen Netzwerken benötigen.
Jede definierte Prüfung kostet Zeit und beeinflusst die Performance. Daher sollten Sie Job-Ende-Prüfungen auf das nötige Minimum beschränken. Insbesondere sollten Sie komplexe Job-Ende-Prüfungsaktionen im SYSOUT-Protokoll vermeiden.
User Exits für die Job-Ende-Prüfung können im asynchronen Betrieb benutzt werden.
User Exits für die Job-Ende-Aktionen können im asynchronen Betrieb benutzt werden.
Bei jedem Exit für die Job-Ende-Prüfung (EJC) und für die
Job-Ende-Aktionen (EJA) können Sie eine asynchrone Exit-Ausführung
definieren. Siehe auch
User Exits
für die Job-Ende-Prüfung und -Aktionen.
Asynchrone Exits werden in dem oder den speziell dafür vorgesehenen
Monitor-Task oder Tasks für Jobs des
Typs NAT
ausgeführt. Somit wird die Behandlung der Warteschlangen für die
Job-Ende-Überprüfungen und Job-Ende-Aktionen innerhalb der allgemeinen
Monitor-Tasks durch sie nicht blockiert.
Die Logik bei der Job-Netzwerkausführung bleibt die gleiche, wenn Sie einen Exit als asynchron auszuführend definieren.
Exits sollten nicht auf asynchrone Exit-Ausführung gesetzt werden, wenn sie eine kurze Ausführungszeit haben und nur wenige Datenbank- und Entire System Server-Aufrufe ausführen.
Exits sollten auf asynchrone Exit-Ausführung gesetzt werden, wenn sie eine längere Ausführungszeit haben und/oder viele Datenbank- und Entire System Server-Aufrufe ausführen.
Bitte beachten Sie den Mehraufwand an Job-Netzwerk-Ausführungszeit, der durch mehr Warteschlangenwechsel zwischen Monitor-Taks verursacht wird.
Die Ausführungszeit eines einzelnen Job-Netzwerks kann durch asynchrone Exits nicht verkürzt werden.
Der Durchsatz bei parallel laufenden Job-Netzwerken mit exzessiver Exit-Nutzung kann aufgrund von mehr parallelen Abläufen besser werden.
Bei komplexen Produktionen mit oft verwendeten JCL-Rahmen sollten Sie allzu häufigen Gebrauch von Symbol-Ersetzungen vermeiden. Nehmen wir beispielsweise an, ein Job mit 100 Symbolen wird 500 mal am Tag benutzt. Vergewissern Sie sich, dass die Verwendung aller Parameter tatsächlich nötig ist.