Cobol Compilererror

[nico1964]

Folgenden Code
Linkage section.
1 doc.
2 pic x occurs 16384 times depending on len.
1 len comp pic 9(9).

PROCEDURE DIVISION using doc len.
aus I-series V6R1 Doku kopiert
bekomme ich folgenden Compilererror:
ID: LNC1030 BEW.STUFE 30 FOLGENR. 003301
Nachricht . . . : 'DEPENDING' ungültig. Erneuter Start beim nächsten
Punkt, COBOL-Verb oder am Anfang der Klausel.

Ist für Ausgabe von XML gedacht:
Bitte um Hilfe

[Fuerchau]

Du definierst eine Tabelle fester Länge, korrekt wäre

02 Len pic S9(5).
02 Table pic x occurs 1 to 16384 depending on Len.

Allerdings frage ich mich, was du damit erreichen willst.
COBOL kann auf Zeichenfelder auch per direktem Substring zugreifen:

myfield (Pos:Len)

[nico1964]

Danke wieder einmal für deine Hilfe, ist nur für einen Versuchsballon bei uns gedacht. Werde wahrscheinlich das ganze sowieso anders lösen müssen.

[Fuerchau]

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.

[Fuerchau]

@Pikachu
Kannst du meine obige Antwort nicht lesen ?

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