Mit der Entwicklung des Systems Ongum wurde vor nahezu zehn Jahren begonnen. Das Ziel war die Automatisierung und die Sicherung des Austausches von Dateien zwischen Rechenzentren. Heute erlaubt dieses Dateivermittlungs-System die bedienerlose, automatische Vermittlung und Uebertragung von Dateien aller Art. Es bedarf keiner Anpassung von bestehenden Anwendungen an Ongum. Durch die Restart-Verarbeitung nach Leitungszusammenbruechen ist das System fuer den 24-Stunden-Betrieb geeignet. Die Vermittlung und der Transport von Dateien zwischen Mainframes ueber Ongum war bisher nur ueber SNA- beziehungsweise Datex-P-Verbindungen moeglich.
Zusaetzliches Medium fuer den Dateien-Transport
Die Verfuegbarkeit von FTAM-Produkten auf Mainframes veranlasste den DSGV, sie als ein zusaetzliches Medium fuer den Transport ueber Ongum zu nutzen. Damit wird der Transport von Dateien via dem Dateivermittlungs-System Ongum ueber dieses Medium moeglich. Insbesondere erlauben diese Produkte aber die Einbeziehung von anderen Systemen in den Ongum-Verbund. Im ersten Schritt wurden daher die FTAM-Produkte FTOS (von SNI) auf BS2000, OSI/FS (von IBM) und Osilink (von Coconet) auf MVS an das Dateivermittlungs- System angebunden.
Damit koennen Unternehmen ueber FTAM ihre Dateien an die Mainframe- Anwendungen heranbringen beziehungsweise von dort empfangen. Der Vorteil fuer die Nutzer liegt auf der Hand: Ueber FTAM empfangene Dateien beduerfen keiner manuellen Bearbeitung, sie werden ueber die in Ongum definierte Folgeverarbeitung direkt den Anwendungen zugestellt; mit FTAM zu versendende Dateien werden erkannt und zum weiteren Transport an die FTAM-Produkte geleitet.
Spaetestens mit der Entscheidung der Deutschen Bundesbank, ihre elektronische Oeffnung mit Hilfe des FTAM-Standards zu bewerkstelligen, bekamen FTAM-Produkte einen betraechtlichen Einsatzschub. Mittlerweile gibt es bereits eine Reihe von Anwendungen, insbesondere im Bereich des Zahlungsverkehrs, die auf dem FTAM-Standard basieren oder aber in der Realisierung sind. Beispiele hierfuer sind neben dem EAF der Bundesbank das BCS des Bankverlages, Elko und Multicash etc.
Im Bereich des DSGV wird das bei der West LB entwickelte Ongum seit 1983 eingesetzt. Das Vermittlungssystem erkennt zu versendende Dateien und stellt sie dem Zielsystem zu. Empfangene Dateien werden den Anwendungen zugeordnet, gegebenenfalls wird eine Folgeverarbeitung initiiert. Das System bietet optionale Unterstuetzung zur Uebermittlung von Dateien des Zahlungsverkehrs. Dazu gehoert die Verarbeitung von A- und E-Saetzen ebenso wie die Komprimierung, Verschluesselung der Daten auf dem Transportweg und ein Quittungsverfahren.
Mit der Einbeziehung von FTAM-Produkten in das Dateivermittlungs- System verfolgt der DSGV mehrere Ziele. Zum einen erschliesst man sich ueber die FTAM-Schnittstelle ein weiteres Transportmedium mit weltweiten Verbindungsmoeglichkeiten. Man erhaelt eine herstellerneutrale offene Kommunikation mit Rechnern unterschiedlicher Hersteller und Betriebssysteme. Dies erlaubt insbesondere die Einbeziehung von Nicht-Ongum-Systemen in den Ongum-Verbund (siehe Abbildung 1).
Zum anderen wurde mit der Realisierung der FTAM-Anbindung das Dateivermittlungs-System fuer weitere Komprimierungsverfahren geoeffnet. Insbesondere wurde die FTAM-Komprimierung eingebunden. Ueber den Einsatz der Komprimierungsverfahren lassen sich auch einige Schwaechen der FTAM-Produkte in der Handhabung von Dateiformaten ausgleichen. Zusaetzlich ergaenzt die Anbindung an Ongum die FTAM-Produkte um die nicht vorhandene Folgeverarbeitung.
Das FTAM-Protokoll ist in der ISO-Norm ISO 8571 beschrieben. Die Standards Promotion and Application Group (SPAGhat das Anwendungsprofil ENV41204 definiert. Es ist in allen FTAM- Produkten realisiert. Durch die Normierungen sind der Funktionsumfang und die Kommunikationsprimitive festgelegt, aber nicht die Einbettung in die Betriebssysteme und insbesondere nicht die Schnittstellen zu den Anwendungen.
Da den Anwendern kein bestimmtes FTAM-Produkt vorgeschrieben werden sollte, erfolgte die Anbindung ueber eine allgemeine, produktunabhaengige Schnittstelle und Module realisiert.
Die Implementierer der FTAM-Produkte haben sehr unterschiedliche Anwendungsmodelle realisiert. Das Ongum-FTAM wurde auf diese produktspezifischen Loesungen abgebildet (siehe Abbildung 2).
Ongum kennt an der FTAM-Schnittstelle kein rollenspezifisches Verhalten. Es muss lediglich vereinbart werden, welche Rollen die Systeme zueinander einnehmen (Initiator/Responder/beides). Sind zum Beispiel fuer das lokale System beide Rollen vereinbart und fuer den entfernten Partner die Initiatorrolle (bei FTAM auf MS-DOS ist dies notwendig), so werden Dateien, die an diesen Empfaenger versandt werden, in einem lokalen, nur ihm zugaenglichen Bereich (VFS) zum Abholen bereitgestellt. Dateien, die dieser Partner an das lokale System schickt, werden ebenfalls in diesem VFS abgelegt und bei Gelegenheit von Ongum empfangen. Im Normalfall versendet Ongum die Dateien als Initiator und empfaengt sie als Responder.
Die Adressierung der Partner erfolgt jeweils ueber eine eindeutige Bezeichnung. Diese wird ueber mehrere Tabellen auf OSI-Adressen, Initiatornamen, Account-Informationen und Passwoerter abgebildet, je nachdem, was die verschiedenen FTAM-Produkte unterstuetzen.
Um Dateien bei einem Partner abholen zu koennen, muss dem Initiator ihr OSI-Name bekannt sein. Da die Namen der Dateien, die fuer den Teilnehmer bereitgestellt wurden, im vorhinein jedoch nicht gelaeufig sind, werden sie in einer Datei hinterlegt, deren OSI- Namen der Initiator weiss. Das Arbeiten mit Inhaltsverzeichnissen kann optional zwischen Teilnehmern vereinbart werden und ist in der Regel nur in der Verbindung mit reinen Initiatorsystemen erforderlich (FTAM auf MS-DOS).
Die FTAM-Anbindung wurde dergestalt ausgefuehrt, dass sie sich moeglichst nicht nur gegen Leitungsausfall, sondern auch im Fall des Systemzusammenbruches robust verhaelt. Das heisst, Informationen ueber Transferauftraege werden dann erst aus der Schnittstelle beziehungsweise den FTAM-Produkten entfernt, wenn sie sicher von Ongum uebernommen wurden. Leider unterstuetzen dies nicht alle Produkte im ausreichenden Masse.
FTOS als eine Ergaenzung zu FT-BS2000
SNI bietet eine FTAM-Implementation unter dem Namen FTOS als Ergaenzung zu FT-BS2000 auf ihren BS2000-Systemen an. Als Benutzer- Schnittstelle steht dem Anwender das FT-Kommando zur Verfuegung. Als Programmier-Schnittstelle dient eine Macro-Version des JCL- Kommandos. Die FTAM-Eigenschaften werden nur dem Systemadministrator sichtbar, der die Partneradressen eintraegt. Beide Schnittstellen sind einfach und effizient. Sie liefern aber keinerlei Informationen ueber Dateien, die von entfernten Systemen aus eingestellt wurden.
Anforderungen aus entfernten Systemen muessen neben der OSI- Adresse des lokalen Systems zusaetzlich die gewuenschte BS2000- Benutzerkennung als Initiatornamen und die Account-Information uebermitteln. Wird dies von den bei den Partnern eingesetzten FTAM- Produkten (zum Beispiel OSI/FSnicht unterstuetzt, so muss im BS2000 diese Zuordnung ueber die Komponente FTAC durchgefuehrt werden. FTAC kann darueber hinaus fuer feinere Regelungen der Zugangsbeschraenkungen, zum Beispiel auf Dateien, eingesetzt werden.
Fuer jeden entfernten Teilnehmer, der als Initiator auftreten kann, wird daher im BS2000 eine eigene BS2000-Kennung eingerichtet. Diese bildet den lokalen VFS des Partners. Hier stellt er seine Dateien ein beziehungsweise holt sie von dort ab. Vom Partner mit Parametern versehene Dateien holt von Ongum ueber die generische Schnittstelle und vermittelt sie an die Anwendungen weiter.
FTOS kann als Initiator aus entfernten Systemen zwar Dateien kopieren, aber nicht loeschen. Damit ist FTOS im Rahmen von Ongum zwar normal einsetzbar, kann aber nicht als reiner Initiator fungieren.
IBM bietet eine FTAM-Implementation unter dem Namen OSI/FS in Verbindung mit OSI/CS an. Fuer jeden FTAM-Benutzer kann ein lokaler VFS definiert werden.
Lokal wird das VFS ueber einen frei gewaehlten Namen adressiert, von aussen ueber eine ihm in OSI/CS zugeordnete OSI-Adresse. OSI/FS kann Initiatornamen an Partner uebermitteln, aber keine Account- Informationen. Eingehende Initiatornamen werden angezeigt.
Als Bedien-Schnittstelle steht dem Anwender ein System von ISPF- Panels zur Verfuegung, wobei das Interface komplex ist. Neben den Initiatorfunktionen und der FTAM-Verwaltung handhabt die Benutzer- Schnittstelle von aussen definierte Dateien. Am Programmier- Interface steht dem Anwender eine Menge von Funktionsaufrufen in C und Cobol zur Verfuegung. Ueber diese Funktionen kann er sowohl das lokale VFS manipulieren als auch Auftraege an OSI/FS initiieren und deren Zustand erfragen. Die Kommunikation zwischen der Anwender- Schnittstelle und dem eigentlichen OSI/FS erfolgt ueber VTAM- Verbindungen. Programmier- und Benutzer-Schnittstelle spiegeln das komplexe Anwendungsmodell wider.
Fuer jeden entfernten Teilnehmer, der als Initiator auftreten kann, wird in OSI/FS eine eigene OSI/FS-Kennung und ein VFS eingerichtet. Darueber wird der Transfer der Dateien fuer den und von dem Teilnehmer abgewickelt.
Die Firma Coconet bietet unter dem Namen Osilink eine FTAM- Implementation unter MVS an. Als Bedien-Schnittstelle stehen dem Anwender ISPF-Panels zum Initiieren von FTAM-Auftraegen und zur FTAM-Verwaltung zur Verfuegung, aber keine Funktionen zum Erkennen von eingegangenen Dateien. Am Programmier-Interface hat der dem Anwender eine Reihe von Funktionen zur Initiierung von Transferauftraegen und zum Erfragen ihrer Stati. Die Programmiersprachen C, PL1 und Assembler werden unterstuetzt. Die Kommunikation zwischen der OsilinkSchnittstelle und dem eigentlichen Osilink erfolgt ueber VSAM-Dateien, in die Auftraege und Ergebnisse eingestellt werden. Das Produkt handhabt zu den OSI-Adressen sowohl Initiatornamen als auch Account-Informationen und kennt kein lokales VFS wie OSI/FS. Der Anwender kann beziehungsweise muss die Abbildung von eingehenden Anforderungen auf das lokale Dateisystem selbst ueber User-Exits im Responder konfigurieren.
Diese Moeglichkeiten werden im Ongum genutzt, um fuer jeden entfernten Partner ein lokales VFS aufzubauen. Er besteht im wesentlichen aus einem Verzeichnis der bereitgestellten und empfangenen Dateien und diesen selbst. Das dem Teilnehmer zugeordnete VFS wird lokal ueber die Teilnehmerbezeichnung und von aussen ueber die OSI-Adresse ermittelt. Eine empfangene Datei wird in dem Verzeichnis registriert und von Ongum ueber die FTAM- Schnittstelle aufgespuert.
FTAM-Anwendungen noch in den Kinderschuhen
Fazit: Allen FTAM-Produkten ist anzumerken, dass ihr Gebrauch erst in den Anfaengen steckt. Sie wurden bisher anscheinend nur in einfachen Anwendungen ohne besondere Last betrieben. Das Dateivermittlungs-System Ongum stellt aber erhebliche Anforderungen an diese Produkte: parallelen Betrieb der Schnittstellen in Subtasks, Restart-Sicherheit, hohe Last (die West LB versendet mehr als 15 000 Dateien monatlich ueber Ongum).
Im Zuge der Implementierung der FTAM-Anbindung wurden bei allen FTAM-Produkten Fehler und Unzulaenglichkeiten gefunden. Diese behoben die Produktanbieter entweder sofort oder sind gerade dabei, die Probleme zu loesen. Trotz einiger punktueller Schwaechen ist mit Produkten auf Basis des FTAM-Standards der Aufbau eines heterogenen Systemverbundes moeglich. Die unterschiedliche Interpretation von Dateiformaten beziehungsweise die fehlende Unterstuetzung kann durch den Einsatz von Komprimierungsverfahren umgangen werden.
Die fuer einen automatischen Betrieb notwendige, bei FTAM fehlende Folgeverarbeitung, wird in diesem Fall durch das Dateivermittlungs-System behoben. Damit ergibt die Kombination dieses Systems mit FTAM-Produkten ein sehr maechtiges Instrument zur Automatisierung und Standardisierung der Datenkommunikation.
*Georg Schaeffler ist Berater fuer den Einsatz von Kommunikationstechnologie bei der Pape & Partner Informationssysteme GmbH, Hamburg.
Abb. 1: Einbeziehung von FTAM-Produkten in das Dateivermittlungs- System Ongum. Quelle: PPI
Abb. 2: Ongum-FTAM-Anwendungsmodell. Quelle: PPI