SQL umwandlun

[andreaspr@aon.at]

Probier mal beim Umwandeln den Parameter
RPG-Vorprozessoroptionen . . . . RPGPPOPT > *LVL2

[BenderD]

... ich tippe mal darauf, dass die fehelende Variable mit falschem Scope (lokal) generiert worden ist. Was sagt denn die Umwandlungsliste?

D*B

[Robi]

@TheDevil
Im HauptPgm ist kein SQL_0* definiert (worden)
Aber das Pgm hat eine Procedur, die auch SQL verwendet.
dort sind (im Spool) die variablen SQL_00010 bis 00017 definiert
1 bis 10 ist nicht definiert, verwendet wird auch nur 0, 3, 5, 6, 7 und 9 die alle als 7030er Fehler auftauchen

@Dieter
Was meinst du? hilft o.a. Beschreibung

@Andreas
mach ich, dauert aber ein wenig. Das ist bei uns alles in 'automatiken' verdrahtet die ich dann händisch
zusammen suchen muß.

[BenderD]

gibt es nun irgendwo die Variable SQL_00003 oder nicht???

[Robi]

Alle SQL_ Variablen des obrigen Codes sind lt. Spool NICHT definiert.
Auch nicht in der Source durch uns. Sie fehlen!

[BenderD]

... wie wandelst du denn? ich mache da z.B.:
CRTSQLRPGI T_TN
OBJTYPE(*MODULE)
DBGVIEW(*SOURCE)
COMMIT(*CS)
RDB(*LOCAL)
CRTPGM T_TN
ACTGRP(T_TN)
und habe die vom Precompiler generierten Variablen in der Umwandlungsliste. Bei dir sind da sicherlich ein paar lokal gelandet. Mach mal irgendein SQL Statement in den main Teil dann funzt das.

[B.Hauser]

Das Problem tritt manchmal auf, wenn keine globalen D-Bestimmungen im Quellcode vorhanden sind.
Füge einfach eine Dummy globale D-Bestimmung ein und wandle nochmal um. (D in Position 6 sollte genügen, ansonsten füge einfach eine globale Variable ein)
Dann sollten alle SQL_ Variablen vorhanden sein.

Birgitta

[Robi]

@Dieter
CRTSQLRPGI OBJ(&OBJLIB/&MBR) SRCFILE(&LIBRPG/&FILE) +
OBJTYPE(*MODULE) TGTRLS(&TGTRLS) ist der Befehl,

&TGTRLS ist allerdings V5R4M0 (das hab ich per debug auf V7R1M0 gestellt, ohne erfolg)

cmddft's sind
RDB(*LOCAL)
DBGVIEW(*SOURCE)
Commit(*none)

Ich bekomme kein Modul

@Birgitta
leider nicht, das Pgm hat einige Globale D Bestimmungen.

@Andreas
mit geändertem

rpgppopt(*LVl2)

hat es geklapt.

kannst du das erklären?
Danke an alle, Robi

[andreaspr@aon.at]

Das Problem hab ich auch schon öfters gehabt, dass wenn z.B. Copy-Strecken oder Proceduren mit SQL verwendet werden, der Pre-Kompiler dies nicht richtig erkennt.
Mit *LVL2 wird alles brav aufgelöst und korrekt umgewandelt.

lg Andreas

[BenderD]

... bei deinem Umwandlungsbefehl bekomme ich auch die vom Precompiler generierten Variablen in die Umwandlungsliste des RPG Compilers?!?!?!

Das Problem des Precompilers ist die lausige Qualität, der will globale Variablen generieren, findet aber zuweilen die richtige Stelle nicht und generiert diese in die erste Procedure. Damit sind sie dann lokal und werden in anderen Procedures nicht gefunden. Dass das dann mit einer damit nichts zutun habenden Compile Option geheilt wird, ist wohl ein weiterer Schmutzefekt, der den anderen aufhebt.

D*B

[B.Hauser]

@Robi

RPGPPOPT *LVL2 löst alle Copy-Strecken auf!
Das deutet daraufhin, dass zu zwar globale D-Bestimmungen hattest, aber diese in Copy-Strecken versteckt.
Wie gesagt einfach eine LEERE D-Bestimmung vor dem 1. C oder P-Statement uns schon klappts.

Birgitta

[Robi]

@Birgitta
Ich weis das du meistens recht hast. Hier aber leider nicht.
Das Pgm hat diverse /copy und auch diverse 'solo' D-Zeilen (global)

Fals es noch jemand interesiert: Das Pgm ist über 5 Jahre alt und wurde vor einigen Tagen zum 12 mal erweitert. Es gab NIE Umwandlungsprobleme. Nur jetzt, warsch. durch irgend eine PTF-Aktion ausgelöst. Alles im PGM im bereich SQL ist 'alter' Kram
Robi