| RZ Automatisierung für OS/390 ASAp/DCM ist simpel, flexibel, weitreichend und ressourcenschonend. ASAp/DCM ist die gelungene Synthese aus - Automatischem Operator
- einfachem Jobscheduling System
- und Benachrichtigungssystem.
ASAp/DCM ist leicht zu bedienen, die meisten Funktionen erschließen sich intuitiv. AV, Operating, Systemprogrammierer und Endanwender sind nach kurzer Einweisung in der Lage, mit ASAp/DCM effektiv zu arbeiten. ASAp/DCM bringt keine nennenswerte Systembelastung mit sich. Der Overhead ist so gering, dass mehrere Kopien gestartet werden können (Anwender-Schedules, Zentrale Schedules, etc.). Die Funktionen im Überblick Jobs, Tasks, Operator Commandos können datums-, zeit- und ereignisabhängig gestartet werden. Vorbedingungen wie "Vorläufer richtig beendet?", "Dateien erstellt?" werden berücksichtigt. System Log und Console werden überwacht, bei Eintreten definierter Ereignisse werden Aktionen eingeleitet: Meldungen umformen, Commandos absetzen, Jobs oder Tasks starten. In Abhängigkeit von System- oder Scheduling-Ereignissen können Texte an externe Benachrichtigungssysteme (z.B. email) übergeben werden. ASAp/DCM - Produktübersicht Zwei in einem ASAp/DCM fasst die Funktionen eines Ablaufsteuerungssystems oder Job Schedulers und eines OS/390 Console Management Systems zu einem Produkt zusammen. Ursprünglich speziell zur Entlastung von Operating und Produktionssteuerung (AV) entwickelt, wird ASAp/DCM dank seiner einfachen Bedienung und seines geringen Ressourcenbedarfs auch von anderen Benutzern geschätzt und sinnvoll genutzt. Im OS/390 Rechenzentrum mit Batchlast ist eine automatische Jobablaufsteuerung unerlässlich
- um das Personal von Routinearbeiten zu befreien
- um die Fehlerquellen einer manuellen Bearbeitung zu vermeiden
- um den Durchsatzes zu verbessern um Steuerung der Lastverteilung (Workload
- Balancing) zu gewährleisten
- um vor SUBMIT eine Betriebsmittelprüfung vorzunehmen (Ressource Contention)
Automatisches Konsolenmanagement vereinfacht die Aufgaben des Operating, beschleunigt viele Abläufe und hilft folgenschwere Fehler zu vermeiden. DCM Dynamic Console Manager arbeitet Hand in Hand mit ASAp und stellt alle denkbaren Funktionen zur Automatisierung der Arbeiten an der Systemkonsole zur Verfügung. Durch die Kombination von automatischem Konsolenmanagement und automatischer Jobsteuerung in einem einzigen System treten zusätzliche Synergieeffekte auf. Zusammen befreien ASAp und DCM Operating, AV und Systemtechnik von vielen manuellen Tätigkeiten und lenken das Augenmerk auf die eigentlichen Aufgaben: Kundenbetreuung, Systemüberwachung, Optimierung. ASAp bietet die Vorteile einer automatischen Jobsteuerung bei äußerst geringer Systembelastung. Der Overhead durch ASAp ist tatsächlich so unerheblich, das die meisten Anwender mehrere Systeme auf der gleichen Maschine (LPAR) einsetzen: ein Produktionssystem, ein Testsystem oder eigene Systeme für isoliert arbeitende Abteilungen/Kostenstellen oder Kunden/Mandanten. Bei dezentraler Steuerung sind die Steuerdateien i. R. kleiner, und damit leichter zu überschauen und zu pflegen. Mittels DCM kann man - auf infache Weise unwichtige Meldungen unterdrücken, um zu verhindern, dass diese die Aufmerksamkeit des Bedienungspersonal unnötig absorbieren
- die Attribute der Meldungen ändern: Hell/dunkel, Farbe, Roll off
- den Text der Meldungen (in Kombination mit den Attributen) ändern
- bestimmte Meldungen durch weitere, erklärende (wenn nötig optisch modifizierte) Messages ergänzen, so bleibt die Originalmeldung erhalten
- eine automatische Antwort für eine Systemmeldung definieren, danach erfolgt WTOR Response mit Maschinengeschwindigkeit
- Kommando-Gruppen definieren, die bei Erscheinen einer bestimmten Meldung automatisch auszuführen sind, damit können zum Beispiel Standardabläufe wie Umschalten von SMF Datasets oder HSM Logs sowie IPL- und Shutdown-Sequenzen automatisiert werden.
- Jobs oder COMMAND GROUPS die unter ASAp (oder einem anderen Job Scheduler) ausgeführt werden ?triggern?
- SYSLOG Files anlegen. Darin hinterlegt der Benutzer sogenannte ?Message Filter? und ?Rule Sets? die festlegen, welche Meldungen abgefangen, geändert, automatisch beantwortet und/oder welche Aktion eingeleitet werden sollen. Die Datei kann mit einem beliebigen Editor, z.B. ISPF bearbeitet werden.
DCM ist in wenigen Minuten installiert. Es benötigt weder Hooks noch SVCs. IPL ist nicht nötig. Die Installation wird mittels eines einzigen IEBCOPY Steps ausgeführt (IEAVMXIT). ASAp Die Hauptaufgabe von ASAp besteht darin, sogenannte Tasks (Aufgaben) einzuplanen und automatisch auszuführen. Ist eine Task einmal definiert und geplant, so ist zur Abarbeitung kein weiterer Eingriff des Nutzers notwendig. Tasks können aus Batch Jobs, Started Tasks, Operator Kommandos oder einer Kombination daraus bestehen. Bei der Definition legt der Anwender fest, ob es sich um eine Datums/Zeit-gesteuerte Task (time driven) oder um eine Ereignis-gesteuerte Task handeln soll. Eine zeitgesteuerte Task wird initiiert sobald der spezifizierte Zeitpunkt erreicht ist, eine Ereignis-gesteuerte Task, wenn das spezifierte Ereignis eingetreten ist, wenn zum Beispiel ein oder mehrere Vorläufer-Jobs korrekt beendet wurden.Mit ASAP können Tasks erstellt werden, die als Teil des IPL Prozesses ausgeführt werden. Dieses Feature, IPL TASK CONTROL genannt, erweitert die Funktion des COMMANDnn Members der SYS1.PARMLIB. Abläufe bestehend aus einer beliebigen Kombination von Operatorkommandos, Batchjobs und Started Tasks können zu bestimmten Zeitpunkten automatisch ausgelöst werden. Durch IPL TASK CONTROL können noch 2 Stunden nach Beendigung des System IPLs Tasks initiiert werden. Diese Funktion automatisiert das IPL und hilft Engpässe zu vermeiden.Unter ASAp werden Tasks auf einfache Weise als einzeilige Einträge im sequentiellen, sogenannten SCHEDULE File definiert. Der Anwender, in der Regel die AV, legt hier fest, welche Jobs zu welchen Zeiten oder unter welchen Umständen zu starten sind. Dieser File kann von einem beliebigen Editor (i.R. ISPF) bearbeitet werden. Ein flexibles Selektionsformat erlaubt simple Angaben zu Ausführungszeiten wie täglich, wöchentlich, einmalig an einem bestimmtem Datum, etc. für Jahre im voraus.Die JCL der Jobs, die von ASAp ausgeführt werden sollen, stellt man in einem PDS, den BASEJCL File. Mehrere BASEJCL Files können konkatiniert werden.ASAp kann Jobs, bevor sie submitted werden, automatisch anpassen. Die Anpassung betrifft nur den gerade gestarteten Job, nicht die Basis-JCL. Alle dazu nötigen Änderungsanweisungen sind in einem Member des PDS EDITCMDS zu hinterlegen: CHANGE, DELETE, INSERT. So können Jobs mit ähnlicher JCL durch ein einziges JCL Member dargestellt werden.Für Jobs können zugehörige Operatorkommandos hinterlegt werden. Diese Kommandos werden dann in der entsprechenden Reihenfolge vor Jobbeginn oder nach Jobende ausgeführt. So wird die Leistungsfähigkeit des Schedulers erhöht, in dem ein Job seine eigene Laufumgebung gestalten kann.Es ist jederzeit möglich Jobs manuell aus der BASEJCL zu submitten. Das SUBMIT Kommando läßt es zu, daß ein EDITCMDS Member angegeben wird. So werden manuelle Änderungen zur Ausführungszeit und dabei möglicherweise auftretende Fehler vermieden. Operator START Kommandos mit längeren Parameterangaben sind Kandidaten für SUBMIT mit EDITCMDS.Unter ASAp können sogenannte COMMAND GROUPS gebildet werden. Einer Abfolge von Kommandos wir dabei ein Gruppenname zugeordnet, der zur Ausführungszeit mit EXEC .... aufgerufen wird: Schichtende, Shutdown, IPL ...ASAp schreibt ein fortlaufendes Log, in dem alle automatisch und manuell gestarteten Aktivitäten aufgezeichnet werden. Dieses Log kann nach jeder ASAp Ausführung ausgedruckt und/oder archiviert werden.Mit Hilfe seines RECOVERY Files, einer Art Checkpoint Datei übergibt ASAp Informationen von einer Session an die folgende: Wann war ASAp zuletzt aktiv, welche Job-Requirements waren schon erfüllt, etc.ASAp hat eine SAF-Schnittstelle, Funktionen können z. B. über RACF geschützt werden.ASAp ist leicht zu installieren und benötigt keine System Hooks, durchschnittliche Installationszeit: 1 Stunde. Anforderungen an das System SASAp setzt OS/390 bzw. MVS ab Release 3.8 voraus. Das System kann als Batch-Job oder Started Task laufen, muß von einer APF autorisierten Bibliothek bzw. Linklist gestartet werden und benötigt eine 4096K Region. DCM setzt MVS/XA oder ein späteres Release voraus, benutzt etwa 256K ECSA Speicher für die Kommunikation mit ASAp und verwendet den WTO/R Standard-Exit IEAVMXIT. | | |