Berufliche High Lights

Direkt zu den Themen

Projekt Backup/Restore

In diesem Projekt durfte ich als Teilprojektleiter mit arbeiten. Die Banken-Applikation IBIS, die wir auf der Mainframe OS-2200 von Unisys betrieben, war darauf ausgelegt, dass wir jeweils bestimmte Files in Gruppen sicherten. Und das direkt von Disk auf Magnetband. Was in der Nachtverarbeitung sehr viel Zeit beanspruchte.
Darauf wurde das Projekt Backup/Restore ins Leben gerufen. Mit dem Ziel, die Zeit der Datensicherung massiv zu kürzen, und das Tape-Handling zu vereinfachen.

Bedingungen

Lösungen

Projekt Laserdrucker Programmierung

Die Banken-Applikation IBIS produzierte jede Nacht eine enorme Menge Output. Anfangs wurde alles auf mechanischen Druckern gedruckt. Und da nur die Daten gedruckt wurden, musste für jede Bank und jedes Formular jeweils das Papier gewechselt werden. Das heisst, es musste immer das Papier mit dem richtigen Vordruck im Drucker eingespannt sein. Also für Bank xy alle für den Zahlungsverkehr, danach die Formulare für die Wertschriften, Kontokorrent, usw. Und das für gegen 70 Banken.
Irgendwann stieg man auf Laser-Drucker um. In der Software des Laserdruckers gab es eine Möglichkeit, dass man die benötigten Formulare programmieren konnte. Diese wurden dann mit den Daten eingeblendet und gedruckt. So konnte man weisses Papier in den Laserdrucker einspannen, und erhielt dann das entsprechende Bankformular mit samt den Daten.
Ich durfte die ersten Schritte und Versuche mit dieser Software machen. Und durfte in München bei Siemens einen entsprechenden Kurs besuchen. Das Projekt wurde dann allerdings fallen gelassen, da unser Software-Lieferant eine andere Lösung entwickelte, die das Problem zum grössten Teil löste. Man musste nur noch das entsprechende Papier mit dem richtigen Banken-Logo einspannen. Der Rest wie Rahmen in Tabellen, usw. war bereits im Printfile enthalten.

Output Management allgemein

Printfile-Handler Alt (PFH-Alt)

So bezeichneten wir die Steuerung der Printfiles, die nach altem Muster direkt im IBIS erstellt wurden. Diese Printfiles waren für mechanische Drucker gedacht. Konnten aber auch auf Laserdrucker gedruckt werden.
Dies enthielt einerseits die Parameterisierung zur Steuerung der Printfiles. Also, ob und wo ein Printfile gedruckt werden soll. Diese Parameter wurden in einem Programm verwendet, mit dem man zum Beispiel mehrere Printfiles nach den Kriterien wie gleiche Bank und gleiches Formular zu einem Printfile mergen (sammeln) konnte. Auch erstellte sie Listen, anhand deren man mit speziellen Tools die Printfiles auf die entsprechenden Drucker senden (symmen) konnte.
Natürlich blieb auch hier der Fortschritt nicht stehen, und die Anforderungen und Wünsche wurden immer grösser. Bald schon wurden viele Printfiles via FTP direkt an die Banken und diversen Institute übermittelt und dort ausgedruckt. Dazu mussten neue Steuertabellen und Tools entwickelt werden, was teils eine interessante Herausforderung war, aber auch viel Arbeit und Verantwortung mit sich brachte. Denn Output an die falsche Bank zu übermitteln war nicht so gut.
Die verwendeten Tools entwickelte ich mit dem sogenannten SSG = Symbolic Stream Generator. Grob gesehen etwas wie PERL, mit dem man Befehle innerhalb eines Jobs anhand einer Steuertabelle generieren konnte.

Printfile-Handler Neu (PFH-Neu)

Der Schritt in Richtung modernes Output Management. Und das auf einem Mainframe-System.
Während im PFH-Alt jeweils Programme innerhalb der Applikation die kompletten Printfiles für Mechanische Printer erstellten, wurde im PFH-Neu ein moderneres Konzept für Laserprinter angewendet. Grundsätzlich lieferten die Applikations-Programme nur noch die Daten. Die Printfiles wurden erst am Schluss der Verarbeitung erstellt und anschliessend direkt auf die Laserdrucker geschickt, respektiv via FTP elektronisch auf externe Drucker bei den Banken übermittelt.
Der Output war so aufgebaut, dass er anschliessend auf sogenannten Versandstrassen maschinell verpackt werden konnte. Zudem war auch eine Beilagensteuerung eingebaut. Damit konnte anhand von verschiedenen Kriterien gesteuert werden, ob dem Kuvert noch eine Beilage mitgegeben wird. Wobei pro Tag und Kunde nur ein Kuvert generiert wurde, das alle Dokumente für diesen Kunden enthielt. Mit anderen Worten: Alle Dokumente wie Zahlungsverkehr, Wertschriften, Kontokorrent, etc. kamen täglich für den gleichen Kunden in das gleiche Kuvert.
Dazu wurden pro Formular viele Steuerdaten benötigt, die gepflegt werden mussten. Dieser Aufgabe widmete ich mich anfangs. Sie wurde später einer anderen Person übertragen.
Dieser PFH-Neu hatte auch ein gestalterisches Element. Und das wurde mir etwas zum Verhängnis…
Jedes Formular bestand aus verschiedenen sogenannten Textblöcken. Grob muss man sich das wie folgt vorstellen:
Aus einem virtuellen Formular wurde anhand von Koordinaten ein Text, zum Beispiel die Adresse, entnommen, und anhand von anderen Koordinaten wurde dieser Text dann in das zu druckende Formular eingefügt. Damit war es möglich, zum Beispiel die Adresse so zu platzieren, dass in das Fenster im Kuvert passte.
Da wir die ganze Banken-Applikation vom damaligen Rechenzentrum der Berner Kantonalbank bezogen, stellte plötzlich jemand fest, dass der Kontoauszug der Regionalbanken genau das gleiche Design wie der Kontoauszug der Kantonalbanken hat.
Jetzt musste der Kontoauszug ein anderes Design haben. Das wurde dann auch definiert. Und mir viel die Ehre zu, das umzusetzen. Das war eigentlich nicht das Problem. Das Problem kam später bei den Releases. Ich bekam die Änderungen vom Software-Lieferant, und musste dann schauen, wie ich das in unserem Kontoauszug umsetzte. Das war nicht immer einfach. Aber mit eisernem Willen und genügend Tests konnte jeweils eine Lösung gefunden werden. Am 1. April 2003 musste alles wieder so eingestellt sein, wie es vom Software-Lieferanten geliefert wurde.

Vermögensverzeichnisse VVZ

Irgend wann wechselte ich definitiv ins Output Management und übernahm den technischen Betrieb und Unterhalt der Vermögensverzeichnisse. Kurz VVZ genannt. Die Daten wurden von der Mainframe geliefert. Die Dokumente wurden anschliessend auf einem Window-Server erstellt. Das im 7x24 Stunden Betrieb.
Die Hauptaufgabe lag darin, mit einem Kollegen zusammen die Server zu pflegen und im Fehlerfall die Störungen zu beheben.
Die Dokumente wurden mit ISIS Papyrus erstellt. Wobei ich mich nur mit dem Papyrus Designer befasste. Für das Postprocessing wurde StreamWeaver von Bitney Bowes eingesetzt.
Da auf dem Titelblatt eines VVZ noch viel leerer Platz vorhanden war, kam man auf die Idee, diesen für Werbung zu benutzen. So wurde der Werbeblock erfunden. Die Banken konnten damit auf neue Produkte aufmerksam machen, oder dem Kunden sonstige Informationen zukommen lassen. Diese Werbeblöcke galt es jeweils zu pflegen. Als Werbemittel mussten sie jeweils genau auf Termin aufgeschaltet, und auch auf Termin entfernt oder geändert werden. Auch mussten andere Änderungen wie zum Beispiel Logos, etc. vorgenommen werden. Und das für 52 Banken. Zudem mussten auch im StreamWeaver Anpassungen, wie Barcode-Generierung angepasst und ein Reprint-Tool erstellt werden.

VVZ-Prototypen für Ibis3g

Während dieser Zeit wurde die Banken-Applikation Ibis3g entwickelt. Und so wurde auch das Output Management entsprechend erneuert. Für die Wertschriften-Abteilung musste auch das VVZ angepasst werden. Ich durfte dazu die Prototypen erstellen. Das allerdings mit Assentis DocDesign. Um diesen Auftrag auszuführen erhielt ich folgendes: Ein Word-Dokument, in dem alles beschrieben war wie Spaltenbreite, Schriftgrösse, etc. Und ein leeres xml-File sowie das xml-Schema. Aber keine Daten. Und ohne die konnte ich gar nichts anfangen. Aber es hiess, da müsse ich selber schauen. Also, schaute ich halt selber.
Die Rohdaten vom sogenannten Alten VVZ waren auf ihre eigene Art und Weise strukturiert und in symbolischer Form vorhanden. Zudem hatte ich einen ausführlichen Record-Beschrieb zur Hand. Nur gab es Zeilen die aus über 2000 Zeichen lang waren. Wobei innerhalb einer Zeile jeweils ab Position X bis Position Y ein bestimmter Wert verborgen war. Also was jetz? Nun, meine Lösung war, dass ich im alten VVZ ein Testfile aus produktiven Daten zusammenstellte, das alle Records enthielt, die möglich waren. Danach schrieb ich ein PERL-Programm, mit dem ich aus den jeweiligen Zeilen die Werte und Daten nach Record-Beschrieb mittels substring ermitteln, und in ein entsprechendes Outputfile schreiben konnte. Die so erhaltenen Daten übertrug ich dann in das xml-File. Zudem kamen neue gesetzliche Vorschriften. So musste zum Beispiel auch Metall (Gold) und Immobilien neu im VVZ ausgewiesen werden. Da ich dafür keine Daten hatte, habe ich halt jeweils etwas erfunden. Mir ging es ja nur darum, dass ich Daten habe. Nur Bankfachlich war das dann falsch. Das kommunizierte ich auch immer wieder. Mit diesen Daten erstellte ich dann die Prototypen.
Auffi
P.S.: Mit „Auffi‟ geht der Lift nach oben, also an den Seitenanfang. ...auf die Idee, „Nach oben‟ zu schreiben, kam ich anfangs nicht.