Zu einem konzentrierten, interaktiven Dialog wuchs sich das Roundtable-Gespräch aus, das die CW in Hannover mit den drei Gästen (v. l.) Dr. Helmut Hueber (Vereinigte Metallwerke Ranshofen Berndorf), Rüdiger Podlech (Bundesverteidigungsministerium) und Christian Hollwich (Agrob AG) und Ausstellern im CeBIT veranstaltete. Zwar hätte sich die Frage stellen lassen, ob denn der Messetrubel überhaupt das geeignete Umfeld darstellt, um Anwenderprobleme in aller Tiefe lösen zu können. Wenngleich es eine Menge guter Gründe geben mag, Hannover nur als Anregung zu nehmen und vom Gespräch auf dem Stand nicht zu viel zu erwarten: Das CW-Roundtable-Gespräch bewies immerhin, der Dialog war notwendig und hat durch das unmittelbare Nachfragen mehr als nur die pure Information an den Tag gefördert. Mit Sicherheit entstand in dieser von der Zeit her komprimierten (wahrscheinlich deshalb konzentrierten) Auseinandersetzung auch eine Vertrauensebene, auf der Fragen und Antworten besser einzuordnen waren. Für alle Beteiligten war als Ergebnis befriedigend, daß schließlich auch die Befragten zu Fragern wurden - und daß sich der Kreis nicht einfach auflöste, sondern im Zweiergespräch den Gedankenaustausch fortsetzte - mit der Anregung für die CW, diese Art von Kommunikation im "CW-Forum" fortzusetzen. Teilnehmer waren: Hans Bilgram, Hewlett Packard; Dieter Dieser, Telex; Dipl.-Ing. Hans-Joachim Feig, PSI; Karl-Heinz Hermann, Softlab; Dr. P. Heyderhoff, Gesellschaft für Mathematik und Datenverarbeitung; Stefan Jähnichen, TU Berlin; Dr.-Ing. Joachim Mestermann, DEC; Werner Renz, MBB; Dr. Peter Schnupp, Softlab; Dipl.-Vwt. Hendrik Vollmann, Philips.
Hollwich: Wie muß ich mich verhalten, wenn ich bei meiner zentralen Rechenanlage in der Leistung zu knapp werde, wenn ich Kernspeicher oder zusätzliche Bildschirme brauche? Als IBM-Kunde denke ich natürlich zunächst mal an die IBM selbst. Es gibt aber auch Mitbewerber, die behaupten, das etwas billiger bewerkstelligen zu können. Da habe ich eine tiefeingefleischte Angst davor, daß dann das System nicht mehr funktioniert. Wie kann man sich da absichern?
Dieser: Sie haben die Telex angesprochen. Unser angestammtes Geschäft ist das Mixwaregeschäft, und wir leben davon, daß wir dem Anwender periphere Geräte für seine IBM-Zentral-Einheit anbieten, die billiger als äquivalente IBM-Geräte sind. Die aber auch in sehr vielen Fällen technologisch fortschrittlicher sind, weil sie dem Anwender höhere Durchsatzraten bieten. Ihre Ängste sind nicht einmalig. Jeder Anwender hat zunächst eine gewisse Skepsis, zu mixen. Diese Angst wird von IBM genährt und entwickelt. Es ist unsere Aufgabe, dem Anwender die Angst zu nehmen. Der kritische Punkt ist: Was passiert, wenn unklar ist, wo eine Störung liegt - im IBM-Teil oder im Mixware-Bereich. Ich darf hierzu sagen, solche Störungen sind seltener, als die IBM ihren Kunden glauben machen möchte. Sie kommen aber vor. Unsere Politik ist eindeutig: Wenn es sich nicht analysieren läßt, wo die Störung liegt, arbeiten wir mit den IBM-Technikern zusammen. Wenn wir behaupten, die Störung ist bei IBM und sie ist tatsächlich aber bei Telex und IBM stellt dem Kunden eine Rechnung, stellen wir dann den Anwender von den anfallenden Kosten frei.
Hollwich: Das ist mir bekannt. Ich habe übrigens die Erfahrung gemacht, daß dort, wo Hardware von verschiedenen Herstellern steht, die technische Wartung eher besser als schlechter funktioniert. Weil sich kein Techniker nachsagen lassen möchte, daß er einen Fehler nicht entdeckt hätte. Meine Frage ist: Was passiert, wenn der Casus belli eintritt, wenn sich nicht herauskristallisieren läßt, wer eigentlich schuld ist, daß die Maschine steht. Die IBM sagt, sie müßte das Mikroprogramm ändern, und dann funktioniert plötzlich der Telex-Kernspeicher nicht mehr. Werde ich dann Ihren Kernspeicher für 10 000e von Mark wieder los, damit des System wenigstens wieder läuft?
Dieser: Der Fall, wie sie ihn beschreiben, ist noch nicht eingetreten. Sie könnten die Kernspeicher oder MOS-Speicher vom Paneel her so auswählen, daß er für das System nicht existent ist, aber Sie können ihn auch völlig lösen vom System, so daß auch die letzte Drahtverbindung nicht mehr vorhanden ist. Das gestattet es Ihnen, dann mit IBM-Minimum alle IBM-Tests zu fahren, um erst mal festzustellen, läuft denn das IBM-System ohne den Fremdspeicher. Wenn Sie diesen Test gefahren haben, können Sie den Fremdspeicher wieder sukzessiv dazunehmen.
Hollwich: Ich glaube Ihnen, daß Ihr Speicher läuft, und ich halte es auch für möglich, daß das IBM-System für sich allein läuft, aber wenn die beiden zusammen nicht laufen, was ist denn dann?
Dieser: Wir sind ja im Geschäft der IBM-kompatiblen Peripherie. Diese IBM-Kompatibilität stellen wir bei Installation und bei Abnahme unter Beweis. Das System muß laufen, das ist der erste Schritt. Wenn die IBM Änderungen am System vornimmt und der Speicher ist nicht mehr kompatibel, dann müssen wir den Speicher wieder kompatibel machen, oder wir nehmen ihn tatsächlich zurück.
CW: Die Frage geht nun an Dr. Hueber.
Dr. Hueber: Ich komme von den Vereinigten Metallwerken Ranshofen-Berndorf AG bei Braunau. Wir haben dort eine Aluminiumgießerei mit einem Aluminiumpreß- und -walzwerk. Installiert ist in unserem Rechenzentrum eine IBM-Anlage 370/145, und wir stehen vor dem Schritt, mit eigenen Rechnern in unsere Werke hinauszugehen. Es stellt sich grundsätzlich die Frage, den Zentralrechner aufzustocken und Online-Lösungen zu installieren oder die einzelnen Betriebsstätten mit eigenen Rechnern auszustatten? Wir haben auf jeden Fall die Vorstellung, wenn wir den Schritt zum Kleinrechner machen, daß das Planungssystem am Zentralrechner bleibt und der Kleinrechner nur bestimmte Hilfsfunktionen erledigt.
Bilgram: Ich kann nur sagen, daß Hewlett Packard das Konzept der dezentralen Datenverarbeitung vertritt. Das kann sowohl bedeuten, daß wir als Zulieferer für IBM arbeiten und - entsprechend der Routine der Koppelung - unser System als Erfassungsgerät eingesetzt werden kann. Mit entsprechenden Terminal- und Online-Sicherheiten, aber auch als eigenintelligente Datenverarbeitungsanlage gefahren werden können. Damit gehen wir soweit, IBM schrittweise abzubauen; jedenfalls nicht anwachsen zu lassen. Es hat sich gezeigt, daß Minicomputer heute wesentlich kostengünstiger sind als später aufgestockte Großcomputer, die eine wesentlich größere Rechenzeit im Dialog haben.
Hueber: Bietet HP Software für kommerzielle Anwendungen an?
Bilgram: Unser Konzept ist, eine leistungsfähige Hardware mit der Betriebssoftware anzubieten. Wir glauben, daß die Standardsoftware in vielen Fällen doch geändert werden muß. Nicht, daß wir sagen, wir haben alles fertig.
CW: Herr Dr. Hueber, können Sie sich vorstellen, daß Sie aufgrund dieser Informationen nunmehr in der Lage sind, auch die einzelnen Produkte gegeneinander abzuwägen und abzugrenzen?
Hueber: Der Besuch der Messe war insofern interessant, als wir zum Ergebnis gekommen sind, daß wir uns wahrscheinlich in der Größenordnung geirrt haben, also eher zu klein geplant haben. Wir wollten aufgrund schlechter Erfahrungen bei sehr großen Konzepten und deren Realisierung schrittweise vorgehen. Ich habe aber nun den Eindruck, der jetzt nochmals durch die Aussagen untermauert wurde, daß sowohl HP wie Digital gute Hardware liefern, es im wesentlichen aber dem Kunden überlassen, sie dann sinnvoll einzusetzen. Ich habe bei Hewlett Packard sehr viel Peripherie am Stand gesehen. An Digital möchte ich die Frage richten, wie weit sie Peripherie zur maschinellen Datenerfassung bieten?
Feig: Wir können den Trend feststellen, daß man zum dezentralisierten System geht.
Dr. Mestermann: Wir haben in bezug auf Fertigungssteuerung einige Systeme mitentwickelt, die noch nicht hundertprozentig fertig sind, teilweise schon realisiert sind. Das ist ja ein großes komplexes Gebiet, ich glaube da wird man lange, lange noch weiterentwickeln, bevor jemand sagen kann, er hat ein ideales System, das überall hineinpaßt. Ich möchte nochmals klarstellen, daß drei verschiedene Aspekte eigentlich hier deutlich gemacht werden sollen. Das eine, was Herr Hueber anschnitt, ist die Tatsache, daß er z. B. einen Hauptrechner hat, den er entweder erweitern möchte oder dem er Rechner dazuaddieren möchte, die gewisse Vorfeldverarbeitung machen. Also den bestehenden Rechner bestehen lassen und zusätzliche Aufgaben auslagern mit der Kopplungsmöglichkeit von den externen Rechnern an den Hauptrechner. Das zweite war, daß das Wort Distributed Processing hier fiel. Es sollte klar sein, daß das, was normalerweise als Detail-Kommunikationsaufgaben von Prozeßrechnern realisiert werden könnte, eigentlich nicht Distributed-Processing ist. Da bilden Rechner eigentlich nur Schalter für mehrere Leitungen und machen in dem Sinne keine Vorfeldverarbeitung. Wenn man mal der Lösung "Hauptrechner plus dezentrale abgesetzte Vorfeldrechner" das Konzept des tatsächlich idealen Distributed-Processing entgegensetzt, bei dem kein Hauptrechner mehr da ist, sondern mehrere vernetzte Rechner miteinander verbunden sind, dann glaube ich persönlich, daß das eigentlich der Schritt ist, zu dem es vielleicht tendiert, der aber nicht Ziel unserer Firma ist.
Es wurde die Frage gestellt, ob wir Peripherie für diese Aufgaben haben oder ausbauen wollen. Wir haben kurz vor der Hannover Messe unser DPM-System angekündigt, das eigentlich genau in diese Richtung zielen soll. Das Konzept liegt darin, daß wir eine Hochgeschwindigkeits-Datenübertragungsleitung (Zweifachleitung natürlich möglichst störunanfällig) über lange Entfernungen durch das Gelände schleifen können und über Steckdosen sowohl interaktive Terminals als auch Process-Daten-Peripherie, also parallele Schnittstellen, anschließen können.
Hueber: Liefern Sie die auch?
Mestermann: Die liefern wir auch.
CW: Herr Podlech ist in Hannover auf ein System gestoßen und hat sich da einige Fragen zurechtgelegt.
Podlech: Ich komme vom Verteidigungsministerium. Ich bin seit kurzer Zeit in der Hard- und Softwareplanung tätig, war davor hauptamtlich, heute noch freiberuflich in der Schulung. Ich habe, glaube ich, ein paar schöne Dinge gefunden, und zwar einmal ein System, das in die Richtung Programmierung für den Produktionsbetrieb zielt, und einmal ein System, das in die Programmierung Richtung Schulung zielt. Ist es von Softlab angedacht, möglich oder realisierbar, daß Sie in Ihr Programmierunterstützungssystem bereits wesentliche Teile eines Compilers integrieren, so daß tatsächlich der Rechner vom eigentlichen Testaufwand freigemacht wird, so daß Sie von Ihrem System aus ein fertiges Programm an den Großrechner abgeben?
Schnupp: Es sind einige Gründe, warum wir bis jetzt den Test und auch die Kombination, sogar die Synthaxprüfung nicht auf dem Feldsystem machen. Ein Grund ist, daß wir glauben, daß der interaktive Test zumindest sehr gefährlich ist, weil er zu einer schlampigen Programmierung führt. Er muß es nicht, aber er tut es häufig. Wir glauben sehr viel mehr daran, daß man ein Programm nach den Methoden der strukturierten Programmierung entwickelt und sich neben der Programmplanung auch ganz bewußt eine Testplanung macht.
Podlech: Sie sagten strukturierte Programmierung. Ist der Programmierer daran gebunden?
Schnupp: Wir zwingen ihn nicht dazu, aber wir unterstützen dies. Wenn man ein sauber strukturiertes Programm macht, egal nach welchen Regeln, dann sollte man gleichzeitig einen möglichst sauberen Testplan machen, der die Testprozeduren bereitstellt. Es ist etwas anderes, wenn man auf Hochschulen experimentiert. Aber für ein kommerzielles Programm sollte man schon aus Gründen der Wartung die Entwicklung so machen.
Podlech: Sind Sie sicher, daß das in der Praxis auch die Realität ist?
Schnupp: Bei uns im Hause ist es für Entwicklungen, die wir selber machen, die Regel. Derartige Tests werden geplant und gepflegt wie das Programmprodukt selber. Das können Sie nicht im inaktiven Test machen. Ich glaube, es ist einfach bodenloser Leichtsinn, ein kommerzielles Programm zu warten und nicht die gesamten Testprozeduren upgedatet mit neuen Änderungen noch einmal durchlaufen zu lassen. Wenn Sie das nicht machen, wird nach ein, zwei, drei Jahren normaler Wartung das Programm unzuverlässig. Das ist eigentlich unser Hauptargument gegen den interaktiven Test.
Podlech: Ware es dennoch auf Wunsch des Kunden möglich, vielleicht einige Unterstützungsteile die Sie standardmäßig anbieten, aus dem System herauszuheben und statt dessen vielleicht den aufwendigsten Teil der Synthaxphase mit hineinzunehmen.
Schnupp: Technisch wäre es sicher möglich. Synthaxchecker sind noch nicht einmal sehr schwierig. Nur haben wir die Erfahrung gemacht, daß Synthaxchecker einfach nicht benutzt werden. Deswegen, weil diese Synthaxchecker eben doch das Programm nicht voll austesten.
Aber sie finden üblicherweise schon nicht mehr vergessene Referenzen. Deswegen ziehen die Leute es doch vor, zu sagen, wir gehen gleich auf den Compiler. Der Compiler gibt uns doch wesentlich mehr Diagnostiken, und wir haben auch die Chance, gleich in Execution zu gehen und sehen vielleicht auch da noch Fehler. Es ist einfach effektiver.
Podlech: Wenn man jetzt aber rangeht, und das soll gleich meine nächste Frage an die Hardwarelieferer sein man muß ja in irgendeiner Form da mal rechnen, daß man sich also überlegt, ein solches System einzusetzen muß man irgendeinen Aufwand in Kauf nehmen, der auf der anderen Seite in irgendeiner Form meßbar eingespart sein soll. Das wäre z. B. meßbare Großsystemleistung, weil ja ein kleines System da vorgeschaltet wird. Haben Sie damit schon irgendwelche Erfahrungen?
Schnupp: Kann ich einfach ganz kurz eine Zahl nennen, vielleicht kann Herr Hermann dann weitermachen? Sie können ausrechnen, daß bei einem Terminal unter einem Timesharing- oder einem Großsystem die Anschaltstunden zwischen 50 und 100 Mark liegen. Das sind die üblichen Kalkulationszahlen. Bei einem System wie PET zahlen Sie für die Anschaltstunde je Programmierer tatsächlich zwischen 5 und 10 Mark.
Podlech: Sie haben aber die Großrechnerzeit dabei nicht mitgegriffen.
Schnupp: Die Zeit, die er auf dem PET-Terminal arbeitet, ist der Großrechner frei, er kann tun, was immer er mag.
CW: Vor allen Dingen haben Sie Jetzt die Miete bzw. den Kaufpreis des Datensammel-Systems, den Sie dafür brauchen. Ist das eingerechnet?
Schnupp: Ja, genau.
Vollmann: Vielleicht kann ich also dazu etwas sagen. Alle unsere Kunden haben, bevor sie ein neues System angemietet oder gekauft haben eine Kostenanalyse gemacht. Das macht heute fast jeder, nicht nur weil das System sehr schön ist. Es ergeben sich Einsparungen auf verschiedenen Bereichen, z. B. eine Produktivitätssteigerung im personellen Bereich, dann gibt es natürlich auch Sachkostenersparnis, die auch sofort realisiert werden kann.
Podlech: Also Abrüstung des Großsystems?
Vollmann: Das heißt in dem Moment nicht unbedingt Abrüstung des Großsystems. Möglicherweise aber doch. Das ist vom Einzelfall abhängig.
Auch im Sachkostenbereich werden heute kleinere Beträge gespart, die sich aber in der Summe addieren. Etwa der Verzicht auf Papier. Außerdem wird die Rechnerzeit stark reduziert. Einer unserer Kunden bestätigte uns, daß allein die Maintenance für die Wartung der Bibliothekssysteme in der Größenordnung von monatlich 2000 Mark angesetzt wird. Dann haben Sie den Plattenspeicherplatz, den Sie mit Ihren Source-Programmen auf dem Großrechner belegen. Also auch hier fallen die Kosten auf der Großrechnerseite weg.
Podlech: Ich glaube, die Diskussion wird erst dann interessant, wenn ein verhältnismäßig großer Programmier-Stab eingesetzt wird. Vielleicht können Sie diesen Begriff "groß" mit einer Zahl fallen?
Herrmann: Wir haben ein System eingesetzt, das bereits bei sechs Programmierern rentabel ist. Und zwar hat jeder dieser Programmierer einen Bildschirm am Arbeitsplatz. Es gibt sicherlich auch andere Fälle, wo man Programmierung und Organisation auseinandergezogen hat. Wir haben auch Fälle, bei denen zwei Programmierer ein Terminal nutzen.
Podlech: Muß man im Einzelfall tatsächlich rechnen, um entscheiden zu können, was ist realisierbar. Sie haben die untere Grenze genannt, können Sie vielleicht auch eine obere Grenze nennen?
Vollmann: Wir schließen an ein System bis zu zehn Plätze an, und das müssen wir jetzt multiplizieren mit zwei oder drei oder sogar vier (Programmierern).
Herrmann: Gerade weil die Leistungsfähigkeit der Maschine außerordentlich groß ist, haben wir uns diese Anlage ausgewählt, um diese Programmentwicklung zu betreiben Es müssen immer mehrere Dinge übereinstimmen.
Feig: Als Softwarehaus ist natürlich Programmentwicklung auch für uns interessant. Inwieweit kann man sie effektiver machen, wie kann man sie ideenvoller und billiger machen? Wie sieht es mit Reaktionszeiten aus die die Programmierer an den Terminals zu erwarten haben? Ist ein Programmentwickler mit dem kleinen Gesichtsfeld, das ihm das Terminal gibt, zufrieden, kann er damit effektiv arbeiten? Ist die Frage schon jemals vorgekommen, daß einem Anwender der Gesichtskreis, den er durch den Bildschirm hat, zu klein war?
Podlech: Jeder, der irgendwie mal in der Programmierung geschafft hat und irgendwann mal so einen Packen Lochkarten bekommen hat, weiß, wieviel Zeichen aus diesen Daten wirklich interessant sind und wie schnell der Rest irgendwohin wandert. Ich glaube da ist der Bildschirm doch die bessere Lösung. Zur Reaktionszeit, ich weiß nicht, ob Sie gestern Türken gebaut haben? Ich habe davorgesessen, mir war es manchmal ein bißchen zu schnell. Ich kann mir durchaus vor, stellen, daß Ihr Programmierer, der in dem System drin ist, mit den Reaktionszeiten zufrieden ist.
Herrmann: Wir haben dem Programmierer einen Rechner zur Verfügung gestellt, nur dadurch ist es möglich schnelle Antwortzeiten zu erhalten.
Podlech: Nun will ich zu meinem zweiten Fund kommen. Nämlich einer Programmiersprache, die nicht nur von Informatikern, sondern auch von Pädagogen unter pädagogischen Gesichtspunkten entwickelt wurde. Herr Dr. Heyderhoff, was ist Elan?
Heyderhoff: Es gibt, gefördert vom Forschungsminister, einen Sachverständigenkreis, der ein ganzes Jahr lang darüber nachgedacht hat, welche Sprache für die Ausbildung geeignet ist. Der Sachverständigenkreis stellte fest: Basic ist eine für Ausbildungszwecke aus didaktischen Gesichtspunkten ungeeignete Sprache. Im Basic fehlen die wesentlichen Grundlagen für das Programmieren, es gibt in Basic keine frei werdenden Variablen. Es gibt in Basic kein Prozedurkonzept. Man kann nicht einmal ein rekursives Programm in Basic schreiben. Das sind so die wichtigsten Schwierigkeiten.
Wenn man der nachwachsenden Generation ingenieurmäßige Methoden, die systematische Systementwicklung, das strukturierte Programmieren weitergeben will, dann ist eine Sprache wie Basic total, Fortran nicht viel weniger ungeeignet. Selbst Cobol PL 1 sind nicht sonderlich geeignet. Der Sachverständigenkreis stellte fest, daß heute Pascal geeignet ist und daß praktisch parallel zur Arbeit des Sachverständigen weiterentwickelt wurde: nämlich Elan. Die also noch fünf Jahre jünger ist als Pascal und wo die Ergebnisse der neuen Informatik-Wissenschaft in noch aktuellerer Weise in diese Sprache hineingeflossen sind.
Podlech: Wir können jetzt leider nicht so detailliert in die Sprache einsteigen. Welchen zeitlichen Aufwand muß ein Lehrer treiben, um sich Visitenkarten drucken lassen zu können, ich bin Elan-Programmierer?
Jähnichen: Die Lehrerfortbildung ist eines der wesentlichsten Anliegen. Ich veranstalte zur Zeit gerade einen Lehrerfortbildungskurs, der geht über 40 Stunden.
Podlech: Welche Vorkenntnisse bringen diese Lehrer mit?
Jähnichen: Relativ wenig. Die meisten können ein bißchen Basic programmieren.
Feig: Darf ich die Frage stellen, was kann der Mann nachher in kommerzieller oder Prozeß-EDV wirklich leisten? Wenn einer jetzt Pascal oder Elan kann, dann kriegt doch der direkte Hersteller der Anlagen, die ich betreibe, einen Lachkrampf.
Jähnichen: Die Frage der Ausbildung ist nicht nur in dem Erlernen einer Programmiersprache zu sehen, sondern in der Systematik. Das Umsetzen dieser Problemlösung in eine Problemsprache ist eine Fertigkeit, die ich jemandem, der Elan kann, innerhalb von einem halben Tag beibringen kann.
Feig: Ich glaube, da können wir alle an unsere eigene Erfahrung appellieren. Die schwierigste Sprache, die jeder von uns gelernt hat, war die erste Sprache. Da hat man nicht nur die Sprache gelernt, sondern Programmierlogik, oder wie man es bezeichnet.
Jähnichen: Ich glaube, daran mangelt es auch bei den meisten Programmierern, die heutzutage irgendwo tätig sind. Sie können zwar Programme schreiben, sie können aber nicht systematisch programmieren.
Podlech: War nicht das Ziel von Basic zum Beispiel die Tatsache, daß Sie eine Sprache erstens leicht erlernen können und zweitens mit dieser Sprache Probleme lösen können und drittens der Vorteil, daß Sie diese Sprache schnell auf kleine Rechner bringen können? Trifft das auch für Elan zu?
Jähnichen: Über die Implementierung kann man folgendes sagen. Elan ist zur Zeit verfügbar auf Großrechenanlagen, auf der Siemens 4004, auf IBM 370 und in Bälde auch im TR 440. Wir arbeiten an der Implementierung für DEC- und für HP-Rechner.
Podlech: Welche Hauptspeichergröße müßte ein Rechner haben, der zur Unterstützung im Schulbetrieb eingesetzt werden kann.
Jähnichen: Wir gehen von einer Größenordnung von 32 KWorten mit Externspeichern und 4 Bildschirmterminals aus.
Podlech: Es gibt wahrscheinlich noch viele interessante Fragen, die wir in diesem Zusammenhang diskutieren können, und ich freue mich, daß gerade auch die Gesprächspartner, die wir fragen wollten, selbst Fragen hatten.