Mit Adolf Jändl, Leiter des EDV-Referates beim Bayerischen Landwirtschaftsministerium, sprach Dieter Eckbauer
- Herr Jändl, das Bayerische Landwirtschaftsministerium hat einen flächendeckenden Terminal-Rechnerverbund unter IBMs Systems Network Architecture (SNA) realisiert. Bevor wir in die Tiefe gehen - was verstehen Sie unter SNA?
SNA ist ein Kormmunikations- und Steuerungskonzept, mit dem verschiedene räumlich auseinanderliegende Hardware-Komponenten zum zentralen Rechner über entsprechende Software gesteuert werden.
- Also ein streng zentralistisches Prinzip?
Es ist so, daß wir vom Konzept her ein zentrales Rechenzentrum betreiben, das unsere dezentralen Dienststellen bedient. Wir haben dazu eine Reihe von Terminals sowohl hier in München als auch draußen, im Raume Bayern, installiert.
- Und diese Terminals sind online mit dem Zentralrechner verbunden?
Ja, über Standleitungen. Es ist auch so, daß nicht nur unsere eigenen, sondern auch andere landwirtschaftlich orientierte Stellen als Mitbenutzer des zentralen Rechenzentrums mit solchen Geräten ausgestattet sind.
- Sind das dumme oder intelligente Terminals?
Das ist eine sehr gemischte Ausstattung. Je nach der Anwendung stehen dort sowohl Stapel-Datenstationen mit Lochkarten-Eingabe und -Ausgabe über Drucker als auch reine Dialog-Bildschirme. Darüber hinaus sind auch intelligente IBM 3790-Terminals installiert.
- Wie ist diese ganze Netz-Konfiguration gewachsen?
Zuerst ist das zentrale Rechenzentrum aufgebaut worden. Es wurde 1970 installiert. Damals mit einer 360/55 -ich glaube mit 256 K.
Wir haben dann 1972 die ersten HASP-Terminals und 73/74 die ersten Bildschirm-Terminals eingesetzt. Intensiv sind wir 74/75 in die Bildschirm-Programmierung eingestiegen. Dann sind die Bildschirme mehr und mehr auch für andere Zwecke eingeführt worden, und dabei ergab sich nun das Problem, daß verschiedene Außenstellen, wie zum Beispiel Weihenstephan oder , die Landesanstalt für Tierzucht in Grub, sowohl Batch-Betrieb als auch Dialog über Bildschirme gebraucht haben. Um die Leitungskosten zu minimieren, war es natürlich zweckmäßig, beide Terminal-Typen und Betriebsarten über eine Leitung zu bedienen.
- Wo lag das Problem ?
Das ging nicht mit den vorhandenen Steuerungsmechanismen wie Tcam und Btam, sondern eben nur mit der neuen Software - und das war dieses SNA - Konzept, bei dem über eine Leitung verschiedene Terminaltypen, gleichzeitig bedient werden können.
- Bedeutet das, daß von der Anwendung her ein bestimmter Bedarf da war und IBM auf diese Anforderungen reagiert hat?
Solche Bedürfnisse entstehen ja nicht ad hoc und so klaffen zwischen dem Angebot des Herstellers, das diese Bedürfnisse abdeckt, und den Anwenderwünschen schon ziemlich große zeitliche Lücken. Wir hätten wahrscheinlich unser Netz eher aufgebaut, wenn die entsprechenden Software-Steuerungsmöglichkeiten dagewesen wären. Aber wir haben das Netz nicht weiter ausbauen können, weil wir dann zur selben Dienststelle zwei verschiedene Leitungen hätten betreiben müssen, nämlich eine Standleitung für die Bildschirme und eine zweite Leitung, für ein Batch-Terminal. Erst dadurch, daß wir über eine Leitung beide Terminals bedienen konnten, ist die Sache für uns auch finanziell interessant geworden, und dann war der Weg frei, um wirklich stärker auszubauen.
- So eine Anwendung hätte IBM auch ohne viel Aufhebens mit ein paar zusätzlichen Hardware- und Software-Features geradebiegen können. Dazu bedurfte es eigentlich keines "allumfassenden" Konzeptes wie SNA.
Das ist richtig. Aber es ist schon so, daß auch der Anwender eine gewisse organisatorische Struktur haben muß, damit die Dinge wie SNA interessant werden.
- Wie meinen Sie das?
Wir haben zum Beispiel keinen zentralen Programmierstab, sondern die Programmierung wird immer dort gemacht, wo die Anwendungen anfallen. Das heißt, wir haben zum Beispiel die Landesanstalt für Tierzucht außerhalb von München, und dort sitzen auch die Programmierer, die die Anwendung für diese Landesanstalt programmieren. Ähnlich ist es in Weihenstephan und an den anderen Stellen, so daß von vornherein die ganze Programmierung sehr stark dezentralisiert war. Um diese Dezentralisierung überhaupt sinnvoll aufrechterhalten zu können, war natürlich notwendig, daß die Mitarbeiter der dezentralen Dienststellen auch an ihrem Arbeitsplatz programmieren können.
- Dann sind also die Programmierer in den dezentralen Dienststellen Fachleute, was ja in den meisten Betrieben nicht der Fall ist?
Das sind landwirtschaftliche Fachleute.
- Mit EDV-Kenntnissen?
Ja, das war unser Konzept, daß die Leute, die aus der Fachverwaltung kommen und eine landwirtschaftliche Ausbildung haben, zusätzlich programmieren können. Interessant an der Lösung ist, daß der Informationsweg zwischen dem Anwendungsfachmann und dem EDV-Spezialisten unheimlich kurz ist, weil die zwei sich zumindest auf der fachlichen Ebene verstehen. Der Programmierer, der die Fachanwendung selber programmiert, weiß am besten, was der Kollege braucht. Das ist schon ein großer Vorteil, der sich erst jetzt so richtig zeigt, zumal auch die Programmierer-Hilfsmittel verbessert wurden. Wenn Sie zum Beispiel an die Programmiersprachen denken, die doch wesentlich benutzerfreundlicher geworden sind.
- Trotzdem: Blicken die Anwender bei der Vielzahl von Hardware- und Software-Komponenten, die SNA zusammen faßt, überhaupt noch durch oder müssen sie sich voll auf die System-Spezialisten des Herstellers verlassen?
Sie müssen das bei uns so sehen, daß wir nicht zu einem bestimmten Zeitpunkt voll eingesprungen sind, sondern daß sich die Sache langsam entwickelt hat. Es ist sicher ein Problem - wie Sie sagen -, daß es zwischen dem Rechenzentrum und dem Endbenutzer sehr viele verschiedenartige Software- und auch Hardware-Komponenten gibt. Wenn Sie mal die Technik anschauen, dann haben Sie nach dem Host-Rechner die Datenfernübertragungs-Steuereinheit 3705, das Modem, dann die Standleitung, dann kommt auf der anderen Seite wieder ein Modem und eventuell ein Knoten, in dem diese eine Leitung in mehrere andere Leitungen aufgespalten wird. An einer dieser Leitungen , hängt wieder ein Modem, Standleitung, Modem und ein weiteres Terminal.
- Da haben Sie schon mehr als eine Handvoll Einzel-Komponenten ...
... dazu kommt jetzt noch die Software. In der 3705 das Netzwerk-Steuerprogramm NCP, im Rechner selbst ACF/ Vtam, dann die Leitungssteuerung unter SDLC. Und da ist es nun bei uns so gewesen, daß das Ganze einfach aus kleinen Anfängen entwickelt worden ist. Wir haben angefangen mit der 3705 und zuerst die 2701 emuliert. Der zweite Schritt war, Vtam auf der großen Anlage zu installieren. Dann kam als nächstes SDLC, so daß nicht das Gesamtpaket auf Schwung installiert wurde. Darin sähe ich echt Probleme, wenn der Benutzer die Sache selber überhaupt nicht mehr durchschaut und zu sehr auf das angewiesen ist, was der Hersteller sagt. Aber dadurch, daß bei uns alles langsam entwickelt worden ist, sind wir mit der Entwicklung mitgewachsen, und ich glaube, daß wir den Durchblick haben - zumindest bereitet uns SNA keine Schwierigkeiten.
- Aber Sie hatten doch bereits eine Vielzahl von Anwendungen auf der Anlage. Laufen die denn unabhängig von SDLC?
Ja, die laufen unabhängig. Es ist ja nur der Vtam-Teil geändert worden, die Anwenderprogramme sind gleich geblieben Es ist das neue Vtam-Teilstück eingeschoben worden und die Anwendung hat wieder funktioniert. Letztendlich wurde das der Endbenutzer überhaupt nicht merken.
- Kann denn der Benutzer draußen an den Terminal den Job starten?
Ja. Der kann auch Ergebnisse anschauen. Er ist voll verantwortlich und zuständig für seine Verarbeitung der Anwendungsprogramme. Er kann selber nach bestimmten Richtlinien, die ihm das Rechenzentrum gibt, den Job in bestimmte Warteschlangen stellen, die dann vom Rechner entsprechend abgearbeitet werden. Vom Bildschirm aus hat er die Möglichkeit, mit TSO sein Anwendungsprogramm in den Batch zu bringen und den Output über den Bildschirm anzuschauen. Er kann auch steuern, daß der Output an bestimmten anderen Orten ausgedruckt wird.
- Wir möchten auf Ihre SNA-Definition zurückkommen, die Sie vorhin gegeben haben. Worin sehen Sie den Vorteil dieses Netzwerk-Konzeptes und wo hat es Schwächen?
Wir wollen möglichst einheitliche Software haben. Wir wollen ungern neben SDLC auch noch BSC fahren. Wir haben in den letzten Jahren die Schwierigkeit gehabt, daß wir verschiedene Terminals hatten, die zu dem Zeitpunkt noch nicht SDLC-fähig waren. Wenn Sie an die 3271-Stationen denken, die mußten ja hardwaremäßig nachgerüstet werden, damit sie überhaupt SDLC-fähig wurden. Wir haben auch heute noch den Fall - gerade bei IBM - daß noch nicht alle Geräte SDLC-fähig sind.
- Können Sie uns Beispiele nennen?
Wenn Sie nur an den ganzen Bereich Basisdatenverarbeitung denken. Wir haben zum Beispiel den Tischcomputer 5110 eingesetzt, der heute noch nicht SDLC-fähig ist. Leider, das ist echt ein Problem für den Benutzer. Oder denken Sie an das Textsystem 6, auch das ist heute noch nicht SDLC-fähig. Das sind zwar Einzelfälle, aber die tun uns zum Teil weh, weil sie außerhalb unserer Standards laufen. Und das ist etwas, was für den Kunden nicht immer ganz verständlich ist. Wenn man schon das SNA-Konzept anbietet, dann müßten eigentlich die Geräte, die auf den Markt kommen, alle SNA-fähig sein. Das ist leider nicht der Fall.
- Ist das wirklich so gravierend?
Unser Ziel ist es, nur SDLC zu fahren, weil wir dann nur die Software, die SDLC bedient, im Rechner haben müssen. Wenn wir auch noch BSC haben, dann ist das ein zusätzlicher Aufwand mit zusätzlichen Fehlermöglichkeiten. Aber das ist ein Koordinierungsprozeß, der natürlich auch innerhalb, der IBM eine gewisse Zeit braucht, bis er abgeschlossen ist. Wir hoffen , daß wir jetzt überwunden haben, und Sie sehen es ja auch an den Neuankündigungen, die alle SDLC-fähig sind.
- Nun ist SNA ein herstellerspezifisches Netzwerk-Konzept. Legen Sie sich hard- und softwaremäßig nicht zu sehr fest?
Uns ist klar, daß wir momentan mit SDLC und dem ganzen SNA-Konzept bei einem Hersteller bleiben müssen. Irgendwann wird es sicher so sein, daß aus dieser Herstellerebene das Ganze über Schnittstellen zu anderen Netzen verknüpfbar sein muß. Ob, es dann so weit kommt, daß dieses jetzt herstellerbezogene Netz reibungslos in ein Gesamtkonzept eingebunden werden kann, ist wieder eine andere Frage. Aber je eher das möglich ist, um so besser ist es für uns.