STRQMQRY Probleme mit Record Number

[harkne]

Hallo zusammen,

ich schon wieder mit einem anderen Problem

Kurz das Problem als erstes.
Ich führe aus STRQMQRY einen SELECT Feld FROM Datei aus und gebe eine 2. Datei aus. Die 2. Datei hat aber nicht immer die Satzreihenfolge wie die 1. Datei. Warum ist das so?

Wir haben ein Tool (FMTJRNE) was mit DSPJRN die Daten aufbereitet

Hierbei wird über DSPJRN eine Datei ausgegeben die #FMTJRN2 heißt
Das Datenfeld aus #FMTJRN2 wird mittels STRQMQRY in eine Datei #FMTJRN3 ausgegeben.
Der Befehl sieht wie folgt aus
STRQMQRY QMQRY(ZUQXSQL) OUTPUT(&TYPE) +
OUTFILE(&OLIB/&OFIL) OUTMBR(&OMBR +
&ORPL) ALWQRYDFN(*YES) SETVAR((LINE01 +
&LINE01) (LINE02 &LINE02) (LINE03 +
&LINE03) (LINE04 &LINE04) (LINE05 +
&LINE05) (LINE06 &LINE06) (LINE07 +
&LINE07) (LINE08 &LINE08) (LINE09 +
&LINE09) (LINE10 &LINE10))
Es ist nur &LINE01 gefüllt und enthält
&LINE01 = 'Select Joesd from QTEMP/#FMTJRN2'

Den Rest erspare ich Euch, denn hier haben wir ab und an bereits einen Fehler, mit ab und an meine ich, mal funktioniert es und manchmal nicht und zwar folgendes:

Später wird über die Relative Satznummer der #FMTJRN2 und der relativen Satznummer der #FMTJRN1 (was die richtigen Einzelfelder aus FMTJRN3 hat) ein Join (WHERE RRN(F1)=RRN(F2)) gemacht

Das funktioniert immer dann wenn auch die Satznummern gleich sind. Bis vor gut einem Jahr hatten wir nie Probleme damit. Jetzt ist es aber so, dass die FMTJRN3 welche über STRQMQRY ausgegeben wurde nicht immer die gleiche Satzreihenfolge wie die in FMTJRN2 hat obwohl sie daraus erzeugt wird. Somit stimmen die Daten wie PROGRAMM und JOB nicht mehr zusammen zu den Daten. Wie gesagt, manchmal funktionierts manchmal nicht.

Es gibt keine Indizes auf die #FMTJRN2, weiß jemand warum er in die Ausgabedatei dann eine andere Sortierreihenfolge verwendet wie die, die er schon hat?

Was gibt es für alternative Tools?

Ich hoffe ihr könnte mir weiter helfen.

Viele Grüße Harald

[Fuerchau]

Ich würde nie mit einer RRN hier arbeiten. Im Journal gibts doch eine eindeutige Folgenummer die mit ausgegeben wird.

[harkne]

Das Problem ist, die Daten werden aus FMTJRN3 in eine Datei FMTJRN1 kopiert welche das gleiche Aussehen wie die Datei hat auf die der DSPJRN ausgeführt wurde.

Also z.B. DSPJRN auf eine Datei Namens PF1
Es wird ein CPYF (1 Satz) mit PF1 in FMTJRN1 gemacht mit CRTPF(*YES) somit hat FMTJRN1 das Aussehen der Ursprungsdatei.
Dann DSPJRN in FMTJRN2
Das Datenfeld aus FMTJRN2 in FMTJRN3
Und dann ein CPYF von FMTJRN3 in FMTJRN1 mit NOCHK.
Und jetzt FMTJRN2 und FMJRN1 verbinden. Das geschieht mit der relativen Record number da ich die Nummer aus dem DSPJRN ja dort nicht mehr habe.

[BenderD]

... schau dir mal
http://bender-dv.de/Snippets.html#ANZJRN
an.

D*B

PS: ist zwar schon ein wenig älter, sollte es aber tun.

[harkne]

@Bender
Ich glaube das reicht mir. Das ist natürlich besser weil gleich eine Datei erstellt wird die alle Datenfelder beinhaltet. Perfekt. Ich versuche das mal in unser vorhandenes Programm einzubinden. Bei uns hier ist der FMTJRNE ein Command und wenn ich das richtig gesehen habe, wird im Beispiel eine Datei verwendet.

Vielen Dank

[Fuerchau]

Wenn möglicherweise die Ausgabedatei noch existiert, solltest du die Replace-Option wählen oder gleich einen DLTF vorher einbauen.
Die Alternative dazu ist ja nun statt STRQMQRY einen RUNSQL (ohne STMT) durchzuführen.
Da kannst du einen "create or replace table as (select ....) with data" ausführen.
Wenn die Sortierfolge der Quelle erhalten bleiben soll, hänge einen "order by rrn(file)" an.

[harkne]

Ich habe mir Teile von Benders Quelle geschnappt.
Da wir ja mit dem Befehl arbeiten und dort die Möglichkeit von OUTFILE TYPE möglich ist, habe ich das Problem dass die DSPJRN Datei immer unterschiedlich aussieht.

@Bender, du wählst in diesem Codebeispiel die Felder mit SELECT JO..., JO... usw aus. Ich hätte gerne SELECT *.J, *.D, aber bei *.J sollte das Datenfeld nicht dabei sein.

Wahrscheinlich einfach hinterher einen ALTER TABLE DROP FELD oder kann ich bei der Erstellung irgendwas angeben dass er eine Spalte nicht dazu nimmt?

[BenderD]

... das ist kein Code"beispiel", sondern ein Programm, das den Namen der journalisierten Datei und von bis und den gewünschten Namen der Zieldatei als Parameter bekommt und dann universell eine strukturierte Zieldatei erstellt, die relevante Journalfelder und den aufgedröselten Datensatz enthält. Auch da kann man einen Command davorbasteln oder wenns denn sein muss, Felder weglassen oder dazu erfinden...

D*B

PS: mittlerweile gibt es da auch table_functions, wenn man das mit schlechterer Ergonomie haben will.

[harkne]

@BenderD
Yupp schlechte Wortwahl von mir. Du benutzt allerdings keinen OUTFILE TYPE bei der Ausgabe. Deshalb meinte ich habe mir Teile des Programms was ich gebraucht habe heraus genommen. Durch den OUTFILE TYPE entscheidet dann der der den Befehl anwendet was "relevante" Journalfelder sind und was nicht. Da das hier schon drin war habe ich das vorhandene bei uns angepasst.

[BenderD]

... sorry, war nicht abwertend gemeint. Das Programm ist eines meiner persönlichen Toolumgebung, das es in mehreren Anpassungen gibt. Ich habe eine Variante davon vor 11 Jahren konsolidiert und als Open Source auf meine Webseite gestellt. Aktuell habe ich nicht nachgesehen, was das im Detail tut (und was nicht). Das ist ja auch open source, damit man das selber anpassen kann.

D*B