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.

04.07.1980

Nur der "Native-Mode" bringt volle Leistung

Mit Bodo Frösch, Leiter Produkt Marketing EDV bei der NCR GmbH, Augsburg, sprach Dieter Eckbauer

Jede Umstellung ist schwer. Das gilt besonders für den Wechsel von einem Rechnersystem auf ein anderes. Nicht einmal die Herstellertreuen sind vor Anpassungsquerelen sicher. Denn Anlagenwechsel bedeutet in der Regel auch Betriebssystemwechsel und Übergang auf eine andere Programmiersprache. Gegen den Wechseltrust haben die Hersteller das Schluckmittel "Kompatibilität" entwickelt. NCR erschien das nicht wirksam genug. Die Augsburger sprechen neuerdings von "Migration-Path-Engineering", wenn sie ihr Konzept der "Aufwärtsverträglichkeit" herausstellen wollen.

- Mit einer per Weichware und Mikroprogrammen realisierten Kompatibilitätsbrücke will NCR seinen Kunden den Umstieg von einer Anlage auf eine andere erleichtern. Sind Sie an einem Replacement von Wettbewerbsanlagen nicht interessiert?

Das war bei der Implementierung dieser Technik nicht die Hauptmarschrichtung. Zunächst galt es, für unsere Kundenbasis einen Migrations-Pfad zu finden und den auf neuer Hardware attraktiv zu gestalten.

- Ist eine Migration auch nach unten hin möglich?

Wir garantieren in jedem Falle einen Aufstieg nach oben, wissen aber aus Erfahrung, daß unsere Kunden unter gewissen Umständen auch nach unten "migraten" können, dann nämlich, wenn diejenigen Sprachelemente, die sich bei jeder größeren Maschine im Umfang erweitern, nicht verwendet wurden. "Migration-Path" wird freilich in der Regel mit Aufstiegs- oder Wachstumspfad übersetzt - und wir können uns nicht recht vorstellen, warum ein Anwender nach unten "migraten" sollte.

- Es muß doch die Möglichkeit gegeben sein, wenn eine Firma sich gesundschrumpft, die EDV entsprechend anzupassen.

Das ist richtig. Innerhalb einer Systemfamilie geschieht das in den meisten Fällen durch Hinzufügen oder Wegnehmen von Terminals oder peripheren Einheiten. Diese Fälle kommen konkret in der Praxis vor, da müssen wir zustimmen.

- Mit diesem Migration-Path-Konzept gleichen Sie doch nur einen Wettbewerbsnachteil aus, der entsteht, weil Sie eben für die verschiedenen Leistungsbereiche vier Familien anbieten. Bei Univac zum Beispiel gibt es dieses Migrations-Problem nur einmal, wenn der Anwender von der Serie 90 auf die Serie 1100 übergeht. Und die Serie 60 von Honeywell ist sogar von unten bis oben rauf voll kompatibel.

Ich möchte zwar nicht in Wettbewerbsvergleiche einsteigen, aber es gibt einen weiteren EDV-Hersteller der es trotz großer Benutzerbasis nicht geschafft hat, einen Migrationspfad über mehrere Systemfamilien hinweg zu offerieren. Dort besteht immer wieder das Problem der Umstellung auf neue Programmiersprachen, auf neue Hardware, auf neue Betriebssysteme. Und das ist in allen Fällen ein Stilbruch, den die Anwender nur sehr schwer überwinden können.

- Wenn alte Programme unverändert auf eine neue, jedoch kompatible Anlage übernommen werden, ist dies oft mit Leistungseinbußen verbunden. Steht hinter dem "Migration-Path-Konzept" der Gedanke, daß eine Anpassung der Software durch den Anwender in jedem Fall teurer ist?

Das stimmt. Man muß zugestehen, daß eine Anlage immer nur dann die volle Leistung bringt, wenn sie im sogenannten "Native-Mode" verwendet wird. Man muß also hier einen gesunden Kompromiß zwischen den Aufwendungen für Programmanpassungen und dem angedeuteten Geschwindigkeitsverlust im Vergleich zum "Native-Mode" finden. Wird sind den Weg gegangen, die Aufwärtskompatibilität in Form des Migration-Path-Engineerings zu bieten. Das heißt im Klartext: Keine Änderungen an den Source-Programmen, keine Änderungen an der Job-Control-Language, keine Änderung in den Dateien, auch wenn auf andere Hardware-Architekturen ohne periphere Einheiten übergegangen wird. Wir gingen sogar noch einen Schritt weiter: Wir sind Objektprogramm-kompatibel - und das nachweisbar.

- Gleichwohl wird es schwer sein, den Markt zu überzeugen, daß Ihnen im Einzelfall nicht doch der Verkauf der größeren Anlage am Herzen liegt und weniger die Optimierung des existierenden Systems beim Kunden. Anders gefragt: Was schlagen Sie dem Anwender im Einzelfall vor?

Ich glaube, in den wenigsten Fällen entscheidet die Leistung der Maschine, sondern die Leistung der angebotenen Anwendersoftware, sei sie branchenneutral, sei sie branchenspezifisch. Erst in zweiter oder dritter Linie wird über die interne Leistung einer Anlage diskutiert. Dieses Migration-Path-Konzept bietet dem NCR-Kunden, der aufgrund seiner geänderten Verarbeitungsverhältnisse aufsteigen will, die Möglichkeit, dies problemlos zu tun. Auch der Hersteller hat einen Vorteil: Wenn er sich an dieses Konzept hält, kann er für die neuere Maschine sofort Applikations-Software offerieren, die erprobt und ausgetestet ist.

- Nun muß der Anwender, um Leistungseinbußen zu vermeiden, das neue System entsprechend größer auslegen. Es entsteht ein Sprung bei den Fixkosten, der durch den eigentlichen Mehrbedarf an Kapazität nicht gerechtfertigt ist, so daß man in der Übergangsphase von einem Overselling sprechen kann.

Wenn die Notwendigkeit auftritt, auf eine Hardware mit höherer Leistung zu gehen, können wir das mit dem bei einem Kunden installierten System relativ einfach bewerkstelligen. Wir können dann die Anlage im Feld, sprich beim Kunden, ohne Austausch der Zentraleinheit in gewissen Leistungsstufen und mit Hilfe anders gearteter Firmware entsprechend upgraden. Erst beim Übergang vom größten Modell einer Familie zum kleinsten Modell der nächstgrößten Familie könnte die Gefahr bestehen, ein Overselling vorzunehmen. Aufgrund unserer Erfahrungen mit der 8.000er Serie können wir sagen, daß wir über eine so fein abgestufte Modellpolitik verfügen, daß Overselling zu den Ausnahmen gehört.

- Wann wird NCR ein besseres Cobol haben als Cobol 74t

Wenn ein besserer oder neuerer Cobol-Standard verabschiedet ist. Wir folgen in unseren Compiler-Implementierungen jeweils den Cobol-Standards. Bisher haben wir konkret zwei Standards implementiert: Cobol 68 und Cobol 74. Sie können den gleichen Weg bei unseren Fortran-Implementierungen verfolgen. Wir haben Fortran 68 eingeführt und implementieren zur Zeit Fortran 77. Das sind die letztverabschiedeten, gültigen Standards dieser Sprache.

- NCR beabsichtigt also nicht, sich auch einmal in die RPG-Umgebung, sprich IBM-Nähe, zu begeben?

Nicht zwingend auf der Ebene von RPG, viel eher durch angebotene Konvertierungshilfen von RPG in Cobol 74.

- Das Migration-Path-Konzept ist eine Unterstützung für den Kunden. Jetzt wartet man eigentlich darauf daß das mit Kosten für den Kunden verbunden ist, denn da steckt ja auch ein Entwicklungsaufwand drin.

Normalerweise überlassen wir den Kunden, die diesen Umstellungsweg mit Hilfe unserer Konvertierungshilfen gehen, diese Umstellungshilfen gegen Zahlung einer einmaligen Lizenzgebühr. Sie gibt ihm dann das unbegrenzte Recht der Nutzung im Rahmen seines Miet- oder Kaufvertrages für die Anlage.

- Irgendwo muß doch ein "Aber" versteckt sein, sonst würden Sie dieses Konzept doch nicht so lautstark propagieren?

Ich glaube, unsere Schwierigkeit besteht darin, dem Markt - sei es den Anwendern, sei es unseren Mitbewerbern - klarzumachen, daß dieser Aufstiegspfad wirklich existiert: Aus allen Marktanalysen, die ja unter Wettbewerbsbeobachtern ausgetauscht werden, geht aufgrund der Formulierungen hervor, daß man nicht so recht an diese Objektprogramm-Kompatibilität glaubt. Formulierungen wie: "Die Kompatibilität geht angeblich bis zu . . . zeigen uns, daß der Markt immer noch nicht voll begriffen hat, was hinter dem Migration-Path-Engineering steckt.

- Mit Begriffen wie "Kompatibilität" und "Aufstiegsmöglichkeit" gehen die Hersteller geradezu verschwenderisch um. Damit können sie vieles begründen - aber auch vieles kaschieren.

Aus eben diesem Grund verwenden wir bei unserem Konzept nicht die Begriffe Kompatibilität oder Aufwärtskompatibilität. Wir sagen, es handelt sich um einen Aufstiegspfad und verwenden bewußt das englische Wort Migration-Path-Engineering, das mehr besagt als nur Kompatibilität.

- Sagt es wirklich mehr aus?

Vermeiden wollen wir das Mißverständnis, das immer wieder aufkommt: daß man unter Kompatibilität stillschweigend nur Programmkompatibilität versteht, daß die Job-Kontrollsprache beim Wechsel eines Betriebssystems geändert werden muß daß die Dateien umformatiert werden müssen, daß man neu kompilieren muß mit all den zusätzlichen Eigenheiten, die der Compiler dann hat. Und hier bietet das Migration-Path-Konzept einen lückenlosen Weg, indem wir von Systemen der 8200-Serie von der 8250, von der 8270 aus Programme auf diesen Wachstumspfad hin zu 8430 schicken können.

- Und hier kann man von einer Eins-zu-Eins-Umstellung sprechen?

Es ist schlichtweg ein Kopiervorgang, obwohl die Hardware dahinter inklusive der Peripherie zu 100 Prozent anders ist.