MÜNCHEN - 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
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.
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.
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 durch 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.