Datenstruktur mit allen Feldern eines Satzformates füllen (LIKEREC)

[Klaus Meyer]

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

[B.Hauser]

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]

Hallo Birgitta,

hat super geklappt. So wollte ich das haben.

Sonnige Grüße aus dem tropischen Norden.
Klaus

[Pikachu]

Bei Nutzung einer externen Datenstruktur ist zu beachten, daß die betreffenden Felder dann nicht mehr gepackt, sondern gezont im Programm angelegt werden, siehe Umwandlungsliste.

[B.Hauser]

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

[wti]

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

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

[Fuerchau]

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.

[wti]

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?

[Fuerchau]

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.

[wti]

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

[Fuerchau]

Da die Felder der Printerfile nicht in der DS sind, werden sie durch Namensgleichheit gefüllt, da ja das Feld nur 1x definiert ist.
Dies betrifft aber grundsätzlich nur I- und O-Felder sowie nicht qualified.
Eine Umbenennung der I-Felder (in I-Bestimmungen) wirkt auch tatsächlich auf die Übertragung und wird korrekt gefüllt. Nur die DS passt halt nicht.Das war schon immer so, bleibt auch weiterhin so und ist nichts unbekanntes;-).