View Full Version : SQLRPGLE /V5R3: Eindeutige Variablen
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
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.
das scheint ein bug im Precompiler zu sein: APAR SE18182
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
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
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.
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
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.
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. :eek:
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.