All X'0D' lost during reading line sequential file using microfocus se
in [Cobol]
|
From: taoxianfeng on 26 Jul 2008 11:41 Actually I have also tried INSERTNULL=ON (default is on and I'm using off now) in the extfh config file and the N runtime switch(default is on). All the other characters less than X'20' were successfully outputted with a X'00' (null) before them. BUT THE X'0D' STILL DISAPPEARED. I really can't believe this and I'm getting confused why some file handler options and runtime switches seem to be conflicting or doing the same thing, such as: INSERTNULL and N runtime switch EXPANDTAB/INSERTTAB and T runtime switch and the file handler options have higher priority. Who can explain it? On Jul 26, 12:22 pm, "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote: > I think the additional information that you need was in another note that I > received which states, > > " ...the information you are after is there but hidden away in the > documentation. The File Handler configuration option INSERTNULL allows any > character to be added to a line sequential file by adding a null character > before each character less than x"20". These then get stripped out on the read. > Again this is not documented fully in the INSERTNULL documentation but is in the > documentation for the "N run-time switch" > > Therefore, it seems that a READ (with MF and Line Sequential) will ALWAYS "strip > away" characters < X"20". > > -- > Bill Klein > wmklein <at> ix.netcom.com<taoxianf...(a)gmail.com> wrote in message > > news:c6cb331a-8e7d-493a-8d3b-872e94b2c6fd(a)j7g2000prm.googlegroups.com... > On Jul 25, 6:42 pm, "William M. Klein" <wmkl...(a)nospam.netcom.com> > wrote: > > > > > > > OK, I think I understand the "desire". You want to use X"0A" but *not* X"0D0A" > > as the record delimiter for line sequential files. (Something that is > > "operating system" and/or application dependent). Your desire is to be able to > > have X"0D" *data* in LINE SEQUENTIAL files. > > > From a "usually reliable source" Micro Focus *does* support (allow) this. The > > following is the solution that I was provided: > > *** > > "File Handler configuration option LSRECDELIM set in EXTFH.CFG can be used to > > set the record delimiter used for LSEQ files. > > > Syntax: > > > LSRECDELIM=[0A|0D0A] > > > Parameters: > > > 0A The hexadecimal character x"0A" is used as the record delimiter for line > > sequential files. > > > 0D0A The hexadecimal characters x"0D0A" are used as the record delimiter for > > line sequential files." > > > -- > > Bill Klein > > wmklein <at> ix.netcom.com<taoxianf...(a)gmail.com> wrote in message > > >news:75979a92-6155-4583-9cf4-c80425d1b015(a)v39g2000pro.googlegroups.com.... > > > > Hi all > > > > I'm writing a batch source to match 2 input files which is exported > > > from AIX DB2 giving the matched records. > > > > All other characters are going well except X'0D':all of them get lost > > > when reading the input files into the program. I tried many file > > > handler options and runtime switches but no one worked. Any advice is > > > appreaciated. Thanks in advance! > > > > Line sequential file, variable-length record. > > > > This is the file handler I'm using now: > > > [XFH-DEFAULT] > > > STRIPSPACE=OFF > > > INSERTNULL=OFF > > > EXPANDTAB=OFF > > > > AIX 5.3, Microfocus Server Express 5.0- Hide quoted text - > > > - Show quoted text - > > Thanks for you advice. But I tried it and the result is the same. I > think the LSRECDELIM option just affect the record delimiter (0A or > 0D0A) but failed to change something for a single 0D.- Hide quoted text - > > - Show quoted text -
From: William M. Klein on 26 Jul 2008 14:26 If you are current on your Micro Focus support (i.e. paid up), then the place to ask this questions is via supportline. HOWEVER, the bottom-line is that if you define a file as line sequential, then you will have problems trying to read records that include (as data) bytes with characters less than X"20". This is documented - even if not well. Treating the file as Record Sequential and "building" it yourself will work (as you have indicated). However, there is also the question of HOW and WHY you have "line sequential" files with X'0D" "data" or any other bytes with < X"20". These may cause problems with other applications - not just Micro Focus COBOL (as the X"1?" notes in this thread have indicated and as previous notes discussing "tabs" have indicated.) -- Bill Klein wmklein <at> ix.netcom.com <taoxianfeng(a)gmail.com> wrote in message news:a1910703-f28b-44d8-a0b0-94e10617dbbe(a)k36g2000pri.googlegroups.com... Actually I have also tried INSERTNULL=ON (default is on and I'm using off now) in the extfh config file and the N runtime switch(default is on). All the other characters less than X'20' were successfully outputted with a X'00' (null) before them. BUT THE X'0D' STILL DISAPPEARED. I really can't believe this and I'm getting confused why some file handler options and runtime switches seem to be conflicting or doing the same thing, such as: INSERTNULL and N runtime switch EXPANDTAB/INSERTTAB and T runtime switch and the file handler options have higher priority. Who can explain it? On Jul 26, 12:22 pm, "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote: > I think the additional information that you need was in another note that I > received which states, > > " ...the information you are after is there but hidden away in the > documentation. The File Handler configuration option INSERTNULL allows any > character to be added to a line sequential file by adding a null character > before each character less than x"20". These then get stripped out on the > read. > Again this is not documented fully in the INSERTNULL documentation but is in > the > documentation for the "N run-time switch" > > Therefore, it seems that a READ (with MF and Line Sequential) will ALWAYS > "strip > away" characters < X"20". > > -- > Bill Klein > wmklein <at> ix.netcom.com<taoxianf...(a)gmail.com> wrote in message > > news:c6cb331a-8e7d-493a-8d3b-872e94b2c6fd(a)j7g2000prm.googlegroups.com... > On Jul 25, 6:42 pm, "William M. Klein" <wmkl...(a)nospam.netcom.com> > wrote: > > > > > > > OK, I think I understand the "desire". You want to use X"0A" but *not* > > X"0D0A" > > as the record delimiter for line sequential files. (Something that is > > "operating system" and/or application dependent). Your desire is to be able > > to > > have X"0D" *data* in LINE SEQUENTIAL files. > > > From a "usually reliable source" Micro Focus *does* support (allow) this. > > The > > following is the solution that I was provided: > > *** > > "File Handler configuration option LSRECDELIM set in EXTFH.CFG can be used > > to > > set the record delimiter used for LSEQ files. > > > Syntax: > > > LSRECDELIM=[0A|0D0A] > > > Parameters: > > > 0A The hexadecimal character x"0A" is used as the record delimiter for line > > sequential files. > > > 0D0A The hexadecimal characters x"0D0A" are used as the record delimiter for > > line sequential files." > > > -- > > Bill Klein > > wmklein <at> ix.netcom.com<taoxianf...(a)gmail.com> wrote in message > > >news:75979a92-6155-4583-9cf4-c80425d1b015(a)v39g2000pro.googlegroups.com... > > > > Hi all > > > > I'm writing a batch source to match 2 input files which is exported > > > from AIX DB2 giving the matched records. > > > > All other characters are going well except X'0D':all of them get lost > > > when reading the input files into the program. I tried many file > > > handler options and runtime switches but no one worked. Any advice is > > > appreaciated. Thanks in advance! > > > > Line sequential file, variable-length record. > > > > This is the file handler I'm using now: > > > [XFH-DEFAULT] > > > STRIPSPACE=OFF > > > INSERTNULL=OFF > > > EXPANDTAB=OFF > > > > AIX 5.3, Microfocus Server Express 5.0- Hide quoted text - > > > - Show quoted text - > > Thanks for you advice. But I tried it and the result is the same. I > think the LSRECDELIM option just affect the record delimiter (0A or > 0D0A) but failed to change something for a single 0D.- Hide quoted text - > > - Show quoted text -
From: HeyBub on 26 Jul 2008 17:07 taoxianfeng(a)gmail.com wrote: >> >> Set up the file as sequential with single byte record and read into a >> buffer in W-S until you find the record terminator.- Hide quoted >> text - >> >> - Show quoted text - > > umm...It should be an approach.Probably a bit slow. I will have a try. > > Thank you very much. A "bit slow" ain't the half of it. Fortunately, our compiler has a method of reading a file given {starting-byte} {length of string to read}. To read the file sequentially we do: MOVE 0 TO START-BYTE MOVE 32000 TO LENGTH-STRING. PERFORM UNTIL TOO-TIRED (read the file using START-BYTE and LENGTH-STRING) (determine length of record - ours ends with a TAB character) (process record) ADD LENGTH-OF-RECORD TO START-BYTE END-PERFORM
From: Richard on 26 Jul 2008 17:10 On Jul 27, 4:55 am, "Michael Mattias" <mmatt...(a)talsystems.com> wrote: > "Robert" <n...(a)e.mail> wrote in message > > news:u5im84d8rkk8mfioccqtv8iuklp7uvn2nb(a)4ax.com... > > > On 26 Jul 2008 13:47:04 GMT, billg...(a)cs.uofs.edu (Bill Gunshannon) wrote: > > It seems [hex] 1A means end of file on the console, not on disk files. > > It means end of file only to an application which wants it to mean end of > file. > > To many ancient applications, x'1A' does mean end of file... it started with > applications first written for the CP/M operating system and early MS-DOS > applications which DID use x'1A' as an end-of-file marker. I think that > stopped with MS-DOS 2.0, but some applications still retain the logic of > "x'1A'=EOF" > > (Remember using EDLIN? you could either type Ctrl+Z or use one of the > function keys (F6?) which did the same thing.) CP/M 1.x to 2.x files only held the end of file as a sector number so all file sizes were multiples of 128 bytes. Applications, such as text editors filled the last sector beyond the actual data with 0x1A as a convention. MS-DOS, even 1.0, did have the file size in bytes but many applications were converted from CP/M, or had versions for CP/M, and still used 0x1A. Even edlin was originally written for CP/M.
From: Richard on 26 Jul 2008 17:22
On Jul 27, 6:26 am, "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote: > If you are current on your Micro Focus support (i.e. paid up), then the place to > ask this questions is via supportline. > > HOWEVER, the bottom-line is that if you define a file as line sequential, then > you will have problems trying to read records that include (as data) bytes with > characters less than X"20". This is documented - even if not well. > > Treating the file as Record Sequential and "building" it yourself will work (as > you have indicated). However, there is also the question of HOW and WHY you > have "line sequential" files with X'0D" "data" or any other bytes with < X"20". > These may cause problems with other applications - not just Micro Focus COBOL > (as the X"1?" notes in this thread have indicated and as previous notes > discussing "tabs" have indicated.) > > -- > Bill Klein > wmklein <at> ix.netcom.com<taoxianf...(a)gmail.com> wrote in message > > news:a1910703-f28b-44d8-a0b0-94e10617dbbe(a)k36g2000pri.googlegroups.com... > Actually I have also tried INSERTNULL=ON (default is on and I'm using > off now) in the extfh config file > and the N runtime switch(default is on). > All the other characters less than X'20' were successfully outputted > with a X'00' (null) before them. > BUT THE X'0D' STILL DISAPPEARED. I really can't believe this and I'm > getting confused why some file handler > options and runtime switches seem to be conflicting or doing the same > thing, such as: > > INSERTNULL and N runtime switch > EXPANDTAB/INSERTTAB and T runtime switch > > and the file handler options have higher priority. > Who can explain it? The N and T runtime switch usage dates back to MF's Level II COBOL on 1982 and has been retained for compatability reasons in every MF Cobol since. |