COBOL embedded SQL

[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

[KingofKning]

Danke Dir für den Hinweis, werde ich morgen ausprobieren, lasse gerade ein rclstg auf der Kiste laufen.
Ich befürchte das ich morgen wieder in die Firma fahren muß da er nach dem rclstg ja wohl kein Subsystem startet um aus der Frene zuzugreifen.

GG

[KingofKning]

Hallo,
manchmal ist es zum Mäusemelken... BTW, war heute in der Firma um die AS/400 nach dem rclstg neu zu starten und habe festgestellt das mein Weihnachtsmann von einer Maus angeknabbert wurde...... Danke.

Aber zum Thema.

Folgende Deklaration habe ich:
EXEC SQL BEGIN DECLARE SECTION END-EXEC.
01 SQL-WERT-9 PIC 9(04).
01 SQL-WERT-X PIC X(04).
EXEC SQL END DECLARE SECTION END-EXEC.

Und folgenden Code will ich benutzen:

ST-04.
MOVE WERT-9 TO SQL-WERT-9.
EXEC SQL SET :SQL-WERT-X = CAST(HEX(:SQL-WERT-9) AS CHAR(04))
END-EXEC.
GO TO ST-88.

Und die Fehlermeldung lautet:
49 EXEC SQL SET :SQL-WERT-X = CAST(HEX(:SQL-WERT-9)
5722ST1 V5R4M0 060210 SQL-COBOL-Programm erstellen DOSBANK
DIAGNOSENACHRICHTEN
MSG ID WTK SATZ TEXT
SQL0312 30 49 Position 49 Variable SQL-WERT-9 nicht definiert oder
nicht verwendbar.

Für Hinweise dankbar.

GG

[KingofKning]

Tja, die allwissende Müllhalde hat ab und zu auch antworten parat.

Es muss wie folgt definiert werden:
01 SQL-WERT-9 PIC S9(07) COMP-3.

Dann klappt es auch.

GG

[Fuerchau]

Hier sind verschiedene Sachen vermischt.
PIC 9(04) kann nicht verwendet werden, da SQL aus irgendwelchen Gründen kein Unsigned mag.
PIC S9(04) währe gegangen.
Allerding liefert die Funktion HEX eine Zeichenkette doppelter Länge!
Ein CAST(... char(4)) führt zum Abschneiden, was ohne NULL-Anzeiger zu einem negativen SQL-Code führt. Mit Nullanzeiger entspricht dies eher einem LEFT(HEX(...), 4).
Ob du das gewollt hast?

Und das Ergebnis von HEX(: SQL-WERT-9) ist nun auch 8 Bytes lang.