SYSTEMKRITISCH.org

Puh. Ich bin mit dem Wareneingang einer Schnittstelle fertig geworden.

Konkret Bestellung aus ERP über WMS an Logistikdienstleister, Rückmeldung für das WMS mit der Anlage das externen Wareneingangs in unserem System, die tatsächliche Wareneingangsmeldung, erstellen von Ladungsträgern, Buchen der Bestände, Rückmeldung ans ERP. Insgesamt benötige ich für diesen Prozess 29 Tabellen. Zum Auslesen, Schreiben, Updaten, you name it.

Versteht mich nicht falsch: Die Arbeit macht, trotz Deadline, super viel Spaß und ist maximal herausfordernd. Auch weil bei 29 Tabellen regelmäßig irgendwelche Trigger Inserts/Updates verhindern. Oder Feldnamen in Tabelle A ungleich Feldnamen in Tabelle B bedeuten, obwohl sie identisch deklariert und namiert sind. Für 2025 fühlt sich das eine Nummer zu unflexibel an. Zu groß. Zu schwer. Zu langsam.

Eine Tabelle hat oft irgendwas zwischen 60 und 80 Felder. Da den Überblick zu behalten ist unmöglich ohne Hilfsmittel. 

Und vor allem ist das komplette Produkt undokumentiert. Ich bin ein bisschen stolz auf das, was mir da gelungen ist. Und beim nächsten Mal mache ich alles ganz anders :-)

Für das Schnittstellenprogramm in Java 8, das auf einer Kundenmaschine unter IBM i 7.4 läuft, habe ich einen ProgramCall für ein COBOL PGM eingebaut. Übergeben werden alle möglichen und unmöglichen Parameter, damit das sauber durchläuft.

Dann kam mir, dass ich theoretisch nicht auf den externen Dienstleister beim Test angewiesen bin, weil ich ja schon Daten erhalten habe. Also baue ich morgen ein Testprogramm, welches ich in der QSH via java -jar test.jar parameter1 parameter2 parameter3 aufrufe. 

    public static void main(String[] args) {

        System.out.println("Anzahl Parameter: " + args.length);

        for (int i = 0; i < args.length; i++) {

            System.out.println("Parameter " + i + ": " + args[i]);

        }

    }

Man erkennt das Prinzip, oder? Durchlauf für jeden Parameter, der übergeben wurde. Kein off-by-one-Fehler.

Jedenfalls bekomme ich so einen oder alle Testfälle durch und finde heraus, ob der eigentliche Call des COBOL PGMs funktioniert. Warum nochmal shippen wir COBOL nicht aufs plattformunabhängige(re) Java? Fangfrage.

Momentan bin ich wieder voll auf Kurs und wandere, dank meiner Habits, auf drei unterschiedlichen Lernpfaden. Parallel.

Für den Lebenslauf

Auf Interskill schließe ich gerade nach und nach das RPG-Modul ab und gehe dann die beiden Advanced Zertifikate an. Für die Badges zum vorzeigen auf LinkedIn und Xing.

Für meine berufliche Praxis

Auf Coursera habe ich den IBM IT-Projektmanager Kurs herausgedeutet, der mich - zusätzlich zum Wissensgewinn und den Badges - auf die CAPM-Zertifizierung vorbereitet.

Für das Herz

Ich habe so Bock auf den MERN-Stack, dass ich - bevor ich den React-Kurs durchlaufe - den Kurs von Maximilian Schwarzmüller zum Thema JavaScript grinde. JavaScript!? Keine Ahnung, was ich gegen JS hatte. Mir macht das richtig fun!

Wie ich nachhaltig, Schritt für Schritt, meine Ziele erreiche:

➡️ Initialisierung: Was muss sich am dringensten verändern in meinem Leben? Wie sehe ich mich in sechs Monaten? Wie sieht ein perfekter Tag aus? (Happiness Advantage) Was macht mich glücklich? Was macht mich überhaupt nicht glücklich?

➡️ Vision: Ich möchte...

➡️ Ziel: In {n} Monaten werde ich {z} (realistisches, messbares Ziel) erreicht haben.

➡️ Micro-Habit: Um mich meinem Ziel anzunähern, mache ich jeden Tag {x} und {y}.

➡️ Trigger: Jeden Tag nach Tätigkeit {y} (Feierabend, Abendroutine mit Kind, Küche aufräumen) mache ich {x}. Danach mache ich {y}.

➡️ Identität:
    "Ich bin dieser jemand, der {z} ist/lebt/macht."

➡️ System: Ich tracke jeden Tag in meinem Tagebuch via einfacher Checkbox, ob ich {x} und/oder {y} ausgeführt habe. In meinem täglichen Tagebuch ist gut lesbar zu beginn vermerkt, dass ich mein Ziel zum ... erreicht habe, wenn ich mich an mein System halte. 

Dort vermerke ich auch, was heute gut und was heute nicht so gut lief mit Blick auf meine Gewohnheit und was ich morgen besser/anders machen könnte (Anpassung des Auslösers, Anpassung der Tiefe)

Tipps:
- setze zu Beginn des Loops höchstens drei Micro-Habits um.
- duchhalten - auch wenn (noch) keine Veränderungen feststellbar sind
- Woche 1: Tracken ohne Wertung - Bei Umsetzungsproblemen: Was muss ich anpassen, damit ich die Micro-Habits umsetzen kann oder sind die gesetzten Ziele nicht von Bedeutung? (führt zu Neustart des Loops)
- Woche 2: Anpassen und durchhalten!
- Woche 3: Mehr Tiefe - Micro Habits anpassen / erweitern
- Woche 4: Was hat sich verändert? Was bleibt? Was stresst? Was funktioniert?

Motivation is what gets you started. Habit is what keeps you going. System is what carries it to the finish line.

Der CRONJOB des mutigen Entwicklers lautet "Work Job Schedule Entry". Hier können wiederkehrende Jobs angelegt werden - zeitlich gesteuert. Von täglich bis monatlich ist alles möglich. Wichtig ist nur das Learning, dass ich das Subsystem angebe, über das der Job gestartet werden soll. Wobei auch das kein riesen Problem wäre, wenn es ein "läuft einmal durch, Fehler werden ignoriert, gut ist"-Programm ist, welches gestartet werden soll. Ich habe auf einem Kundensystem jedoch leider einen solchen Job angelegt ohne Verweis auf ein bestimmtes Subsystem. Es wird ein Programm aufgerufen, dass alle 5 Minuten läuft. Sich also nicht beendet.

Und der lief in der QBATCH. Das Problem dabei ist, dass die QBATCH nur einen Job gleichzeitig erlaubt. Anders als andere *NOMAX Job Queues. Und als ich eine aktuallisierte Version einhängen wollte musste ich natürlich den Job beenden. Das hätte ich mal besser um 19 Uhr gemacht. So aber rückte die Systemsicherung nach, die in der Regel um 23 Uhr läuft und beendet kurzerhand für 1,5 Stunden den Regelbetrieb. Ab 10:30 Uhr morgens. 

Viel gelernt, passiert mir nie mehr. 

Gibt jetzt auch schlimmeres. Aber eben auch geileres morgens um halb 11 in Deutschland.