View Full Version : Problem mit gepackten/gezonten Felder aus externer DDS
Weiss jemand, warum Zahlenfelder, die in einer externen DDS gezont definiert sind, im Programm gepackt eingebunden werden, wenn die Datei in der F Bestimmung angesprochen wird.
Wenn jedoch eine extern definierte Datenstruktur auf dieselbe Datei referenziert, dann sind die Felder gezont.
:confused:
Ich muss in einigen Programmen (in denen bereits die Datei in den F-Bestimmungen definiert ist) eine neue Datenstruktur einfügen, damit ich den Datensatz der Datei in einem MOVE-Befehl ansprechen kann. Dadurch werden aber einige Felder von gepacktem Format in gezontes Format umgesetzt.
Da ich diese Felder u.a. als Programmparameter verwende,
knallt es.
Gruß Thomas
Ob gepackt oder gezont wird folgendermassen entschieden:
1. Ist das Feld nur in den F-Bestimmungen vorhanden, wird eine implizite I-Bestimmung generiert und die Definition genau übernommen, also gepackt oder gezont.
1.b Bei Ausgabedateien (PRTF/DSPF) sind die Felder IMMER gezont.
2. Wird das Feld in den C-Bestimmungen als Ergebnisfeld definiert (durch Längenangabe) ist das Feld grundsätzlich gepackt.
3. Wird das Feld durch *LIKE DEFN bestimmt, entscheidet wie es unter 1. bzw. 2. definiert wurde.
4. Wird das Feld in den I-Bestimmungen explizit durch eine DS definiert, gilt genau diese Definition und KEINE andere.
Da in RPG jedes Feld nur 1 Mal vorkommen darf gibt es ggf. Redefinitionsfehler bei Mehrfachdefinitionen:
a) wenn gleichzeitig mittels 2. und 3. definiert wird
b) wenn Ausprägung (VK / NK) 1. und 2. bzw 1. und 3. abweicht
Hallo Thomas,
handelt es sich bei den Parameter-Felder um Input-Only-Felder, d.h. sie werden in den aufgerufenen Programmen nicht verändert?
Arbeitest Du mit *Entry PList oder Prototyping?
Bei Input Only-Feldern kannst Du im Prototyp das Schlüssel-Wort CONST angeben.
Entspricht die Parameter-Definition dem übergebenen Parameter-Format, wird ein Pointer auf das Original-Parameter-Feld an das rufende Programm übergeben.
Weicht das Format ab, wird ein temporäres Feld im Parameter-Format erzeugt und ein Pointer auf dieses Feld an das rufende Programm übergeben.
Damit ist gepackt/gezont, Anzahl der Nach- und Vorkommastellen beim Parameter-Feld uninteressant.
Bei Prozeduren oder Funktionen kann auch das Schlüssel-Wort VALUE benutzt werden.
Beim Schlüssel-Wort VALUE wird der Parameter-Inhalt(keine Adresse) an die aufgerufene Pozedur übergeben.
In der aufgerufenden Prozedur kann das Parameter-Feld (im Gegensatz zum Schlüssel-Wort CONST) verändert werden, das rufende Programm(Prozedur) erhält die Änderung jedoch nicht zurück.
Bei Ausgabe-Feldern bleibt nur den Parameter umzuladen.
Birgitta
Erstmal danke für Deine Beschreibungen.
Dein Punkt 1 trifft bei mir aber nicht so zu wie beschrieben:
>> 1. Ist das Feld nur in den F-Bestimmungen vorhanden, wird
>> eine implizite I-Bestimmung generiert und die Definition genau
>> übernommen, also gepackt oder gezont.
Wenn ich das extern gezont definierte Feld nur in den F-Bestimmungen eingetragen habe, dann ist es in den generierten I- bzw. O-Bestimmungen laut Umwandlungslisting auch gezont. Aber ganz am Schluss in der Feldübersicht der Umwandlungsliste sieht man, dass das Feld doch gepackt definiert ist! Meiner Ansicht nach nicht ganz korrekt.
Wenn das Feld sowohl in den F- als auch als Datenstruktur (mit EXTNAME auf die Datei) in den D-Bestimmungen eingetragen ist, dann ist das Feld tatsächlich gezont definiert.
Mein Kollege sagte mir gerade, dass das früher wohl anders war, aber bei irgendeinem OS400 Release geändert wurde (RISC ?!?)
Gruß
Thomas
OK, der Compiler ist etwas intelligenter geworden !
Also: bei impliziter Definition wird das günstigste Format gewählt und gepackt ist nun mal schneller als Zoned.
Ich hab nun verschiedenes ausprobiert und selbst bei Ausgabefeldern (PRTF/DSPF), die automatisch definiert sind, wird das gepackte Format bevorzugt !!!
Erst bei expliziter Definition in einer DS kann das Feld selber bestimmt werden (Ergebnisfelder kennen kein P, daher immer gepackt).
Bei der internen Übertragung zwischen Feld und Dateipuffer wird dann ggf. umgewandelt.
Was RPG so treibt, kann man übrigens sehr gut bei OPM-Umwandlungen und der Generierungsoption *LIST betrachten. Man erhält dann die MI-Auflösung und versteht dann vielleicht besser was da so alles abgeht.
Ich werde den Tip mit der OPM-Umwandlung mal ausprobieren.
Vielleicht komme ich ja weiter.
Aber ich fürchte, dass ich mein Problem doch mit der Hand am Arm lösen muss => Parameterfelder separat definieren und füllen.
Trotzdem danke!
Thomas
Solange die Felder einzeln übergeben werden gehts ja mit incl. move: parm qfld zfld 60
Werden Strukturen übergeben, geht es am einfachsten über extern beschriebene DS die in beiden Programmen verwendet werden.