Die Mainframes
Als ich zum LKV kam, stand im Zentrum des Geschehens in dem gemeinsamen Rechenzentrum von MKV und Kammer eine IBM 4331. Eine Bandstation und ein Lochkartenleser/stanzer waren neben der Console die wichtigsten Module. Die ebenfalls vorhandene Plattenstation, die bereits KSDS (Key Sequential DataSet) unterstützte hatte seinen Einzug in den Alltag des RZ noch nicht gefunden. Wenn einer der Programmierer ein Programm testen wollte, wurde der Operator von seinem Consolenplatz verscheut und seine Arbeit kam zum Erliegen. Programme mußten oft immer wieder getestet werden, weil viele Fehler erst während der Produktion auffielen. Ich würde sagen: RPG sei Dank. RPG war ein Reportgenerator von IBM und in unserem Rechenzentrum gab es damals nur eine Programmiersprache, die genutzt wurde. Selbst die Zuzchtwertschätzung, ein damals noch recht einfacher Mutter-Töchter-Vergleich lief mit RPG. 99 Anzeiger wurden zur Programmsteuerung verwendet. Für komplexe Programme mußten Anzeiger mehrfach verwendet werden. Das war einfach eine fehleranfällige Katastrophe, die die Programme auch noch schwer interpretierbar und lesbar machte. Mit dem BLUP-Modell, das wir zusammen mit der Universität Bonn einführten, zog schon mal Fortan als zweite Programmiersprache ein. Aber bis ca. 1985 habe ich auch einige Programme in RPG II entwickelt. Eine Futtermittelberechnung für unsere Landwirte fand so großen Anklang, dass eine Kollegin damit etliche 1000 Futterempfehlung pro Jahr produzierte. Obwohl wir, bzw. die Landwirtschaftskammer die LUFA-Analysen im RZ verarbeitete, und diese Daten faktisch nebenan schlummerten, hat die Landwirtschaftskammer uns - trotz eingeholter Einwilligung der Landwirte - den Zugriff verweigert, da sie unser Programm als Konkurrenz ansah. Mein Vorschlag einer Zusammenarbeit in der Fütterungsberatung wurde abgelehnt.
Als ich im RZ zu arbeiten begann, wurde so programmiert, dass alle Daten von Band zu Band geschaufelt wurden und die Aufgaben wurden in vielen nacheinanderfolgenden Steps durchgeführt. Z.B das täglich zu absolvierte MLP-Programm beinhaltete 30 Steps mit bis zu 50 Bandausgaben, von denen einige über Wochen gesichert wurden. Und wenn die Bandstation besetzt war, konnte kein anderes Programm laufen, obwohl die IBM 4331 multitaskingfähig, die Platten eine flexible Speicherung mit KSDS unterstützten. Immer wieder standen Leute aus Labor,Abteilungen und Kammer und warteten, dass ihre Programme endlich starten konnten und sie mit ihrer Arbeit weitermachen konnten. Ich sehe da immer Dich Ewald vor der Bandstation stehen, wenn ich mich erinnere.
Mangelndes Know How war der einzige Grund für diesen Zustand. Auch organisatorisch war das ein einziges Disaster. Chaos im Rechenzentrum war so vorprogrammiert.
Aber schon einfache Abläufe in der MLP-Bearbeitung waren eine Katastrophe. Mußte bsw. ein Laborergebnis überprüft werden, war es notwendig, mühsam im Labor einen mit einem Gummiring zusammengerollter Papierstreifen gesucht werden und mühsam ausgezählt werden, wo sich die Probe befand. Zum Glück hatte ich Unterstützung von einer taffen jungen Frau -Maria Ewigmann- aus dem Labor. Ich hatte meinem Chef, Dr. Teschner und der Geschäftsleitung vorgeschlagen, sie dort einzusetzen, um Ordnung in die Abläufe zu bringen. Dank ihres Einsatzes wurde das MLP-Büro ein hervorragend organisierter Zentralisationspunkt der MLP-Verarbeitung und auch mit meiner Unterstützung- endlich Struktur in die Abläufe gebracht.
Alles dramatisch, aber das Dramatischte waren Lochkartenstanzer und -leser zu dieser Zeit. OMR-Lochkarten mit den Untersuchungsdaten der Kühe - von den Kontrollassistenten nach dem Betriebsbesuch gestrichelt- wurden zusammen mit den Proben aus ganz Westfalen-Lippe herbeigekarrt und dann eingelesen. Wenn die Karten klamm vor Kälte oder Feuchtigkeit waren, brachen die Programmläufe häufig ab und es musste von vorne begonnen werden.
Gleich in meinem ersten Jahr hatte ich das Vergnügen am 23.12 gegen 18:00 Uhr diese Arbeit zu übernehmen. Die Transporte kamen wegen der Wetterverhältnisse spät und die Karten klebten aneinander. Es war zum Verzweifeln. Schon der erste , umfangreichste Lauf, der notwendig war, damit die Leute im Labor die Proben untersuchen konnten, brach mindestens 5 mal ab. Alle wollten endlich ihre Arbeit verrichten und nach Hause. Keine Chance, bevor ich nicht diese vermaledeiten Karten bezwungen hatte. Immer wieder kam Rolf Evers, der Laborleiter, herein und fragte nach dem Fortschritt. Gegen 22:00 Uhr war ich dann mit dem ersten Lauf durch und die Laboranten konnten endlich arbeiten. Danach gab es weitere Abbrüche, aber es wartete keiner mehr auf meine Daten.
Ich konnte mich mit diesem Zustand schlecht abfinden und der Behauptung unseres RPG-Gurus, es ginge nicht anders, konnte ich keinen Glauben schenken. Also habe ich recherchiert und mir die Programmiersprache PL/1 angeschaut. Wenn ich mich reccht entsinne, koste die Anschaffung von PL/I für die IBM pro Jahr 17000 DM, die sich aber schnell bezahlt gemacht haben. Damit habe ich alles umgeschrieben, was mir unter die Finger kam. Mit neu eingestellten Programmierern zusammen, haben wir dann mit mehr Power an besseren Lösungen gearbeitet. Unter der Nutzung von KSDS (Key sequentiell Data Set) und PL/1 habe ich z.B. erreicht, dass man die tägliche MLP bei mAbstürzen wegen Lochkartenproblemen immer wieder aufsetzen konnte und alle Aufgaben in einem Programmlauf erledigt wurden statt in 30 und die Daten datenbankähnlich (weitgehend normalisiert) für die weitere flexible Nutzung gespeichert werden konnten. Wir haben also keine starren Datenformate verwendet, in denen die Daten in einem Block - versehen mit vielen Redundanzen, gespeichert wurden. So fand das Jonglieren mit den Bändern - zumindest für die tägliche Verarbeitung ein Ende.
Geärgert hatte mich auch die Begrenzung der Lochkarten auf 80 Spalten. Das war eine Grenze, die für bestimmte Arbeiten der Kontrollassistenten unbefriedigend war. Auch da bot PL/1 mit dem Column Binary-Verfahren Abhilfe. Jetzt konnten zumindest einige Spalten mit mehreren Feldern belegt werden. Bis wir die Lochkarten endgültig aus dem RZ verbannen konnten, hat es aber noch etliche Jahre gedauert.
Heftig war auch der MLP-Jahresabschluß unter RPG. Auch das war eine reine Bandlösung und lief nach dem oben geschilderten Muster. Und wenn etwas schief lief und Landwirte gegen die Ergebnisse protestierten, konnte es erst zum nächsten Jahresabschluss korrigiert werden. Und da kam meine Nähmaschine ins Spiel. Nähmaschine, so nannten meine Kollegen meinen neuen tragbaren CP/M-Rechner Osborne 1, den ich mir bei Eintritt beim LKV gekauft hatte. Mit diesem Rechner und Supercalc hatte ich ein Programm entwickelt, mit dem der Jahresabschluss für einzelne Betriebe on the fly korrigiert werden konnte. Ein bischen ärgerlich daran war, dass ich damit gezwungen war, auch die Datenerfassung zu übernehmen. Nun ja. Zumindest mussten die Landwirte kein Jahr mehr auf einen korrigierten Jahresabschluß warten. Und die Mühe hat mich dafür sensibilisiert in Supercalc, Excel und Co. nur Hilfswerkzeuge zu sehen, die für professionelle Programmierung nur zur nachrangigen Aufbereitung gebraucht werden konnten. Privat habe ich etwas später meinen Osborne durch einen PROF 80 mit Grip1-Grafikkarte ersetzt. Grafikprogrammierung war damit schon ein besonderes Erlebnis. Insgesamt war der Prof 80 ein leistungsfähigerer Computer, für den Heise die Baupläne und Platinen lieferte. Ich habe mir da einen fertig gelötetes Exemplar gekauft, aber leider stürzte er wegen Wärmeproblemen nach ein paar Stunden durchgehender Arbeit immer wieder ab. Wenn ich dann manchmal etliche Stunden entwickelt hatte , ohne zu sichern, war das frustrierend. So wurde mein nächster Rechner ein Atari ST, kein PC. Atari und Mac waren trotz des Siegeszuges der IBM-PCs in vielerlei Hinsicht weit überlegen.
In den nächsten Jahren habe ich viel Arbeit in die Neuorganisation der Abläufe im Rechenzentrum gesteckt und wir haben etliche Programme mit PL/1 neu entwickelt. Aber die Pflege des MLP-Jahresabschlußprogramms und die Zuchtwertschätzung blieben lange in der Verantwortung meines damaligen Chefs. Band zu Band, Lauf nach Lauf.