Wer sich flexiblen Anforderungen stellen und trotzdem die Kosten in Schranken halten will, muß nach - derzeit noch - ungewöhnlichen Lösungen Ausschau halten. Eine davon lautet: Für jede Anwendung die richtige System-Welt. Das Einrichtungshaus Ostermann in Witten verteilte die Aufgaben auf drei unterschiedliche IBM-Welten. Rolf Dziony* zeigt, wie sie technisch und wirtschaftlich wieder vereint wurden.

Gelegentlich hat sich die EDV nach dem Menschen zu richten. Dann etwa, wenn dieser sein Einkaufsverhalten ändert. So liegt zur Zeit die "Mitnahme" von Möbeln bei den Kunden voll im Trend. Die Konsequenz: Die Schnittstelle zwischen dem Kunden und der DV des Händlers muß noch reibungsloser und einfacher funktionieren. Damit der Kunde eine zuverlässige und schnelle Bestandsauskunft noch im Verkaufsraum erhalten kann, muß der Warenfluß im gesamten Wirtschaftssystem automatisiert werden. Sämtliche Daten müssen zu allen Verkaufsöffnungszeiten verfügbar sein.

Diese Forderung sollte das System des Einrichtungshauses Ostermann für alle sechs Filialen in Nordrhein-Westfalen erfüllen. Darüber hinaus sollten die 700 Mitarbeiter jederzeit auf Knopfdruck den aktuellsten Informationsstand in ihrem Bereich haben, vor allem die Geschäftsleitung, die täglich Statistiken samt Grafik und Prognose für ihre Entscheidungsfindung braucht.

Nach Abwägung aller organisatorischen Erfordernisse und betriebswirtschaftlichen Faktoren wurde Anfang 1990 folgendes Ziel festgeschrieben: Verteilte DV in allen Häusern kommt aus Flexibilitäts- und Kostengründen nicht in Frage. Vielmehr sollte für die verschiedenen Anwendungen eine jeweils passende Systemumgebung gefunden werden.

Das Ergebnis: Die Datenbestände werden zentral im Haupthaus in Witten verwaltet, die Anwendungen dezentralisiert und untereinander verknüpft.

Der bereits vorhandene 4381-Rechner ist künftig ausschließlich für administrative, steuernde und zentral reglementierende Aufgaben reserviert; die neu angeschaffte AS/400 übernimmt ihrem Charakter gemäß fachabteilungs- und anwendungsorientierte Aufgaben; die PCs schließlich erfüllen die individuellen und arbeitsplatzorientierten

Aufgaben. Alle Mainframe-Leistungen werden ausschließlich zentral vom Stammhaus an die angeschlossenen Verkaufshäuser geliefert. Weil das IBM-Angebot hier jedoch Lücken aufweist, die der Verknüpfung von

Anwendungen in unterschiedlichen Systemarchitekturen entgegenstehen, mußte zusätzliches Software-Know-how von außen geholt werden.

Das Konzept beinhaltet, daß

- die Anwendungsprogramme ihre Daten immer lokal bereitgestellt bekommen. Damit sind sie unabhängig von den anderen verbundenen Systemen und erlauben eine schnelle und einfache Programmierung;

- alle empfindlichen und geänderten Daten sofort an die anderen "Welten" geschickt werden. Die gemeinsamen Datenelemente der /370 und der AS/400, zum Beispiel Artikel- und Lager-Stämme oder Preise, werden in beiden Systemen geführt.

Diese Redundanz führt dazu, daß alle Local-Anwendungen (auf der 4381 oder AS/400) nicht in die jeweils andere Welt durchgreifen müssen.

Voraussetzung ist die absolute Übereinstimmung der doppelt geführten Daten, das heißt, alle Relevanten Änderungen auf der /370 müssen unverzüglich zur AS/400 gesendet werden und umgekehrt.

Die Crux liegt in der Datenintegration

Oberste Bedingung für eine solche Lösung ist die Datendurchlässigkeit und Integration der beteiligten Systeme vom Verkaufsraum bis zum täglichen Rechenzentrumslauf bei absoluter Datenintegration. Die folgenden Beispiele zeigen auf, welche Anwendungen durch einen Verkaufsvorgang initiiert werden.

Beispiel Barverkauf:

Der Kunde möchte einen Artikel bar bezahlen. Die Kasse hat den zur Zeit gültigen Preis gespeichert. Bei der Auslösung der Rechnung meldet die Kasse den Vorgang über den Kommunikations-PC an die AS/400, die daraufhin eine entsprechende Bestandsänderung durchführt. Für Artikel, die am Lager abgeholt werden müssen, wird ein Bereitstellungspapier ausgelöst. Die Daten werden von der AS/400 über den Token-Ring auf der 4381 ausgedruckt. Die abgebuchten Mengen werden abends im Batchlauf auf dem Mainframe nachvollzogen. Während der Geschäftsöffnungszeit ist für die Anwendungen die AS/400 das führende System.

Beispiel Kundenbestellung:

Bei Lagerartikeln führt der Verkäufer eine Vorreservierung durch und vermindert so direkt den aktuellen, verfügbaren Bestand. Das System verhindert Vorreservierungen, die terminlich über den Wiederbeschaffungszeitraum hinausgehen.

Die abgebuchten Mengen und die Aufträge werden ebenfalls abends im Batchlauf auf der 4381 nachvollzogen. Durch die endgültige Erfassung der Aufträge werden die Vorreservierungen wieder aufgelöst. Anzahlungen zu einer Kundenbestellung werden an der Kasse verbucht und an die Finanzbuchhaltung, die auf der 4381 läuft, weitergeleitet.

Beispiel Stamm- und Schlüsseldaten:

Diese Daten werden ausschließlich auf der 4381 gepflegt. Jede Veränderung wird automatisch parallel auf der AS/400 nachvollzogen. Damit ist die Durchgängigkeit des Berichtswesens bei allen Geschäftsvorfällen auf der 4381, der AS/400 und den Kassen sichergestellt.

Außerdem wird so erreicht, daß die AS/400 als zentrales System genutzt werden kann. Selbstverständlich bedurfte die Verbindung der einzelnen Systeme einiger software-technischer Anpassungen.

Die Aufgaben des Systemverbundes wurden von spezialisierten Softwarehäusern (Insoft, Düsseldorf, und Weeke & Mühling, Essen) verwirklicht. Über LU6.2 (APPC-Verbindung) verbanden sie die AS/400 mit der /370-Welt.

Die abteilungsnahe AS/400 steht dabei im Mittelpunkt der Verknüpfungen. Sie unterstützt das SNA-Netz und die PC-Seite gleichermaßen. Drei Systemwelten - 4381, AS/400, PS/2-Modelle mit angeschlossenen Kassen - arbeiten im Verbund über einen Token-Ring. Jedes Verkaufshaus verfügt über einen eigenen Token-Ring, diese wiederum sind über Standleitungen mit 9600 Baud untereinander verbunden.

In der ersten Phase wurde der Zugriff auf die verschiedenen Systeme realisiert. Die bestehende Infrastruktur, wie beispielsweise /370-Bildschirme, wurden für den Zugriff auf die AS/400 über den Token-Ring genutzt. Auch der umgekehrte Weg- AS/400-Bildschirme haben Zugriff auf die /370-Welt - wurde verwirklicht, wobei die PS/2-Modelle über die Steuereinheit sowohl auf der 4381 als auch auf der AS/400 arbeiten. Sollte die 4381 einmal ausfallen, können die /370-Bildschirme immer noch auf der AS/400 arbeiten, da die Emulation nicht auf dem Host stattfindet (HCF), sondern auf der Steuereinheit (Multi-Host-Verbindung) durchgeführt wird.

Damit ist zwar die Nutzung aller Systemkomponenten ermöglicht, das eigentliche Ziel war jedoch, die Anwendungen miteinander zu verknüpfen: Die Anwendungspakete COPICS auf der 4381, das Vertriebsinformations-System OBIS auf der AS/400 und die Arbeitsplatz-Anwendungen (beziehungsweise Kassen) kommunizieren miteinander.

Der Informationsaustausch findet sofort und direkt über alle Systeme statt. Hierzu einige Anwendungsfälle:

Beispiel Bestandsänderung:

An einer Kasse wird ein Artikel verkauft. Der geänderte Bestand wird an das Vertriebsinformationssystem auf der AS/400 und an COPICS auf der 4381 gesandt.

Beispiel Reservierung:

Ein Artikel soll reserviert werden. Die Reservierung findet im Vertriebsinformationssystem auf der AS/400 statt. Diese Informationen werden an COPICS (4381) geschickt.

Beispiel Wareneingang:

Der Wareneingang findet im COPICS statt, also auf der 4381 unter CICS. Auch in diesem Fall muß die neue Bestandssituation an das Vertriebsinformationssystem gesandt werden.

Beispiel interner Warenverkehr:

Alle Bewegungen zwischen den einzelnen Betriebsstätten werden auf der AS/400 initiiert. Bestände werden direkt bei der angegebenen Stelle vermindert und erst durch den Wareneingang der empfangenden Stelle als körperlicher Bestand verbucht. Die Warenbegleitpapiere werden automatisch erstellt und über die 4381 ausgedruckt.

Jedes System im Verbund kann der Auslöser einer Kommunikation sein. In jedem gibt es zu jedem Zielsystem je eine Sende- und eine Empfangsfunktion, also von COPICS an das Vertriebs-Informationssystem und umgekehrt, von den Kassen zum Vertriebs-Informationssystem und umgekehrt etc.

Von den täglich 100 000 Transaktionen auf der 4381 werden zirka 1000 durch die Kommunikation ausgelöst, entsprechend auf der AS/400 insgesamt zirka 40 000 Jobs ( = Transaktionen) pro Tag. Die Übertragung der Daten unter CICS wurde mit der APPC LU 6.2 Schnittstelle programmiert. Da die relevanten Daten der beiden Welten immer auf dem gleichen Stand gehalten werden, müssen diesbezügliche Änderungen zu den DL/1-Datenbanken, in VSAM-Dateien oder in das Tabellen-Verarbeitungs-System VTAS (Insoft) weitergeleitet werden. Die CICS-Anwendungsprogramme sollen hierfür aber keiner "Grundreinigung" unterliegen, sondern eine einfache, schnelle und sichere Anschlußstelle bekommen.

- Einfach: Nur die relevanten Felder werden über ein Link-Modul weitergegeben; eine eindeutige Satzart definiert den Umfang (Feldkennungen sind also nicht nötig).

- Schnell: Alle geänderten Felder werden bis zum Ende der Transaktion (Commit) in einem Speicherbereich festgehalten. Die komplette Sendung gilt dann als ein Päckchen und wird weitergeleitet.

- Sicher: Falls das Anwendungsprogramm vor dem Commit abbricht, werden keine Daten weitergegeben. Die Speicherbereiche werden freigegeben und das CICS-Rollback-Geschäft läuft weiter.

Falls das Empfangssystem nicht bereit war, sind auf jeden Fall alle Daten in einer Sendedatei gelandet und können jederzeit weitergeleitet werden. Beim Hochfahren des CICS wird automatisch ein Programm gestartet, das alle nicht bearbeiteten Sendungen "nachschickt".

Das Versenden der Daten läuft als Hintergrund-Task nur im Bedarfsfall an. Das Programm benutzt die APPC-Schnittstelle, baut die Verbindung auf, sendet das "Päckchen" und wartet auf eine Empfangsbestätigung (Confirm). Da diese Aktivitäten wie in einer "Blackbox" ablaufen, werden Statistiken über die gesendeten Daten im Tabellenverwaltungssystem VTAS festgehalten. Sie geben Auskunft über die maximale Laufzeit einer Sendung, die maximale Datenlänge oder über aufgetretene Fehler. Eine Anzeigetransaktion ermöglicht die Ansicht der gesendeten und empfangenen Daten.

Empfangen der Daten aus der AS/400

Auch hier werden wieder die LU-6.2-Schnittstelle und APPC durch eine CICS-Task gestartet, um die Daten aus der AS/400 zu empfangen. Die Daten werden schnellstens in die Empfangsdatei gebracht, anschließend wird eine Verteiler-Transaktion im Hintergrund gestartet. Diese Task ruft anschließend diverse CICS-Programme (je nach Satzart) auf, um die empfangenen Daten in die, entsprechenden Bereiche zu bringen. Alles in allem werden neben diversen Systemanpassungen in der TCT (Terminal Control Table) und VTAM nur ein VSAM/KSDS-Dataset und sechs Assembler-Programme von eins bis sechs KB Größe benötigt.

Vorhandene Ressourcen werden optimal genutzt

Die Nutzenbilanz des Integrations-Projektes sieht nach nunmehr fast einjähriger Bewährung in der Produktion durchweg positiv aus. Zwischen Projektstart und Projektende lagen, inklusive Schulung und Testphase, nur sechs Monate. Die Neuanschaffung der AS/400 kam billiger als die Anschaffung eines größeren /370-Systems. Die Softwarelizenzen kosteten für den realisierten System-Mix wesentlich weniger, das Preis-Leistungs-Verhältnis war ungefähr doppelt so günstig. Den größten Gewinn sieht Ostermann jedoch in dem erreichten Wettbewerbsvorteil durch die rasche Auskunftsbetreuung des Kunden im Verkaufsraum.