Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

16.01.1981 - 

VDRZ-Kritiker Adenauer läßt nicht locker:

"Der Markt wird Papa den Garaus machen"

Die Deutsche Bundespost hat vor längerer Zeit unter dem Namen Datex-P einen neuen Datenübertragungsdienst angekündigt und in Betrieb genommen. Der neue Dienst sollte der Telekommunikation eine Reihe von Möglichkeiten eröffnen, die dem Anwender nicht oder so nicht zur Verfügung standen.

Datex-P sollte dem Benutzer unter anderem

- freie Wahl der Übertragungsgeschwindigkeit,

- freie Wahl der Übertragungsmodi,

- ursprünglich auch die Bildung geschlossener Teilnetze,

- bei fester Anschaltgebühr entfernungsunabhängige, mengenabhängige Gebührenberechnung und vor allem

- Freizügigkeit des Datenverkehrs zur Verfügung stellen.

Die Post hat Hardware und wesentliche Teile der Software für den Datentransport in Kanada gekauft, weil dort wie in anderen Ländern schon seit einiger Zeit auf Erfahrung im paketvermittelten Datenübertragungsdienst zurückgegriffen werden konnte. Dort ebenfalls verfügbare Anpassungsrechner, über die große und kleine Computer der verschiedenen Hersteller an das Netz angeschlossen werden können, mit denen die Eigenschaft der Freizügigkeit des Datenverkehrs dort vor längerer Zeit realisiert wurde, hat sie aus mehreren einleuchtenden Gründen nicht mitgekauft.

BMFT wollte das Rad erfinden, das die Post verschmäht hatte

Daraufhin beschloß das Bundesministerium für Forschung und Technologie, daß "es in der Bundesrepublik einen gewissen Nachholbedarf gegenüber einigen Industrienationen gibt" [1]. Die Folge des Beschlusses war, daß für die Bundesrepublik nicht nur das Rad neuerlich erfunden werden mußte, sondern daß ohne Rücksicht auf die inzwischen fortgeschrittenen technischen Möglichkeiten die veraltetet Konzeption autonomer Anpassungsrechner zwischen Terminal oder großem Rechner und Netz der Post realisiert wurde.

Früher, zur Zeit der ursprünglichen Konzeption von paketvermittelten Datenübertragungsdiensten herrschten zumindest auf der Terminalseite nicht programmierbare, "fest verdrahtete " Ein-/Ausgabestationen vor. Auf der Seite größerer Rechner wer gerade die Komponente Programmspeicher um ein Vielfaches teurer als heute. Es war damals durchaus erforderlich, die für die Freizügigkeit des Netzzugangs erforderlichen sehr aufwendigen Umsetzungsbearbeitungen in ein autonomes Gerät zu verlegen.

Heute aber wie vor zwei Jahren gibt es am Markt keine nicht zumindest in ROMs programmierbaren Terminals mehr, und die Preise für die Komponente Programmspeicher in größeren Computer sind auf Bruchteile der Preise in der ersten Hälfte der siebziger Jahre gefallen. Schon aus diesen Gründen der technologisch-wirtschaftlichen Entwicklung ist es unsinnig, die Anpassung zwischen Datex-P-Netz und anzuschließenden Geraten in einem autonomen Rechner zu realisieren.

Es kommt hinzu, daß es sich bei dem, was für die sogenannte Freizügigkeit im einzelnen erforderlich ist, vor allem um das Umsetzen von Steuerschlüsseln in den Datenpaketen in Geräte-, Programm- und Datenzugriffsfunktionen der angeschlossenen oder anzuschließenden kleinen und großen Computer handelt. Wo anders als dort kann es wirtschaftlich sein die Umsetzung zu realisieren?!

Wenn Rechner unterschiedlicher Provenienz Daten zueinander übertragen, muß es Konventionen geben beispielsweise

- über den Zugang in die Job Control Language aller beteiligten Rechner,

- über den Zugang in die Betriebsysteme aller beteiligten Rechner,

- über die Umsetzung von Programmfunktionen in Funktionen der Datentransportsteuerung und umgekehrt

- über die Umsetzung von in den Datenpaketen enthaltenen Steuersignalen in Funktionen der beteiligten Rechner, die zum Beispiel

- seine die Daten bearbeitende Hardware,

- seine Datei- und Datenbank-Zugriffe und

- seinen Zugang in die Anwendungssoftware steuern.

Kurz und gut: Die Eigenschaft der Freizügigkeit des Netzzugangs von Datex-P erfordert eine abstrakte Datenübertragungskommandosprache, wobei die - unvollständige- Aufzahlung von deren Funktionsumfang zeigt, daß deren reale Interpretation wie Ausführung rechnerspezifisch und damit rechnerseitig erfolgen muß.

Die ursprüngliche Kritik an dem Projekt "Pilotanwendungen des öffentlichen Datenpaketvermittlungsdienstes für den Verbund zwischen Service-Rechenzentren und RZ-Kunden", wie Papa mit allen Vor- und Nachnamen buchstabengenau heißt, richtete sich deswegen zuerst einmal dagegen, daß nicht zunächst die Datenübertragungskommandosprache definiert und genormt wurde, sondern gleich - gewissermaßen kopfüber mit der Entwicklung einiger herstellerspezialisierter und autonomer Anpassungsrechner begonnen wurde. [2]

Eigentlich hört es sich für den Kritiker von damals gut an, wenn das Bundesministerium für Forschung und Technologie heute behaupten läßt Kernziel der öffentlichen Förderung von Papa sei "... die Entwicklung von Protokollen und Schnittstellen zum freien Verbund von Geräten verschiedener Hersteller ...". [3] Es hört sich gut an. Ist es aber auch wahr?

Einführungstermin vorbei - lauffähige Anwendungen gesucht

In allen zur Verfügung stehenden Projektunterlagen wird es wohl etwas anders dargestellt. So schreibt Lange-Hellwig im Vorwort zu der schon aus öffentlichen Mitteln geförderten Vorstudie, Abschnitt I vom 31. 5. 1979 Band 1, Seite 4: "Ziel des Projektes ist es, in jedem Rechenzentrum der Entwicklungsgemeinschaft mindestens 1 Anwendung unter Datex-P zum Zeitpunkt der Einführung des neuen Dienstes lauffähig zu haben." Ja, so steht es da. Heute lassen wir uns gerne darüber belehren, daß der Einführungstermin der 26. 8. 1980 war und gestatten uns die Frage, wie viele Anwendungen ein Vierteljahr später denn schon laufen Man darf sich zu der Frage berechtigt fühlen, weil des Geld gebende Ministerium "den Fortschritt aller Arbeiten" [4] als zufriedenstellend einstuft.

Doch wie auch immer, aus der Zieldefinition läßt sich wohl kaum herauslesen, Papas Ziel sei primär die Definition einer abstrakten Datenübertragungskommandosprache gewesen. Sehen wir weiter: In der Vorhabensbeschreibung vom 20. 7. 78, die ab Seite 7 in die vorerwähnte Vorstudie eingebunden ist, findet sich unter anderem: "Die Zielsetzung des Projektes besteht darin, neue Kommunikationstechnologien anzuwenden. Das Projekt gliedert sich in drei Phasen: Vorbereitungsphase für Pilotinstallationen, 2. Inbetriebnahme von Pilotinstallationen (Testphase), 3. Anwendungsphase. Aufgrund der Ergebnisse der drei Phasen soll das Projekt die Branche der Service-Rechenzentren in die Lage versetzen, neue DV-Dienstleistungen anzubieten, neue Kunden zu bedienen, vornehmlich jene, denen aus wirtschaftlichen Gründen der Einstieg in die Datenverarbeitung bisher verwehrt blieb."

Die Reihe der buchstabengenauen Zitate ließe sich fortsetzen. Nirgends steht etwas darüber, daß primär eine abstrakte Datenübertragungskommandosprache entwickelt werden sollte. Wie in Wahrheit von kompetenten Fachleuten im vorhinein die Verteilung der Problemgewichte und der Aufwand ihrer Bewältigung gesehen wurden, läßt sich am besten aus dem Beitrag des späteren Generalunternehmers für Papa in der Vorstudie auf den Seiten 33 ff herauslesen:

"Das Projekt Papa hat zum Ziel, den Pilotrechenzentren des VDRZ, unter Verwendung des paketvermittelten Datexdienstes der Deutschen Bundespost, die freizügige Kommunikation als neue Dienstleistung anzubieten.

Dies bedeutet, daß:

1. Funktionen für die Realisierung der freizügigen Kommunikation zu entwickeln,

2. Rechner für die Adaption der Terminal- und Host-Systeme zu beschaffen und zu betreiben,

sowie

3. die Pilotrechenzentren, also gewissermaßen die ´Kunden´ der freizügigen Kommunikation, zu beraten und zu betreuen sind.

Die wesentlichen Aufgaben sind also:

1 Leitung (des Projektes)

2 Kundenberatung

3 Betrieb

4 Entwicklung

.....

Die Organisation des Projektes Papa hat unter anderem folgende Randbedingungen zu berücksichtigen:

a) Im Rahmen des Projektes sind Funktionen zu realisieren (höhere Kommunikations-Protokolle), die in verschiedenen internationalen und nationalen Arbeitskreisen und Parallelprojekten mit dem Ziel einer Normung diskutiert werden. Die Realisierung im Rahmen des Projektes Papa ist eine Grundlage für einen ´nationalen Standard´.

Folgerung:

- Hoher Kommunikationsaufwand mit externen Partnern.

- Einfluß auf Spezifikationen und Design der Papa-Realisierung von außen.

- Änderung der Spezifikation und Realisierung als Ergebnis der Normungsaktivitäten.

b) Es ist geplant, die Terminal- und Host-Anpassungsrechner (TAR und HAR; siehe technisches Konzept), nach Beendigung des Probebetriebs (eventuell früher) in die Verantwortung der Deutschen Bundespost geben zu können.

Folgerung:

- Abstimmung der Spezifikationen mit der Post.

- Berücksichtigung der Postplanung.

- Berücksichtigung der Postinteressen bei der Auswahl der Basissysteme.

- Mögliche weise vollständige oder teilweise Obergabe der Systeme TAR/HAR in die Postverantwortung während des Pilotbetriebs.

c) Die Hersteller der Basissysteme für TAR/HAR haben möglicherweise selbst Interesse an der Entwicklung der Protokolle für diese Systeme.

Folgerung:

- Einstieg der Hersteller ermöglichen.

- Liefertermine für Protokolle beachten.

- Verantwortung für Betrieb und Wartung definieren.

d) Die aktive Mitarbeit der EDV-Hersteller an der Adaption, an das Transportsystem sowie die Unterstützung bei Fehlerdiagnose wird zwar angestrebt, sollte jedoch nicht sehr hoch eingeschätzt werden.

Folgerung:

- Adaptions-, Test- und Betriebsaufwendungen realistisch einschätzen.

e) Die Pilotrechenzentren bedürfen bei der Planung neuer Applikationen für den Dialogbetrieb sowie bei der Änderung vorhandener Applikationen umfangreicher Beratung und Betreuung.

Folgerung:

- Aufwand für Beratung und Betreuung vorsehen.

- Unterstützung bei HW-Auswahl und Herstellergespräche der Pilotrechenzentren.

- Unterstützung bei Installation beziehungsweise bei Adaption an das ´Papa-Transportsystem´.

f) Das Projekt ´Sedis´ untersucht die Marktperspektiven für die Mitglieder des VDRZ. Die Ergebnisse der Projekte ´Sedis´ und ´Papa´ beeinflussen sich.

g) Die Eigenleistungen der Pilotrechenzentren während Entwicklung und Betrieb sind in das Projektergebnis einzubringen.

h) Die Realisierungsaufwendungen für die Funktionen des TAR und des HAR sind sehr umfangreich.

Der Planung und Entwicklung des Testbetriebs ist daher frühzeitig die erforderliche Beachtung zu schenken.

Bei ausreichender Berücksichtigung dieser Randbedingungen folgt, daß neben der reinen Entwicklung der Funktionen für die freizügige Kommunikationen

- höhere Kommunikationsprotokolle

- Mapping

- Host-Adaption

umfangreiche Software-Enwicklungen für System- und Testfunktionen erforderlich und erhebliche Aktivitäten und Aufwendungen für Betrieb und Kundenbetreuung einzuplanen

sind." [5]

Diese realistische Einschätzung des späteren Generalunternehmers zeigt, wie sich des Bundesministerium für Forschung und Technologie- verteidigt, wenn es schreiben läßt: "Bei der in dem Artikel herausgegriffenen Frage der Anpassungsrechner geht es nicht um die Projektziele selbst, sondern um die untergeordnete Frage der Realisierung der Projektziele ... unter Nutzung des heutigen Postangebotes." [6] - Ausreden, nichts als Ausreden.

Das Millionending überfordert die BMFT-Beamten

Abgesehen von der fragwürdigen Argumentationsverschiebung wäre eigentlich einzusehen daß man im Zuge einer Technologie-Entwicklung Sachverhalte anders und neu zu sehen lernt. Aber nein, das Bundesministerium für Forschung und Technologie läßt behaupten, es habe mit seinen 15 Millionen Mark Förderungsmitteln nichts anderes im Sinn gehabt, als die Beschleunigung der Normung einer abstrakten Datenübertragungskommandosprache.

Das nun aber wäre mit wenigen hunderttausend Mark an ein energisch handelndes Gremium auch zu haben gewesen. Dann hatten nicht "Implementierung und Test dieser Protokolle für Hostrechner vom Typ IBM, Siemens, Honeywell Bull, Hewlett-Packard und DEC mit insgesamt zehn verschiedenen Betriebssystemen" [7] und Realisierung "dieser Protokolle auf insgesamt elf verschiedenen Terminals" [8] in den urtümlichen HARs und TARs sein müssen, für 15 und mehr Millionen Mark Steuergelder.

Die Post scheint zu ähnlichen Einschätzungen Papas wie die Kritik gekommen zu sein, als sie sich entschloß, die IBM 3270- und Siemens 8160-Prozeduren in ihrem Netz zu implementieren. Die Ausführungen des BMFT zu diesem Punkt indizieren, daß die Technologiebeamten gar nicht überblicken, was das für ihr Millionending bedeutet. Anders als die Markte für große und mittlere Computer wird der Terminalmarkt nämlich nicht so stark von einigen wenigen beherrscht. Dort gibt es eine Vielzahl durchaus leistungsfähiger und zum Teil sehr erfolgreicher Anbieter.

Alle, ausnahmslos alle, die auf dem deutschen Markt Erfolg haben, benutzen die Programmierbarkeit ihres Materials dazu, entweder zumindest die IBM 3270- oder Siemens 8160-Prozedur oder wahlweise beide oder sogar, vor allem in Clusteranschlüssen, beide zugleich zu emulieren. Es gibt Terminal-Anbieter, die gar keine eigenen Prozeduren haben, sondern grundsätzlich, auch bei Übertragungen zwischen den eigenen Geraten IBM- oder Siemens- oder Prozeduren anderer Hersteller anwenden.

Wenn deswegen die Post jetzt Datex-P kompatibel zu IBM 3270 und Siemens 8160 anbietet, können alle Terminals, die wahlweise über eine der beiden oder beide Emulationen verfugen, also nicht nur IBM- und Siemens-Terminals, wie das BMFT wähnt, an Datex-P angeschlossen werden. Für wesentliche, überwiegende Teile der Marktteilnehmer hat die Post die Eigenschaft der Freizügigkeit ihres neuen Dienstes vorläufig realisiert. Anpassungsrechner der Papa-Provenienz erscheinen damit nur noch für das Marketing von Honeywell Bull von Bedeutung. Und bei aller Sympathie für diesen sorgfältig geführten ausländischen Hersteller: Es verstößt gegen das Gesetz, die Technologie ausländischer Lieferanten zu fördern.

Vor allem aber die Preisrelationen werden Papa am Markt den Garaus machen. Zwar doktert die Post noch an den endgültigen Preisen herum. Es gibt aber schon einen seit langem veröffentlichten Anpassungspreis, der wegen der ähnlichen Problemstellung als Anhaltspunkt dienen kann: den Preis für Anpassung zu X.28.

Dort kostet die Anpassung durch die Post 6 Pfennige/Min., maximal aber 180 Mark pro Monat, fürwahr ein stolzer Preis. Aber die Preisstellung ist immerhin volumenproportional mit monatlicher Höchstgrenze.

Papa zielt weit am Markt vorbei

Wenn man den Projektunterlagen von Papa trauen darf, sollte ursprünglich ein Terminal-Anpassungsrechner 20 000 und die Host-Anpassungsrechner 50 000 bis 100 000 Mark kosten, beides ohne Entwicklungskosten. Wenn man das mit einer Nutzdauer von sechs Jahren, neun Prozent kalkulatorischen Zinsen und sieben Prozent Wartungskosten in die monatliche Belastung umrechnet, würde der TAR ungefähr 545 Mark und der HAR ungefähr 1360 bis 2720 Mark im Monat kosten, wohlgemerkt, ohne die Entwicklungskosten. Die Anwender müßten schon von allen guten Geistern verlassen sein, solche Beträge auszugeben, wenn sie exakt das gleiche bei der Post für einen Bruchteil der Kosten und dazu noch volumenproportional kaufen können. Und der Preis der Post ist so satt kalkuliert, daß darin die Entwicklungskosten abgedeckt sein müßten.

In mehreren Veröffentlichungen sind konkret, teilweise detailliert begründet gegen die Förderung von Papa folgende. Vorwürfe erhoben worden:

1. Die Technologie der Anpassungsrechner war vor Projektbeginn frei käuflich. Ein Erwerb hätte Bruchteile der von dem Projekt verschlungenen Millionen gekostet.

2. Das Projekt wurde in einer falschen Schrittfolge realisiert.

3. Die technologische Konzeption autonomer Anpassungsrechner ist im Kern überholt und zu teuer.

4. Durch die Anpassung der Post zu den Prozeduren 3270 und 8160 ist ein weiteres Betreiben des Projektes gesetzeswidrig geworden.

5. Die Resultate des Projektes sind nicht marktfähig.

Was dem Kritiker von seiten des Autors Lange-Hellwig in agitatorischer Rage unter der Überschrift "Nicht jeder Adenauer ist ein Konrad" in der COMPUTERWOCHE, Jg. 1980, Nr. 47, auf Seite 15 entgegengeheult wird, ist zwar in der Argumentation unsubstantiiert, aber verzeihlich, weil immerhin vorgeworfen wird, daß in des Autors Mitverantwortung viele Millionen an Steuergeldern verplempert worden sind.

Papa beweist: Markt und Staat ist zweierlei

Wenn aber eine ministerielle Behörde, das Bundesministerium für Forschung und Technologie, mit zweifelhaften Ausreden auf im einzelnen begründete Vorwürfe dem Kritiker öffentlich ausrichten läßt, "sein Artikel gehe an der Realität vorbei" [9], er stelle Sachverhalte falsch dar, er benutze groteske Begriffe und stelle "unlogische und nicht sehr sachverständige Verbindungen her" [10], so muß dies als bedauerlicher Fehlgriff in das Arsenal des einer Behörde zustehenden Sprachschatzes bezeichnet werden.

Wenn des Projekt fortgesetzt werden sollte, gießt Papa nicht einfach nur Wasser, sondern ganze Sturzbäche auf die Mühlen jener, die in letzter Zeit am Sinn staatlicher Technologie-Breitenarbeit zweifeln. Sie sagen daß die Industrie aus sich heraus eine Technologie immer dann sofort bereitstellt, wenn sie der Markt verlangt und bezahlt. Bezahle aber der Markt eine Technologie nicht, werde sie auch nicht gebraucht. Bezahle der Markt eine Technologie, sei sie volkswirtschaftlich sinnvoll. Bezahle der Markt eine Technologie nicht, sei sie volkswirtschaftlich auch nicht sinnvoll, wobei die großen Gemeinschaftsaufgaben von diesen Überlegungen ausgeklammert werden.

Papa aber als Gemeinschaftsaufgabe der Volkswirtschaft? - Möge das Projekt in Frieden beendet werden!

1) Vgl. Bernd Reuse, "BMFT wehrt sich gegen Papa-Angriff", in COMPUTERWOCHE, München, Jg. 1980, Nr. 47, S. 16

2) Vgl. Thomas Adenauer Datex-Politik macht Post zum Computer-Händler", in COMPUTERWOCHE, München Jg. 1979, Nr. 40, S. 1 f.

3) Bernd Reuse, "BMFT wehr sich gegen Papa-Angriff", in COMPUTERWOCHE, München, Jg. 1980, Nr. 47, S. 16

4) ebenda

5) Abschnitt I der Vorstudie zum VDRZ-Gemeinschaftsprojekt Papa, Stand: 31. 5. 1979, Band 1 Hrsg. Verband Deutscher Rechenzentren e. V. Hannover, 1979

6) -[10] Vgl. Bernd Reuse, "BMFT wehrt sich gegen Papa-Angriff", in COMPUTERWOCHE, München, Jg. 1980, Nr. 47, S. 16