EDV-Projekte meines Berufslebens

Aus heutiger Sicht erscheinen die folgenden Projekte geradezu als lächerlich. Aber wenn man die technischen Möglichkeiten der damaligen Zeit betrachtet, kann man das als Pionierarbeit bezeichnen. Es gab oftmals auch zumindest DDR-weite Anerkennung! Auch einige spätere Projekte entlocken einem ein leichtes Schmunzeln.

Text-Verarbeitung (1975)

Von 1970 bis 1980 (dann verschenkt an die Volkssternwarte Radebeul) verfügten wir (die Fa. VEB Glasinvest Radebeul) über einen Kleinrechner Cellatron C 8205 (D4a). Dieser basierte auf dem D1, einer Entwicklung von Nationalpreisträger Prof. N.J.Lehmann (bei dem ich Rechentechnik-Vorlesung hatte), der in größerer Stückzahl in Zell-Mehlis für die DDR und das sozialistische Ausland, insbesondere die UdSSR, gebaut wurde. Die Maschine basierte auf DTL-Logik (Transistoren von Hitachi) und einer Magnettrommel als Hauptspeicher mit einer Kapazität von 128 Spuren x 32 Worten x 33 Bit und 18.000 Umdrehungen / Minute (ca. 20 Minuten Anlaufzeit), besaß Lochbandleser und -stanzer sowie zur Bedienung, Ein- und Ausgabe eine elektrische Schreibmaschine. Das war der erste Personal-Computer der Welt: frei programmierbar und passte in der Originalform auf jeden Schreibtisch!

Auf den vorhandenen 16 kByte außer dem Betriebssystem auch noch eine „Text-Verarbeitung“ unterzubringen, war für mich eine echte Herausforderung. Überlegungen stellte ich u.a. auch während meiner Armee-Zeit an. Die vom Hersteller bereitgestellten Text-Funktionen bestanden darin, einen Ausgabe-Befehl mit dem jeweiligen Zeichen (codiert natürlich) auszuwerten, d.h. man brauchte pro Zeichen 33 Bit. Eine Eingabe war in dieser Form nicht vorgesehen; man konnte aber den Code eines eingegebenen Zeichens ablegen.

Ich schaffte es, 5 (statt 1) Zeichen pro Speicherplatz unterzubringen sowie die Ein- und Ausgabe-Routinen auf gerade mal 64 Speicherplätzen. Das Ganze programmierte ich auch noch zeitoptimal (bei einer Zykluszeit von 3 Millisekunden war das sehr wesentlich!). Dafür musste die Geometrie der Magnettrommel berücksichtigt werden, d.h. die Operanden mussten zwischen die Operationen an geeigneter Position eingepasst werden – das ging nur mit „Schieberei“, man musste die geringsten Kompromisse wählen.

Programmiert wurde übrigens in Maschinensprache, numerisch codiert (die Speicherzellen wurden durchnummeriert, und der Befehl „210“ beispielsweise war eine Festkomma-Addition). Die Programme entwarf ich erst mal in ALGOL 60 (meine „Muttersprache“) und setzte sie per Hand um. Später machte man das mit „Pseudo-Code“. Die Verwendung des weit verbreiteten PAP (Programm-Ablauf-Plan) lehnte ich grundsätzlich ab, weil Spaghetti-Code einer strukturierten Programmierung entgegensteht.

Link: http://www.robotrontechnik.de/index.htm?/html/computer/d4a.htm

Wärmetechnische Berechnungen (1973)

Für bereits oben genannten „Dampf-Rechner“ C8205 gab es später auch einen Compiler „PS2“, entwickelt von einer Plauener Firma. Bereits vorher gab es in Maschinensprache geschriebene wissenschaftlich-technische Programme, z.B. für Fundamentpläne, Durchlaufträger, „Bühnenträgerlagen“; der Programmieraufwand dafür war immens, ebenso wie der Aufwand für Testung, Dokumentation und Änderung. Das lohnte sich nur für Programme, die in großer Stückzahl eingesetzt wurden.

Für unseren Betrieb, der Glasschmelz-Anlagen projektierte, hätte sich dieser Aufwand nie gelohnt. Mit Hilfe von PS2 (gewisse Ähnlichkeiten zu ALGOL vereinfachten das Verständnis) war es uns möglich, individuelle Programme für den Eigenbedarf zu erstellen. Mein erstes eigenständiges „Projekt“ war die Berechnung des Wärmedurchganges bzw. Temperaturprofiles einer mehrschichtigen Wand mit temperaturabhängigen nichtlinearen Material-Koeffizienten (Wärmeleitung, Dichte, Wärmekapazität). Das Problem bestand darin, dass der Temperaturverlauf zu berechnen gewesen wäre, wenn man die Außentemperatur gekannt hätte, aber die erhielt man erst, wenn man die Temperaturen im Material gekannt hätte. Wenn ich mich recht erinnere, führte ich den Lösungsweg auf Differential-Gleichungen zurück und legte darüber eine nichtlineare Optimierung durch quadratische Interpolation der Ergebnisse der Diffential-Gleichungen.

Die Bewältigung dieser Aufgabe setzte eine kollektive Zusammenarbeit (zwischen einem EDV-Techniker und Mathematiker und einem Wärmetechniker) voraus. Der Clou war, dass ich als Nicht-Fachmann letztendlich bei Fragen des Wärmedurchganges von den Spezialisten zu Rate gezogen wurde. Von da an teilte ich meine Arbeit zwischen der EDV-Abteilung und verschiedenen Fachabteilungen.

Die Compilierung der Quellprogramme war natürlich viel umständlicher als man das heute gewöhnt ist: Compiler per Lochband einlesen, Quell-Programm per Lochband nachladen, Übersetzung starten, Maschinen-Programm per Lochband ausstanzen, „Betriebssystem“ (numerische Bibliotheken) vom Lochband einlesen, Maschinen-Programm nachladen – dann ging es erst richtig los.

Monte-Carlo-Simulation (ca. 1978)

Im Rahmen der Planung einer größeren Flachglas-Anlage in Torgau stellte sich die Frage nach der Dimensionierung des Scherbenlagers. Einerseits musste das Flachglas nach der Abkühlung sofort geschnitten werden – die Optimierung der Schnitte war ein extra Problem – und sofort abtransportiert werden. Andererseits war Torgau damals dafür bekannt, dass immer im unpassenden Moment die Bahnschranke geschlossen war, und Glatteis war im Winter auch nicht gerade selten. Das nicht abtransportierte Glas ließ sich nicht ökonomisch zwischenlagern, sondern wurde als Scherben später wieder dem Schmelzprozess zugeführt. Dafür wurde ein Zwischenlager benötigt.

Auch wieder im Kollektiv nahmen wir uns der Dimensionierung des Scherbenlagers an. Wir sammelten Informationen über die Verteilung der Schließzeiten der Bahnschranken sowie über die witterungsbedingten Sperrzeiten der Zufahrtsstraßen. Der Auftraggeber wunderte sich sehr über unsere Anfragen. Als wir die Daten zusammen hatten, erstellten wir ein Programm für den C 2805 unter Benutzung der Programmiersprache PS2. Die „Störungen“ durch Wetter und Bahn wurden ausgewürfelt.

Dazu ermittelten wir zunächst grob eine passende Verteilungsfunktion der Störungen, die wir dann programmtechnisch aus einer Gleichverteilung transformierten. Die Erzeugung gleichverteilter Zufallszahlen ist längst den Betriebssystemen überlassen, aber damals mussten wir uns schon selbst kümmern. Dabei gingen wir etwas gründlicher vor. Zunächst las ich mir die verschiedenen Verfahren (Kongruenz-Verfahren, Fibonacci-Zahlen etc.) an und informierte mich über Kriterien zur Bewertung der „Güte“ (Gleichverteilung, Autokorrelation der Folge, Zyklen, Verteilung auf- und absteigender Sequenzen usw.) der erzeugten Zufallszahlen. Das Gelesene testete ich natürlich auch aus. Das Ergebnis war erschreckend: keines der damals bekannten Verfahren erfüllte annähernd alle Kriterien.

Ich fand eine ideale Lösung des Problemes: ich wechselte das Verfahren (verschiedener Modulus des Kongruenzverfahrens, Wechsel zu Fibonaccizahlen, verschiedene Startwerte etc.) in Abhängigkeit von den letzten Bits der Uhrzeit. Diese Methode muss nicht immer vorteilhaft sein: für den Vergleich verschiedener Prozesse kann es auch besser sein, wenn man immer wieder die selbe Zufallszahlenfolge verwendet.

Praktisch lief das Ganze so ab: Wir starteten das Programm mit den notwendigen Werten zum Feierabend und ließen den Rechner über Nacht laufen. Am nächsten Morgen unterbrachen wir das Programm und stanzten das Ganze auf Lochband, damit wir mit unserer täglichen Arbeit fortsetzen konnten. Am Nachmittag starteten wir wieder unser Simulations-Programm und lasen das Lochband vom Morgen wieder ein usw.

Stücklistenprogramm (ca. 1975)

Eigentlich war es nicht möglich, mit dem C 8205 Stücklisten zu erzeugen, die Speicherkapazität reichte gar nicht. Mit Tricks gelang es uns doch noch. Zunächst speicherten wir die Texte komprimiert (s.o.). Ähnliches machten wir mit den Artikeln: da die Anzahl der glasanlagenspezifischen Artikel sehr überschaubar war, packten wir mehrere in einen Speicherplatz. Ebenso wurden die Baugruppen (die ja nicht allzu viele Elemente besitzen) komprimiert. Letztlich wurde auch noch das Programm komprimiert und interpretierend ausgeführt. Als Nebeneffekt verringerte das auch den Datenerfassungs-Aufwand.

Es bedurfe nicht viel Aufwandes, um meinen mehr technologisch geprägten Programmier-Kollegen in diese spezielle Programmierung einzuführen.

Umbau Kleinrechner und Nutzung von Mikrorechnern (1980)

1980 erhielten wir einen KRS 4201 (abgerüsteter Bruder des PRS 4000, der gewisse Ähnlichkeiten mit der PDP 8 aufgewiesen haben sollte; die Architektur war sehr Prozessrechner-typisch). Dieser wurde gleich im Neubau installiert, während die Belegschaft erst später einzog. Es gab allerdings einige Abstürze infolge nicht ganz stabiler Baustellen-Stromversorgung.

Der Rechner besaß 16 k x 32 kbit (also 32 kByte) Hauptspeicher, eine Bedienschreibmaschine, Lochband-Geräte, einen Mosaikdrucker. Programmiert wurde er in Assembler. Zunächst beschafften wir uns Plattenspeicher: ein Gehäuse (welches bestückt nicht in den Fahrstuhl passte), zwei Laufwerke mit je einer Fest- und einer Wechselplatte 14“ mit der „sagenhaften“ Kapazität von je 2,5 Mbyte. Den Assembler haben wir bald beerdigt und ersetzt durch ein integriertes ALGOL 60 basierendes Betriebssystem (von Dr. Kaminsky – seine geniale Entwicklung brachte ihn leider in Konflikt mit der Staatsmacht der DDR, siehe folgenden Link: http://www.rittergutstaucha.fitbro.de/rittergut_staucha_sachsen/zusammenarbeit-mit-herrn-dr-k-autor-hans-bottcher/ ), welches sowohl Compiler als auch Laufzeit-System beinhaltete. Dieses gab es in einer Festkomma- und in einer Gleitkomma-Version. Unter Verwendung der Plattenspeicher entfiel die lästige Lochband-Arbeit. Für die Plattenspeicher programmierte ich ein einfaches Datei-System (als Sub-Routinen); vom Hersteller war nur direkte Adressierung über Oberfläche, Spur und Sektor vorgesehen.

Für die Datenerfassung stand uns ein „Org-Automat“ (elektrische Schreibmaschine mit zwei Lochband-Lesern und zwei Lochband-Stanzern) und ein Ascota-Buchungsautomat zur Verfügung. Damit sollten wir den Rechner rund um die Uhr füttern.

Die erste Erweiterung betraf den Anschluss eines Bildschirm-Terminals (nachdem uns ständig die Bolzen der Schreibmaschine aufs Knie fielen). Offiziell gab es eine Lösung über serielles Interface, das war sündhaft teuer und schaffte nur 9.600 Baud. Wir besorgten uns die Lösung eines anderen Anwenders, der das Ganze über ein Parallel-Interface, welches ohnehin für die Drucker vorhanden war, realisierte. Diese Lösung bauten wir aus (Erweiterung des Funktionsumfanges). Zugrunde lag ein Intel 808-basierendes Mikrocomputersystem (K 1510) in der Bauform PBT4000, welches wir auch für andere Zwecke verwendeten. Ohne diese Lösung wäre die nachfolgend beschriebene Simulation speicherprogrammierbarer Steuerungen nicht möglich gewesen.

Da wir für Schalldruck-Messungen einen Analogschreiber im Einsatz hatten, bastelten wir diesen über D/A-Wandler an o.g. Bildschirm-Terminal; dazu erweiterte ich wiederum die in Assembler geschriebene „Firmware“ des Terminals (u.a. Zeichengenerator) und programmierte diverse Routinen für den Kleinrechner.

Aufgrund guter Erfahrungen bauten wir uns auf dem Mikrocomputersystem noch drei Erfassungsgeräte zusammen mit Lochbandperipherie. Das minimale Betriebssystem baute ich zu einem brauchbaren Erfassungssystem um. Das Ergebnis war nicht nur komfortabler, sondern auch deutlich preiswerter als die sonst üblichen Org-Automaten.

Einen weiteren K 1510 verwendeten wir für die Registratur der Zugänge zum Betrieb (Zeiterfassungs-System für „flexible Arbeitszeit“, die aus ideologischen Gründen nicht „Gleitzeit“ genannt werden durfte, der Begriff „Stechuhr“ war ebenfalls außerordentlich verpönt). Dieser Mikrocomputer übernahm das Auslesen der Lochkarten (Betriebsausweise) und das Abspeichern des Datensatzes mit der Uhrzeit; im Fehlerfall wurde eine Schranke über den Digital-Ausgang geschlossen. Die Daten wurden täglich auf Lochband gestanzt und im Kleinrechner ausgewertet. Ein großes Problem war die Erkennung der Personal-Nummer auf der Lochkarte. Die Löcher wurden an ihrer Flanke erkannt, ein Interrupt ausgelöst und per Programm zu dieser Nummer zusammengesetzt. Nun kommen natürlich mehrere Interrupts für eine Spalte zusammen, und zwar nicht immer in der selben Reihenfolge, auch beeinflusst das Zittern des Benutzers die Interrupts (wer den I 808 kennt, weiß um die bescheidene Interrupt-Behandlung). Um das in den Griff zu bekommen, stellte ich erst mal einige Wochen das Gerät an meinen Schreibtisch, und jeder, der mich besuchte, musste erst mal seine Karte einlesen. Damit ermittelte ich eine brauchbare softwaremäßige Entprellung. Zuvor musste jedoch erst mal die vom Hersteller bereitgestellte digitale Eingangskarte umgelötet werden.

Der 6. K 1510 wurde für mobile Datenauswertung (s.u.) eingesetzt. Dafür entwickelte ich zunächst eine Bibliothek für die Standard-Funktionen. Ein Kollege „übersetzte“ dann meine in ALGOL geschriebenen KRS-Programme in Maschinensprache.

Nach kurzer Zeit erzielten wir somit eine wesentlich komfortablere Rechner-Ausstattung als dies der Hersteller bereitstellen konnten. Daraufhin erhielten wir ziemlich oft Besuch zwecks Besichtigung unserer „Musterlösung“.

Links: http://www.robotrontechnik.de/index.htm?/html/computer/r4201.htm
http://www.robotrontechnik.de/html/computer/pbt4000.htm

Prozess-Analyse (um 1981)

Auch wenn immer wieder Versuche unternommen wurden, ist es eigentlich unmöglich, den Betrieb einer Glasschmelz-Anlage zu modellieren. Nicht nur das mathematische Modell an sich (z.B. Strömungsverhalten durch Wärmekonvektion in der Schmelzwanne als Teilaufgabe), sondern auch die stoffspezifischen Werte in nichtlinearer Abhängigkeit von der Temperatur, verbunden mit exo- und endothermen Stoffumwandlungen sowie das Zusammenspiel aller so schon komplexen Komponenten machen die Absicht zur Unmöglichkeit.

Wohl oder übel kann man sich der Modellierung nur über die Auswertung von Messdaten nähern, die aber brauchbare Aussagen nur für die jeweilige Anlage erlauben, sich aber nicht für Planung oder Dimensionierung eignen. Das ist aber besser als nichts, zumal derartig energieintensive Prozesse ein großes Einspar-Potenzial haben.

Wir tüftelten einen Messplan (Versuchsplan) aus, um den Einfluss der Temperaturen an den Brennern auf die Temperatur-Verteilung der Glasschmelze (Konvektions-Walzen) sowie die Temperatur des Abgases (Verlust) unter Berücksichtigung der Qualität zu ermitteln. Die Messtechnik war ohnehin vorhanden, wir benötigten noch eine Uhr (hat damals 20.000 DDR-Mark gekostet) und (noch teurere) A/D-Wandler sowie Lochbandstanzer.

Zunächst holten wir regelmäßig die Lochbänder aus der Lausitz nach Radebeul. Die Datensätze unterwarfen wir einer multiplen quasi-linearen Regressions-Rechnung, wofür ich das Programm schrieb. (Zur Erläuterung: es wurde für jeden abhängigen Wert eine Funktion y(x) = a0 + a1*x + a2*x² + … + an*x hoch n + b1*f1(x) + … bm*fm(x) gesucht, für die die Summe der Abweichungs-Quadrate minimal war.) Das war natürlich nur der Einstieg. Später haben wir auch ein nichtlineares Glied (wie z.B. c*e hoch (d*x)) eingefügt und diesen Parameter d über eine numerische Optimierung mit quadratischer Interpolation ermittelt. Als Letztes haben wir dann auch Größen mit einer Verzögerung in das Modell mit einbezogen, wobei auch hier die mutliple quasi-lineare Regression als Unterfunktion immer mitlief. Mir war bewusst, dass dieses Verfahrensweise keinen mathematischen Qualitätskriterien standhält, aber besser als gar keine Erkenntnisse! Selbstverständlich haben bei einem statistischen Modell-Ansatz bekannte physikalische Zusammenhänge den Vorrang und müssen bei der Regressions-Rechnung als erstes berücksichtigt werden!

In einem Fall konnten wir die Ergebnisse nicht verstehen – und siehe da, eine Messtelle war kaputt. Die Temperatur-Messung erfolgte übrigens mit Platin-Elementen, die nicht gerade billig sind.

Im Ergebnis fanden wir ein Anlagen-Regime, das bei besserer Qualität weniger Energie benötigte.

Aufgrund der guten Erfahrungen portierten wir den Kern des Programm-Komplexes auf Mikrocomputer K 1510, um die Auswertungen vor Ort vornehmen zu können.

SPS-Programmierung (um 1985)

Für die größte Glasschmelz-Anlage der DDR sollten wir die Automatisierung planen. Diese sollte zweistufig sein: Prozessrechner (verantwortlich war ein Institut in Jena) und speicherprogrammierbare Steuerung (PS 2000; das war unser Part). Der Umfang der SPS belief sich auf 11 voll bestückte Steuerungen, wovon 3 für die Gemengeaufbereitung und 8 für die Schmelze vorgesehen waren. Da wir überhaupt keine Erfahrungen mit SPS hatten, konsultierten wir die damals in der Anwendung führenden Kollegen der Papierfabrik Schwedt. Diese hatten als Erfahrungswert 6 Monate zur Programmierung einer zu einem Viertel belegten Steuerung, danach noch einige Wochen Testung und Fehlerbeseitigung. Wir hatten den 44-fachen Umfang zu bewältigen und dafür keine zwei Jahre Zeit. Fehler konnten wir uns keine leisten, denn ein Fehler konnte eine riesengroße Explosion (bei der benötigten Gasmenge) auslösen. Also mussten wir uns etwas einfallen lassen.

Die vorgesehene Programmierung in einer sehr primitiven Programmiersprache war viel zu aufwändig und natürlich sehr fehleranfällig. Hier setzten wir den ersten Hebel an und erfanden eine problemorientierte Programmiersprache, wo die Setzbedingungen über algebraische Gleichungen (unter Nutzung von verständlichen Namen) beschrieben wurden und die Rücksetzbedingungen automatisch erzeugt wurden. Das Ergebnis musste zwangsläufig formal widerspruchsfrei und lückenlos sein! Letztenendes wurden der Maschinencode automatisch erzeugt und gleich auf die EPROMS geschrieben auf einem PAPL (auf Basis K 1510).

In einem zweiten Teil wurde der Prozess modelliert unter Berücksichtigung der Eingangs- und Ausgangsvariablen der Steuerung – das ist bei einer binären Steuerung noch vergleichsweise einfach. Jede Änderung eines Ausgangswertes der Steuerung bewirkt eine Aktion des Prozesses, der nach einer bestimmten Zeit einen Eingangswert der Steuerung ändert (z.B. durch Erreichen einer Endlage oder einer Maximal-Temperatur etc.). Dies bewirkt wiederum eine Reaktion der Steuerung. Dazwischen gibt es natürlich noch jede Menge Störungen. Die beiden Modelle übersetzten wir (natürlich vollautomatisch) in zwei Computerprogramme. Unser ALGOL-Betriebssystem erlaubte ein minimales Mutlitasking: in 10 Sekunden-Zeitscheiben wurde zwischen zwei Programmen (incl. Betriebssystem-Zustand) umgeschaltet. Somit konnten wir die Steuerung gegen den Prozess simulieren. Der Ablauf wurde durch das angebastelte Terminal verfolgt, von dort konnte jederzeit unterbrochen werden zwecks Eingabe einer Störung, aber auch ein Ausdruck auf den Nadeldrucker angestoßen werden. Damit war die Erstellung der SPS-Programme völlig reduziert auf die verfahrenstechnische Seite ohne jeglichen Einfluss der Steuerungs-Problematik.

Die Dokumentation (grafisch als Zustandsdiagramme, Ein- und Ausgangslisten etc.) wurde vollautomatisch erzeugt.

Wir benötigten insgesamt weniger als 2 Jahre von der Aufgabenstellung bis zur Inbetriebnahme für alle 11 vollbepackten Steuerungen! Das System hatte sich auf Anhieb bewährt. Alle Steuerungen liefen sofort fehlerfrei. Die Dokumentation ist gut verständlich und wird mit Programmänderung automatisch aktualisiert. Programmänderungen im laufenden Betrieb sind mit wenig Risiko behaftet. Daraufhin haben wir unser System auch für andere Auftraggeber bzw. in Dienstleistung eingesetzt. Nach 1990 portierte ich die Programme auf den PC und eine andere Steuerung (ich glaube, es war die S 2000), wobei die Bedienung nochmals vereinfacht wurde.

Links: http://www.robotrontechnik.de/html/computer/ps2000.htm
http://www.robotrontechnik.de/html/computer/s2000.htm

Nettolohn-Programm (1980)

Mit der Ablösung des C 8205 durch den KRS 4201 benötigten wir auch ein neues Lohnprogramm. Was sich heute keiner mehr vorstellen kann: das erste Problem bestand in der Suche nach geeigneten Lohnschein-Vordrucken. Wir waren zwar mittlerweile mit der Zellstoff- und Papier-Industrie im selben Ministeriumsbereich, mussten aber dennoch an Papier sparen; wir brauchten jedes Blatt zur Ausfertigung der Projekt-Dokumentationen, die ja unser Endprodukt waren. Als diese Hürde geknackt war, ging ich an die Programmierung (d.h. zunächst Problemanalyse). Auch dieses Programm wurde von Anfang an in ALGOL 60 erstellt.

Das Programm enthielt einige Besonderheiten. So war es möglich, einen Vormonat rückzurechnen (Korrektur als Minus-Rechnung), Konstanten temporär zu überschreiben sowie Werte auch als Formeln einzugeben. (Zwischen den Variablen-Datensätzen durften auch ganze Stammdatensätze oder einzelne Felder eines Stammdatensatzes stehen; wurden in einer Zahl Operationszeichen oder Klammern entdeckt, wurde ein Formelinterpreter aufgerufen.)

Letztendlich verwies unsere bewährte Lohnbuchhalterin bei Fragen zur Lohnrechnung die Kollegen an mich.

1990 portierte ich das Ganze auf PCs unter MS-DOS unter Verwendung von Turbo-PASCAL und einiger verfügbarer Bibliotheken. Rechentechnisch lief das erwartungsgemäß, aber die Unsicherheit bezüglich der gesetzlichen Regeln (weder das Finanzamt noch die Krankenkassen konnten verbindliche Auskunft geben, wie unter welchen Umständen Lohn und Abzüge zu berechnen sind!) veranlasste mich, die Programme in die Tonne zu drücken. Mit einem teuren gekauften Programm ging es aber zum damaligen Zeitpunkt auch nicht besser!

Bibliotheken für den Mikrorechner K 1510 (1981)

Wie bereits beim C 8205 und beim KRS 4201 standen auch für U 808-basierende Mikrorechner-Systeme keine Compiler zur Verfügung. Speziell beim K 1510 (U 808-basierend) gab es nicht mal brauchbare Bibliotheken. Deswegen musste ich die in ALGOL üblichen Standard-Funktionen selbst programmieren, was mir auch ganz gut gelang (bzgl. Genauigkeit und Performance) und zu einigen „Nachnutzungen“ führte. Eine einfache Textverarbeitung (Editor) programmierte ich ebenfalls (diese wurde dann für die Datenerfassung verwendet). Auf dieser Basis waren wir in der Lage, vorhandene ALGOL-Programme vom KRS 4201 zu portieren; u.a. wurde die sehr flexible pseudo-lineare Regression incl. Formelinterpreter übertragen. Somit hatten wir auch für unsere Baustellen einen Rechner für die nötigsten Auswertungen.

Die bis dahin über ein Ascota-Erfassungsgerät (Ascota 170) erfolgte Datenerfassung verlagerten wir auch auf einen K 1510, nachdem ich Eingabe-Routinen mit Plausibilitäts-Prüfungen bereitgestellt hatte.

Weiterbildungsprogramm

Nachdem die ersten „Bürocomputer“ (8-bit-Personalcomputer, z.B. PC 1715; diese basierten übrigens auf dem U 880 wie Zilog Z 80) im Betrieb vorhanden waren, stellten wir diese auch für die Belegschaft zur Verfügung. Das setzte natürlich eine entsprechende Qualifikation voraus. Da wir selbst Neulinge auf diesem Gebiet waren, verpflichteten wir zunächst für die erste Lehrgangs-“Runde“ einen externen Kollegen von Robotron. Nachdem wir uns selbst (auch an anderer Stelle) ausreichend qualifiziert und informiert sowie die ersten Erfahrungen gesammelt hatten, führten wir bis 1990 Lehrgänge durch (zuletzt dann für 16-Bit-Computer A5100 etc.). Am Ende hatten fast alle Kollegen unserer 310-köpfigen Belegschaft (bis hin zu Pförtner und Reinigungskraft) mindestens einen Grundlagen-Lehrgang (Bedienung und wichtige Kommandos) und mehr als die Hälfte des ingenieurtechnischen Personals zusätzlich mindestens einen Lehrgang in Textverarbeitung, Tabellenkalkulation oder Datenbanken besucht. Viele Techniker verschiedener Fachbereiche und auch fremder Betriebe wurden auch in Programmierung (BASIC oder Turbo-PASCAL) geschult.

Nach der „Wende“ haben sich mehrere frühere Kollegen bei mir bedankt, weil ihnen der Umstieg auf PC-Technik keine Probleme bereitete.

Ich verrate wohl kein Geheimnis, dass die Textverarbeitung ein angepasstes Wordstar, Tabellenkalkulation Supercalc und Datenbank dBase II waren. Wir haben gleich die Originale verwendet (auch Original-Bücher), die waren immer ein wenig voraus. Lediglich das Betriebssystem DAC (von Dampferzeugerbau Berlin) war dem Original CP/M weit voraus, weil es u.a. auch die größeren Möglichkeiten der Z 80-CPU nutzte.

Baustellen-Überwachung (1999)

Eine Baustelle sollte überwacht werden, u.a. um den Baufortschritt zu dokumentatieren. Auf der Baustelle befand sich ein einfacher ISDN-Anschluß. Eine Axis-Webcam übermittelte zu vorgegebenen Zeiten Bilder per FTP auf einen Webserver. Dort waren die Bilder in die Homepage der Firma eingebunden.

Mit der vorhandenen Lösung konnte man bei entsprechenden Gegebenheiten auch Live-Bilder von der Kamera abrufen, dann wurde diese einfach als Webserver mit CGI-Erweiterungen genutzt. Ein Alarmanschluß ist ebenfalls vorhanden, damit ließen sich automatisch e-Mails absenden mit den letzten Bildern als Attachements.

Kopplung der NT-Netzwerke zweier Standorte einer Firma (1999)

Die Kopplung erfolgte mittels zweier Bintec-Router (XSO und XM PPPoE) über ISDN (Wählleitung).

Ein NT 4-Server fungiert als primärer Domänencontroller, der andere als Backup-Domänencontroller und Exchange-Server. Letzterer übernimmt die Aufgabe des DHCP- und DNS-Servers (mit einer garantiert nicht vorkommenden Domain *.intern).

Später wurde das System auf Windows 2000 / Exchange 2000 umgestellt.

Darüberhinaus gab es folgende Möglichkeiten:

Bei entsprechenden Voraussetzungen war eine Verbindung der beiden Firmenstandorte über VPN geplant (die Bintec-Router lassen sich mit der entsprechenden Software nachrüsten) sowie der Einsatz eines Citrix-Terminalservers.

Heterogenes Firmennetz mit Host-Anbindung (1999)

Das Firmennetzwerk bestand ursprünglich aus einem NetWare 3.12-Server, einer 10BaseT-Verkabelung und einer Glasfaserverbindung in ein benachbartes Gebäude. Im ersten Schritt wurde der Server geupdatet auf NetWare 4.11 sowie die Verkabelung u.a. um einen 24 Port 10/100 Switch von Bay Networks auf 100 Mb/s migriert. Weiterhin wurden gemeinsam Partnerfirmen verschiedene Host-Anbindungen (Rumba-Client, Gateway zu SAA über einen Wellfleet-Router einerseits und IBM Client Access mit einer auf DLC-Protokoll basierenden AVM/NOVELL ISDN-Router-Verbindung zum Host) realisiert. Das interne Netzwerk basiert zwar noch auf IPX/SPX, jedoch werden auch noch die Protokolle TCP/IP und DLC benötigt, was eine Herausforderung an die Konfiguration der PCs darstellt.

Zusätzlich wird noch ein NT-Server mit 40 GB Raid 5-Plattenkapazität betrieben sowie ein NT-Server für e-Mail und Fax (Tobit DAVID) und die Sammlung der Daten der Eingangskontrolleinrichtung.

CDs werden über einen CD-ROM-Server bereitgestellt, der von einem Microtest DiskZerver angetrieben wird und je nach Plattenkapazität mehr oder weniger viele CD-ROMs und DVD-ROMs cachen kann.

Die Verwaltung der Server erfolgt einheitlich über die NDS, die NT-Domäne ist mittels NDS for NT integriert.

Die Daten werden auf zwei MLR-Streamern der Fa. Tandberg gesichert. Zum Virenschutz wird Intel Virusprotect eingesetzt.


Letzte Änderung: 03.09.15