Das mit dieser Frage aufgeworfene Problem erledigte sich von selbst, wenn die Betriebssysteme der Hersteller alle Anwenderforderungen erfüllen würden. In der Praxis lassen sich Eingriffe in die maschinennahe Software indes nicht immer vermeiden. Um nicht zu riskieren, ins "unterstützungslose" Abseits zu geraten, verfährt Volker Lowitsch, Leiter Systemprogrammierung bei der Karstadt AG (Essen), im Fall des "unumgänglichen" Eingriffs nach der Maxime "möglichst wenig, möglichst selten".
Denn allzu leicht könnte durch Eigenlösungen, so Lowitsch, die Kompatibilität zu den Betriebssystem-Entwicklungen des Herstellers verloren gehen. Betriebssystem-Änderungen sollten deshalb gemeinsam mit dem Hersteller durchgeführt werden, empfiehlt Lowitsch. Daß derartige Eingriffe überdies nur erfahrene Software-"Chirurgen" vornehmen sollten, kommt auch in den anderen Beiträgen zum Ausdruck.
Dipl.-Math.
Volker Lowitsch
Leiter Systemprogrammierung, Karstadt Aktiengesellschaft, Essen
Die Notwendigkeit ins Betriebssystem einzugreifen ist grundsätzlich risikohaft. Wir greifen daher ungern ein. Das ist jedoch in der Praxis nicht immer zu vermeiden, weil aus bestehenden Zielsetzungen und unternehmensorientierten Bewertungen Forderungen entstehen, die von dem universell orientierten Betriebssystem des Herstellers nicht erfüllt werden. Die Konsequenz heißt Eingriff.
Wir übersehen dabei nicht, daß die Risikobreite neben der Qualität des vom Hersteller gelieferten Betriebssystems zusätzlich abhängig ist von Wissen und Erfahrung der dazu Beauftragten. Wir differenzieren verschiedene Risikoebenen:
1. Zur Optimierung des Systemdurchsatzes modifizieren wir das vom Hersteller zur Verfügung gestellte Betriebssystem, da es nur die Ausführung bestimmter Funktionen ermöglicht, nicht jedoch die Gegebenheiten spezieller Anwendungen und des vorhandenen Anwendungsmixes berücksichtigt. Zur Durchführung der erforderlichen Modifikation ersetzen wir im Betriebssystem vordefinierte Dummy-Module unter Einhaltung fest vorgegebener Schnittramm-Module testen wir sowohl stellen durch entsprechende eigene Programmlösungen. Diese Programm-Module testen wir sowohl losgelöst als auch in Verbindung mit dem Betriebssystem, um das Risiko möglichst klein zu halten. Die Probleme bei Releasewechsel - soweit voraussehbar - definieren dabei unsere Entscheidung zum Eingriff.
2. Für wesentlich problematischer halten wir nach heutigem Erkenntnisstand indirekte Eingriffe ins Betriebssystem die vorhandene Systemfunktionen durch eigene Programmlösungen ersetzen, wie zum Beispiel die Entwicklung eigener Zugriffsverfahren. Das Risiko dieser Eigenlösungen liegt nicht so sehr in einer erhöhten Fehlerhäufigkeit, sondern vielmehr in dem entwicklungshemmenden Effekt. Denn die Hard- und Softwareentwicklung der Hersteller ist in der Regel aufwärtskompatibel. Kompatibilität zur Eigensoftware kann dagegen nicht vorausgesetzt werden. Die negativen Auswirkungen, die sich daraus ergeben rechtfertigen - wie wir meinen - nur in Ausnahmefällen derartige Entscheidungen.
3. Für einen sehr kritischen Eingriff in das Betriebssystem halten wir die Absolutkorrektur von Hersteller-Systemmodulen. Die Auswirkungen derartiger Eingriffe sind wegen der Komplexität der eingesetzten Betriebssysteme nicht voraussehbar und damit auch nicht bewertbar. Wir halten es daher nicht für verantwortbar, Absolutkorrekturen zur Realisierung eigener Problemlösungen vorzunehmen.
Wir entscheiden also nach der Maxime, möglichst wenig, möglichst selten und nur wenn unumgänglich einzugreifen.
Peter Pfeilschifter
Systemprogrammierer, Feucht bei Nürnberg
Das Problem der "Änderung" von Betriebssystem-Software wurde speziell von Herstellerseite lange Zeit mit Argwohn betrachtet. Inzwischen jedoch gibt es auch von dieser Seite Produkte, welche eine Änderung der bestehenden Software erforderlich machen. Damit ist das Problem der Softwareänderung auch für den Benutzer nicht mehr so prekär wie in früheren Zeiten.
Grundsätzlich sollte man bei Eingriffen in die bestehende Software jedoch versuchen diese so klar wie möglich in ein Betriebssystem zu integrieren etwa dadurch, daß man eine Phase umbenennt und an ihre Stelle eine eigene Phase mit dem ursprünglichen Namen stellt. Diese Phase führt zunächst die vom Benutzer gewünschten Arbeiten aus und ruft schließlich die umbenannte Originalphase auf. Eine Änderung des "Source-Codes" von Betriebssystemphasen ist weniger zu empfehlen, da dies bei "Release"-Umstellung immer wieder nahezu den gleichen Arbeitsaufwand wie bei der Erstellung nach sich zieht. Eventuell wird sogar die Umstellung vorläufig verhindert, da der neue "Source-Code" nicht immer gleich beschafft werden kann.
Eine andere Art des Eingriffs in ein Betriebssystem bietet sich durch den Einsatz von "User-Exits". Zum Beispiel besitzt der im Dos/VS vorhandene "Job-Exit" hier viele Möglichkeiten. Die Aussage eines Rechenzentrumleiters dazu: "Unser 'Job-Exit' ist ein halber Supervisor." Ein anderer gut zu gebrauchender "Exit" ist der von "Jobaccount". Nachdem die Exit-Möglichkeit von Herstellerseite geboten wird, können hier auch keine Einwände gemacht werden.
Eine Voraussetzung für Eingriffe in ein Betriebssystem ist jedoch, daß der Benutzer weiß wie die internen Abläufe an der von ihm geänderten Stelle sind und welchen Einfluß sein Einbau auf den gesamten Ablauf hat. Ohne entsprechende eigene Kenntnisse des Betriebssystems ist daher dem Benutzer von Änderungen abzuraten.
Letztlich sollte sich der Anwender immer den Rückzug freihalten, nicht um etwa auf seinen Einbau zu verzichten, sondern um im Zweifelsfall eventuell auftretende Fehler mit der Originalfassung seines Betriebssystems ebenfalls erzeugen zu können. So besitzt man gegenüber dem Hersteller ein stichhaltiges Argument für einen Fehlernachweis.
Durch entsprechende Systemeinbauten ist ein Betriebssystem den speziellen Kundenerfordernissen besser anzupassen, wenn der Hersteller derartige Lösungen nicht - oder auf absehbare Zeit noch nicht - anbieten kann.
Peter Pfeifer
Leiter der System- und Anwendungsprogrammierung
Landeszentralbank in Bayern
Die gestellte Frage, undifferenziert betrachtet, würde ich mit Nein beantworten.
Eingreifen in oder besser Ändern von Betriebssystemkomponenten bedeutet in letzter Konsequenz auch, neben dem eventuell erreichten Effekt, daß der Hersteller die Verantwortung für negative Folgen solcher Modifikationen ablehnt - und das mit Recht. Betrachtet man dieses Problem jedoch aus dem Blickwinkel der praktischen EDV-Anwendung, und nur dann kann eine konkrete Antwort gegeben werden, so kann das Ergebnis unter bestimmten Voraussetzungen auch "Ja" lauten.
Ein Betriebssystem umfaßt in seiner Gesamtheit
a) den Systemkern oder das Organisationsprogramm, alle zur Datenbearbeitung, Datenträgerverwaltung, Gerätebearbeitung und Auftragsbearbeitung notwendigen Komponenten sowie Anwender-Software wie zum Beispiel Datenbanksysteme, Hilfsprogramme, Übersetzer und
b) im weiteren Sinn eigenerstellte Anwender-Systemprogramme.
Eine Modifikation der unter
a) definierten Komponenten sollte nur dann zugelassen werden, wenn dies zur Aufrechterhaltung des Echt- oder Testbetriebes unbedingt notwendig ist und vorher anwenderseitig alle anderen Umgehungsmöglichkeiten eines Problems geprüft worden sind. Die Änderungen sollten, falls dies im Moment möglich, nach exakter Abstimmung mit dem Hersteller und auf dessen Anordnung vorgenommen werden, denn nur er kennt die logischen Zusammenhänge und Abhängigkeiten zwischen geänderter Systemkomponente und den anderen Systemteilen genau.
Die Betriebssysteme der Hersteller sind heute den Anforderungen entsprechend leistungsfähig und erlauben dem Anwender eine wirtschaftliche Bedienung seines Systems. Dennoch gibt es auf den Gebieten
- Betriebssicherheit
- Systemoptimierung
- Anwenderflexibilität und -freundlichkeit
meiner Meinung nach noch etliche Lücken, die eine effektive Auslastung bestimmter Anlagenkomponenten, je nach programmtechnischer Anforderung, nicht zulassen.
Das Ziel der eigenen Systemprogrammierung muß es deshalb sein, Systemprogramme zu erstellen, die eine noch wirtschaftlichere Ausnutzung der Anlagen ermöglichen. Diese eigenerstellte Systemsoftware kann im weiteren Sinne auch unter dem Begriff Betriebssystem eingeordnet werden; da sie mit Betriebssystemteilen beziehungsweise Systemdateien zusammenarbeitet, das heißt bestimmte Schnittstellen Anwender - Betriebssystem (P1-Teile) müssen unter Umständen modifiziert werden, um ein bestimmtes Ziel zu erreichen. Diese Eingriffe akzeptiere ich dann, wenn sichergestellt ist, daß diese Arbeiten zentral in der Systemprogrammierung verbleiben und ferner gewährleistet ist, daß bei neuen Betriebssystemversionen und Herstellerentwicklungen der Wartungsaufwand des eigenen Systemprogramms im vernünftigen Verhältnis zum Nutzen steht". Gerade dieses Problem darf bei der Entwicklung eigener Systemprogramme nicht unterschätzt werden.