SQLRPGLE /V5R3: Eindeutige Variablen

[Karl23]

Hallo Forum,

ich habe ein Problem, daß erst bei der Umstellung auf V5R3 aufgetreten ist.
Ich mache in meinen Programmen intensiven Gebrauch von Prozeduren. Dabei verwende ich meist einheitliche Namen für Variablen.
Bisher war das auch kein Problem und die Module wurden klaglos kompiliert.

Jetzt erhalte ich eine Fehlermeldung der Wetigkeit 11. Diese besagt sinngemäß, daß die Variablennamen in SQL eindeutig sein müssen.
Die *SECLVL Info rät, entweder die Variablen umzubenennen oder mit einem Qualifikationsmerkmal zu versehen.

Dazu jetzt meine Fragen:

1. Kann ich das Problem durch Erhöhung der Abbruchsbewertung z.b. auf "15" umgehen ?

2. Was ist mit Qualifikationsmerkmal gemeint ?

Bin für jeden Hinweis mehr als dankbar !
Es sind eine Menge Programme und bei allen die Variablen umzutaufen würde eine elende Arbeit bedeuten.

LG
Karl

[Fuerchau]

Das Probelm ist der SQL-Precompiler, der nun mal alle Variablen einer Quelle als potentielle SQL-Variablen übernimmt.
Ich kann nun mal (leider) auch Variablen verwenden, die erst später definiert werden.
Zu 1: Durch Erhöhung der Abbruchbewertung kann ich sicherlich die Programmerstellung erzwingen, solange bei den SQL-Befehlen ausschließlich eindeutige Variablen verwendet werden.
Zu 2: Qualifikationsmerkmale sind nun mal auch Umbenennungen (z.B. Prefix) !

Lösung:
Die Prozeduren in eigene Quellen aufteilen, einzeln als Modul erstellen und später dann per CRTPGM das tatsächliche Programm erstellen.
Und/oder gemeinsame Prozeduren in Service-Programme verlegen.

[JustMe]

das scheint ein bug im Precompiler zu sein: APAR SE18182

[Karl23]

Hallo liebes Forum,

WOW !!! Das geht ja schneller als die Feuerwehr !

Vielen dank schon mal für die schon jetzt gegebenen Antworten. Der APAR Hinweis hat mir den heutigen Tag gerettet ! Es sind jede Menge Cum.Ptfs aufgespielt worden, aber mangels IPL noch nicht aktiv. Ein Fehler im Pre-Compiler war im Grunde auch mein erster Verdacht, da auf der Vorgängermaschine mit älterem Release niemals Probleme bei den fraglichen Programmen aufgetreten sind.

@Mod. Fuerchau:

Auch Ihnen meinen Dank für ihre Ausführungen .
Das von Ihnen geschilderte Vorgehen entspricht durchaus meinem Programmierstil.
Funktionen, die potentielle Kandidaten für Wiederverwendung sind, z.B. "GetDayofWeek" oder "SetNewPrice" werden bei mir in Serviceprogrammen zusammengefaßt und bei Bedarf angezogen.
Es gibt aber auch Fälle, die eigentlich nur für eine ganz konkrete Prolemstellung passen. Da tendiere ich dazu, die Funktion in dem jeweiligen Programm zu integrieren.
Dann gibt es auch noch Fälle, wo ich entgegen sonstiger Gepflogenheiten eine globale Variable aus einer Procedure heraus verändere.
Das ist nicht unbedingt schön, ich weiß, aber in manchen Fällen kann das Sinn machen.

LG
Karl

[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