Dieses Kapitel behandelt folgende Themen:
Das Entire Operations-System basiert auf Adabas, Natural und den Entire System Server (früherer Produktname: Natural Process). Deshalb beziehen sich die nachfolgenden Performance-Überlegungen auf diese Komponenten bzw. auf Entire Operations selbst.
Wenn im Entire Operations Monitor ein 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 ebenfalls die zum Entire System Server gegebenen Hinweise.
Definieren Sie die benötigten Editor Buffer Pools so groß, dass eine Auslagerung auf den EDTWORK Dataset vermieden wird. Weitere Informationen siehe Editor Buffer Pool im Abschnitt Allgemeine Anmerkungen zur Installation.
Prüfen Sie in der Adabas-Statistik, ob die Pools voll laufen, auf die Anzahl an Throwbacks, Anzahl an Formatüberschreitungen und die Thread-Verwendung, und korrigieren Sie die erforderlichen Parameter.
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 IOs, 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:
Auf welcher Platte liegen die Komponenten dieser Dateien (AC,UI/NI/MI,DS)?
Wie schnell reagieren diese Geräte auf Ein-/Ausgabeanforderungen?
Wie steht es um die ISN- und DSN-Parameter-Wiederverwendung?
Verteilen Sie ASSO und DATA auf soviele Platten, wie Adabas Threads aktiv sind. WORK und PLOG sollten auf separaten Platten liegen.
Ordnen Sie die Entire Operations-Systemdateien 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 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, dann muss der Monitor auf die Freigabe dieses Datensatzes warten. Prüfen
Sie in einem solche Fall den Inhalt der Adabas-Hold-Warteschlange auf Einträge,
die auf die Systemdateien zeigen. Ändern Sie die Adabas-Zeitparameter
TNAx und
TT so, 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_LIMITin Adabas für Open Systems.
Passen Sie den Wait Intervall 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 nicht allzu viele Jobs gibt, die ausgeführt werden müssen.
Falls Sie überwiegend große Batch-Jobs haben, dann erhöhen Sie gleichermaßen die Wartezeit des Monitors. Es besteht auch die Möglichkeit, den Wait Interval innerhalb eines Natural-Programms über eine Anwendungsprogrammierungsschnittstelle (API) zu ändern und dieses Programm über Entire Operations selbst aufzurufen.
Um den Mehraufwand bei Systemverwaltung 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 gelten nicht, 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.
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 häufig verwendeten JCL-Rahmen sollten Sie allzu häufigen Gebrauch von Symbol-Ersetzungen vermeiden. Nehmen wir beispielsweise mal 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.