SQLRPGLE /V5R3: Eindeutige Variablen

[Karl23]

Hallo Forum,

nach einigen Gesprächen mit einem durchaus netten und kompetenten Mitarbeiter aus dem Hause IBM ist die Sachlage klar.
Es läuft auf die von Moderator Fuerchau beschrieben Variante hinaus.
Es wurden zahreiche "Verschärfungen" im Zuge des neuen Releases in Bereich des SQL-Precompilers eingeführt. Viele davon wurden aufgrund massiver Proteste diverser Kunden wieder zurückgenommen.
Der jetzige Stand führt aber dennoch zu dem unerfreulichen Umstand, daß der Pre-Compiler nicht in der Lage ist, vernünftig mit der Sichtbarkeit von Variablen in Prozeduren umzugehen.

Wird also, wie in einem meiner Programme, eine Variable &ArtikelNr: 7S,0 definiert und wird in einer anderen Prozedur dieselbe Variable als Bestandteil einer DS definiert, dann fängt der Pre-Compiler zu motzen an.

Im Ergebnis heißt das, daß sämtliche SQLRPGLE Programme geprüft und ggf. modifiziert werden müssen.
Meine persönliche Meinung dazu möchte ich noch loswerden:
Es ist ein eher schlechter Witz, was hier abgeliefert wird. Es kann ja wohl nicht angehen, daß Programme die bisher mit 0 Fehlern anstandslos kompiliert wurden jetzt nicht mehr ohne Fehler umzuwandeln sind.
Zum einen ist sowas vielen Kunden nur sehr schwer zu vermitteln und es bleibt letzlich ein übler Nachgeschmack an mir hängen, zum andren kann ich ja schlecht hellsehen. Was ich heute kodiere kann bei solcher Vorgehensweise schon morgen pflegebedürftige Makulatur sein.
Abwärtskompatibilität war stets ein Testament in diesem Umfeld und auch eine echte Stärke.
So ist es denn irgendwo der blanke Hohn, daß ich uralte /32 oder /34 Relikte noch klaglos kompilieren und einsetzen kann, mir aber andrerseits relativ neue Dinge um die Ohren fliegen.

Frustrierte Grüße
Karl

[Fuerchau]

Dem kann ich nicht so ganz zustimmen !
Was die Eindeutigkeit der Variablen für den SQL-Precompiler angeht, so sollte man sowieso grundsätzlich dafür sorgen.
Dieser kommt ja auch z.B. nicht mit der neuen Funktion "qualified" bei DS zurecht. Auch diese Variablen werden dann als doppelt erkannt.

Und was die Prozeduren angeht, sollte man sich auch überlegen, diese in separate Module zu verlegen, damit sie nicht jedesmal wieder mit umgewandelt werden.

Ggf. kann man sich dann ein BNDDIR anlegen um das fertige Programm dann anzulegen.

Alternativ hilft auch das kleine Tool von Dieter Bender.

[Xanas]

Also ich verwende Qualified DS beim SQL Fetch.

D Datenstrukturname E DS Extname(Dateiname)

.
.
.

C/exec sql
c+ Fetch Cursor into : Datenstrukturname
c/end-exec

[Fuerchau]

Deine Struktur ist NICHT qualified !
Jedes Feld der DS ist einzeln ansprechbar.

Aber versuch das mal:
D Datenstrukturname E DS Extname(Dateiname) QUALIFIED

Jedes Feld muss nun mit "Datenstrukturname.Feldname" benannt werden.

[Xanas]

Ja richtig das hatte ich oben vergessen, aber im Programm hab ich die DS Qualified angegeben.

D Datenstrukturname E DS Qualified Extname(Dateiname)

Sorry kleiner vertippser.

[Karl23]

Hello Mod. Fuerchau,

ich darf mich nochmal für die Hilfe zu diesem Problem bedanken !
Was die Beurteilung des Sachverhalts anlangt werden wir vermutlich nicht auf einen Nenner kommen - ist ja aber auch nicht weiters schlimm.

Ich halte den Precompiler für eine suboptimale Lösung, wenn er mit den Gegebenheiten in RPGLE nicht zu Potte kommt.
Durch Prozeduren ist endlich die Möglichkeit gegeben mit lokalen Variablen zu arbeiten und dann unterstützt der Precompiler dieses feature nicht.
Sorry, aber ich halte das für schwach.

Die Lösung alles in Module bzw. Serviceprogramme auszulagern ist formal durchaus überzeugend und plausibel. Von einer Java-Denke ausgehend ist es sicher der richtige Ansatz alles in separate, kleine Classes, in unserem Fall Module auszulagern.
Aus der Praxis heraus denke ich aber, daß dieser weg oft nicht in letzter Konsequenz durchgehalten werden kann.
Wie gesagt : Meine Meinung ! Wir müssen da nicht zusammenkommen.

Gruß
Karl

P.S.: Daß ehedem fehlerfrei zu kompilierende Quellen quasi über Nacht zu fehlerhaften Quellen werden, halte ich immer noch für einen Witz.
Ein Ansatz wie die "deprecated classes" wäre erschiene mir hier weitaus angebrachter.

[BenderD]

Hallo,

ich stimme den Einschätzungen bezüglich des Pre Compilers völlig zu: das Ding ist eine Frechheit. Wenn ich den Quatsch mit /end-free C/EXEC-SQL und den C+ Lochkarten schon sehe, das kann doch nicht so schwer sein das ordentlich zu machen und V5R3 setzt dem ganzen die Krone auf: nach jedem PTF fliegen andere Quellen aus dem Fenster und dann noch Hohn und Spott von IBM:
http://www.itjungle.com/fhg/fhg071404-story01.html

mfg

Dieter Bender

Hello Mod. Fuerchau,

ich darf mich nochmal für die Hilfe zu diesem Problem bedanken !
Was die Beurteilung des Sachverhalts anlangt werden wir vermutlich nicht auf einen Nenner kommen - ist ja aber auch nicht weiters schlimm.

Ich halte den Precompiler für eine suboptimale Lösung, wenn er mit den Gegebenheiten in RPGLE nicht zu Potte kommt.
Durch Prozeduren ist endlich die Möglichkeit gegeben mit lokalen Variablen zu arbeiten und dann unterstützt der Precompiler dieses feature nicht.
Sorry, aber ich halte das für schwach.

Die Lösung alles in Module bzw. Serviceprogramme auszulagern ist formal durchaus überzeugend und plausibel. Von einer Java-Denke ausgehend ist es sicher der richtige Ansatz alles in separate, kleine Classes, in unserem Fall Module auszulagern.
Aus der Praxis heraus denke ich aber, daß dieser weg oft nicht in letzter Konsequenz durchgehalten werden kann.
Wie gesagt : Meine Meinung ! Wir müssen da nicht zusammenkommen.

Gruß
Karl

P.S.: Daß ehedem fehlerfrei zu kompilierende Quellen quasi über Nacht zu fehlerhaften Quellen werden, halte ich immer noch für einen Witz.
Ein Ansatz wie die "deprecated classes" wäre erschiene mir hier weitaus angebrachter.

[Karl23]

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

[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