View Full Version : Datenstruktur mit allen Feldern eines Satzformates füllen (LIKEREC)
Klaus Meyer
28-07-08, 08:00
Hallo Forum-Kollegen
ich habe versucht, die Daten aller Felder eines Satzformates in eine Datenstruktur zu schreiben, damit ich mir den aktuellen Inhalt vom Datensatz sichern kann, und mit den Werten weiter arbeiten kann, aber immer noch den Ursprung zur Verfügung habe. Leider ist in dem Moment der Übertragung (Read Satzformat Datenstruktur) der Inhalt im Satzformat der Datei nicht mehr vorhanden.
Die Datenstruktur habe ich so angelegt: D $VSFABSFM DS likerec(VSFABSFM:*input)
Was muss ich tun, damit ich den Inhalt im Satzformat und in der Datenstruktur gleichzeitig zu Verfügung haben.
Gruß
Klaus Meyer
So geht das nicht!
Wenn Du die Datensätze ohne Datenstruktur einliest oder in eine externe unqualifizierte Datenstruktur bei der das Schlüssel-Wort PREFIX nicht verwendet wurde, hast Du die Format-Daten.
Wenn Du den Datensatz über in eine qualifizierte Datenstruktur oder eine externe Datenstruktur mit PreFix, sind die Format-Daten weg.
Beides in einem Schritt geht nicht!
Was Du natürlich machen kannst, wenn Du den Original-Datensatz sichern möchtes:
1. Eine externe unqualifizierte Datenstruktur anlegen.
2. Eine weitere Datenstruktur z.B. qualifizierte Externe Datenstruktur oder mit LikeRec definierte Datenstruktur
3. Nach dem Einlesen den Datenstatz entweder mit EVAL oder EVAL-CORR in die zweite Datenstruktur schieben.
D DSFileA E DS EXTNAME(FileA)
D DSFileASav DS LikeRec(FileAF: *Input)
*------------------------------------------------------
/Free
Read FileAF DSFileA;
DSFileASav = DSFileA;
/End-Free
Das Einlesen in die Datenstruktur DSFileA is nicht zwingend erforderlich.
Birgitta
Klaus Meyer
28-07-08, 13:49
Hallo Birgitta,
hat super geklappt. So wollte ich das haben.
Sonnige Grüße aus dem tropischen Norden.
Klaus
Bei Nutzung einer externen Datenstruktur ist zu beachten, daß die betreffenden Felder dann nicht mehr gepackt, sondern gezont im Programm angelegt werden, siehe Umwandlungsliste.
Bei Nutzung einer externen Datenstruktur ist zu beachten, daß die betreffenden Felder dann nicht mehr gepackt, sondern gezont im Programm angelegt werden, siehe Umwandlungsliste
Bei Nutzung einer Datenstruktur ist zu beachten, dass keine Konvertierung von gezonten Feldern in gepackte Felder erfolgt, sondern die Felder so erscheinen wie definiert!!!
Also gezont bleibt gezont und gepackt bleibt gepackt, was ich durchaus als Vorteil bewerten würde.
Gepackte Felder werden in Datenstrukturen nur dann in gezont konvertiert, wenn eine Auflistung der Felder (ohne weitere Definition) erfolgt.
Birgitta
So geht das nicht!
Wenn Du die Datensätze ohne Datenstruktur einliest oder in eine externe unqualifizierte Datenstruktur bei der das Schlüssel-Wort PREFIX nicht verwendet wurde, hast Du die Format-Daten.
Wenn Du den Datensatz über in eine qualifizierte Datenstruktur oder eine externe Datenstruktur mit PreFix, sind die Format-Daten weg.
Beides in einem Schritt geht nicht!
Was Du natürlich machen kannst, wenn Du den Original-Datensatz sichern möchtes:
1. Eine externe unqualifizierte Datenstruktur anlegen.
2. Eine weitere Datenstruktur z.B. qualifizierte Externe Datenstruktur oder mit LikeRec definierte Datenstruktur
3. Nach dem Einlesen den Datenstatz entweder mit EVAL oder EVAL-CORR in die zweite Datenstruktur schieben.
D DSFileA E DS EXTNAME(FileA)
D DSFileASav DS LikeRec(FileAF: *Input)
*------------------------------------------------------
/Free
Read FileAF DSFileA;
DSFileASav = DSFileA;
/End-Free
Das Einlesen in die Datenstruktur DSFileA is nicht zwingend erforderlich.
Birgitta
Moin @Birgitta,
ich habe ein ähnliches Problem und greife hierfür diesen alten Post auf.
Für eine Journalisierung bzw. ein spätere Auswertung der Druck-Daten muss ich alle Daten eines Satz-Formates in einer Printer-File in eine separate Datei schreiben.
In einem anderen Post habe die Lösung gefunden alle Satz-Formate mit QUALIFIED zu definierten. Dies ist für meine Anwendung nicht möglich, da die Printer-File mehrere Hundert Satz-Formate und das Programm viele Tausend lines of code hat. Der Aufwand wäre einfach zu groß.
Ich habe deine Lösung versucht aufzugreifen, was bei mir allerdings zu Umwandlungsfehler führt:
D ds_abrdvar E ds extname('AB671PV':'ABRDVAR' : *all)
D prtf_ds ds likerec(ABRDVAR : *all)
RNF3804 Name #ZL2 in externer Beschreibung AB671PV... wurde nicht umbenannt; der externe Name wird ignoriert.
Was habe ich falsch gemacht?
Sorry - ich hatte noch eine Daten-Struktur definiert :confused::confused::confused
Jetzt habe ich Probleme mit den in Printer-File definierten Indicatorn:
000461 D ds_abrdvar E ds extname(AB671PV:ABRDVAR:*output) 250623 000461
*--------------------------------------------------------------------------------------------* 1
* Datenstruktur . . . . . . : DS_ABRDVAR * 1
* Externes Format . . . . . : ABRDVAR : A010001018/AB671PV * 1
* Formattext . . . . . . . . : Deckblatt-Variablen * 1
*--------------------------------------------------------------------------------------------* 1
000001=D *IN51 1N 1000001
======> aaaaa
*RNF3314 20 a 1000001 Der Eintrag für den Namen ist ein reserviertes Wort;
standardmäßig werden Leerzeichen angenommen.
000002=D *IN69 1N 1000002
- New Page -
5770WDS V7R4M0 190419 RN IBM ILE RPG A010001018/AB671 BRUDEVIT 23.06.25 09:06:04 Seite 15
Zeil.- <---------------------- Quellenbestimmungen ------------------------------><-- Bemerkungen --> Do S. Änd.- Src Folge-
Nummer ....1....+....2....+....3....+....4....+....5....+ ....6....+....7....+....8....+....9....+...10 Num Z. Datum ID nummer
======> aaaaa
*RNF3314 20 a 1000002 Der Eintrag für den Namen ist ein reserviertes Wort;
standardmäßig werden Leerzeichen angenommen.
000003=D *IN97 1N 1000003
======> aaaaa
Im Prinzip brauche ich eine Daten-Struktur je Satz-Format in der Printer-File, die "automatisch" mit den Werten in dem Print-Record gefüllt wird (redefine). Diese Daten-Struktur übergebe ich dann an eine Prozedur, die den Datensatz in eine Datei schreibt.
Der Satz "Das Einlesen in die Datenstruktur DSFileA is nicht zwingend erforderlich." war meine Hoffnung...
Ich würde mir gerne die Übertragung jeden einzelnen Feldes ersparen :)
Vielen Dank und viele Grüße
Wolfgang
P.S. natürlich freue ich mich auch über Lösung von anderen Kollegen ;);)
So einfach ist auch dies wiederum nicht:
Bei nicht qualified DS kann ein Feld nur in einer DS stecken.
Bei qualified geht das wiederum schon, aber einen automatischen Move gibts da nicht.
Da man bei DSPF/PRTF den Vorteil der Mehrfachdefinition in verschiedenen Formaten gerne genutzt hat, ist das für erweiterte Wünsche dann wieder kontraproduktiv.
I- und O-Felder finden ihren Bezug über ihre Namen.
Der Compiler generiert dann intern die passenden Moves zum jeweiligen Format. Somit schafft das Programm dann die Verbindung zwischen Feld und IO.
Mit qualified kannst du im Prinzip dasselbe erreichen, man muss dafür aber was tun:
Per "Read File DS" kann man die Daten in eine qualified DS lesen.
Per "Write File DS" aus dieser schreiben.
Nun benötigst du nur eine handvoll "eval-corr" um identische Feldnamen mit passenden Typen hin und her zu übertragen. Den Rest erledigst du dann per Einzel-Move/Eval.
So einfach ist das nun wirklich nicht :confused
Ich habe die Daten-Struktur definiert bekommen. Allerdings funktionierte das mit den Indicator in der Printer-File nicht und einige der Felder sind bereits im bestehenden Programm definiert.
Diese beiden Probleme kann ich umgehen, indem ich die Felder in der externen Daten-Struktur umbenenne:
dcl-ds ds_AB671PV_ABRDVAR ext
extname('AB671PV':'ABRDVAR' :
*output);
Ind51 extfld('*IN51');
Ind69 extfld('*IN69');
Ind97 extfld('*IN97');
$$ZL2 extfld('#ZL2');
$$ZL3 extfld('#ZL3');
$$ZL4 extfld('#ZL4');
$$ZL5 extfld('#ZL5');
$$ZL6 extfld('#ZL6');
$$ZL8 extfld('#ZL8');
$$LGNR extfld('LLGNR');
$$VWNR extfld('LVWNR');
$$TXAB0A extfld('#TXAB0A');
$$TXAB0B extfld('#TXAB0B');
$$TXAB0C extfld('#TXAB0C');
...
end-ds;
Leider geht mit dem Umbenennen der Felder auch der Feld-Inhalt verloren - was ich mir nicht erklären kann. Das Feld bekommt doch "nur" einen anderen Namen - der Speicher-Platz ist doch der gleiche...
Felder in der Printer-File:
EVAL #zl5
#ZL5 = 'Vor- und Nachname '
EVAL #zl6
#ZL6 = 'Straße und Hausnummer '
EVAL #zl8
#ZL8 = 'PLZ und Ort '
Felder in der Daten-Struktur:
EVAL ds_AB671PV_ABRDVAR
IND97 OF DS_AB671PV_ABRDVAR = ' '
IND69 OF DS_AB671PV_ABRDVAR = ' '
IND51 OF DS_AB671PV_ABRDVAR = ' '
$$ZL2 OF DS_AB671PV_ABRDVAR = ' '
$$LGNR OF DS_AB671PV_ABRDVAR = .
#KKZ OF DS_AB671PV_ABRDVAR = '-A '
$$ZL3 OF DS_AB671PV_ABRDVAR = ' '
$$VWNR OF DS_AB671PV_ABRDVAR = .
$$ZL4 OF DS_AB671PV_ABRDVAR = ' '
$$ZL5 OF DS_AB671PV_ABRDVAR = ' '
$$ZL6 OF DS_AB671PV_ABRDVAR = ' '
$$ZL8 OF DS_AB671PV_ABRDVAR = ' '
#DRKDT OF DS_AB671PV_ABRDVAR = 23062025.
#LGADR OF DS_AB671PV_ABRDVAR =
'Straße&Hausnummer, PLZ&Ort '
#LANZP OF DS_AB671PV_ABRDVAR = 01052015.
#LEHZP OF DS_AB671PV_ABRDVAR = 30042016.
$$TXAB0A OF DS_AB671PV_ABRDVAR = ' '
$$TXAB0B OF DS_AB671PV_ABRDVAR = ' '
$$TXAB0C OF DS_AB671PV_ABRDVAR = ' '
$$TXAB1A OF DS_AB671PV_ABRDVAR = ' '
$$TXAB1B OF DS_AB671PV_ABRDVAR = ' '
$$TXAB1C OF DS_AB671PV_ABRDVAR = ' '
$$TXAB2A OF DS_AB671PV_ABRDVAR = ' '
$$TXAB2B OF DS_AB671PV_ABRDVAR = ' '
Hier kann man gut erkennen, dass die Felder, die nicht von #... auf $$... umbenannt wurden, den zugewiesenen Wert enthalten. Alle Inhalte in den umbenannten Feldern sind verloren gegangen bzw. nicht (mehr) in der Daten-Struktur.
Ich kann also das Satz-Format einer Printer-File in eine Daten-Struktur übertragen - aber nur wenn ich keinen Rename vornehmen muss...
Hat jemand eine Idee?
Das Umbenennen in der DS hat keinen Einfluss auf IO.
Das hat nichts mit der Umbenennung in den I-Bestimmungen zu tun!
Die DS wird definiert "as is", die Verwendung entscheidest du und nicht der Compiler.
Eine Beziehung zwischen DS und IO gibt es generell nicht.
Nur die RPG-Definition "Eine Variable existiert nur 1 x", scheint eine Beziehung herzustellen. In Wirklichkeit generiert der Compiler die passenden MOVE's.
Indicator sind vom Typ "ind" (N), in der Datei vom Typ CHAR(1). Das ist nicht dasselbe. Deshalb klappt das auch nicht mit OUTPUT-DS's. Hier hilft allenfalls INDARA in der DSPF/PRTF, da dann die *IN nicht zur DS gehören.
Die Variable IND97 entspricht daher nicht *IN97 bzw. *IN(97) und du scheiters bei EVAL-CORR.
Nur mit Definition kannst du i.d.R nichts reißen.
In den I-Definitionen werden auch nur die Felder aufgeführt, die in der Quelle verwendet sind.
Wenn alle benötigt werden, kann man eine DS extern, nicht qualified, definieren.
Was allerdings dann wieder scheitert, wenn ein Feld in mehreren DSN's auftaucht.
Die einzige Lösung sind Qualified DS'n mit "Read/Write DSName".
D.h. auch, dass O-Bestimmungen durch Write ersetzt werden müssen.
Das Umbenennen in der DS hat keinen Einfluss auf IO.
Das hat nichts mit der Umbenennung in den I-Bestimmungen zu tun!
Das ist auch mein Kenntnisstand.
Trotzdem...
Feld (DruckDatum) nicht umbenannt
000010=D $$ZL5 30A EXTFLD (#ZL5) AdressZeile4 2000010
000011=D $$ZL6 30A EXTFLD (#ZL6) AdressZeile5 2000011
000012=D $$ZL8 30A EXTFLD (#ZL8) AdressZeile6 2000012
000013=D #DRKDT 8S 0 DruckDatum 2000013
Wert in der Daten-Struktur:
#DRKDT OF DS_AB671PV_ABRDVAR = 23062025.
Feld (#ZL5 ff.) umbenannt
000010=D $$ZL5 30A EXTFLD (#ZL5) AdressZeile4 2000010
000011=D $$ZL6 30A EXTFLD (#ZL6) AdressZeile5 2000011
000012=D $$ZL8 30A EXTFLD (#ZL8) AdressZeile6 2000012
000013=D #DRKDT 8S 0 DruckDatum 2000013
Feld in der Printer-File (im Debug)
EVAL #zl5
#ZL5 = 'Vor- und Nachname '
EVAL #zl6
#ZL6 = 'Straße und Hausnummer '
EVAL #zl8
#ZL8 = 'PLZ und Ort
Feld in der Daten-Struktur (im Debug)
$$ZL5 OF DS_AB671PV_ABRDVAR = ' '
$$ZL6 OF DS_AB671PV_ABRDVAR = ' '
$$ZL8 OF DS_AB671PV_ABRDVAR = ' '
#DRKDT OF DS_AB671PV_ABRDVAR = 23062025.
Ich werde die Sache jetzt aber nicht weiter verfolgen. Einen Teil der Werte finde ich in der Daten-Struktur und die anderen Felder übertrage ich halt einzeln.
Ist vielleicht für den ein oder anderen interessant davon gehört zu haben.
Danke für deinen Vorschlag...
Diese Vorgehensweise (qualified) ist für meine Anwendung nicht möglich, da die Printer-File mehrere Hundert Satz-Formate und das Programm viele Tausend lines of code hat. Der Aufwand wäre einfach zu groß.