All X'0D' lost during reading line sequential file using microfocus se
in [Cobol]
|
From: taoxianfeng on 24 Jul 2008 21:45 On Jul 25, 4:30 am, Richard <rip...(a)azonic.co.nz> wrote: > On Jul 24, 9:40 pm, taoxianf...(a)gmail.com wrote: > > > 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. > > LINE SEQUENTIAL is defined as being variable records where the end of > each record is indicated (on AIX) by a x'0D' character. These are > added automatically when writing and stripped off when reading. > > You have specified that the file is 'line sequential' and then > complain when you get the designated behavior. > > Specify the file like this: > > SELECT TextFile > ASSIGN whatever > ORGANIZATION LINE SEQUENTIAL > FILE STATUS .. > . > > DATA DIVISION. > FILE SECTION. > FD TextFile > RECORD VARYING FROM 0 TO 256 DEPENDING ON TSize. > 01 TextLine. > 03 TLc PIC X(256). > > TSize will contain the record length. You can insert a x"0D" after > that or use reference modification on the compares, or just compare > lengths. I don't agree.Isn't line sequential file delimited by X'0A'? These are the documentation I referred: (JP)http://www.microfocus.co.jp/manuals/SE40/fhorgs.htm (EN)http://supportline.microfocus.com/Documentation/books/sx50/ sx50indx.htm Line Sequential Files The primary use of line sequential files (which are also known as "text files" or "ASCII files") is for display-only data. Most PC editors, for example Notepad, produce line sequential files. In a line sequential file, each record in the file is separated from the next by a record delimiter. The record delimiter, which is the line feed (x"0A") character, is inserted after the last non-space character in each record. A WRITE statement removes trailing spaces from the data record and appends the record delimiter. A READ statement removes the record delimiter and, if necessary, pads the data record (with trailing spaces) to the record size defined by the program reading the data. To define a file as line sequential, specify ORGANIZATION IS LINE SEQUENTIAL in the SELECT clause for the file in your COBOL program, for example: select lineseq assign to "lineseq.dat" organization is line sequential. Or could you give me the documentation link saying that line sequential file is delimited by X'0D'? Thank you very much
From: taoxianfeng on 25 Jul 2008 02:24 On Jul 25, 1:05 pm, Robert <n...(a)e.mail> wrote: > On Thu, 24 Jul 2008 18:34:40 -0700 (PDT), taoxianf...(a)gmail.com wrote: > >I don't agree.Isn't line sequential file delimited by X'0A'? > > The operating system, not Cobol, specifies the line terminator. AIX and other Unix use > x'0D'. Old Macs (OS9) used 0A. Windows uses 0D0A. > > A FILE is delimited by its size (in the directory), not by a character. If your textbook > says a file is terminated by 0A or 1A, it is 25 years out of date. Well...seems I failed to address it clearly.Let's read MY code: SELECT INFILE1 ORGANIZATION IS LINE SEQUENTIAL ASSIGN TO EXTERNAL INFILE1. FD INFILE1 DATA RECORD IS IN- REC1 RECORDING MODE V RECORD IS VARYING IN SIZE FROM 1 TO 5000 DEPENDING ON WK-INREC1- LEN BLOCK CONTAINS 0. 01 IN-REC1 PIC X(5000). 01 WK-INREC1-LEN PIC 9(008). 1. The RECORD LENGTH will be stored into the WK-INREC1-LEN variable automatically when executing "READ INFILE1" each time. And, believe or not, it's dedided by X'0A' like that: 1 dot for 1 byte;0D for 1 byte ......0D.....0A (record length:12) ...0D......0D....0A (record length:14) I know the rest of IN-REC1 is filled by space (or nothing if using SPACEFILL=OFF); I also know the method of searching for the 1st non- space reading from right to left. BUT I DON'T NEED THEM since I have no problem about the length of each record. 2.The doc I referred to is saying "The record delimiter, which is the line feed (x"0A") character". I didn't mean file delimiter(EOF,X'1A' or something else) either. I'm just talking about RECORD DELIMITER or LINE DELIMITER and doubting your "AIX and other Unix use x'0D'". 3.Take the example again, my ESSENTIAL QUESTION is ALL X'0D' WERE LOST LIKE THIS: input file: ......0D.....0A ...0D......0D....0A output file: ...........0A .............0A IF, the record is delimited with X'0D' as you said, then how can I get it in the output file since it exists in the input file?
From: taoxianfeng on 25 Jul 2008 02:27 On Jul 25, 1:05 pm, Robert <n...(a)e.mail> wrote: > On Thu, 24 Jul 2008 18:34:40 -0700 (PDT), taoxianf...(a)gmail.com wrote: > >I don't agree.Isn't line sequential file delimited by X'0A'? > > The operating system, not Cobol, specifies the line terminator. AIX and other Unix use > x'0D'. Old Macs (OS9) used 0A. Windows uses 0D0A. > > A FILE is delimited by its size (in the directory), not by a character. If your textbook > says a file is terminated by 0A or 1A, it is 25 years out of date. Well...seems I failed to address it clearly.Let's read MY code: SELECT INFILE1 ORGANIZATION IS LINE SEQUENTIAL ASSIGN TO EXTERNAL INFILE1. FD INFILE1 DATA RECORD IS IN-REC1 RECORDING MODE V RECORD IS VARYING IN SIZE FROM 1 TO 5000 DEPENDING ON WK-INREC1-LEN BLOCK CONTAINS 0. 01 IN-REC1 PIC X(5000). 01 WK-INREC1-LEN PIC 9(008). 1. The RECORD LENGTH will be stored into the WK-INREC1-LEN variable automatically when executing "READ INFILE1" each time. And, believe or not, it's decided by X'0A' like that(the input read counter also proves it): 1 dot for 1 byte;0D for 1 byte ......0D.....0A (record length:12) ...0D......0D....0A (record length:14) I know the rest of IN-REC1 is filled by space (or nothing if using SPACEFILL=OFF); I also know the method of searching for the 1st non- space reading from right to left. BUT I DON'T NEED THEM since I have no problem about the length of each record. 2.The doc I referred to is saying "The record delimiter, which is the line feed (x"0A") character". I didn't mean file delimiter(EOF,X'1A' or something else) either. I'm just talking about RECORD DELIMITER or LINE DELIMITER and doubting your "AIX and other Unix use x'0D'". 3.Take the example again, my ESSENTIAL QUESTION is ALL X'0D' WERE LOST LIKE THIS: input file: ......0D.....0A ...0D......0D....0A output file: ...........0A .............0A IF, the record is delimited with X'0D' as you said, then how can I get it in the output file since it exists in the input file?
From: Richard on 25 Jul 2008 03:41 On Jul 25, 12:51 pm, taoxianf...(a)gmail.com wrote: > On Jul 25, 2:28 am, Robert <n...(a)e.mail> wrote: > > > > > On Thu, 24 Jul 2008 02:40:37 -0700 (PDT), taoxianf...(a)gmail.com wrote: > > >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 > > > Define the file as record sequential, record length 512, and parse the lines yourself. The > > last short block is a little tricky.- Hide quoted text - > > > - Show quoted text - > > Do you mean fixed-length record sequential? The record exported from > AIX DB2 is variable-length so I think it will be even worse. Sequential fixed length files have nothing but the data bytes, no header or termination bytes. Defining the file as sequential with a fixed length will allow you to read (and write) whatever bytes you want but it will read <record size> bytes and you will get an exception on the last record because it does not fill the record buffer. You can have single byte sequential to avoid the last record problem, but it may be somewhat slow. Set up the file as sequential with single byte record and read into a buffer in W-S until you find the record terminator.
From: taoxianfeng on 25 Jul 2008 04:22
On Jul 25, 4:41 pm, Richard <rip...(a)azonic.co.nz> wrote: > On Jul 25, 12:51 pm, taoxianf...(a)gmail.com wrote: > > > > > > > On Jul 25, 2:28 am, Robert <n...(a)e.mail> wrote: > > > > On Thu, 24 Jul 2008 02:40:37 -0700 (PDT), taoxianf...(a)gmail.com wrote: > > > >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 > > > > Define the file as record sequential, record length 512, and parse the lines yourself. The > > > last short block is a little tricky.- Hide quoted text - > > > > - Show quoted text - > > > Do you mean fixed-length record sequential? The record exported from > > AIX DB2 is variable-length so I think it will be even worse. > > Sequential fixed length files have nothing but the data bytes, no > header or termination bytes. Defining the file as sequential with a > fixed length will allow you to read (and write) whatever bytes you > want but it will read <record size> bytes and you will get an > exception on the last record because it does not fill the record > buffer. You can have single byte sequential to avoid the last record > problem, but it may be somewhat slow. > > 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. |