-
Externe Datenstruktur basierend auf Bildschirmformat
Hallo *all,
ich definiere in einem RPG-Programm in der D-Karte eine Externe Datenstruktur basierend auf einem Bildschirmformat.
Code:
D W30 E DS EXTNAME(TPK01W:TPK01W30)
D QUALIFIED
Welche Möglichkeit gibt es dies Datenstruktur mit den Bildschirminhalten zu versorgen, ohne jedes Feld separat anzusprechen.
Eventuell so in der Art:
EVAL W30 = TPK01W30
Ziel soll sein, den alten Bildschirminhalt mit dem neuen Inhalt zu vergleichen. Bisher haben wir hierfür Hilfsfelder definiert.
Vielen Dank für eure Tipps und Hilfen.
-
In den F-Bestimmungen kannst du die Formate der DSPF ebenso "qualified" definieren.
Der Code ist dann allerdings etwas aufwendiger, erleichtert aber das Leben:
Code:
* file1 has formats HDR, INFO, ERR.
* file2 has format INFO.
* The QUALIFIED keyword is used for both files, making it
* unnecessary to rename one of the "INFO" formats.
* Note that the record format names are not qualified when
* specified in keywords of the File specification.
Ffile1 if e disk qualified
F ignore(hdr)
F rename(err:errorRec)
Ffile2 o e disk qualified
* The record formats must be qualified on all specifications other
* than the File specification for the file.
D ds1 ds likerec(file1.info : *input)
D errDs ds likerec(file1.errorRec : *input)
D ds2 ds likerec(file2.info : *output)
/free
read file1.info ds1;
eval-corr ds2 = ds1;
write file2.info ds2;
read file1.errorRec errDs;
Figure 116. Example of the QUALIFIED keyword
der Nachteil ist sicherlich, dass man bei allen Read/Write/Exfmt sowohl den Datei.Format-Namen als auch die DS angeben muss.
Zusätzlich bedarf es eines "eval-corr" für die Übertragung zwischen den DS.
-
Zitat von Gutmann
Ziel soll sein, den alten Bildschirminhalt mit dem neuen Inhalt zu vergleichen.
D W30 E DS EXTNAME(TPK01W:TPK01W30) INZ
D X30 E DS EXTNAME(TPK01W:TPK01W30) PREFIX(X:1)
X30 = W30;
Exfmt ...
If W30 <> X30;
...
-
@Robert
So einfach geht das leider nicht, da das Ein-/Ausgabeformat einer DSPF ja abweichend ist.
Per LIKEREC und QUALIFIED kannst du jedoch für beides eine eigene DS definieren.
Für den Vergleich benötigst du dann halt eine 2. DS.
Nach einem READ kannst du die beiden Input-DS vergleichen und dann sichern.
Ebenso kannst du per EVAL-CORR schon mal die Eingabe-DS in die Ausgabe-DS übertragen.
Die COBOL-Fraktion arbeitet schon sehr lange nach diesem Verfahren.
Der vertretbare Aufwand, kein EXFMT mehr verwenden zu können wird durch den Vorteil klarerer Strukturen mehr als aufgewogen.
Zumal das häufige Definieren von Hilfsfeldern großenteils entfällt. Schließlich hat man ja die Eingabefelder schon mal 2-fach (Input-DS und Output-DS) und spart sich das "merken" in Hilfsvariablen.
-
Vielleicht kann ich auch noch etwas zum Thema beitragen. Ab einem bestimmten Release bzw TR (ich weiß aber nicht mehr genau welches), muss man die Bildschirm-Datenstrukturen nicht mehr in input und output unterscheiden, man kann einfach das Schlüsselwort *all verwenden.
Hier ein Beispiel mit einem DSPF, das ein normales Format (fmt1) und eine SFL (sfl1) hat:
Code:
// Bildschirm
dcl-f bvn9ue1d WORKSTN handler('PROFOUNDUI(HANDLER)') alias qualified
sfile(sfl1:f1.s1_satznr);
// Qualifizierte Datenstrukturen für Bildschirm-Handling:
dcl-ds f1 likerec(bvn9ue1d.fmt1:*all); // Alle Felder des normalen Formates
dcl-ds s1 likerec(bvn9ue1d.sfl1:*all); // Alle Felder von sfl1
//Zugriff auf "normales" Format:
exfmt bvn9ue1d.fmt1 f1;
//Zugriff auf Subfile:
chain satznr bvn9ue1d.sfl1 s1;
PS: Wir sind auf 7.1 TR 11
Dieter
-
Hallo,
danke für die schnelle Hilfe.
Konnte es soweit mit einem Testprogramm nachbauen und läuft.
Auch das mit einer einzigen Datenstruktur für Ein- und Ausgabe klappt soweit.
Einziges Problem, wobei ich das schon rausgefunden habe, im Bildschirmfile müssen den definierten F-Tasten auch Antwortbezugszahlen zugewiesen werden (zumindest hat es sich im Debug so dargestellt).
Wobei dann heißt es in den Abfragen eben nicht mehr:
sondern:
Nochmal vielen Dank für eure Hilfe
-
Das wundert mich dann aber doch.
Aber was solls, für die Tasten (und anderes) kann man die INFDS einer DSPF verwenden.
Dort wird die gedrückte Taste mit einem Hexcode (für F1-F24, Pageup/down/Home/Dup/Pos1) abgelegt.
Wenn man sich dafür dann Konstanten einfallen lässt, dann kann man das auch wieder ohne BZ's erledigen.
Nur so als Tipp:
Indikatoren sollten besser mit *ON oder *OFF abgefragt/gesetzt werden. Das ist sprechender.
-
Zitat von Fuerchau
Nur so als Tipp:
Indikatoren sollten besser mit *ON oder *OFF abgefragt/gesetzt werden. Das ist sprechender.
... sprechend wäre true und false, was RPG nicht kennt - kann man aber über Definition von Konstanten nachbessern.
D*B
der bei unerwartetem *OFF immer meint, er müsste die Birne austauschen...
-
Nun ja, keine mir bekannte Sprache beherrscht die Syntax "Bool is true", es heißt immer "Bool = true" bzw. "Bool == true".
Wobei man hier z.B. in Microsoft C++ noch unterscheiden muss:
true = 1
TRUE = 1
VARIANT_TRUE = -1 <= Dies ist bei COM-Schnittstellen wichtig.
Einzig die VB-Abfrage "if bool then" liefert immer die korrekte Antwort, "if bool = True then" liefert nur bei "-1" die korrekte Antwort.
Da kann ich mit den Unschönheiten von *OFF/*ON schon leben.
Noch eine Inkonsistenz:
"MOVEA '1111' *IN,1" setzt die IN01-IN04 auf *ON.
"%subarr(*in:1:4) = *ON;" macht das ebenso.
Allerdings ist "%subarr(*in:1:4) = '1111';" nicht erlaubt, da der Compiler nun die Zeichenkette als CHAR abweist.
-
Ich muss da jetzt aus Neugierde doch nachfragen:
Was ist der eigentliche GRUND, dass die Bildschirmfelder verglichen werden sollen?
Wenn das nur den Sinn hat um zu erkennen, dass vom User in einem Feld Daten erfasst/geändert wurden, geht das ja auch ohne jeglichen Datenstrukturen etc..
-
Nun ja, so ganz geht das leider nicht.
Die DSPF-Möglichkeiten sind da doch eher eingeschränkt.
Das MDT-Flag (CHANGE, BLANK) teilt mir nur mit, dass in dem Feld was eingegeben wurde.
Wenn es aber der vorherige Wert war wird die BZ trotzdem gesetzt.
Mit Qualified habe ich da halt einfacher die Möglichkeit mir in einer 2. DS die vorherigen Eingaben zu merken. Früher musste ich Hilfsfelder oder DS definieren und jedes Feld einzeln übertragen.
-
Genau wegen dem CHANGE Schlüsselwort habe ich nachgefragt.
Dass bei Eingabe der "gleichen" Daten die BZ auch eingeschaltet wird, ist klar - das reicht in den allermeisten Fällen ja auch.
Na passt - wollte nur erfragen, ob es da noch weitere Hintergründe gibt.
Similar Threads
-
By harkne in forum NEWSboard Programmierung
Antworten: 8
Letzter Beitrag: 05-08-14, 21:47
-
By MGJ79 in forum NEWSboard Programmierung
Antworten: 7
Letzter Beitrag: 24-04-14, 10:00
-
By tarkusch in forum NEWSboard Programmierung
Antworten: 1
Letzter Beitrag: 24-01-14, 16:51
-
By XMan in forum NEWSboard Programmierung
Antworten: 6
Letzter Beitrag: 08-01-14, 18:51
-
By Klaus Rotering in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 26-01-01, 08:58
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks