Siemens und das Betriebssystem BS1000



Geschichte


Entwicklungsgeschichtlich hat das BS1000 seine Wurzeln im Plattenbetriebssystem (PBS), das ursprünglich auf den Zentraleinheiten der Serie Spectra 70 Modell 4004-16 (~50Kops 16Kb) und 4004-26 zum Einsatz kam. Von Siemens weiterentwickelt war es die Grundlage für das spätere BS1000. Siemens lieferte BS1000 ab 1968 einschließlich der laufenden Erweiterungen als Gegenleistung auch an die RCA, wo es auf dem Modell /45 der RCA Serie 4004-45 Bedienfeld Spectra 70 zum Einsatz kam. Aus eigener Fertigung wurde z.B. ab Herbst 1968 der Rechner 4004/45 ausgeliefert. Die Arbeitsspeichergröße konnte von 32kB auf 512kB ausgebaut werden. Bis zu 15 unabhängige Programme waren im Simultanbetrieb ablauffähig. Die Programme konnten in den Sprachen Assembler, COBOL, ALGOL, FORTRAN und RPG entwickelt werden. Als Ein-/Ausgabegeräte verfügte man inzwischen auch über eine Anzahl von Produkten aus eigener Fertigung. Entwicklungsgeschichte von BS1000 reicht von der Version 1.0 von 1968... weiter über die 1.4 von 1977 (Siehe Systeminformation vom 01.12.1976 als PDF) bis zur letzten ausgelieferten BS1000 Version 1.5 von 1979, die damals speziell für die Dresdner Bank entwickelt wurde. In der letzten Version 1.5 wurde der Prog.-Befehlszähler von 15 auf 32 erweitert, das heißt, es konnten 32 Programme parallel ausgeführt werden. Die Dresdner Bank hatte mehrere BS1000 Systeme die auf den Zentraleinheiten 7.760 und 7.780 bis Anfang der 80 Jahre im Einsatz waren. Ende der 70er, Anfang der 80er drängte Siemens seine BS1000 Kunden behutsam zum Umstieg auf das moderne Virtuelle Betriebssystem BS2000, das seit 1973 offiziell mit der Version 1.0 ausgeliefert wurde.
↑ Top ↑

Pressemitteilungen zum Thema BS1000



Siemens pflegt BS1000 mit neuer Version


26.01.1979 - MÜNCHEN (de)
"Weil es noch eine Menge Anwender dieses Betriebssystems gibt", wurde das BS1000 von Siemens jetzt um eine Version 1.5 fortgeschrieben: "Das kann man nicht so klammheimlich auslaufen lassen", begründet ein Sprecher der Münchner die Software-Kosmetik. Das neue Release unterstützt nunmehr auch die Zentraleinheit 7.760 (ab 128 KB Hauptspeicher) sowie verstärkt die 7.000er-Peripherie am System 4004. Zu den vom BS1000 bisher nicht bedienten I/O-Geräten gehören die Floppy-Disk-Station 3170 und der Floppy-Disk-Zusatz 30230 für die Erfassungsplätze 3020/3023. Darüber hinaus hat Siemens die Transdata-Datenstationen 920, 9210 und 9230 mit BS1000-Support versehen. Schließlich können Mehrfachsteuerung 8170 und das Datensichtgerät 8162 neuerdings an BS1000-Maschinen arbeiten.
↑ Top ↑

SCOUT-Mitglieder bringen Entwicklungsantrag nicht durch


09.03.1979 - MÜNCHEN (de)
Kompatibilität BS1000/BS2000 von Siemens abgelehnt Siemens-Anwender, die das Betriebssystem BS1000 einsetzen, verspüren wenig Neigung, auf BS2000 umzustellen: Liegt's daran, daß Inkompatibilität zwischen beiden Betriebssystemen besteht, oder hat Siemens die Verträglichkeit bisher deshalb nicht hergestellt weil keine entsprechenden Benutzeranforderungen vorlagen?Aufschluß in dieser Frage liefert der "Erfahrungsbericht 1978" des Arbeitskreises "Datenbanken" der Siemens Computer User Team (SCOUT) e. V.: Neben der Feststellung "Entwicklungsantrag "Kompatibilität BS1000/BS2000" (von Siemens, d. R.) abgelehnt" enthält das interne SCOUT-Papier indessen eine Fallstudie, die die Vor- und Nachteile eines Wechsels von BS1000 auf BS2000 aufzeigt. SCOUT-Mitglied Karl Kammermaier von der ESG/FEG (München) berichtet, daß die Umstellung des Datenbanksystems Sesam "aus der Sicht der Programmierung" als "sehr positiv", "aus der Sicht der Operatoren" dagegen als "Wenig günstig" angesehen wurde. Den ungekürzten Text lesen Sie Seite 9.
↑ Top ↑

Erfahrungsbericht der Firma ESGFEG

(Werkzeugmaschinen und Handhabungsautomaten)

09.03.1979 MÜNCHEN (cw)
SESAM-Umstellung von BS1000 auf BS2000
Bei allen Benutzergruppen wurde mit einer Anpassungszeit von etwa drei Monaten gerechnet. Tatsächlich konnte nach etwa drei Monaten bei den Programmierern, sechs Monaten bei den Arbeitsvorbereitern, drei Monaten bei den Operatoren, zwölf Monaten bei den SESAM-Anwendern von einem weitgehend problemfreien Betriebsablauf gesprochen werden.

In allen SESAM-Anwenderprogrammen mußten vor den Anweisungs- und Fragebereichen auf Wortgrenze ausgerichtete 4-Byte-Längenfelder eingefügt werden. Das konnte bei Cobol nur mit bestimmten Programmierregeln erreicht werden. Wegen des ganztägig geladenen SESAM ist in allen Direktänderungsprogrammen ein temporärer CLOSE CLDB vor dem abschließenden CLOSE unbedingt erforderlich. SEDI61/SEBE können nur noch Sätze bis maximal 2048 Bytes verarbeiten. Eine Möglichkeit, den Satztyp "Variabel" verarbeiten zu können, wäre bei beiden Programmen wünschenswert, da im BS2000 allgemein die Verarbeitung von RECFORM = V praktischer ist.

BS2000-Schwierigkeiten

Von Oktober 76 bis April 77 ereigneten sich zahlreiche (täglicher Durchschnitt drei) Systemabstürze, die durch den Konzentrator und dessen Behandlung durch die Software bedingt waren. Seit Mai 77 ist durch BS2 V.3.0 dieser Fehler beseitigt, allerdings traten bis Oktober 77 viele andere, meist DMS-Fehler auf, die seit Einsatz der BS2 V.3.1 verschwunden sind. Bis heute allerdings bleiben die unzureichenden Betriebssystemfehlermeldungen (dem Anwender fehlt bei DMS-Fehlern der Dateiname) und die nicht funktionierende Privat(Platten)-Datenträgerverwaltung zu bemängeln. Ferner hat es sich als nachteilig erwiesen, keine Steuerungsmöglichkeit der in der Anlage ablaufenden Prozesse zu besitzen. Ein gestaffeltes System von Bevorzugung bis Benachteiligung benutzerspezifischer Prozesse wäre wünschenswert, um einen besseren Aufgabendurchsatz zu erzielen.

SESAM-BS2000-Schwierigkeiten
↑ Top ↑

Von November 76 bis Juli 77 kämpften wir mit zahlreichen zentralen Fehlern und anderen Abstürzen bei SESAM- Seit dieser Zeit ist eine Beruhigung eingetreten. Die Komprimierungsform Z ist nicht mehr möglich, da sich die SEBE-Verarbeitung gegenüber SESAM V.9.3.2 geändert hat. Der Platzbedarf für die ständig zur Verfügung stehenden Datenbanken kannte von sechs auf vier Laufwerke verringert werden, da die ORG-Bereiche wesentlich kleiner wurden und die Bereichsverwaltung des BS2 Pufferbereiche in den Datenbanken überflüssig machte.
Die Direktänderung ist sichtlich um mehr als das Zweifache schneller als in V 9.3.2. Dafür benützt die SESAM-Direktänderungsprotokolldatei je Änderung einen ganzen Plattenblock (2048-Bytes), das heißt, es muß jetzt eine Bandstation für diese Datei dauernd verwendet werden. SEBE braucht das 1,5fache der BS1000-Laufzeit, davon entfallen 40 Prozent der CPU- und auch der Laufzeit auf das Segment BO. Der etwa fünffache Platzbedarf der ZD-ZUG-Datei gegenüber der Eingabedatei bringt Laufzeit- und vor allem Platzprobleme im zur Verfügung stehenden Publicspace. Ein von uns gestellter Verbesserungsvorschlag, der den Platzbedarf auf das Zweifache verringern wurde, wurde abgelehnt SEBE tragt im ORG- und ZDR-Katalogeintrag nicht den aktuellen Wert LASTPAGE ein, daher bleibt bei einer Verkleinerung der Datenbank der Platz belegt. Die von SEBE verwendeten Generationsnummern der Hilfs- und Sicherungsdateien sind für den Arbeitsvorbereiter nicht hantierbar. Wir versuchen Prozeduren zu entwickeln, die dieses Problem restlos lösen und allgemein verwendbar sind.
↑ Top ↑

Bei allen Dienstprogrammen ist bei fehlerhaftem Abbruch ein wahlfreier Systemschalter zu setzen, mit dem der Benutzer den weiteren Ablauf seiner Verarbeitung steuern kann. Beim Aufbau der AWL's ist die Sortierzeit (rund 75 Prozent der Kombination SEDI31-SEAL) gegenüber V 9.3.2 wesentlich schlechter geworden. Das Lesen durch ein Benutzerprogramm in der Datenbank über Suchfrage und Folgeantwortabruf ist durch die verwendete ITC um das 2,4fache gegenüber V.9.3.2 langsamer geworden. Die anfallenden, teilweise horrenden CPU-Zeiten in SESAM können dem verursachenden Benutzer leider nicht verrechnet werden. Die nachträgliche SESAM-Fehlerverfolgung gestaltet sich schwierig, da keine Uhrzeit in den Meldungen im SYSLST-Protokoll festgehalten ist. Für die aktuelle Fehlersuche sollten diese gleichen Meldungen in einer jederzeit (während SESAM noch läuft) zu lesenden Datei abgesetzt werden.
Abschließend bleibt festzustellen: In unserer Firma konnte die Situation der Programmierung durch den Einsatz von BS2000 wesentlich verbessert werden, ebenso hat die Arbeitsvorbereitung gute Möglichkeiten, ihre Läufe vorzubereiten. Dagegen müßten die Betriebssicherheit und der Durchsatz der Produktivläufe trotz schnellerer und größerer ZE speziell auch im SESAM-Bereich noch stark erhöht werden, damit wir unsere von BS1000 übernommenen sowie neu hinzugekommenen DV-Aufgaben bewältigen können.
↑ Top ↑

Neue Anwendung BS2000

Seit Februar 77: ZE 4004/151 (768 k), 8 X 200-MB-Platten, davon drei für BS2000 und fünf für Benutzer, sechs Magnetbänder 1600 BPI.
6°° - 18°° Bis zu 25 Dialoganwendungen, davon vier Terminals mit Datenbankdialog der Fachabteilungen und vier externe Terminals ebenfalls mit SESAM-Dialog. Durch die acht Datenbankdialoganwendungen sind vier Platten ganztägig belegt, auf denen sich neun Datenbanken befinden. Der SESAM-Dialog wird mit SESAMF1- und FEG-eigenen Auswertungsmoduln durchgeführt. Die anderen bis zu 17 Dialoganwender programmieren im Dialog in Cobol, Fortran und PL1; führen Testläufe oder lassen kleinere Programme laufen. Umfangreichere Läufe werden grundsätzlich nur nachts durchgeführt.

18°° - 6°° Produktivläufe

Wegen angestiegenem Arbeitsvolumen und Verbesserung des ungenügenden Laufzeitverhaltens im Dialog wird seit April 78 eine ZE 7.748 mit 1 MB eingesetzt. Die Zahl der Platten erhöht, wurde auf elf erhöht, dadurch stehen jetzt drei Laufwerke zur freien Verfügung bei gleichzeitiger Erweiterung des Betriebssystems auf vier Platten.

Bisherige Anwendung

ZE 4004/151 (512 K), acht X 200-MB-Platten, davon zwei für BS1000 und sechs für Benutzer, sechs Magnetbänder 1600 BPI
6°° - 7°° Testzeit 1,
7°° - 9°° vier Terminals der Fachabteilungen im Hause,
9°° - 11°° vier Terminals des externen Auftraggebers in Köln und Koblenz,
11°° - 13°° Testzeit 2,
13°° - 6°° Produktivläufe.

↑ Top ↑

User drängen Siemens zum Handeln


05.10.1979 - FRANKFURT (je)
Rund drei Viertel der Entwicklungsanträge, die das Siemens-Computer-User-Team (SCOUT) im Berichtsjahr 1978/79 an Siemens stellte, wurden positiv aufgegriffen. Die Kritik, die SCOUT am Verhalten des Hardware-Produzenten übt, richtet sich gegen zu lange oder überhaupt nicht definierte Realisierungszeiten und die Schwierigkeiten bei der Umstellung von BS1000 auf BS2000. Einen Tag nach der Mitgliederversammlung - sie wählte einen neuen SCOUT-Vorstand - tagte in Frankfurt auch der Führungskreis von SCOUT und beschäftigte sich mit Spezialthemen. Mit und ohne unmittelbare Beteiligung von Siemens hat SCOUT über das Berichtsjahr 78/79 hinweg etwa 60 Arbeitstagungen durchgeführt, auf denen Siemens-EDV-Produkte zur Diskussion standen. Als Teilergebnis dieser Erörterungen hat SCOUT etwa 140 Entwicklungsanträge zu Siemens-Software-Funktionen eingebracht. Sie enthielten Forderungen nach Verbesserung bestehender wie auch völlig neuer Produkte - so verlangt SCOUT beispielsweise ein neues Remote-Spool-System. Siemens ist auf diese Forderungen weitgehend - zu 75 Prozent - eingegangen, läßt aber nach SCOUT-Meinung bei der Realisierung die notwendige Eile vermissen. Der neue SCOUT-Vorstand besteht aus dem bisherigen Vorstandssprecher Bert van Rennings (Dresdner Bank), den ebenfalls wiedergewählten Jürgen Janck (BfA) und Werner A. Graml (ESG/FEG) sowie dem neugewählten Maurice Nicollier von der Züricher Telekurs AG. Für das nächste Berichtsjahr wurde von den Arbeitskreisleitern - es gibt acht Arbeitskreise, die zum Teil in Arbeitsgruppen weiter gegliedert sind - ein umfangreiches Arbeitsprogramm vorgestellt. Alle Arbeitskreise wollen sich mit den Testmethoden vor Kundenfreigabe der von ihnen betreuten Software-Produkte befassen und Verbesserungsvorschläge unterbreiten. Auch die Durchforstung des Ausbildungsprogramms hinsichtlich Vollständigkeit und zweckmäßiger Funktionsgliederung hat man sich vorgenommen. Auf dem Programm des SCOUT-Führungskreises standen unterschiedliche Themen. So berichtete ein Anwender von den Möglichkeiten und Grenzen eines Projekt-Steuerungssystems. Ein SCOUT-Mitglied referierte über seine Erfahrungen mit dem bei Siemens in Frankfurt erstmals eingeführten Systemdienst - kombinierte Hard- und Software-Wartung - und kam zu einem positiven Ergebnis. Siemens präsentierte vor dem Führungskreis die Einsatzmöglichkeiten seiner neuen Serie 7.5XX und diskutierte mit den Teilnehmen darüber. Kritik war von SCOUT zu hören, weil Siemens "den bisherigen BS1000-Kunden mit der notwendigen auf BS2000 eine Nagelkette vor die Nutzungsmöglichkeiten diese sehr preisgünstigen Systems gelegt hat". Die sich daran anschließende Diskussion um die Umstellungsmöglichkeiten von BS1000 nach BS2000 ergab, daß hier von Siemens die Systemunterstützung noch erheblich verbessert werden muß.
↑ Top ↑

1980 SCOUT: BS1000-Fortentwicklung gesichert


08.02.1980 - FRANKFURT (je)
Das Siemens-Computer-User-Team(SCOUT) will nun auch lnteressenvertretung für Anwender des vor ungefähr einem halben Jahr auf den Markt gebrachten Betriebssystems BS3000 werden. In der ersten Phase dieses Vorhabens sollen BS3000-Themen unmittelbar im SCOUT-Führungskreis behandelt werden. Wie das SCOUT-Sekretariat mitteilt, war bis Ende Januar noch kein BS3000-Anwender dem Siemens-User-Team beigetreten. Derweil gilt das Hauptaugenmerk des Anwenderklubs den etablierten Betriebssysemen BS1000 und BS2000. In Anbetracht der "zaghaft einsetzenden Hinwendung derzeitiger BS1000-Benutzer zum BS2000" so SCOUT-Vorstand Bert van Rennings - hat SCOUT an die von Siemens angestrebte Migration von BS1000 nach BS2000 folgende Forderungen geknüpft: Diesem Ziel dienen Schnittstellengarantien und kompatible Betriebssystemschnittstellen. Inzwischen liegt der Anwendervereinigung ein mehrseitiger, vom Siemens-Vorstand unterzeichneter Brief vor in dem außer der Zusicherung, daß BS1000 den SCOUT-Wünschen gemäß weiterentwickelt wird, auch eine grobe Terminplanung festgeschrieben ist, die darüber Auskunft gibt, zu welchem Zeitpunkt welche Entwicklungsstufe zu erwarten ist. Ungeklärt dagegen und weiterhin heftig diskutiert sind Fragen der Konvertierung von dem einen Betriebssystem in das andere, ferner auch der Siemensschen Datenbankpolitik. "Es ist sinnvoll und notwendig", schreibt van Rennings, "alle formulierten Forderungen auf eine möglichst I breite Basis zu stellen. Alle Siemens-DV-Kunden, die ein aktives Interesse an den Produkten ihres EDV-Herstellers haben" sollen sich an SCOUT c/o Dresdner Bank Ressort Organisation - Systemtechnik, Gallusanlage 7-8, in Frankfurt wenden.
↑ Top ↑

Selbst ist der Umsteiger: BS2000 Umstieg auf Video


07.11.1980 - MÜNCHEN (bi)
Für Umsteiger auf BS2000 von BS1000 oder auch von anderen "bestimmten Wettbewerbsbetriebssystemen" - so die Ankündigung - hat Siemens jetzt acht Umschulungskassetten produziert. Die Videokassetten sind für den Selbstunterricht gedacht und laufen auf normalen Videorecordern (VCR-Standard) mit Farbfernsehgerät. Die Filme und das entsprechende Begleitmaterial vermitteln, so versichert die Siemens-Schule für Datenverarbeitung in München, umfassendes Basiswissen über Anwendung und Bedienung des BS2000 (ohne Bandbetrieb). Nach Abschluss der Videoschulung und nach etwas Praxis sei der Anwender in der Lage, mit Hilfe der Systemmanuale und in weiterführenden Kursen an der EDV-Schule von Siemens sich auch noch die allerletzten Feinheiten des BS200 an zueignen.



Siemens Lehrfilme: Wechsel auf BS2000


12.06.1981 - MÜNCHEN (pl)
Zu den acht Videofillmen "Systemwechsel auf BS2000", die umfassendes Basiswissen über die Anwendung und Bedienung des Betriebssystems BS2000 vermitteln, bietet Siemens letzt zwei weitere Lehrfllme an, die für den Cobol-Anwender bestimmt sind.
Der erste Film informiert über das Cobol-Programmentwicklungssystem namens Code 1. Der zweite neue Lehrfilm "Sprachübersetzer COB1 im BS2000" beschreibt in einer knappen halben Stunde die Leistungsmerkmale, Eigenschalten und Bedienung des COB1-Compilers und erläutert die BS2000-spezifischen Systemnamen. Für die neue Datensichtstation Transdata 9750 gibt es jetzt auch eine eigene Anleitungsunterweisung auf Videoband, die die Akzeptanz dieses nach den jüngsten Erkenntnissen der Arbeitswissenschaft gestalteten Gerätes weiter erhöhen dürfte. Der Lehrfilm stellt die Datensichtstation vor erklärt ihre Inbetriebnahme, zeigt ihre Bedienung und erläutert ihre Funktion im "Bermuda"-Betrieb, einer speziellen Software für die formatunterstützte Datenein- und -ausgabe. Information: Siemens AG, Zentralstelle für Information, Postfach 103, 8000 München 1, Tel.: 089/23 41.



Von BS1000 auf BS2000 anstrengend aber lohnend


02.10.1981 (cw)
Die Betriebssystem-Umstellung von BS1000 auf BS2000 stellt wechselwillige Siemens-Anwender nicht selten vor erhebliche Manpower-Probleme. Dem DV-Personal bleibt da oft nichts anderes übrig, als viele Abende und einige Wochenenden im Rechenzentrum zu verbringen RZ-Leiter Gerhard Gontermann moniert, daß der Hersteller einfach zuviel Wissen voraussetze. Außerdem sei es Glückssache, in den Broschüren das Richtige zu finden. Auch Uwe Neveling hält mit seiner Kritik nicht hinterm Berg: "Die Herstellerneutralität ist durch die Einhaltung der KDCS-Schnittstelle allein nicht gewährleistet. Diese Forderung ist sicherlich ein Ziel, das mit der heutigen Herstellerphilosophie nicht in Einklang steht." Einig sind sich die Befragten darin, daß, "wenn alles vorüber ist", das Arbeiten mehr Spaß macht als vorher.
↑ Top ↑

Uwe Neveling
Leiter der Abteilung Systementwicklung, Nova-Versicherungen, Hamburg
(Siemens 7.755 und 7.760, BS2000)


Auch die Nova-Versicherungen folgen gezwungenermaßen (wie wahrscheinlich viele andere Anwender auch) der geschäftspolitischen Entscheidung des Herstellers, volle BS1000-Anwendungen auf das Betriebssystem BS2000 umzustellen. Und das, obwohl wir mit dem Betriebssystem BS1000 und den bei uns eingesetzten Realtime-Software-Komponenten Asmus (Monitor) und Prisma (DB-System) zufrieden sind. Der Umstellungsaufwand ist beträchtlich und bindet einen großen Teil unserer Projektkapazität. Um den Aufwand einigermaßen erträglich zu gestalten, haben wir der eigentlichen Umstellung eine Konzeptionsphase vorangestellt. Unsere Vorgaben für das Konzeptionsteam Dialoganwendungen lauten:
  1. Erreichen eines mindestens BS1000 analogen Zeitverhaltens
  2. Gewährleistung eines hohen Maßes an Herstellerneutralität
  3. Minimierung des Umstellungsaufwandes
Dieses Konzept wurde mit qualifizierter Siemens-Unterstützung entwickelt und zunächst gemeinsam bezogen auf eine Realtime-Komponente erprobt. Jede Dialoganwendung wurde und wird danach in drei BS2000-Prozesse aufgeteilt:
  1. Die UTM-Anwendung (Für Asmus gibt es keine BS2000-Version, der Umstieg auf einen anderen Monitor war daher unumgänglich. Wir haben uns für UTM entschieden)
  2. Die eigentlichen Nova-Anwendungsroutinen (Umstellung 1: 1)
  3. Der Prisma-Verbindungsprozeß
Die Verständigung der drei Prozesse findet über ereignissteuernde BS2000 Makros statt. Ferner greifen die Prozesse auf gemeinsame Bereiche zu. Die Aufwendungen für den UTM und den Prisma-Prozeß entstehen nur einmal, das heißt, die noch umzustellenden Dialoganwendungen nutzen in vollem Umfang das bereits Realisierte. Die künftigen Umstellungsaktivitäten beschränken sich auf die Anpassung der Anwendungsprozesse an das Betriebssystem BS2000.
Erste Erfahrungen mit einem umgestellten Aufgabenkomplex zeigen, daß nicht alle Anforderungen erfüllt wurden. Das Zeitverhalten ist als äußerst kritisch anzusehen. Zur Zeit stellen wir noch eine Verdoppelung im Vergleich zum BS1000 fest.
Das zur Verbesserung des Zeitverhaltens vorgeschlagene Verfahren des Mehrfachladens des UTM-Prozesses ist nur bedingt wirksam. Wir sind nicht sicher, ob es sich wie gewünscht realisieren läßt. Wir warten auf Vorschläge des Herstellers zur Beseitigung bestimmter Nachteile, die durch den Einsatz von BS2000 verursacht werden.
Auch die Herstellerneutralität ist durch die Einhaltung der KDCS-Schnittstelle allein nicht gewährleistet. Diese Forderung ist sicherlich ein Ziel, das mit der heutigen Herstellerphilosophie nicht im Einklang steht. Lediglich die Minimierung des Umstellungsaufwandes ist erfüllt worden. Wir sind gespannt, wie es weiter geht.
↑ Top ↑

Remy Bogner
DV-Leiter, Allgemeine Elsässische Bankgesellschaft, Frankfurt
(Siemens 7.738, BS1000)


Ein Hardware-Wechsel hat für den Anwender in der Regel einen guten Grund. Meistens wird eine derartige Maßnahme durchgeführt, wenn eine gewisse Leistungsgrenze erreicht ist - sei es im Hauptspeicherbereich, bei der CPU-Geschwindigkeit, bei der Peripherie oder im Betriebssystem. In unserem Institut war vor ein paar Jahren die Maschine nicht mehr auf dem neuesten Stand. Der Hauptspeicher war zu klein und die CPU war für größeres Multiprogramming nicht ausreichend. Da wir die Absicht hatten, Online-Anwendungen zu realisieren und dies auf der alten Maschine nicht möglich war, wurde eine Umstellung erforderlich.
Der Hardware-Wechsel war gleichzeitig mit einem Rechenzentrum-Umzug von Köln nach Frankfurt verbunden. Auch der örtliche Wechsel brachte letztendlich Probleme. Wir hatten jetzt zwar einen größeren Maschinensaal sowie neue DFÜ-Standleitungen zu den Filialen, womit bessere Möglichkeiten zu Paralleltests gegeben waren. Nachteilig wirkte sich jedoch aus, daß die Programmierer und das Operator-Team während des Parallel-Laufes getrennt arbeiten mußten.
Probleme mit dem Hersteller gab es in dieser Phase nicht. Sämtliche Maschinen wurden rechtzeitig geliefert, die Siemens-Techniker hatten die Arbeiten schneller als geplant durchgeführt und die Kinderkrankheiten der neuen Anlage wurden schnell beseitigt. Auftretende Komplikationen wurden dabei mit zusätzlicher Hardware gelöst.
Das Betriebssystem stellten wir damals nicht um, wohl aber die Anwender-Software. Hier kann sich der Anwender leicht verrechnen, denn eine 1 :1-Umstellung ist nicht immer der richtige Weg. Auch kann es sich als unsinnig erweisen, dieselben Programme in gleicher Art auf der großen Anlage laufen zu lassen. Damals gingen wir von der 4004-127 mit 192 K auf eine 7.738 mit einem halben Megabyte. Als wir feststellten, daß es Kapazitätsprobleme gab, mußten wir kurzfristig auf ein Megabyte erweitern. Eine Umstellung zieht auf jeden Fall mehr Aufwand nach sich, als vorher geplant. Erst nach einigen Jahren treten jedoch in einem System Schwächen auf, deren Behebung im Normalfall während der täglichen Arbeitszeit nicht durchgeführt werden kann Wichtig und gleichzeitig Voraussetzung für einen guten Hardware-Wechsel ist die klare Analyse und Planung, wobei die Software-Änderung mit der Hardwarelieferung synchronisiert und ein Verrechnungsfaktor von 1,5 bis 2 berücksichtigt werden sollte. Für das geplante System ist eine Änderung immer eine erforderliche Gesundheitskur. Neues Blut und mehr Luft im Speicher wirkt sich später immer positiv aus.
↑ Top ↑

Dietrich Bergmann Leiter Org./DV,
Heinze GmbH, Celle (Siemens 7.541, BS2000)


In unserem Unternehmen gibt es seit 15 Jahren Datenverarbeitung. 1978 wurde der Siemens-Rechner 7.738 installiert. Im Oktober 1979 beschlossen wir, das System 7.541 mit 2 Megabyte und Festplattenspeichern zu bestellen. Das bedeutete gleichzeitig den Übergang auf das Dialogbetriebssystem BS2000. Wir entschieden uns, das Datenbanksystem Sesam beizubehalten, das Transdata-Spektrum auszubauen und den neuen Anforderungen durch die Datensichtstationen 9750 anzupassen. Um den Plantermin April 1981 einzuhalten, begannen wir im Oktober 1980 mit der Umstellung. Vorher waren unsere Mitarbeiter entsprechend geschult worden. Zerlegt man die Umstellung in Phasen, so ergibt sieh folgende Gliederung:
  1. Erfahrungen mit dem BS2000 und Dienstprogrammen sammeln
  2. Umstellung der Unterprogramme sowie eines ersten Programmkomplexes in BS2000
  3. Anpassung der Batchprogramme und Umstellung, Beginn der Produktion auf der 7.738 im BS2000
In der ersten Phase wurden nun Programme zur Übung erstellt, um das Arbeiten mit dem neuen PL/1-Compiler sowie mit Assembler, Sort, Edor (interaktives Datenbearbeitungsprogramm), UTM (Universeller Transaktionsmonitor) und PDN (Betriebssystem für Transdata-Vorrechner) kennenzulernen.
Für einen Dialogkomplex wurde auf der 7.738 unter dem BS1000 eine Verfügbarkeit benötigt, die es dem Umstellungsteam erlaubte, lediglich in einer Blockzeit von vier Stunden täglich im BS2000 zu arbeiten. Um eine längere Blockzeit zu ermöglichen, wurde dieser Programmkomplex als erstes ins BS2000 umgestellt. Durch Erstellung eines UTM-Teilprogrammes konnte die Blockzeit im BS2000 mit Beginn der dritten Phase auf sieben Stunden täglich erhöht werden.
In der dritten Phase konnten die Batch-Programme (rund 600), die zu 95 Prozent in PL/1 codiert sind, mit dem zugehörigen Job-Control nach Abschluss der Umstellarbeiten und Funktionstest für die echte Produktion freigegeben werden.
Für Programme, deren Ergebnisse nur mit großem Aufwand überprüfbar waren, zum Beispiel bei Änderungen in der DB und Statistik-Auswertungen, wurden zum Vergleich Parallelläufe durchgeführt. Die übrigen Programme wurden direkt in das BS2000 übernommen.
An das DV-Personal, insbesondere Programmierer, Arbeitsvorbereiter und Operateure, wurden während dieser Zeit erhöhte Anforderungen gestellt. Eine Unterstützung durch Siemens wurde nur sporadisch in Anspruch genommen.
↑ Top ↑

Reinhard Rauth,
DV-Leiter, Heinz Kettler GmbH, Ense-Parsit
(Siemens 7.531, BS2000)


Die Umstellung von BS1000 auf BS2000 wurde bei uns auf der vorhandenen 4004-220 durchgeführt. Erst nach den Produktionsläufen in BS2000 wurde die 7.531 installiert. Als reiner Batch-Anwender (ohne Bildschirme) standen 235 Jobs mit rund 300 Programmen zur Umstellung an. Vor dem Beginn der Umstellungsarbeiten wurde eine Bereinigung der vorhandenen Programme im Hinblick auf BS2000 und Jobs durchgeführt. Ziel dieser Bereinigung war die Konzentration auf zwei Programmiersprachen (Cobol und RPG), bei Verminderung der seit 1973 aufgebauten Jobs. Es wurden Assemblerprogramme in Cobol umgeschrieben und beschlossen, Neuprogrammierungen nur noch in Cobol durchzuführen. Nach Abschluss dieser Maßnahmen wurde als Umstellungskursus "BS2000 Anwendung - Umschulung" besucht.
Die Umstellung der Programme erfolgte ohne Schwierigkeiten. Noch 1979 steckten die Konvertierungshilfen für Jobs in den Anfängen. Ein Großteil wurde manuell ins BS2000 übersetzt. Als riesiger Nachteil erwies sich dabei die Tatsache, daß keine Bildschirme vorhanden waren.
Auszug aus einem Projektbericht von Siemens: "Die Korrektur der Jobs mit EDV über Lochkarten-Eingabe ist nicht sinnvoll, da sie umständlich und zeitaufwendig ist. Die Job-Korrektur über Bildschirm würde eine Zeitersparnis von 80 Prozent bringen."
Die Produktionsdaten wurden mittels Banddateien übernommen, auf Parallel-Läufe verzichteten wir. Während der Umstellungsphase lief der RZ-Betrieb weiter. Die Konvertierungen und Tests wurden nach Schichtende durchgeführt. Der Zeitaufwand für die Umstellung betrug etwa ein Mannjahr.
Innerhalb der abgeschlossenen Verträge wurde von Siemens zusätzliche Manpower zur Verfügung gestellt. Wichtiger als externe Hilfe war jedoch die unbürokratische Beratungsphase vor Installation der BS2000 und die Zusammenarbeit während der Umstellung mit den Systemberatern des Herstellers, von der beide Partner profitieren.
Die reine Umstellung 4004-220 8S1000: BS2000 brachte für uns keine Veränderung. Der Mangel an Bildschirmen ließ den Änderungsaufwand für Programme und Jobs gegenüber BS1000 generell steigen. Erst die Installation der 7.531 ermöglichte uns, die Vorteile des BS2000 voll zu nutzen. So konnte durch "Programmieren im Dialog" die Produktivität der Programmierer um rund siebzig Prozent gesteigert werden.
↑ Top ↑

Gerhard Gontermann
Leiter des Rechenzentrums Gontermann GmbH, Siegen
(Siemens 7.730, BS2000)


Die Umstellung von BS1000 auf BS2000 kann sich als relativ problemlos erweisen, wenn der Anwender nicht bereits im BS1000 Dialog-Anwendungen hat. Der Zeitpunkt des Systemwechsels ist eine Personalfrage. Es müssen eine Menge Vorarbeiten im BS1000 gemacht werden, wie Programme abziehen als Source-Programme, oder Dateien sichern. Ideal wäre es, diese Arbeiten außerhalb der normalen Zeit durchzuführen, weil dann der DV-Alltagskram wegfällt. Die Mitarbeiter müssten gebeten werden, die Umstellung am Abend oder am Wochenende durch zuziehen. Voraussetzung für ein optimales Gelingen des Systemwechsels ist die Schulung der Mitarbeiter. Das Problem: Kaum ein Benutzer kann hierfür zuviel Zeit und Geld opfern. Besonders wichtig für die Mitarbeiter sind bestimmte Grundkenntnisse der Editor-Funktionen. Es würde aber genügen, wenn lediglich eine Person aus der DV-Crew einen Editor-Kurs besucht und das Wissen an die Kollegen weiter gibt.
Der nächste Schritt, die Systemgenerierung, sollte rechtzeitig mit dem Hersteller geklärt werden. Grund: Mit BS2000 muß ein Betriebssystem generiert werden, auf das man für den Test und die Umstellung zurückgreifen kann. Wir haben festgestellt, daß Siemens während der Umstellung des mit Fragen und Begriffen konfrontiert hat, mit denen ein "BS1000-Mann" nicht viel anfangen kann. Hier müsste Siemens wesentlich mehr Vorarbeit leisten und nicht zu viel voraussetzen.
Der eigentliche Prozess, von BS1000 in BS2000 zu wechseln, dauert vielleicht eine Viertelstunde. Die Umstellung der Programme ist mit Cobol fast problemlos. Bei Assembler muß man sich indessen die Dateien sehr genau anschauen. Hier gibt es andere Regeln, die jedoch in den Handbüchern nachgelesen werden können. Mit RPG sind Veränderungen notwendig, vor allem in den Datei-Definitionen und bei Schalterbehandlungen. Großer Wert sollte darauf gelegt werden, die Benennung von Dateien und Programmen vor der Umstellung vorzunehmen, weil es im BS2000 die Möglichkeit gibt, komplett durch eine Vergabe (beispielsweise eines Punktes) alle Dateien aufzurufen oder kenntlich zu machen. Die Fehler-hinweise und die Beschreibung der Fehler ist für einen DV-User, der aus dem BS1000 kommt, eine wahre Katastrophe. Es ist reine Glückssache, wenn man in den Broschüren das findet, was gerade benötigt wird. Dies hat Siemens nicht gut gelöst.
Nach einiger Zeit kennt man allerdings die Fehler, und die Schwierigkeiten bauen sich langsam ab. Wir haben, um eine Größenordnung zu nennen etwa 700 Programme für etwa 40 Arbeitsgebiete in fünf Monaten umgestellt. Die Programmierung im BS2000 ist ein Gedicht. Es gilt, die Programmierer in ihrer Arbeit eher zu stoppen als anzufeuern.
↑ Top ↑

Siemens in der Klemme


Der Elektrokonzern passt sich dem Marktführer IBM an!
23. März 1984 07:00 Uhr
Von Hermann Bößenecker Zeit Online

So etwas wäre in keiner anderen Branche denkbar: Ein treuer Kunde, der Jahrzehntelang die Produkte eines Unternehmens zur allgemeinen Zufriedenheit benutzt hat, entscheidet sich mit einmal für ein Angebot der Konkurrenz. In der Datenverarbeitung sind solche Entscheidungen nicht selten.

Doch der Dresdner Bank, dem bisher weltweit größten Computer-Kunden des Elektrokonzern Siemens, ist dieser Entschluss besonders schwer gefallen. Das Geldinstitut stand vor der Wahl, nicht weniger als dreitausend Programme, mit denen rund fünftausend Terminals in tausend Geschäftsstellen an die Frankfurter Zentrale angebunden sind, entweder auf das neue Siemens-Betriebssystem (BS2000) „umzuschreiben“ oder aber der mächtigen IBM Tribut zu zollen, also auf deren Betriebssystem für die oberste Rechner-Ebene (MVS = Multiple Virtual System) umzusteigen. Unter „Betriebssystem“ versteht man die von den Herstellern mitgelieferten, in Systemprogrammen fixierten Regieanweisungen („Software“) für den Umgang mit der Maschine („Hardware“).

Die Dresdner Bank stand vor einer Entscheidung, die – so Organisationschef Walter Gruhn – "weit über ein Jahrzehnt hinaus wirksam“ sein wird. Wenn sie trotz ihrer großen Zufriedenheit" mit Siemens zum IBM-System überwechselte, so aus zwei Gründen: „Wir haben damit größere Sicherheit und einen größeren Markt.“ Der IBM-Standard gilt heute weithin als „Weltstandard“. So richten sich die meisten Computer-Hersteller nach dem Giganten aus, suchen ihre Maschinen mit denen des Marktführers kompatibel, also verträglich“ und damit problemlos zusammenschaltbar zu machen.

IBM ist zwar keineswegs der innovative Computerbauer, aber mit einem Marktanteil von weltweit deutlich über fünfzig Prozent schreibt er der DV-Industrie das Gesetz des Handelns vor. Und IBM ist immer für Überraschungen gut. „Die Siemens-Leute sagen uns, was sie in drei Jahren machen wollen, damit wir uns darauf vorbereiten“, formuliert Gruhn seine Erfahrungen. „IBM dagegen sagt gar nichts und kommt dann überraschend mit neuem Gerät.“

Mit dieser selbstherrlichen Politik ist der Computer-Riese immer erfolgreicher. Es ist ungemein schwierig, den Langzeit-Strategien der Hersteller auf die Spur zu kommen, mit deren Kolossen die Rechenzentren der Industrie und des Handels, der Banken und Versicherungen bestückt sind. Die Systeme der einzelnen Lieferanten sind nach wie vor nur begrenzt miteinander kombinierbar, und niemand weiß heute, was die Konkurrenz morgen bringen wird.

Noch nie haben die Chefs der Datenverarbeitungsabteilungen in großen deutschen Unternehmen deshalb so intensiv über die Zukunft ihres Tuns und damit über anstehende Investitionsentscheidungen nachgedacht wie zur Stunde. Vor allem jene Unternehmen, die in den letzten Jahren wie die Dresdner Bank auf die Rechner von Siemens gesetzt haben, sind in einer Entscheidungsklemme. Sie müssten schon heute Gewissheit darüber haben, wie Siemens in den nächsten fünf bis zehn Jahren operieren und mit welchen anderen Systemen seine Großrechner auf die Dauer kompatibel sein werden.
↑ Top ↑

Nachwort von F10479


Mit BS1000 habe ich den Einstieg in die EDV Hautnah miterlebt. 1974 begann ich in die EDV einzutauchen und die Digitale Welt neugierig zu erkunden. Mit der heutigen Sicht vom war es ein Digitaler-Meilenstein den ich damals miterleben durfte und nicht missen möchte. Der Umstieg von BS1000 nach BS2000 war für mich nicht so schwer, da ich durch gezielte Weiterbildung (HW/SW) auf den neusten Stand gebracht wurde. Für viele Kunden von Siemens war es eine Herausforderung mit der Option auf die Zukunft in eine neue virtuelle und moderne EDV Landschaft. Leider sind nicht alle Kunden diesen Weg mit Siemens gemeinsam gegangen. Der größte BS1000 Kunde die "Dresdner Bank" hatte nicht den Mut den Weg mit Siemens zu gehen, und ist 1984 zu dem Mainframe Weltmarktführer "IBM" gewechselt. Andere Kunden haben den Umstieg zum BS2000 mit Erfolg gemeistert und haben die Vorteile des neuen Betriebssystems für neue Innovationen positiv genutzt. Heute am gibt es im europäischen Raum eine Stabile BS2000 Anwendergemeinde, die noch lange die BS2000 Mainframe Fahne hochhalten wird.
↑ Top ↑

  Design and Service © 26.08.2005 Michael Engel All Rights Reserved. Version 1.00  |  Impressum