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.

18.03.1977 - 

Kostengünstige TP-Lösung bei der DESMA-Werke GmbH, Bremen:

Mit TCSS angefangen und dabeigeblieben

Jeder Organisations- und EDV-Leiter, der mit einer IBM-Anlage arbeitet, steht bei Einführung von TP-Anwendungen vor der Frage, welches TP-Monitor-System er einsetzen soll. Die IBM offeriert ihm ganz selbstverständlich ihr CICS, auch dann, wenn die vorhandene Anlage nicht eine 145 oder 148 mit mindestens 1000 K ist. Da die Startschwierigkeiten der ersten CICS-Anwender nicht verborgen geblieben sind, haben von vornherein auch Systeme wie Taskmaster, TICS oder Shadow gute Chancen, eingesetzt zu werden. Kurz bevor der Anwender sich nun für einen Nicht-IBM-Monitor entschließt, empfiehlt ihm die IBM, doch für den Beginn TCSS zu nehmen, um dann später immer noch umsteigen zu können. Diese Empfehlung hat zunächst den großen Vorteil, daß das TCSS mit 12x 600 Mark monatlich von allen angebotenen Monitorsystemen mit Abstand das preisgünstigste ist. Auch die sonstigen Vorteile sind eher bestechend: Leicht und schnell zu installieren, ein recht komfortabler Mapping-Support, keine Umstellung für die Anwendungsprogrammierer, wie sie beispielsweise bei Multitasking-Systemen erforderlich ist, die von dem Programmierer eine Reentrant-Programmierung verlangen. Die Startphase verläuft dann auch meist recht befriedigend; es werden rasch eine Reihe von Anwendungsprogrammen geschrieben, und da bei TCSS nur eine Task arbeitet, bleibt auch bei Maschinen mit nur 160 K p Kernspeicher noch ausreichend Kapazität, neben der TP-Partition noch eine Power- und zwei Verarbeitungspartitions abzuwickeln. Bei bis zu fünf Bildschirmen sind die Antwortzeiten durchaus akzeptabel. Die Schwierigkeiten beginnen mit jedem Bildschirm, der darüber hinausgeht, und erreichen beim Einsatz von acht Bildschirmen nicht mehr vertretbare Antwortzeiten bis in die Gegend von 6 bis 10 Sekunden.

Mehrkosten von 65 000 Mark

Spätestens zu diesem Zeitpunkt wird die IBM erneut bei dem Kunden vorstellig und empfiehlt ihm, jetzt auf CICS umzusteigen, da ja ganz klar ersichtlich sei, daß so nicht weitergearbeitet werden könne. Wie viele Anwender sich von diesem Argument überzeugen lassen, ist nicht bekannt Es gibt durchaus Anwender, die sich nicht für CICS entscheiden sondern beispielsweise auf Shadow überwechseln. Eine weitere Möglichkeit, das Problem zu lösen, ist, sich mit den Schwächen und Möglichkeiten des TCSS selbst zu beschäftigen, um durch Eingriffe in das Programm wieder befriedigende Antwortzeiten zu bekommen. Denn über eine Tatsache muß man sich ganz klar sein: Der nackte Umstieg auf ein größeres Multitasking-System ohne gleichzeitige Maschinenerweiterung bringt bei kleinen Anlagen noch keine Vorteile; unter Umständen wird der Batchbetrieb sogar noch langsamer, und die Monitore sind nur dann schneller wenn sie einigermaßen aus dem vollen schöpfen können.

Stellt man in Rechnung, daß allein durch den Umstieg auf CICS in Verbindung mit DBOMP-Dateien mindestens 1800 Mark monatlich an Lizenzgebühren aufzuwenden sind (die Umstellung der Anwendungsprogramme nicht mitgerechnet), so ergibt sich damit innerhalb von drei Jahren ein Kostenfaktor von 65 000 Mark. Bei Einsatz von Shadow oder Taskmaster kann vielleicht ein Zehntausender gespart werden - bei sicher höheren Aufwendungen für die Anpassung der Anwendungsprogramme. Bei diesen Kosten lohnt sich die Überlegung, durch eigene Programmierkapazität die Schwachen des TCSS abzustellen

Diese Überlegung wurde bei der DESMA-Werke GmbH angestellt Bereits nach kurzer Prüfung kam man zu dem Ergebnis, daß es möglich und sinnvoll sei, das TCSS zu verbessern. Als Ursache für die langen Antwortzeiten wurde die Roll-in-Roll-out Technik des TCSS erkannt, die bewirkt, daß bei jeder Transaktion ein Roll-in-Roll-out eines kompletten Programms erfolgt. Wenn dann zusätzlich bei virtuellen Betriebssystemen noch gepaged wird, ist leicht vorstellbar, wieviel Kanalbewegungen zur Platte und zurück notwendig sind,

um nur eine Bildschirm-Transaktion durchzuführen.

Hinzu kommt daß das TCSS, unabhängig von der Größe eines Benutzerprogramms immer einen Bereich in der Länge des größten Programms rollt; wobei die Größe bestimmt wird durch den Benutzerteil plus den Vereinbarungen für alle unter TCSS vorkommenden IS-, DA- und DBOMP-Dateien einschließlich der zugehörigen I/O-Areas und MODS, auch wenn diese im speziellen Anwendungsprogramm gar nicht angesprochen werden

Es wird nicht mehr gerollt

Für die Neukonzeption wurde folgender Weg eingeschlagen:

Alle vereinbarten Benutzerdateien wurden, genau wie die TCSS-eigenen Dateien, direkt und nur einmal dem Monitor zugeschlagen und auf die Roll-in-Roll-out-Technik und damit auf die Hauptschwierigkeit des Systems komplett verzichtet. Der Monitor weist, gesteuert über die Terminallisten, jedem Terminal einen eigenen Programm-, Map- und Save-Bereich zu und überläßt die Verwaltung des Speicherplatzes ganz dem Betriebssystem, wobei mit "Programmbereich" wirklich nur das Anwendungsprogramm selbst ohne Dateivereinbarungen und I/O-Bereiche gemeint ist; womit es beispielsweise wieder sinnvoll geworden ist, sparsam zu programmieren. Die virtuelle TP-Partition muß dabei zwar erweitert werden, die reale Speicherzuordnung für die TP-Partition, nämlich 16 K für das BTMOD, ändert sich aber nicht. Obwohl bis auf diese 16 K der TCSS-Monitor voll virtuell gefahren wird, war der Erfolg dieser Maßnahme einfach frappierend. Die vorher unerträglichen Antwortzeiten an den Bildschirmen waren praktisch auf null geschrumpft. Außerdem wurde der Stapelbetrieb durch die Reduzierung der Kanalbelastung wieder merklich schneller.

Systemimmanente Schwächen ausgemerzt

Ermuntert durch die sehr guten Erfolge bei der Überarbeitung von TCSS machte man sich anschließend daran, gleich einige weitere Schwächen des Systems zu beseitigen. So wurde beispielsweise der Datentransfer zwischen Puffer und Map-Areas erheblich verbessert und durch Hinzufügung neuer Funktionen die Operator-Konsole zu einem Masterterminal für das gesamte TP-System erweitert. So ist es beim Originalsystem nicht möglich, während des Betriebes einzelne Dateien abzuschließen, es sei denn, man beendet die ganze TP-Partition. Durch die Zusatzfunktionen ist es jetzt möglich, einzelne Dateien ohne Unterbrechung der Partition abzuschließen, wieder zu eröffnen sowie PDUMPs für das Monitorsystem wie auch für einzelne Terminals zu erzeugen.

Zusammenfassend wäre zu sagen: Das TCSS hat sich als ein zuverlässiges und einfach einzusetzendes TP-System erwiesen, das die normalen TP-Belange kleiner und mittlerer Anwender voll abdeckt.

Durch den Zusatz TCSS/HS (High-Speed) ist es gelungen, die systemimmanenten Nachteile zu überwinden, und die Möglichkeit gegeben, nach einer TP-Startphase unter TCSS weiterarbeiten zu können und nicht auf teurere Systeme umsteigen zu müssen.

Damit hat der EDV-Anwender nicht nur das mit Abstand preisgünstigste TP-System, ihm bleiben auch alle Kosten und Mühen einer Umstellung erspart.

Der Zusatz TCSS/HS ist mittlerweile auch für andere Anwender des TCSS verfügbar über das Büro für Software-Entwicklung, Bremen, Mühlenfeldstr. 61c.

*Günter C. Heintz ist EDV-Leiter bei der DESMA-Werke GmbH, Bremen