Cobol embedded SQL

[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.