Was ist "Polisy"?

07.08.1981

Das Versicherungssystem "Polisy (siehe nebenstehenden Beitrag) ließ bei seiner Entwicklung nicht nur in Australien die Fachwelt aufhorchen entstand es doch In nur 18 Mann-Monaten und in beachtlichen Tempo: Pro Tag und Mitarbeiter produzierte die kleine Inscom Pty Ltd. durchschnittlich 1500 Cobol-Zeilen, voll getestet und kompliziert.

Zum Vergleich: Im allgemeinen rechnet man für die Entwicklung so ehrgeiziger Projekte wie Versicherungs-Anwendungen drei bis fünf Jahre Zeitaufwand und Teams von über einem Dutzend Mitarbeiter. Inscoms Direktor David Albert verriet der australischen CW-Schwesterzeitschrift Computerworld jedoch sein Rezept: Wir wählten eine Perkin-Elmer-3240, die uns vor allem wegen ihres "Transaction Controllers" (ITC) ansprach; derartige Supermini sind ja besonders für die Transaktionsverarbeitung ausgelegt, und auch die Software Entwicklerei für solche Rechner unterscheidet sich gravierend vom üblichen Vorgehen in einer Batch-Umgebung.

Der hier angesprochene Transaction Controller, so muß man ergänzen steuert die gesamte Kommunikation zwischen dem Prozessor und den Terminals, teilt Prozessor-Ressourcen zu und hilft bei der Entwicklung der Bildschrim-Masken. Dazu kommt noch das Total-Data-Base-System zur umfassenden Dateibehandlung.

Sämtliche Transaktionen werden bei Polisy mit Datum, Terminal-Nummer und Signatur des betreffenden Operators versehen.

Inscom hat einen eigenen Programm-Generator entwickelt, mit dessen Unterstützung man in wenigen Stunden seine eigenen Anwendungen vorbereiten kann; benötigt er einen Report, kann der zuständige Programmierer (fürs erste Jahr wird einer "mitgeliefert") diesen in wenigen Stunden programmieren. Gerade hier, so erläuterte Albert, zeige sich der große Nutzeffekt der modernen Software-Tools.

Neben der leichten Handhabung, eine "Help"-Funktion hilft beim Einarbeiten, zeichnet "Polisy" sich auch durch ein umfangreiches Sicherheitssystem mit Paßwörtern aus.

Neben eingegebene Daten werden am Terminal ediert und überprüft; alle Transaktionen verändern den Datenbestand in Echtzeit, wodurch nächtliche Batch-Läufe vermieden werden. und kommt der Datenbestand vom 3240 automatisch auf den Status quo ante gebracht.