EDV – Ende der Vernunft

Datensatzanzahlermittlung unter DB2/OS400

Ermittlung der Anzahl aktiver Datensätze einer physischen oder logischen
Datei einer DB2 unter OS400.

Mit SQL geht das ganze zwar auch recht einfach:

SELECT COUNT(*) FROM LIB.FILE

hat jedoch den Nachteil dass die Datenbank dann wirklich die Datensätze einmal durchzählen muss (jedenfalls schlussfolgere ich das der Laufzeit entsprechend)

Ein kleines CL welches sich die API QUSRMBRD (Retrieve Member Description) zu Nutze macht, kann dies in sehr kurzer Zeit erledigen. (API Beispiel in ILE RPG)

             PGM        PARM(&LIB &FILE &RCDCNT)
             DCL        VAR(&LIB) TYPE(*CHAR) LEN(10)
             DCL        VAR(&FILE) TYPE(*CHAR) LEN(10)
             DCL        VAR(&QUALFILE) TYPE(*CHAR) LEN(20)
             DCL        VAR(&RCDCNT) TYPE(*DEC) LEN(9 0)
             DCL        VAR(&FDATA) TYPE(*CHAR) LEN(736)
             DCL        VAR(&FDATALEN) TYPE(*CHAR) LEN(4) +
                        VALUE(X'000002E0')
             DCL        VAR(&ERRORDS) TYPE(*CHAR) LEN(16) +
                        VALUE(X'00000000')
             CHGVAR     VAR(&QUALFILE) VALUE(&FILE *CAT &LIB)
             CALL       PGM(QUSRMBRD) PARM(  +
                            &FDATA           +
                            &FDATALEN        +
                            'MBRD0200'       +
                            &QUALFILE        +
                            *FIRST           +
                            '0'              +
                           &ERRORDS)
             CHGVAR     VAR(&RCDCNT) VALUE(%BIN(&FDATA 253 4))
             ENDPGM

Die API wird für das übergebene File aufgerufen und die Informationen in FDATA übertragen. Die Datensatzanzahl steht in Stelle 253-256, Binär in 4 Bytes.

Das CL steht nur als Beispiel, es funktioniert zwar, jedoch sind keinerlei Fehlerabfragen implementiert.

Continue reading...

McServer

Irgendwie hab ich geahnt, dass IBM sich so langsam von einer Grosskantine mit 3 festen Menüs in einen Fast Food Laden verwandelt, doch nun hab ich sogar einen handfesten Beweis, gefunden in dem JobLog des Management Central Servers:

Continue reading...

Früher war alles besser

Ich bin zwar erst 28, aber jeden Tag möchte ich doch lieber ein Stück von Früher zurückhaben.

- Die netten Frauen am Telefon sollen sich mit “Marktforschungsinstitut” melden, nicht mit “Research Center”
- IT Consultants sollen sich wieder EDV Berater nennen.
- CIO’s sollen wieder EDV Leiter heissen
- und selbst ein Software Developer darf sich wieder Programmierer nennen.

Aber sie tun immer noch das gleiche wie vorher auch. Aber das scheint modern (sorry: trendy) zu sein. Selbst IBM hat in ihrem Umbenennungseifer einfach mal den Namen des Midrange Systems iSeries in i5 (Ausgesprochen: Eif Eif) geändert, obwohl sich in der Architektur nichts geändert hat. Das System hatte ja nun schon viele Namen: S/36, S/38, AS400 (kurz auch AS400e), iSeries(ein eServer) und nun noch i5, was IBMs Werbestrategen (sorry: Marketing) damit bezweckt scheint so seltsam wie Feenstaub zu sein.

Continue reading...

Updatefreuden

Da kommt Freude auf, bei uns läuft gerade das Roll-out (Achtung neudeutsch -> nd.) der neuen Windows XP Clients(nd.) und erfahrungsgemäss passieren Dinge von denen man nicht mal ahnte dass es sie geben könnte.

Mit einem Hotfix(nd.) Q812937 hat Microsoft ihr OS so gepatcht (nd.), dass auf dem QDLS (Document Library System) von der iSeries über die Netzwerkfreigabe keine Dateien mehr gelöscht werden können. Eine Lösung wird es nicht geben, denn mit diesem Patch hat Microsoft eine neue Vorgehensweise eingeführt, mit der Dateien gelöscht werden, die in Zukunft auch so beibehalten wird.

IBM wird dieses Problem auch nicht beheben, eine Umstellung von QDLS auf das root-Filessystem der iSeries ist natürlich eine Alternative, jedoch “mal eben so umstellen” ist leider nicht.

Als Lösung wird angeboten, man könne doch den Hotfix deinstallieren… was natürlich wieder zur Folge haben wird, dass andere Storagelösungen Probleme verursachen können.
Eigenlich mag ich schwarzen Humor.

Continue reading...

Java auf der iSeries

Einfach mal Zusammengetragen:

Um herauszufinden welche Versionen man auf der iSeries installiert hat:

Im OS/400:

GO LICPGM

Auwahl 10 – Installierte Lizenzprogramme anzeigen

Die Java Versionen sind die Lizenzprogramme:

5722JV1 *BASE -> Developer Kit Basis
5722JV1 3     -> Java Developer Kit 1.2
5722JV1 5     -> Java Developer Kit 1.3
5722JV1 6     -> Java Developer Kit 1.4

Es können mehrere parallel installiert sein.

Um die Systemweite Default-Version einzusehen und auch zu ändern, gibt es eine Datei namens SystemDefault.properties, welche sich in /QIBM/UserData/Java400 befindet.
Einige Java-Programme werden über Shell-Scripte gestartet (z.B. Jakarta Tomcat), welche zusätzlich den Pfad von Java als Umgebungsvariable(JAVA_HOME) benötigen.
Systemweite Umgebungsvariablen ändert man mit

WRKENVVAR LEVEL(*SYS)

Jobweit dementsprechend mit

WRKENVVAR LEVEL(*JOB)

Dort sollte es einen Eintrag geben (je nach Verwendungszweck Systemweit oder nur für den aktuellen Job), der der jeweils benutzten Java Version entspricht:
bei 1.4 wäre das:

Name                        Wert
JAVA_HOME                   '/QIBM/ProdData/Java400/jdk14'

Um Native an die Version zu gelangen:
im OS/400:

STRQSH CMD('java -version')

Ausgabe (z.B.):

Java-Version "1.3.1"

Dazu die Java Toolbox, die alle Tools enthält um auf iSeries Daten zuzugreifen:

5722JC1 *BASE -> Toolbox for Java

Alternativ zu 5722JC1 kann man auch JT Open benutzen, ein Open Source Projekt von IBM,
welches die gleichen Funktionen besitzt wie die Toolbox des Lizenzprogrammes. Der Unterschied besteht lt. Aussage von IBM darin, dass man den Vorteil hat, schneller an aktuellere Versionen und Patche zu gelangen als man das über das Lizenzprogramm bekommen könnte. Ich gehe davon aus, dass die Codebasis die gleiche ist. Zudem hat das Lizenzprogramm eine jt400Native.jar (funktioniert nur lokal auf der iSeries), die performanter ist als die generische jt400.jar (geht übers Netzwerk).

Continue reading...

Java in RPG

Seit einigen Tagen nun bin ich dabei, das POI-Projekt von Apache Jakarta für unsere Excel Exporte aus der iSeries zu nutzen. Da ILE RPG nun die Sprache ist in der wir entwickeln und diese(+Vorgänger) darin erfassten Programme nun teilweise seit über 20 Jahren ihren zuverlässigen Dienst verrichten, liegt es Nahe, die Java-Funktionen über JNI in RPG zu nutzen.
Nun kommen mir jedoch Zweifel ob dies der richtige Weg ist. Java hat die Technologie die man heutzutage braucht, RPG auf der iSeries die Stabilität und die Erfahrung der Programmierer. Was ist nun der richtige Weg?
Nur Java oder RPG und Java gemischt über JNI?
Ich werde erst einmal den zweiten der Wege gehen, da in meiner Abteilung 60 Jahre RPG Know-How gegenüber 6 Monate Java Kenntnisse da stehen.

Ich hoffe, dass Zusammenspiel dieser beiden Sprachen wird kein Unglück über mich bringen, auf jeden Fall werde ich diese Entwicklung mit Argusaugen betrachten.

Continue reading...