PDA

View Full Version : RPG Dateifehler



KingofKning
27-11-13, 08:56
Hallo,
ich habe hier ein Programm welches Belege zuordnen soll. Leider gibt es da Überschneidungen im Belegnummernkreis, so daß er er sich Datensätze aus dem Jahr 2004 anstatt 2013 holt.

Da ich genau kein RPG Programmierer bin, wollte ich hingehen und habe eine View erstellt wo ich nur die Sätze ab 2013 erscheinen lasse.

Dummerweise bekomme ich jetzt beim Aufruf den Fehler:

Fehlernachricht CPF4131 wurde während OPEN für Datei AKO01PF angezeigt.
Fehler beim Aufruf des Indexierprogrammes ARCHIVP/ARIDXAS..
Client-Anforderung - Ausführen des Programms ARCHIVP/ICCRTIDX.
Aktualitätsprüfung für Datei, AKO01PF Bibliothek ARCHIVP, Teildatei
AKO01PF.
Fehlernachricht CPF4131 wurde während OPEN für Datei AKO01PF angezeigt.
Fehler beim Aufruf des Indexierprogrammes ARCHIVP/ARIDXAS..

Aktualitätsprüfung fällt eigentlich als Ursache weg, da das Programm frisch gewandelt ist.

Kann es sein das er meine View nicht mag? Müßte ich die gegen eine LF ersetzen?

In dem Programm wird nur mit der Belegnummer zugegriffen, aber nicht mit dem Datum.

// Datensatz in Anwendungsdatei lesen
chain KLIST_AK AKO01PF;
if not %found; // Wird kein Satz gefunden ...
K_FAKT = 6; // ... auch in Auftrags-History nachsehen
chain KLIST_AK AKO01PF;
if not %found; // Auch kein Satz gefunden ...
*IN99 = *on; // ... Fehlerbedingung markieren ...
leavesr; // und die Unterroutine verlassen.
endif;
endif;

Wie müßte ich das Programm dann abwandeln um zu sagen wenn das Feld AKKDT1 < 2013 ist dann such den nächsten Satz?

Quasi ein
while akkdt1 < 2013
chain
end.
Das halt nur in RPG

Für Hinweise dankbar.

GG

dschroeder
27-11-13, 09:24
Hallo,

du schreibst nicht, wie die KLIST aussieht. Deshalb nur eine allgemeine Antwort:

Eine Schleife, die solange läuft, wie das Datum < 2013 ist, könnte so aussehen:

dow akkdt1 < d'01.01.2013';
// In der Schleife einen Satz weiterlesen:
read AKO01PF;
enddo;

Es gibt noch den Befehl "reade" (heißt "read equal"). Dort gibt man einen Schlüssel mit. Der Befehl liest den nächsten Datensatz. Aber nur, wenn der nächste Datensatz den gewünschten Schlüssel hat.
reade KLIST_AK AKO01PF;
- Ob das geht, hängt vo der KLIST ab.


Schneller geht es eventuell mit folgendem Dateipositionierungsbefehl:
Falls das mit der KLIST zu machen ist, könnte man die 2013er-Sätze aber auch mit SETGT einfach überspringen:
... keylist anpassen
SETGT KLIST_AK AKO01PF;


Gruß,
Dieter

KingofKning
27-11-13, 09:58
Hallo Dieter,
Klist sieht zur Zeit so aus.
C** Firmennummer und Barcodenummer
C KLIST_AK KLIST
C KFLD K_FA
C KFLD K_ABKZ
C KFLD K_FAKT
C KFLD K_ANR
C*
C *LIKE DEFINE AKFA K_FA
C *LIKE DEFINE AKABKZ K_ABKZ
C *LIKE DEFINE AKFAKT K_FAKT
C *LIKE DEFINE AKANR K_ANR

Könnte ich da das Feld akkdt1 anfügen und mit 2013 füllen und den chain dann durch SETGT ersetzen?

GG

mk
27-11-13, 10:03
Hallo,

evtl. auch eine Möglichkeit :

Anlegen einer DDS Logischen Datei mit select auf das Datumsfeld


Dann muss im RPG nur den Namen der logischen Datei angeben
und alles läuft weiter

Gruß
Michael

dschroeder
27-11-13, 10:07
Das Feld kannst du nur anfügen, wenn die Datei, die du mit dem RPG-Programm verarbeitest, das Datum auch in seiner Schlüsselliste hat. Du musst also in der Datei AKO01PF nachsehen, wie die Schlüsselliste darin definiert ist. Hinter dem Schlüssel K_ANR müsste dann der Schlüssel AKKDT1 stehen. Vorsicht: Wenn die Datei nicht die korrekte Schlüsselliste hat, dann ändere das bitte nicht so einfach!

Vielleicht findest du noch eine weitere logische Datei, die die richtige Schlüsselliste beinhaltet.

mk
27-11-13, 10:41
Hi

evtl. vorher ein OPNQRYF mit select auf die Daten
und ein OVRDBF auf die Inputdatei.
Das könnte auch funktionieren

Fuerchau
27-11-13, 10:47
Aktualitätsprüfung für Datei, AKO01PF Bibliothek ARCHIVP, Teildatei
AKO01PF.

Der Fehler ist normalerweise nach einer Umwandlung weg.
Es sei denn, du hat über 2 Libs ggf. 2 Versionen der Datei.

KingofKning
27-11-13, 11:32
Hallo Fuerchau,

die Datei ist qualifiziert angegeben.

0020.00 H dftactgrp(*no) actgrp(*caller) bnddir('IAPDIR01') 060303
0021.00 080929
0022.00 F** "Auftragskopfdatei" EXTFILE('XXX01/AKO01PF') 131124
0023.00 FAKO01PF IF E K DISK EXTFILE('ARCHIVP/AKO01PF') 131124
0024.00 080929

Sprich die View steht in der Archivp und greift auf die Datei ako01pf in der Originallib XXX01 zu.

Deswegen bin ich ja auch der Meinung das er ein anderes Problem hat.

In der View ist die Datei auch qualifiziert angegeben.

Datum/Uhrzeit der letzten Änderung. . . . : 24.11.13 12:50:29
Datum/Uhrzeit der letzten Sicherung . . . : 26.11.13 23:02:13
Datum/Uhrzeit des letzen Zurückspeicherns :
Datum der letzten Benutzung . . . . . . . : 27.11.13
Anzahl der benutzten Tage . . . . . . . . : 2
Rücksetzungsdatum . . . . . . . . . . . :
Anzahl der Datenteildateien . . . . . . . : 1
Basiert auf Datei . . . . . . . . . . . . : AKO01PF
Bibliothek . . . . . . . . . . . . . . : XXX01
Teildatei . . . . . . . . . . . . . . . : AKO01PF
Satzformatliste
Satz- Fmt.Ebenen-
Format Felder Länge ID
AKO01PF 329 1307 44D35B0ECA50B
Text . . . . . . . . . . . . . . . . . . . : FORMAT0001
Gesamtanzahl Formate . . . . . . . . . . . . : 1
Gesamtanzahl Felder . . . . . . . . . . . . : 329


GG

B.Hauser
27-11-13, 12:03
Da er allerdings eine VIEW generiert hat und eine VIEW IMMER ungeschlüsselt ist, kann er nicht einfach die physische Datei durch eine View ersetzen.
Die einfachste Möglichkeit ist an dieser Stelle tatsächlich eine DDS beschriebene logische Datei mit den gleichen Schlüssel-Feldern und entsprechenden Select/Omit Anweisungen zu erstellen, diese im RPG-Programm angeben und das Programm anschließend kompilieren.

Anstatt der DDS beschriebenen logischen, könnte man auch in Release 6.1 und höher einen SQL-Index mit den entsprechenden Schlüssel-Feldern und zusätzlicher WHERE-Bedingung generieren und diesen Index in den F-Bestimmungen angeben. (SQL Indices können zwar in SQL-Statements nicht direkt angegeben werden, wohl aber mit native I/O wie geschlüsselte logische Dateien verwendet werden.

Birgitta

Fuerchau
27-11-13, 12:40
CPF4131 deutet immer auf Ungleichheit der Format-ID's zwischen datei zur Compile- und zur Laufzeit.
Im Joblog steht eigentlich genaueres.

Ggf. ist das Problem der Compiler, dass zum Compilezeitunkt eine andere Version der Datei in der LIBL gefunden wird.
Auch das wird aber in der Spoolausgabe angegeben (Satzformat von welcher Datei).

Vielleicht wird "EXTFILE" zur Compilezeit nicht ausgewertet. Es funktioniert ja auch nicht, wenn hier eine Variable angegeben wird.