COBOL embedded 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]

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.

[nico1964]

Muss ich Dir wieder einmal vollkommen Recht geben. Bei uns scheitert es am nicht ausgeben wollenden Geld und aber vor allem an der Manpower(1,5 Pgmer). Was passiert wenn man Fremde ans Werk lässt, die keinen blassen Schimmer von der Anwendung haben und kaum Ahnung von AS/400 hat die Firma in den Jahren 2007 und 2008 bei der Umstellung von DKS auf SAP gesehen. Keinen Bedarf das nochmal zu erleben. Und zu diesem Zeipunkt waren wir noch 7 interne Programmierer.

[AS400.lehrling]

DKS - da dürften inzwischen wohl die pgmer aussterben die das noch aktuell halten, bzw in der Lage sind notwendige Neuerungen Einzupflegen.


Gruß Lehrling

[KingofKning]

Hallo,
an Hand Deiner Anleitung wollte ich die Konvertierung von Dezimal nach Hex in SQL erledigen.
Leider läuft das Teil auf Fehler und ich weis nicht warum

5722ST1 V5R4M0 060210 SQL-COBOL-Programm erstellen DOSBANK 25.12.14 12:10:54 Seite 2
Satz *...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 FLGNR. Letzte Änderung
55 EXEC SQL SET : SQL-WERT-X = CAST(HEX(WERT9) AS CHAR(4))
DIAGNOSENACHRICHTEN
SQL0104 30 55 Position 49 Token WERT9 ungültig. Gültige Token: :.

Für Hinweise dankbar.

GG

[B.Hauser]

WERT9 ist vermutlich eine Host-Variable (innerhalb des Souce Codes definiert) und muss deshalb mit einem führenden Doppelpunkt angegeben werden.

Birgitta

[B.Hauser]

gelöscht, da doppelt gepostet

Birgitta