SQLRPGLE /V5R3: Eindeutige Variablen

[BenderD]

Hallo,

es bleiben für mich eigentlich nur 2 Dinge:
- so defensiv arbeiten, wie nur irgend möglich (wobei mich dieser Pre Compiler Schwachsinn dennoch erreicht hat) - für embedded SQL heißt das, immer im Auge haben, dass das Ding OPM Stand hat. Also: nur globale Variablen verwenden, diese nur für das SQL Geschäft verwenden, keine Prefixe SQ nehmen, keine qualified DS verwenden; SQL Ressourcen immer eindeutig verwenden und aufräumen (bei V5R3 gibts auch Probleme mit impliziten Close Operationen. Bei dem angesprochenen Problem ist der Work around mit GENLVL 11 Risiko los, sollte man aber bei Programm Änderungen aufräumen.
Was das CL Problem angeht, das ist dokumentiert und wird vermieden, wenn man keine Literale verwendet, Commands helfen hier ebenfalls weiter und die Verwendung von Prototypen, wo immer möglich; Ersetzen von CL durch RPG mit APIs und system oder QCMDEXC ist hier ebenfalls sinnvoll.
- zweite Maßnahme ist absolute Kulanz gegenüber Kunden, solche Aufwände nehme ich immer auf meine Kappe, wenn sie denn anfallen sollten.
Dass solche Dinge vorkommen, ist die eine Sache, das wirkliche Ärgernis ist für mich, wie IBM damit umgeht.

mfg

Dieter Bender

Hallo Dieter Bender,

es freut mich, daß auch andere meine Sicht der Dinge teilen !
Die heile Welt gibt es nirgends und auch renommierten Anbietern wir IBM gelingt manches gut und manches weniger gut.
Aber Gags wie diese sind irgendwo Existenz bedrohend. Ich mag die Problemlage einem EDV-Leiter noch vermitteln können, aber bei einem kaufmännischen Leiter oder Firmeninhaber sieht die Sache schon ganz anders aus.
Wie soll ich so jemand vermitteln, daß zum einen ich keinen Fehler gemacht habe, und er zum anderen Geld ausgeben muß/soll ohne auch nur irgendeinen Gegenwert dafür zu erhalten ?

Bei der Komplexität heutiger IT ist es schlechterdings unmöglich ständig über sämtliche, potentielle Problemfelder auf dem Laufenden zu sein. Bei Scherzen wie diesen, gerät jeder Releasewechsel zum va banque Spiel.

In der guten, alten Zeit, als das Wünschen noch geholfen hat, da waren Themen wie Investitionsschutz und Abwärtskompatibilität heilige Kühe in Rochester. Die letzten Jahre scheint sich hier einiges verändert zu haben.

Das erste Mal richtig auf die Fresse gefallen bin ich bei einer Änderung im Bereich CL Variablen.
Das ist zwar schon eine Weile her, aber aus meiner Sicht immer noch leicht schwachsinnig.
Daß eine Variable in der Länge 1024 Schwupp die Wubb mit irgendwelchen Hauptspeichermühl bis an' s Ende aufgefüllt wird, ist für mich ein ähnlicher Dummfug wie das Precompiler-Thema.
Die Variable um 1 zu verlängern und ein Zeichen an der letzten Stelle zu plazieren mag ja das Problem lösen, aber um welchen Preis ?
Wer zahlt mir die Beseitigung von Problemen, die vorher keine waren und überflüssig sind wie ein Kropf ?

LG
Karl

[Fuerchau]

Was soll eigentlich das gekloppe ?
Wenn man einige Grundregeln einhält, kommt man auf solche Fehler gar nicht (ich muss mich da immer wieder wundern, dabei bin ich gar nicht so diszpliniert).

Was das CL-Problem angeht, so ist das nun mal bekannt, dass eben der CMD-CALL die Übergaben von Zeichen-Variablen in der angegebenen Länge bzw. mind. 32 Stellen macht. Wenn man das weiß, passiert eben nix.

Aber wie heißt es da doch so schön:
Wozu gibts eigentlich (unternehmensspezifisch) Programmierrichtlinien die solche Probleme (s.o.) normalerweise ausschliessen ?!

[BenderD]

@Baldur:

soweit das CL und die 32 Stellen (und die 15 5) angeht habe ich alle Probleme mit Commands vermieden, aber was SQL angeht, da geht seit V5R3 verstärkt der Punk ab, da sind einige Sachen implizit geändert worden, so die Reaktion auf Variablen, die mit unterschiedlichem Scope und gleichem Namen deklariert worden sind und das implizite schließen von Cursorn - neben einigen Bugs, die mit wechselnden PTF Ständen ein- und ausgebaut worden sind und in dieser Situation ist das Getöse über die tollen Verbesserungen absolut ärgerlich. Das knallt nur deshalb relativ selten, weill in den meisten Programmen so wie 1870 programmiert wird mit Rekord Löffel Exzess - ich will garnicht erst anfangen mit Ooops Nerv, das ist einfach nur peinlich, wenn man bei Kunden mit so einem Murks arbeiten muss, wo SQL Statements drin sind, die nicht funktionieren und die man dann per Hand korrigieren muss, damit es funzt... die Oracle Fraktion lacht sich schief, wenn sie sowas sieht und der Verweis auf ein Service Pack, das das behebt - naja.
Ich bleibe dabei: DB2/400 muss sich jede Mühe geben, wenn es als Datenbankserver Konkurrenz Fähigkeit weiter unter Beweis stellen will!!!

mfg

Dieter

Was soll eigentlich das gekloppe ?
Wenn man einige Grundregeln einhält, kommt man auf solche Fehler gar nicht (ich muss mich da immer wieder wundern, dabei bin ich gar nicht so diszpliniert).

Was das CL-Problem angeht, so ist das nun mal bekannt, dass eben der CMD-CALL die Übergaben von Zeichen-Variablen in der angegebenen Länge bzw. mind. 32 Stellen macht. Wenn man das weiß, passiert eben nix.

Aber wie heißt es da doch so schön:
Wozu gibts eigentlich (unternehmensspezifisch) Programmierrichtlinien die solche Probleme (s.o.) normalerweise ausschliessen ?!

[Karl23]

Hallo Mod Fuechau,

was das Gekloppe soll ?
Nun, wenn wir in einer idealen Welt lebten, dann hätte ich in der Tat keine Probleme.
Nur ist es leider in den seltensten Fällen so, daß ich Software neu entwickle. Der sehr viel häufigere Fall ist das Pflegen und ggf. modifizieren alter, bestehender Anwendungen. Hier schaut die Sachlage ganz anders aus.

Ein großer, renommierter Kunde den wir betreut haben, hatte in seinen Eigenentwicklungen, die sich im Lauf von über 10 Jahren ergeben haben, vergessen, die Mandantenfähigkeit zu berücksichtigen. Unsere Aufgabe war es, eben diese zu realisieren.
Können Sie sich in etwa den Aufwand vorstellen den alleine der CL-Scherz verursacht hat ?
Das war nicht meine Software, aber das ändert nichts.
Aber ich frage mal anders rum: Ist Ihnen irgendeine andere Spache bekannt, in der Sie einen 1024 stelligen String declarieren, diesen explizit leeren und im Ergebnis dann keine leeren String, sondern einen zugemüllten String vorfinden ?
Was soll ich davon halten, daß auf einer nagelneuen i-series mit letzen Cum.PTF installiert, der Befehl STRDBG mit einem MCH6401 in' s Nirvana abrauscht ?
Den unerquicklichen Zustand rund um den SQL-Precompiler hat ja Dieter Bender schon sehr gut beleuchtet, von daher spar ich mir die Wiederholung.

Ich war und bin ein wirklicher Fan der AS/400 respektive i-series. Ich kenne das System ebenso wie ihren Vorgänger /38 seit Markteinführung in Deutschland. Diese Systeme waren solide und verläßlich wie ein Panzer. Nach mehreren Exkursionen in die Win-Welt ist mir das immer wieder sehr bewußt geworden.
Das was mir in letzter Zeit hier so begegnet ist wenig erfreulich.
Es ist sicher jedermanns ganz persönliche Meinung und die sei auch jedem unbenommen.
Ich bleibe dabei:
Was auf einem Vorgänger-Release sauber und fehlerfrei läuft und mir nach einem Releasewechsel um die Ohren fliegt, oder mich zu erheblichen manuellen Änderungen nötigt, das kann und werde ich als schlechte Lösung ansehen.

LG
Karl

[BenderD]

Hallo,

Können Sie sich in etwa den Aufwand vorstellen den alleine der CL-Scherz verursacht hat ?
Das war nicht meine Software, aber das ändert nichts.
Aber ich frage mal anders rum: Ist Ihnen irgendeine andere Spache bekannt, in der Sie einen 1024 stelligen String declarieren, diesen explizit leeren und im Ergebnis dann keine leeren String, sondern einen zugemüllten String vorfinden ?

Karl

dieser Effekt ist weder CL, noch überhaupt Sprachbezogen. Hier kommen mehrere Dinge zusammen:
- der gesamte Call Mechanismus von OS/400 basiert auf Call by Reference, sprich es werden Pointer auf Speicher übergeben - Parameter sind also immer im aufrufenden Kontext mit Speicher hinterlegt.
- ein OS/400 Pointer ist immer untypisiert, er weiß also nicht auf was er zeigt.
- Der OS/400 Command Call legt für Literale, die als Parameter übergeben werden Variablen an und übergibt deren Adresse als Pointer an das aufgerufene Programm; numerisch 15 5, alfa mit 32 Byte und nur dann länger, wenn das erkennbar und erforderlich ist, deshalb der Effekt beim verlängern und anfügen eines beliebigen Zeichens.

In der klassischen Denke waren eigene Commands als die Objekte gedacht, mit denen man Parameter Schnittstellen beschreiben kann. In der ILE Denke hat man hierfür Prototypen vorgesehen und verlagert dann die Prüfungen in die Compile Time und zusätzlich bekommt man die Möglichkeit mit der Angabe von VALUE dne stabileren Call by Value - sprich die Übergabe von Werten statt Adressen zu verwenden. Im engeren Sinne wird diese Art der Übergabe allerdings nur simuliert.
Mehr als am Rande sei bemerkt, dass die "zusätzlichen" Bytes am Schluss k e i n Garbage sind, sondern Speicher im aufrufenden Programm, sprich man kann Variablen überklopfen, die nicht übergeben wurden und früher konnte man sogar im Codesegment rummalen, und Programme, die im Call Stack weit tiefer lagen, abschießen; mittlerweile wird das leidlich überwacht.
Hier sollte sich defensives Vorgehen schon lange rumgesprochen haben und hat Probleme immer vermieden:

- Konstanten oder Variablen statt Literale verwenden (gilt übrigens auch für eval)
- automatisch angelegte Variablen generell vermeiden (gilt besonders für eval), das vermeidet auch Rundungsprobleme
- auf genaueste Übereinstimmung der Deklarationen von Schnittstellen Variablen achten.

Was den Vergleich von RPG und CL mit anderen Sprachen angeht: beide sind unverantwortlich lax und prüfen viel zu wenig, dafür unsinniges Zeug (siehe Pre-Compiler), da ist Java ungleich penibler und kooperativer zugleich - nur hier ist die Lage (mit Ile) eher besser als schlechter geworden.

mfg

Dieter Bender

[Karl23]

Hallo Dieter Bender,

vielen Dank für die ausführliche und kompetente Erläuterung des Sachverhalts. Bin zwar auch schon lange im Geschäft, aber wie man sieht, kann man immer noch dazu lernen.
Der Sachverhalt mit den Pointern war mir klar, aber nicht so tief im Detail. Daher nochmals meinen Dank.

LG
Karl

[Fuerchau]

Da kann ich Dieter eben nur zustimmen !

Leider beschäftigen sich viele Programmierer manchmal viel zu wenig mit der Technik der Dinge (was leider erforderlich ist).
Seit V2 ist das Call-By-Reference-Problem mir persönlich bekannt und deshalb vermeide ich es eben. Andere Systeme sind da übrigens auch nicht besser: Siehe insbesonders Windoof mit seinen permanenten Pufferüberschreibungen, daraus resultierenden Attacken und Patches.

Was die Stabilität der Releases angeht, so muss ich dem zustimmen. Mein frühester Einsatz eines neuen Releases ist selten vor 12 Monaten nach der offiziellen Einführung.
Sicherlich bin ich damit nicht auf der Höhe der Zeit, aber wie oben beschrieben, was brauche eine alte Software für ein neues Release.
Und damit bin ich dann auch schon auf der (etwas) sichereren Seite, da diese ganzen "Kinderkrankheiten" zu über 90% beseitigt sind. Und somit halten sich meine Probleme halt etwas stärker in Grenzen.

RPG und CLP entsprechen da eben auch der laxen Handhabe von C. Selbst mit C++ bin ich noch weit davon entfernt "sichere" Progamme zu schreiben (wie oft habe ich schon undefinierte Abstürze, wenigstens bleibt XP meist am Rennen).

Naja, und Java...... (man lernt noch).

[BenderD]

Sorry Baldur,

ich muss nochmal klopfen.
Die AS400 war nur deshalb eine Insel der Glückseligkeit, solange die echten Killer Applikationen auf anderen Büchsen liefen. Ich sage nur WebSphere auf AS400, da sehnt man sich nach einer Windows Büchse (oder Tomcat auf Linux )) ).
Ich würde ja gar nicht so drauf rumklopfen, wenn das nicht langsam einreißen würde und wenn IBM zuweilen etwas mehr Asche auf das eigene Haupt streuen würde - ich habe erst kürzlich wieder eine V5R3 Möhre mit einem Dump abrauchen sehen (ohne jeden WebsFear) und an Jobs, die man nicht mehr canceln kann, gewöhnt man sich ja fast und ich finde die AS400 Community sollte sich da ruhig deutlicher gegenüber der IBM positionieren, das kann nur helfen.

mfg

Dieter Bender

PS: Und mit dem C: C Pointer wissen im allgemeienen auf was sie zeigen und Strings sind üblicherweise Null terminated. In C muss man also Dinge aktiv aushebeln, die man in RPG kaum abstellen kann.

Siehe insbesonders Windoof mit seinen permanenten Pufferüberschreibungen, daraus resultierenden Attacken und Patches.

RPG und CLP entsprechen da eben auch der laxen Handhabe von C. Selbst mit C++ bin ich noch weit davon entfernt "sichere" Progamme zu schreiben (wie oft habe ich schon undefinierte Abstürze, wenigstens bleibt XP meist am Rennen).

Naja, und Java...... (man lernt noch).

[holgerscherer]

Die AS400 war nur deshalb eine Insel der Glückseligkeit, solange die echten Killer Applikationen auf anderen Büchsen liefen. Ich sage nur WebSphere auf AS400, da sehnt man sich nach einer Windows Büchse (oder Tomcat auf Linux )) ).

Dieter, mir ist grade danach und ich hake mich mal bei Dir ein (wie letztens am Kaffeetisch) und heule mit.

Ich bin inzwischen soweit, von V5R3 wieder abzuraten; das ist in einigen Bereichen echt unzuverlässig, es hat etwas mit Ratespiel zu tun. Ich habe erst neulich wieder gesehen, was IBM mit SQL treibt, das von einem WebSphere (auf ner W2K-Workstation) kommt. Da steht eine sauteure 820er (ok, 4 Jahre alt, und nur 370CPW, aber dafür hat man mal echt gblutet), und das Teil überlegt minutenlang, was der SQL-Command überhaupt bedeuten soll.

Andere Kunden, die Windows-Software entwickeln und gerne die AS/400-Datenbank verwenden wollen, fragen sich, warum eine "damals teure" 170er fast stehnbleibt, wenn ein SQL-Command kommt, bei der ein zwei Jahre alter Aldi-PC sich langweilt; bei 50 Usern. Hier hat IBM echt ein POWER-Problem, und in dem Bereich kann man die Apfel-Leute verstehen.

Ich würde ja gar nicht so drauf rumklopfen, wenn das nicht langsam einreißen würde und wenn IBM zuweilen etwas mehr Asche auf das eigene Haupt streuen würde - ich habe erst kürzlich wieder eine V5R3 Möhre mit einem Dump abrauchen sehen (ohne jeden WebsFear) und an Jobs, die man nicht mehr canceln kann, gewöhnt man sich ja fast und ich finde die AS400 Community sollte sich da ruhig deutlicher gegenüber der IBM positionieren, das kann nur helfen.

Dafür haben wir doch unseren Kaffeekranz, habe ich mir mal sagen lassen. Aber die entsprechenden IBMer trauen sich ja auch nicht mehr hin, wenn man sie mal auf ein konstruktives Streitgespräch einlädt. Und leider (bin grade am Einladen für den AWK) ist das Interesse der Anwender auch sehr eingeschlafen; die interessieren sich eher für eine Migration weg von der teuren schwarzen Kiste. Ich selbst entwickle meine Software und alles drumherum explizit für mindestens V5R1; das war noch ein stabiles Release, hat leider Wissenslücken im SQL-Bereich, aber ist inzwischen überall zu finden.

Und wenn wir schon dabei sind und über die Software meckern; wer von Euch hat sich mal so eine 520er genau angeschaut und etwas "getriezt"? Da ist ja der DELL-PC meiner Frau stabiler und hat nicht ständig gelbe Augen.

-h

[holgerscherer]

Die AS400 war nur deshalb eine Insel der Glückseligkeit, solange die echten Killer Applikationen auf anderen Büchsen liefen. Ich sage nur WebSphere auf AS400, da sehnt man sich nach einer Windows Büchse (oder Tomcat auf Linux )) ).

Dieter, mir ist grade danach und ich hake mich mal bei Dir ein (wie letztens am Kaffeetisch) und heule mit.

Ich bin inzwischen soweit, von V5R3 wieder abzuraten; das ist in einigen Bereichen echt unzuverlässig, es hat etwas mit Ratespiel zu tun. Ich habe erst neulich wieder gesehen, was IBM mit SQL treibt, das von einem WebSphere (auf ner W2K-Workstation) kommt. Da steht eine sauteure 820er (ok, 4 Jahre alt, und nur 370CPW, aber dafür hat man mal echt gblutet), und das Teil überlegt minutenlang, was der SQL-Command überhaupt bedeuten soll.

Andere Kunden, die Windows-Software entwickeln und gerne die AS/400-Datenbank verwenden wollen, fragen sich, warum eine "damals teure" 170er fast stehnbleibt, wenn ein SQL-Command kommt, bei der ein zwei Jahre alter Aldi-PC sich langweilt; bei 50 Usern. Hier hat IBM echt ein POWER-Problem, und in dem Bereich kann man die Apfel-Leute verstehen.

Ich würde ja gar nicht so drauf rumklopfen, wenn das nicht langsam einreißen würde und wenn IBM zuweilen etwas mehr Asche auf das eigene Haupt streuen würde - ich habe erst kürzlich wieder eine V5R3 Möhre mit einem Dump abrauchen sehen (ohne jeden WebsFear) und an Jobs, die man nicht mehr canceln kann, gewöhnt man sich ja fast und ich finde die AS400 Community sollte sich da ruhig deutlicher gegenüber der IBM positionieren, das kann nur helfen.

Dafür haben wir doch unseren Kaffeekranz, habe ich mir mal sagen lassen. Aber die entsprechenden IBMer trauen sich ja auch nicht mehr hin, wenn man sie mal auf ein konstruktives Streitgespräch einlädt. Und leider (bin grade am Einladen für den AWK) ist das Interesse der Anwender auch sehr eingeschlafen; die interessieren sich eher für eine Migration weg von der teuren schwarzen Kiste. Ich selbst entwickle meine Software und alles drumherum explizit für mindestens V5R1; das war noch ein stabiles Release, hat leider Wissenslücken im SQL-Bereich, aber ist inzwischen überall zu finden.

Und wenn wir schon dabei sind und über die Software meckern; wer von Euch hat sich mal so eine 520er genau angeschaut und etwas "getriezt"? Da ist ja der DELL-PC meiner Frau stabiler und hat nicht ständig gelbe Augen.

Das hat alles etwas von "Gefrickele". Übrigens wie die Boardsoftware hier, die will nicht richtig mit Mozilla; aber *das* ist ein anderes Thema...

-h

[Fuerchau]

Nun ja, da gilt dann halt der Spruch:

"Wer zu allen Seiten offen ist, der kann nicht ganz dicht sein !"

Sicherlich verwende ich diesen ganzen Kram (WebSphere usw.) auf der AS/400 nicht, deshalb bin ich auch sehr zufrieden mit der "Kiste".
Auch wenn die Software mit 5250 Greenschreen nicht mehr auf der Höhe der Zeit scheint, so können, zumindest meine Kunden, behaupten, dass die Transaktionskosten mit 5250 erheblich niedriger sind (bis Faktor 50), als mit ClientServer-Technologie.

Mit der ganzen PC-Anbindung, die zugegegeben auch erforderlich ist, stehe ich auch immer wieder auf Kriegsfuß. Was bei dem einen PC läuft, klappt beim nächsten, mitunter sogar "identischen" PC dann nicht mehr (MS-ADO, Office, CA-ServicePack, Windows-Patch oder sonst was).

Die Patches und Versionen der vorliegenden PC's (W2K, WNT, XPSP1, XPSP2, Terminalserver, Citrix usw.) sind kaum noch nachzuvollziehen und man steht wirklich wie der Ochs vor'm Berg, warum das denn gerade da nicht läuft.
Allein die Wartung der PC's bindet im Unternehmen 10x mehr Kapazität als die Wartung bzw. Pflege der AS/400 (siehe Problem: warum piepst mein PC bei 5250-Emu nicht?, oder bei Holgers Mozilla).

Packe ich immer mehr auf die AS/400, wie Linux, Notes usw. muss ich halt auch auf der AS/400 mit identischen Problemen kämpfen wie in der PC-Welt. Habe ich nur 1 AS/400, die alle möglichen Komponenten enthält, sind die Probleme eben verschärft.
Da kann die PC-Fraktion ruhig behaupten, dass diese "stabliler" liefen, dafür habe ich aber auch dann mehrere Server und wenn da mal einer hängt, naja dann wird der eben gebootet und dann gehts schon wieder.

Und was die Performance angeht, so bin ich auch da mit der AS/400 sehr zufrieden. Per SQL-Analyse stelle ich eben die meisten Engpässe ab und meine SQL-Programme sind dann auch schnell. Wenn mir eine Abfrage mit Group und Subselect's aus 12.000.000 Sätzen innerhalb von 2 Minuten als Ergebnis 2.100.000 Sätze liefert (bei gleichzeitig ca. 2.500 Job's auf dem System) finde ich das schon in Ordnung. Mein PC (3 GHz schafft das nicht).

Aber was solls, man muss eben wissen was man tut