View Full Version : IFS Dateien mit Satzende CRLF oder LF erkennen.
Hallo zusammen,
bisher haben wir Dateien im IFS immer mit CRLF am Satzende erhalten.
Jetzt kommen die auf einmal gemischt. Es heißt, ich weiß nicht ob sie mit LF oder CRLF enden.
Gibt es eine "einfache" Möglichkeit dies über RPG oder SQL fest zu stellen.
Ich habe mir schon überlegt eventuell nach x'0D25' (CRLF) zu suchen, aber ich weiß nicht wie ich diesen Hexwert im SQL angeben kann
Ich hoffe auf Eure Hilfe
Viele Grüße Harald
CPYFRMIMPF erledigt das vollautomatisch, zumal als Satzbegrenzer *ALL möglich ist.
CPYFRMIMPF kommt auch mit "Einfelddateien" zurecht.
Es lohnt sich, darüber nachzudenken.
wie Baldur schon schrieb ...
Hex im SQL einfach mit ... where hex(Substr(Feldname....) ='0D25'
Wir benutzen CPYFRMSTMF, kann ich da auch bedenkenlos *ALL angeben?
Ja natürlich.
Ich bekomme z.B. Dateien aus Windows, die arbeiten meist mit CR+LF, oder aus Linux, die arbeiten i.d.R nur mit LF.
Wobei ja *ALL der Default ist.
Habe das gerade mit SQL verucht:
SELECT LINE FROM TABLE(QSYS2.IFS_READ_UTF8(PATH_NAME => '/SpareParts/SCAN/SMC/RECEIVE/SAVE/S1000151.1088716.#.SCANDATA_PROD_20240314_10311667 .TXT'))
where locate(x'0D', line) >0;
Es funktioniert aber nicht, weil ich denke, dass im Feld LINE CRLF nicht zu finden ist.
Wenn ich es mit SELECT HEX(LINE) mache, dann sehe ich auch nur die Hex Zeichen der Daten und nicht 25 oder 0D.
Was mache ich falsch?
Danke.
Vermutlich macht das ifs lesen das genauso wie cpyfrmstmf.
Es erkennt das ende der Zeile und lässt CR/LF weg.
mein Post bezog sich allgemein auf das Abfragen von Hex Werten im SQL
Danke Robi, kein Problem.
Frage an *ALL: Können wir bedenkenlos auf *ALL beim CPYFRMSTMF umstellen (aktuell haben wir CRLF)? Gibt es der Wert *ALL schon immer und wenn ja, dann habe ich echt keine Ahnung, wieso wir CRLF verwendet haben.
Da wir nun massig Dateien empfangen haben mit LF, aber auch mit CRLF muss ich die Dateien ermitteln, die LF haben, damit wir einen Wiederanlauf starten können.
Hat jemand eine Idee?
qsh grep ist dein Freund:
https://www.ibm.com/docs/da/aix/7.3?topic=g-grep-command
Als Pattern wäre denkbar, wenn es denn bereits CCSD 1141/273 ist.
"^[\x0D]\x25"
Ansonsten "^[\x0D]\x0A"
Erklärung: ^[\x0D] = nicht CR, gefolgt von \x0A (LF).
Ich habe mir einen Code aus dem Internet geholt
Die Variable RTVDTA liefert mir hex 25 00 an Stelle 81 und 82
Wenn ich die Datei über Notepad++ aufmache ist aber dort ein CR LF
Weiß jemand warum das sein kann?
Ich habe Zeile 25 bis 28 angepasst in meiner Version aber das ist nicht wichtig.
Ich habe natürlich auch meine Datei angegeben
01 ctl-opt option(*srcstmt) dftactgrp(*no) ;
02 dcl-pr OpenFile pointer extproc('_C_IFS_fopen') ;
03 *n pointer value ; //File name
04 *n pointer value ; //File mode
05 end-pr ;
06 dcl-pr ReadFile pointer extproc('_C_IFS_fgets') ;
07 *n pointer value ; //Retrieved data
08 *n int(10) value ; //Data size
09 *n pointer value ; //Misc pointer
10 end-pr ;
11 dcl-pr CloseFile extproc('_C_IFS_fclose') ;
12 *n pointer value ; //Misc pointer
13 end-pr ;
14 dcl-s PathFile char(50) ;
15 dcl-s OpenMode char(5) ;
16 dcl-s FilePtr pointer inz ;
17 dcl-s RtvData char(32767) ;
18 PathFile = '/SIMON/test_read.txt' + x'00' ;
19 OpenMode = 'r' + x'00' ;
20 FilePtr = OpenFile(%addr(PathFile):%addr(OpenMode)) ;
21 if (FilePtr = *null) ;
22 dsply ('fopen unable to open file') ;
23 return ;
24 endif ;
25 dow (ReadFile(%addr(RtvData):32767:FilePtr) <> *null);
26 RtvData = %xlate(x'00':' ':RtvData) ; //End of record null
27 RtvData = %xlate(x'25':' ':RtvData) ; //Line feed (LF)
28 RtvData = %xlate(x'0D':' ':RtvData) ; //Carriage return (CR)
29 dsply %subst(RtvData:1:52) ;
30 RtvData = ' ' ;
31 enddo ;
32 CloseFile(%addr(PathFile)) ;
33 return ;