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