Cobol Compilererror

[nico1964]

Die Depending-Variante ist sowieso nur sinnvoll, wenn man den Search-Befehl verwendet um Tabellen zu durchsuchen, da AT END halt am Ende der Tabelle aufhört.
Der Speicherbereich muss sowieso vorgehalten werden und ist nicht dynamisch.

So was in der Art soll es werden, nur halt nicht ganz so einfach und trivial, d.h. ich werde weiter forschen, wie in den letzten 2 Jahren dauernd, da ja plötzlich unsere i5 doch wieder an Ansehen gewonnen hat und jetzt die ganzen neuartigen Spielereien eingebaut werden müssen, um unsere Prozesse im BackOffice bestmöglich zu unterstützen(z. B. Abfragen von Webservices für WorkFlow's)

[Fuerchau]

Was forscht du denn da so?
Und warum muss es COBOL sein?
ILERPG ist da inzwischen wesentlich komfortabler.
Auch die Verwendung von SQL ist manchmal nicht zu verachten.

[Pikachu]

Es geht wohl um dieses COBOL-XML-Beispiel von IBM.

[nico1964]

Es geht wohl um dieses COBOL-XML-Beispiel von IBM.

JA aber nur als denkanstoss und schauen, was wir daraus machen können, wir sind ja mittlerweile kreative Dinosaurier geworden(verwenden RTC/RDp, HTTPAPI, einiges an SQL statt COBOL bei Neuanwendungen.)

[nico1964]

Na ja es geht um unsere liebe alte, unfelxible aber doch perfekt gebaute Anwendung im BackOffice, wo schon die verschiedensten Vorgänger des EDV-Leiters versucht haben, diese COBOL-GreenScreen Applikation durch was neues, modernes, flexibles zu ersetzen. Bisher sind alle an der Funktionalität gescheitert, da dies ein seit dem Jahr 1990 immer weiterentwickeltes Expertensystem ist, welches mittlerweile auch schon mit WebServices (HTTPAPI) spricht. Für diesen Aufruf verwende ich auch Cobol und das funktioniert ganz gut. Nun kommen immer mehr Anforderungen, XML und der ganze neue Spaß und bisher hat es immer geheißen, das wir auf der i-series nie benötigt werden, aber wie es die Zeit so mit sich bringt, werden doch einige Dinge ganz einfach durch den Geschäftsprozess definiert(SEPA statt V3 im Zahlungsverkehrt).
Und da ich an der Logik der Prozesse und Programmabläufe nicht viel ändern will, versuche ich das ganze aus den COBOL-PGM's heraus.

[KingofKning]

Was forscht du denn da so?
Und warum muss es COBOL sein?
ILERPG ist da inzwischen wesentlich komfortabler.
Auch die Verwendung von SQL ist manchmal nicht zu verachten.

Weil Cobol einfach lesbarer ist als RPG (wenn es nicht gerade free-rpg ist)

GG

[Fuerchau]

Nunja, COBOL war schon immer mehr was für Romanschreiber, z.B.:

COBOL:

write mydsp [from DSPFMT-O] format is "DSPFMT"
read mydsp [into DSPFMT-I] format is "DSPFMT"
[move corr DSPFMT-I to DSPFMT-O]

ILE/RPG

EXFMT DSPFMT

Da gibt es sicherlich noch eine Vielzahl ähnlicher Beispiele.

[Pikachu]

Ich sag nur: READE

[KingofKning]

Nunja, COBOL war schon immer mehr was für Romanschreiber, z.B.:

COBOL:

write mydsp [from DSPFMT-O] format is "DSPFMT"
read mydsp [into DSPFMT-I] format is "DSPFMT"
[move corr DSPFMT-I to DSPFMT-O]

ILE/RPG

EXFMT DSPFMT

Da gibt es sicherlich noch eine Vielzahl ähnlicher Beispiele.

Kann man so machen, muß man aber nicht.

00064 PERFORM Z0150-F-ND
00065 PERFORM Z0150-F-CL
00066 PERFORM Z0150-F-OO
00067 IF NOT DATEI-OK
00068 PERFORM Z0150-F-ER
00069 GO TO ST-99
00070 END-IF.

Hier wird eine neuer Dateiname vergeben, die Datei geschlossen und zum Schreiben geöffnet und beim Fehler eine Fehlerroutine angesprungen.
Machen wir seit 20 Jahren so das wir alles in Module ausgelagert haben.

Aber Du bist halt Fan von RPG ich nicht. Lassen wir es wie es ist...

GG

Und warum der blöde Editor hier immer alle Leerzeichen löscht versteh ich auch nicht...

[Pikachu]

Und warum der blöde Editor hier immer alle Leerzeichen löscht versteh ich auch nicht...

Das liegt nicht am Editor, sondern ist eine Eigenschaft von HTML, das grundsätzlich mehrere Leerzeichen und Zeilenumbrüche zu einem einzigen Leerzeichen zusammenfaßt.

Tippe oben auf # oder php damit ein spezieller HTML-Block geöffnet wird, in dem alle Leerzeichen mit ausgegeben werden.

[nico1964]

Weil Cobol einfach lesbarer ist als RPG (wenn es nicht gerade free-rpg ist)

GG

Nicht nur lesbarer, ich arbeite seit 1989 mit selbst entwickelten Cobol-Anwendungen und die derzeitige wurde auch um diese Zeit entwickelt. Und die Logik dahinter möchte ich nicht unbedingt neu erfinden
Gruß
Andreas

[Fuerchau]

"Never change ..." usw.

Ich muss auch gerade eine alte Cobol-Anwendung erweitern (auf V5R2).
Nun hat sich da auch noch SQL eingeschlichen und schon fangen die Schwierigkeiten an.

Neu Dateien haben schon mal gepackte Felder mit 20 oder mehr Stellen.
COBOL kann nur 18 Stellen.
Nunja, per Compileroption kann man auf Extend31/63 umschalten, dann klappt das auch.

Allerdings gilt das nicht für den SQL-Precompiler für Cobol, der lässt weiterhin nur 18 Stellen zu .
Eine Compile-Option habe ich da nicht gefunden.

Also muss ich an diesen Stellen dann nun doch ILERPG-Unterprogramme einbauen.
Mal sehen, wer dass dann irgendwann noch versteht.