COBOL embedded SQL

[nico1964]

Hallo Gemeinde,

hat jemand von euch vielleicht einen Tipp, wie ich am günstigsten und schellsten zu einem Crashkurs für obiges Thema kommen. Hier in Österreich schaut es diesbezüglich sehr sehr dunkel aus(so wie das heutige Wetter).
Für Tipps oder Anregungen wäre ich sehr dankbar.
LG

[B.Hauser]

Selber lernen oder Teilnahme an einem Kurs?
Embedded SQL-Kurse speziell für Cobol gibt es soweit ich weiß nicht. Auch IBM packt RPG und Cobol-Programmierer zusammen, da die (SQL-)Befehle und deren Verwendung in beiden Sprachen identisch ist. Nur die Einbindung ist etwas anders.
RPG: (Free Format)

 Exec SQL SQL-Befehl (auch über mehrere Zeilen) ;

(Klassishes Format)

C/EXEC SQL  ... SQL-Befehl
C+ SQL-Befehl Fortsetzung
C/END-EXEC

Cobol:

EXEC SQL SQL-Befehl auch über mehrere Zeilen END-EXEC.

... und in COBOL muss die SQLCA (Communications Area) explizit als INCLUDE eingebunden werden, während in RPG die Einbindung der SQL Precompiler übernimmt.

Ansonsten sollten natürlich sowohl RPG als auch COBOL-Programmier wissen wie Variablen und Datenstrukturen in ihrer Sprache definiert werden und wie in den entsprechenden Sprachen Schleifen, Ifs und sonstiges programmiert wird.

Zum Nachschlagen kannst Du dann die Online Library befragen:
Embedded SQL - Programming
In diesem Buch wird beschrieben, wie es in RPG, Cobol und C funktioniert.

Birgitta

[nico1964]

Guten Morgen Birgitta,

danke für die Infos, Kurs wäre mir selbstverständlich lieber, aber da spielen im Moment meine Vorgesetzten nicht ganz mit. D.h. ich werde mich wohl oder übel selber durchschlagen müssen und einfach mal ausprobieren ob ich das ganze selber hinbringe. Interaktives SQL verwende ich tag täglich und COBOL programmiere ich auf der AS400 seit 1989, also sollte das ganze ja irgendwie zu verheiraten sein.

Gruss aus dem Verregneten Wien
Andreas

[Fuerchau]

SQL in COBOL ist wirklich denkbar einfach:

Dateityp SQLCBL oder SQLCBLLE (ich bevorzuge letzteres).
Alle SQL-Anweisungen beginnen mit EXEC SQL und enden mit END-EXEC und werden erst ab Bereich B Spalte 12 bis Spalte 71 akzeptiert.
Im Gegensatz zu RPG muss ich SQL-Hostvariablen explizit deklarieren, also:

WORKING STORAGE SECTION.
: die üblichen Definitionen
:
:
EXEC SQL SET OPTION ....
END-EXEC.
EXEC SQL INCLUDE SQLCA <= Wie Birgitta schon sagte, muss explizit eingebunden werden.
END-EXEC.

EXEC SQL BEGIN DECLARE SECTION
END-EXEC.
77 ...
01 ....
EXEC SQL END DECLARE SECTION
END-EXEC.

Alles zwischen BEGIN und END kann als SQL-Hostvariablen verwendet werden.
DECLARE-Sections kann es durchaus mehrfach geben (WORKING-STORAGE, LINKAGE).

In der PROCEDURE DIVISION kannst du dann ganz normales SQL überall einbetten.

EXEC SQL DECLARE GETDATA CURSOR FOR
SELECT ...
WHERE FELD = : MYHOSTVAR OF STRUKTUR
AND FELD2 = "ABCD"
END-EXEC

Einzige Einschränkung die ich bisher gefunden habe:
Da COBOL per Default nur 18-Stellig dezimal kann (PROCESS EXTEND31 / EXTEND63) akzeptiert der SQL-Precompiler keine Hostvariablen größer 18 Stellen.
Sollten diese benötigt werden kann man diese nur als z.B. PIC X(31) und als CAST-Funktion verwenden.

COBOL akzeptiert Konstanten wahlweise in Hochkommata (Warnmeldung 10 oder PROZESS APOST) oder Anführungsstrichen.
COBOL-Embedded SQL akzeptiert Konstanten ausschließlich in Anführungsstrichen!
Werte in Hochkommata wird als casesensitiver Feldname interpretiert.

Merken tut man das fast ausschließlich zur Laufzeit!
Vor Einführung der Globalen Variablen meckerte der Compiler das Fehlen von Variablen an (in Tabelle nicht gefunden).
Seit Einführung dieser Variablen (V7R1?) geht der Precompiler nun davon aus, dass das ja später globale Variablen sein könnten. Tippfehler werden also erst zur Laufzeit bestraft.

Und der Rest ist dann halt einfach SQL.

[nico1964]

Vielen Dank Baldur für Deine ausführlichen Erklärungen. Des weiteren habe ich in einem älteren Beitrag einen leichten Stolperstein gefunden bezüglich numerischer Hostvariablen weil das war heute gleich mein erster Fehler.
Ich glaube, ich werde das schon schaffen und werde halt dann versuchen mehr SQL zu verwenden.
Leider ist unserer Anwendung schon so alt und verstaubt(Beginn der Programmierung 1989/1990), das ich mir schwer tue bestehende Logiken aufzubrechen. Ich würde das ganze nämlich auch gerne von native i-o auf sql umstellen, aber dazu fehlt mir leider die Zeit.

[Fuerchau]

Wie heißt es so schön: never Change...

Ich arbeite zur Zeit auch an einer gemischten COBOL-Anwendung. Im Gegensatz zu RPG (CVTRPGSRC erforderlich incl. aller Copy-Strecken) kann man sehr einfach von CBL auf CBLLE oder SQLCBLLE wechseln ohne an den Quellen was ändern zu müssen.
Daher kann man dann Schritt für Schritt neue Funktionalitäten in SQL einbauen.
Grundsätzliches Umschreiben empfiehlt sich da nicht, da handelt man sich gerade viele Fehler ein.

Da ich auch hier der Einzige bin, kann ich dann ganz neue Programme auch in SQLRPGLE schreiben. Das ist doch erheblich einfacher zu schreiben da COBOL nichts für Schreibfaule ist.

[nico1964]

Da mit never Change .... und so kenn ich auch. Ich habe nur das riesen Problem mit meinen DDS-beschriebenen Datenbanken. Die würde sooooooooooo gerne abschaffen.

Das andere mache jetzt eh auch mittlerweile, wobei ich tue mir in COBOL leichter, da meine RPG-Kenntnisse schon total eingerostet sind(so ungefähr vor 18 Jahren).

Und bei uns sind eigentliche schon fast alle Programme CBLLE bzw. CLLE.

[Fuerchau]

Immerhin hast du ja DDS-Beschriebene, es gibt aber gerade in COBOL noch die intern Beschriebenen.
Die behindern aber massiv den Einsatz von SQL.
Die DDS-Tabellen stellen für SQL ja überhaupt kein Problem dar.

[B.Hauser]

... never change!

Den Spruch kenn' ich leider auch und auch "Hauptsach' s' tut was es tun soll!".

Aber neulich habe ich in einem Blog von Jon Paris und Susan Gantner gelesen, dass die neue Mantra das folgende sein sollte:

No change, no change!

... ich denke diesen Spruch sollte man sich eher zu eigen machen.

Birgitta

[nico1964]

Immerhin hast du ja DDS-Beschriebene, es gibt aber gerade in COBOL noch die intern Beschriebenen.
Die behindern aber massiv den Einsatz von SQL.
Die DDS-Tabellen stellen für SQL ja überhaupt kein Problem dar.

JA das stimmt schon und wir haben da Gott sei Dank weniger Probleme, da ich die Programme im intern Beschriebenen wahrscheinlich an einer Hand abzählen kann.. ggg

[nico1964]

Guten Morgen,
ich glaub Dir schon das dieser Spruch schon eher der Wahrheit entspricht. Aber mach das Leuten klar, die sagen, das System ist eh schon so alt und es funktioniert so wie es funktioniert und wir wollen keinen Cent mehr investieren.

[Fuerchau]

Wenn man natürlich genug Geld und vor allem Manpower und Wissen zur Verfügung hat, ist das mit dem Reengineering natürlich überhaupt kein Problem.
Deshalb haben beide Sprüche durchaus ihre Berechtigung.
Bei "alter" Software scheitert es eben häufig an den obigen beiden Ressourcen. Und bevor man da so Fremde dranlässt oder die eigene knappe Manpower bindet bleibt nun jedem selbst überlassen.

Ich möchte nicht wissen, was SAP das Redesign bzw. die Neuentwicklung von R2 auf R3 gekostet hat. Nicht umsonst liegen die Lizenzen da so hoch.