DSPF Felddefinitionen auslesen

[Fuerchau]

Ja natürlich gibt es auch sowas:

D MyDsI DS likerec(MyFile.FormatName:*input)
D MyDsO DS likerec(MyFile.FormatName:*output)

Ich weis nicht, ob die DS'n dann automatisch qualified sind, wenn nicht, dann qualified anhängen.
Mittels "eval-corr MyDSI = MyDSO;" bzw. umgekehrt kann ich das übertragen.

Für die Write/Reads gibt es dann Ergänzungen:

Read MyFile MyDsI;
Write MyFile MyDsO;

Aber was die Allgemeingültigkeit angeht so ist das ja nur die halbe Wahrheit.
In RPG/LE ist das leider generell nicht möglich, da man den Formatnamen nicht in einer Variablen hinterlegen kann. Dies kann man nur in COBOL oder C++.

Hintergrund:
Jede Datei hat einen FileDescriptor mit einem Puffer.
Abhängig vom Format ist dieser Puffer zu befüllen bzw. wird dieser bereitgestellt.
Um nun die Arbeit des Programmierers zu erleichtern, hat die IBM den RPG-Compiler diesbezüglich intelligient gamacht:
Alle Variablen des Programmes haben mit dem FilePuffer absolut nichts zu tun.
Erst beim EXFMT/READ/WRITE generiert der Compiler zusätzliche Moves zwischen den Variablen und dem Filepuffer. Deshalb kann man Formatnamen nicht variabel gestalten, da der Compiler sonst nicht weiß, was er dann da tun soll.
Die COBOL-Leute haben es da etwas schwerer, da hier grundsätzlich mit dem FilePuffer native gearbeitet wird. Der Programmierer ist also selber verantwortlich, wie er mit dem Puffer umgehen muss. Dafür darf er dann aber den Formatnamen in einer Variablen ablegen.
Geschmacksache, was da nun besser ist.
Mir persönlich ist das egal, ich kann beides ganz gut.

Deine Frage nach "SendKey" verstehe ich da noch nicht. Wozu soll das gut sein?
Auch auf Windows muss ich da schon genau wissen, welches Element da den Focus gerade hat.

STRG+C/STRG+V ist eine Sache der Emulation und der Tastaturkonfiguration.
Ich kann das auch anders Konfigurieren. Manchmal geht auch:
STRG+Einfügen (Kopieren), STRG+Shift+Einfügen (Einfügen), STRG+SHIFT+Entfernen (Ausschneiden).

[volkerK]

Hallo,

vielen Dank nochmals, werde jetzt mir alles durch den Kopf gehen lassen.

Bei dem was ich bisher mit SendKeys gemacht (das war mit VBA) habe brauchte ich das Element nicht zu wissen ich bewegte mich sowiso in einem "fremden" programm, durch die "tab" taste bis ich auf dem Feld stand und gab dann meine Zeichen "ein" ohne zu wissen wie das Element hiess.

Im F04 fall wäre das dann ja sogar so dass ich ja auf dem Feld stehe und dann ja "nur" die zeichen sende. Aber sowas habe ich auf der AS400 noch nicht gesehen (wobei es bestimmt vieles gibt was ich noch nicht gesehen habe)

Viele Grüsse.

Volker.

[Fuerchau]

Auch in einem fremden Programm muss F4 auch programmiert sein sonst klappt es ja nicht.
Wer soll denn sonst entscheiden, was als Auswahl für dieses Feld gilt, wenn ich nicht weiß auf welchem Feld ich stehe?
So ganz kann ich deine Gedankengänge nicht nachvollziehen, denn es macht ja wenig Sinn, F4 als Key zu senden, wenn doch der Bediener entscheidet ob er F4 überhaupt benötigt.

[volkerK]

Hallo,
ich glaube ich habe da jetzt für Verwirrunbg gesorgt , also ich wollte natürlich nicht "F04" senden . Der Benutzer drückt die "F04" dann wird das bedienerführungsPGM gestartet und dieses PGM sendet dann , nachdem der Benutzer den entsprechenden Wert ausgewählt hat zB ein "J" und da wo der Cursor steht wird dann "J" (das ist dann genau das Feld für das die BedFührung angefordert wurde) eingefügt.

Das Beispiel mit dem fremden Programm hatte nichts mit "F04" zu tuen. Da habe ich einfach ein vorhandenes Programm gestartet und dann mit SendKeys die eingaben "simuliert", von VBA aus.

Aber egal mein jetzt Stand ist folgender:

Habe eine ds als Input und eine als Output (so wie du beschrieben hast) angelegt. Das mit dem Qualifizierten namen (MeineDatei.MeinSatzformat) ging bei uns nicht.

Dann nach dem EXFMT ein Chain ( RCDNBR Chain SFL1 DS_INPUT)

dann mit eval DS_OUTPUT = DS_INPUT (eval-corr ging auch nicht) die output ds gefüllt per %subst die entsprechende stelle geändert .

Als abschluss UPDATE SFL1 DS_OUTPUT.

so hat es funktioniert

Nun habe ich noch 2 Fragen
1.Das was bei uns nich funktioniert hat , kann das am Betriebssystem liegen?
2.Beim ersten Versuch war meine input und output DS unterschiedlich in der input DS waren nur die als eingabe oder Both in der DSPF definierten Felder in der Output waren alle. Deshalb hatte ich beim UPDATE bzw beim darauffolgenden EXFMT immer ungültige Daten.
Nun habe ich alle Felder in der DSPF als Both definiert und mittels DSPATR(PR) gesperrt (manche) normaöerweise ist das bei uns gemischt manche sind von anfang an nur als ausgabe definiert ander per Programm und PR.
Muss man das so machen oder habe ich etwas anderes falsch gemacht.?

Aber bis jetzt bin ich zufrieden , danke nochmals.


Viele Grüße
Volker.

[Fuerchau]

Da kann man mal sehen (sorry) wie weit du vom Verständnis der Variablendefinition in RPG/LE entfernt bist.
Grundsätzlich gilt hier folgendes:

Jede Variable gibt es im gesamten Programm nur ein einziges Mal.
Jede Datei (I/O/U) liefert ihre eigenen Variablendefinitionen in den automatischen I- und O-Bestimmungen.
Diese Felder sind nach ILE-Definition sog. Single-Variablen.

Nun kann man natürlich eine Datenstruktur "DS" definieren.
Ist diese DS nicht qualified, sind die enthaltenen Felder nur als Gruppe zu verstehen, die Variablen sind immer noch Single und können deshalb auch nicht in einer 2. DS definiert werden.

Mittels Qualified muss eine DS mit ihren Unterfeldern immer in der Form "XXX.YYY" angesprochen werden, was gedanklich zu einer Mehrfachdefinition führt, real aber nicht ist. XXX.YYY ist ein anderes Feld als ZZZ.YYY.

Wie funktioniert nun IO:
Jede IO-Bestimmung (Read/Write/Chain/Exfmt) ohne spezielle Angaben verwendet ausschließlich die Felder, die in den I- und O-Bestimmungen definiert sind, also i.d.R. nie die Qualified DS'n.

Verwendet man einen Lesebefehl "READ/CHAIN Datei/Format Struktur", dann muss die Struktur per Likerec(*input) definiert sein, umgekehrt bei "Write/Update Format Struktur" muss die DS mit Likerec(*output) definiert sein.

Passend dazu gibt es den "eval-Corr ZielDS = QuellDS;", der natürlich nur auf Qualified-DS funktioniert.

Nun kann man bei der Definition in den F-Bestimmungen einen Prefix "XXX." definieren, der dann auch auf die Qualified-Strukturen verweisen kann, dann kann man mit Likerec(*All) ebenso umgehen.
In neueren Versionen wird Qualified auch auf den F-Bestimmungen erlaubt.

Lehnt dein Compiler den eval-corr ab, gibt es 2 Möglichkeiten:
a) es gibt ihn noch nicht.
b) die beteiligten DS'n sind nicht qualified und/oder es wurden keine passenden Namen gefunden.

Kommen wir nun zu deinen Versuchen:
Ein "EXFMT Format" verwendet die I- und O-Felder aus der F-Bestimmung, ein "EXFMT Format Struktur" verwendet ein DS mit Likerec(*all).
Eine Subfile kann nur Read/Write/Update und kann daher nur mit *Input bzw. mit *Output-DS umgehen, der Compiler meckert das sogar an.
Gibt es keinen eval-corr, muss man die Feldinhalte manuell einzeln übertragen.

Aber um zu deinem Ursprungsproblem zurückzukommen reicht hier wirklich ein einfacher Verteiler und ein allgemeine Prompt-Funktion:

d MyPrompt PR 100 varying
d Feldname 10

select;
when CsrFeld = 'FELD1';
Feld1 = MyPrompt('KDNR'); // Auswahl Kunden-Nr (z.B. per Matchcode)
when CsrFeld = 'FELD2';
Feld2 = MyPrompt('Tab:47'); // Auswahl aus Tabelle 47
:
endsl;

Alles andere ist nur Overhead den anschließend kaum einer versteht.

[BenderD]

Jede Variable gibt es im gesamten Programm nur ein einziges Mal.

... es sei denn, man hat in einer PF/LF eine Integer drin und dasselbe Feld in einem DSPF, da macht es eine packed draus (hat mich reichlich Nerven gekostet, als ich so ein Feld in einer Parameterschnittstelle drin hatte und die F Karte der LF rausgeworfen habe...)

Verwendet man einen Lesebefehl "READ/CHAIN Datei/Format Struktur", dann muss die Struktur per Likerec(*input) definiert sein, umgekehrt bei "Write/Update Format Struktur" muss die DS mit Likerec(*output) definiert sein.

... es sei denn, man hat V7R3 https://www.ibm.com/support/knowledg...rpgrelv7r3.htm
(im verlinkten Doc nach likerec suchen)

D*B

[Fuerchau]

"Jede Variable gibt es im gesamten Programm nur ein einziges Mal."
Dies gilt dann ja trotzdem, ich habe ja nichts über den Typ gesagt.
Bei DSPF/PRTF sind die Dezimalfelder sogar Zoned.
Und ich glaube, dass die Reihenfolge der F-Bestimmungen über den automatischen Typ bestimmt.
Mache ich eine Externe DS, wird der Typ wiederum durch die externe Datei definiert.

Und was halt die diversen Releases angeht, so kommt man mit den Neuerungen kaum nach und merkt dann immer wieder, was dann bei den diversen Kunden wieder nicht geht (V5R4, V6R1, V7Rn).

[volkerK]

Hallo,

an FUERCHAU: wahrscheinlich hast Du mit dem ersten Satz den Nagel genau getroffen im bezug auf das ganze ILE Konzept gibt es bei mir sehr viele Lücken (und nicht nur bei den FeldDefinitionen) aber bis zur Rente habe ich ja noch 10 Jahre (vielleicht kann ich noch etwas ändern).

So wie Du die F04 Lösung mit Verteiler und Prompt vorschlägst habe ich es in vielen PGM schon drin und werde das jetzt so lassen. Die Lösung die DS per %subst zu ändern (dadurch konnte ich diese funktion ganz auslagern es wurde nur die DS übergeben) funktioniert bisher zwar muss da aber noch mit den verschiedenen Felddefinitionen (die in der DSPF sein könten) probieren.

Nun habe ich aber noch eine Frage unabhängig von der F04 Funktion:

Die IN_DS wird durch READC/CHAIN gefüllt . Beim UPDATE gebe ich die OUT_DS an . Die OUT_DS hat mehr Felder wie die IN_DS . Wie bekommt man denn nun die Felder (die beim schreiben in die Subfile ja da sind) in die OUT_DS rein ? Wie gesagt beim CHAIN/READC darf ich sie nicht angeben , ein EVAL würde wegen der unterschiedlichen Felder auch nicht gehen und der EVAL-CORR (den ich nicht habe) würde ja auch nur die Felder füllen die er per Namen zuordnen kann selbst die Felder einzeln füllen geht nicht da ich die Werte ja nicht mehr habe..
Für mich hat es nur die Lösung gegeben IN_DS und OUT_DS gleich zu machen ,dadurch dass ich alle Felder als B oder I in der DSPF definiert habe. Im Programm muss ich dann das DSPATR(PR) setzten dadurch kann ich mir aber gleich einen Kenner für die F04 Funktion setzen.

Seit wann gibt es eigentlich den EVAL-CORR ?

Viele Grüße

Volker.

[dschroeder]

Seit wann gibt es eigentlich den EVAL-CORR ?

Den EVAL-CORR gibt es seit V5R4.

Dieter

[Fuerchau]

Ich verstehe das Problem nicht.
Da ein Format (egal ob SFL oder Record) eben Ein- und Ausgabefelder hat, ergeben sich unterschiedliche Strukturen.
Also fülle ich die OUT_DS mit den benötigten Informationen.
Bei Namensgleichheit mit z.B. einer PF kann ich eben folgendes tun:
eval-Corr OUT_DS IN_PFDS;
OUT_DS.FX = BlaBla;
WRITE SFLFMT OUT_DS;

READ/C FORMAT IN_DS;
eval-corr OUT_DS = IN_DS; // Zur Sicherheit

Der Rest ist eben Programmierlogik.

[volkerK]

Hallo,

eben glaube ich meinen Denkfehler erkannt zu haben :

Du schreibst dass die Subfile mit der OUT DS "gefüllt" wird ich habe die IN und OUT DS'n das bisher nur beim READC und UPDATE benutzt. Dann habe ich ja praktisch Felder gefüllt die ich dann beim READC nicht gelesen habe.

Vielen Dank nochmals , denke jetzt bin ich etwas weiter gekommen.



Volker.