Cobol embedded SQL

[Fuerchau]

Tja, da haben wir es doch schon.
Der Precompiler geht sequentiell vor, d.h., dass Variablen VOR ihrer ersten Verwendung definiert werden müssen.

Wo ich mir nicht ganz so sicher bin, aber das kommt auf einen Versuch halt an, gehören SQL-Cursor-Deklarationen ggf. in die Procedure Division (ich habs jedenfalls immer so gehalten, diese vor dem Open zu deklarieren).

[Fuerchau]

Sorry, nicht genau gelesen:

B010KANST ist ohne Vorzeichen, dies wird bei SQL nicht unterstützt.

Definiere die Variable mit S9(01) !

[wolfinho]

Irgendwie scheint der Pre-Compiler sich Informationen über die DB2-Tabelle zu holen, aber wenn er diese Informationen nicht findet, scheint es auch zu funktionieren, da ich bei der umwandlung eines cobol-programmes mit db2-connect und einem zugriff auf eine fremde db2-tabelle nur folgenden hinweis bekomme:

SQL1103 Position 24 Spaltendefinitionen für Tabelle VADWX027 in T0V nicht gefunden.


Ich denke, das müßte dann so funktionieren.

Nochmals vielen Dank für Deine Hilfe.

Wolfinho

[Fuerchau]

Zur Umwandlungszeit benötigst du natürlich eine korrekt definierte Tabelle (war bei mir bisher zumindest so).

Mit embedded SQL gibts da allerdings noch einen Haken.

Zur Laufzeit musst du einen Connect zum Zielsystem durchführen.
Ein Programm kann jedoch nur 1 Verbindung aufrecht halten.
Machst du einen Connect, wird deine loakle DB disconnected, dann kannst du auf den Host zugreifen. Mittels "Connect reset" wird die Hostverbindung getrennt und wieder lokal verbunden.

Ja nach Datenvolumen verlangsamt dies drastisch die Laufzeit.
Zusätzlich funktioniert das Ganze gar nicht, wenn deine lokale DB unter Commit läuft.
Vor dem Connect zum Host musst du nämlich erst mal einen Commt/Rollback setzen, da sont der Connect fehlschlägt.

Lösung:
Du musst lokale und ferne Zugriff über 2 getrennte Programme UND Aktivierungsgruppen durchführen.
Hierzu eignet sich am besten dann SQLCBLLE, da du nur hier ACTGRP's angeben kannst.

Zwischen den Programmen kannst du dann per "CALL ... using" Daten austauschen.

2. Problem
SQLCBL erstellt intern SQLPKG's.
Um nun auf den Remote-Host zuzugreifen musst du das SQLPKG per CRTSQLPKG auf dem Zielhost erstellen.
Dies ist mit jeder Änderung des Programmes wieder erforderlich.
Unterstützt der Zielhost keine SQLPKG's kann das Programm nicht laufen.

Umgehung ist hier dann eine DDMF, die dann allerdings nicht mit SQL verarbeitet werden kann.

[wolfinho]

Hallo,

vielen Dank für Deine Ausführungen. Meine Vorstellungen gingen dahin, daß ich innerhalb des Programmes mit DB2-Connect die entfernte Datenbank auslese und diese dann über das Dateisystem auf die i5 schreibe. Da ja aber hinter jeder Datei auf der i5 sich eine DB2-Tabelle verbirgt, bin ich mir nicht sicher ob ich vor jedem schreiben ein connect reset absetzen muss. Eigentlich müssten doch die Dateien auf der i5 die Verbindung zu dem Programm noch haben, da der Connect doch nur die embedded-SQL-Statements betrifft, oder ?

Wenn meine Vorstellungen nicht ganz falsch sind, habe ich nur noch das Problem mit dem SQL-Package, welches ja auch auf dem entfernten System zur Verfügung stehen muss.

Ich hoffe ich liege nicht ganz falsch mit meinen Vorstellungen.

[Fuerchau]

Wenn ich das also richtig verstehe, greifst du auf lokale Tabellen nicht mit SQL zu ?
Wenn dem so ist, kannst du natürlich mit Connect zum Host verbinden und lokal mit Read/Write-Methoden arbeiten.
Arbeitest du allerdings auch lokal mit SQL kommst du um einen Connect Host/Connect Reset nicht herum oder du machst eben 2 Programme daraus.

Ob deine SQL's funktionieren, kannst du auch per STRSQL und Connect ausprobieren.

Per WRKRDBDIRE musst du nur die Zieldatenbank definieren.

Im CRTCBLSQL kannst du bereits mit RDB(Hostname) die Ziel-DB angeben, so dass deine SQL's gegen den Host geprüft werden und ggf. das SQLPKG direkt erstellt wird.

In der Quelle kannst du alternativ mit

set options rdb=Host

das Ziel angeben. Es gibt, wie immer, viele Wege zur Anwendung.

[wolfinho]

ich habe die Definition des Cursors jetzt einmal in die Procedure division in die section PGM-LOGIK SECTION. direkt vor dem open aufgenommen. bekomme aber leider noch den gleichen fehler.

dass der declare nach der definition stehen muss ist wohl richtig, aber ich glaube der cursor kann auch in der working-storage section definiert werden. so war es zumindet auf dem großrechner (zos), auf dem ich noch vor 9 monaten programmiert habe.

[wolfinho]

tatsächlich. es lag an dem vorzeichen. jetzt funktioniert es. Vielen vielen Dank für deine hilfe. ich wäre da nie drauf gekommen.

aber noch eine frage am rande, da wir planen über db2 connect auf entfernte systeme zuzugreifen. brauch der db2-precompiler eigentlich informationen der in den embedded sql verwendeten tabellen ?

[wolfinho]

Irgendwie scheint der Pre-Compiler sich Informationen über die DB2-Tabelle zu holen, aber wenn er diese Informationen nicht findet, scheint es auch zu funktionieren, da ich bei der umwandlung eines cobol-programmes mit db2-connect und einem zugriff auf eine fremde db2-tabelle nur folgenden hinweis bekomme:

SQL1103 Position 24 Spaltendefinitionen für Tabelle VADWX027 in T0V nicht gefunden.


Ich denke, das müßte dann so funktionieren.

Nochmals vielen Dank für Deine Hilfe.

Wolfinho