Warum UC4?
- Ihre Batchverarbeitung läuft auf dem Host, und Sie suchen eine leistungsstarke Lösung ohne den Mainframe?
- Oder: Sie betreiben eine UC4 Installation, benötigen aber Funktionen, die im UC4 selber nicht integriert sind?
- Oder: die Wartung und der Betrieb Ihrer UC4 Installation sind sehr arbeitsintensiv, möglicherweise auch fehleranfällig?
Dann kann ich Ihnen bewährte Lösungen anbieten, oder gemeinsam mit Ihnen neue Lösungen erarbeiten - aufbauend auf mehr als 18 Jahren kontinuierlicher Arbeit und Erfahrungen mit Batchautomation durch UC4, UC4 Scripting und dem UC4 Java API. Das Umfeld, in dem ich UC4 eingesetzt habe, deckt praktisch alle für die Automation verwendeten Systemumgebungen ab - von Windows über UNIX (Solaris, AIX, oder Linux) bis hin zu z/OS.
Noch der Hinweis: seit 01.07.13 trägt UC4 den neuen Namen Automic. Ich werde im folgenden dennoch am alten Namen UC4 festhalten, um Verwirrung zu vermeiden.
Warum liegt mein Schwerpunkt auf UC4?
Klassische Batchverarbeitung ist sehr stark abhängig vom zugrunde liegenden Betriebssystem. So sind z/OS basierte Jobscheduler - CA7, OPC oder Control-M - ausgesprochen leistungsfähig unter z/OS, tun sich aber schwer, Aktivitäten auf anderen Betriebssystemen wie bspw. Solaris oder AIX zu starten. (Diese Funktionalität ist bei den verschiedenen Produkten in den letzten Jahren allerdings besser geworden.)
Demgegenüber ist für UC4 das Betriebssystem, auf dem irgendwelche Abläufe gestartet werden sollen, praktisch unerheblich. Der UC4 Server läuft auf den gängigen Serverplattformen und Datenbanken. Und sobald es einen Agenten für ein Betriebssystem gibt, lassen sich dort Aktivitäten, Filetransfers, Scripte usf. problemlos ausführen - einschließlich der Rückmeldung von Statusinformationen, Fehlern u.ä.
Weitere Vorteile oder Stärken von UC4 sind:
- UC4 ist "lightweighted": die Ressourcenanforderungen für den Betrieb lassen sich staffeln von gering, über moderat bis hoch - abhängig von den tatsächlichen Anforderungen im Betrieb.
- UC4 ist aus Sicht des Betriebes einfach zu bedienen. So ist der Umstieg für Operatoren von anderen Consolen oder Systemen deutlich einfacher als bswp. ein Wechsel von UC4 nach CA/7. Dies ist aber zugleich auch eine der Schwächen des Produktes: die Leichtigkeit der Bedienung verdeckt die Schwierigkeiten und zugrunde liegende Komplexität des Produktes im Betrieb.
Wo viel Licht, da auch viel (oder weniger) Schatten. Es sei nicht verschwiegen, daß auch ein Produkt wie UC4 seine Schwächen hat - erinnert sei nur an Agenten und Hostgruppen in Abläufen, bei denen Generierung und Laufzeit zu unterscheidlichen Zeitpunkten stattfinden. Und auch die Leichtigkeit, mit der sich im Dialog-Client Objekte und Abläufe erstellen lassen, täuscht über die Tücken und Komplikationen, die sich durch die unüberlegte Verwendung des Clients ergeben können.
Wichtige Eckpunkte des Betriebs von UC4
Ein derartiges leistungsfähiges Produkt wie UC4 birgt angesichts seiner einfachen Bedienbarkeit und Flexibilität die Gefahr, in Situationen zu geraten, die nur noch schwer beherrschbar sind. Gerade die Einfachheit, mit der sich Abläufe auf den unterschiedlichsten Systemplattformen implementieren lassen, lassen vergessen, daß solche Abläufe auch gewartet und betrieben werden müssen. Im folgenden seien daher einige Eckpunkte aufgeführt, um UC4 zukunftsträchtig betreiben zu können (die Auflistung ist weder vollständig noch nach Wichtigkeit sortiert):
- Konventionen und Namenskonventionen: die einfache Bedienbarkeit von UC4 bringt einige Schwierigkeiten mit sich, die bei anderen Jobschedulern in der Form nicht auftreten. Größte Schwierigkeit ist nach meinen Erfahrungen, daß mit der leichten Bedienbarkeit ein großes Potential für eine wild wachsende Installation besteht. Vieles kann "on the fly" gemacht werden, fliegt aber nicht weiter und verschwindet wieder, sondern bleibt dauerhaft im System bestehen. So entstehen Altlasten, schnell und zuverlässig. Konventionen, insbesondere system- und mandantenübergreifende Namenskonventionen sind daher wesentlich für einen UC4 Betrieb, der eine langfristige Perspektive enthalten soll.
- Trennung von Produktion- und Testumgebungen: u.z. physische Trennung, nicht nur logische Trennung. Eigentlich ist dies eine Selbstverständlichkeit. Dennoch fallen immer wieder Installationen auf, bei denen diese Trennung - meist aus Kostengründen - nicht der Fall ist. Spätestens aber wenn die nächste UC4 Version eingespielt werden soll (oder muß) wird sich die Frage stellen, wo denn diese neue Version zunächst sinnvoll getestet werden kann.
- Ansprechpartner und Zuständigkeiten: die einfache Bedienbarkeit von UC4 ermöglicht es, Aufgaben des Betriebes an Abteilungen und Gruppen zu verteilen, die von UC4 nur begrenzte Kenntnisse besitzen. Das ist solange kein Problem, wie diese begrenzten kenntnisse nicht dazu führen, daß - bspw. in Folge zu großer Berechtigungen - Veränderungen im System vorgenommen werden, die die Stabilität der Abläufe beeinträchtigen. Klare Zuständigkeiten, in Verbindung mit einem klaren Sicherheitskonzept, helfen hier, den Betrieb dauerhaft störungsfrei aufrecht zu erhalten.
- Konfigurierbarkeit der Abläufe: ein probates Mittel, die Aufwände für Pflege und Wartung zu minimieren, liegt in der Auslagerung der Konfiguration der UC4 Abläufe in UC4 Variablen. Vorteil ist, daß Parameter so zentral gepflegt werden können - der Aufwand für die Pflege verringert sich gerade in Installationen mit einer größeren Anzahl von Mandanten deutlich.
- Modularisierung: aus der Softwareentwicklung bekannt sind die Vorteile der Modularisierung. UC4 bietet hier leider nur wenig Unterstützung an - außer mit Includes. Mit ihnen aber ist es möglich, eine Flexibilität zu erreichen, die fertige Jobs oder Filetransfers praktisch einzig aus der Konfiguration des Jobs erstellt - ohne eine zusätzliche Zeile Code!