All X'0D' lost during reading line sequential file using microfocus se
in [Cobol]
|
From: Robert on 24 Jul 2008 23:31 On Thu, 24 Jul 2008 17:51:59 -0700 (PDT), taoxianfeng(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. A variable length record is just a string of bytes terminated by x'0D'. Line sequential parses the records for you. You are complaining about that. Line sequential just gives you 512 bytes of raw data, allowing you to parse them yourself. Is the problem that you don't know the length of an input line sequential record? Why do you care? The tail end will be filled with spaces. You COULD search right to left for a non-space, or follow Richard's instructions for getting the length.
From: Robert on 25 Jul 2008 00:05 On Thu, 24 Jul 2008 18:34:40 -0700 (PDT), taoxianfeng(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.
From: Bill Gunshannon on 25 Jul 2008 11:42 In article <e5ji84te3em3ejs7bi75271mgekufiu8ri(a)4ax.com>, Robert <no(a)e.mail> writes: > On Thu, 24 Jul 2008 18:34:40 -0700 (PDT), taoxianfeng(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. Ummm... No... Unix has always used 0x0A and I would be very surprised if AIX used anything different. > > 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. That would depend on a number of things primary of which would be the OS. Windows still supports FAT and FAT had two differnt kinds of text files. One delimited by size and one that ended upon the reaching a ^Z. There was no way I am aware of to determine which method a file used without examining the file. This caused a lot of headaches for people writing file transfer software as using the wrong method usually reulted in garbage on the end of the file. bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves billg999(a)cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include <std.disclaimer.h>
From: Robert on 25 Jul 2008 20:11 On Thu, 24 Jul 2008 23:27:52 -0700 (PDT), taoxianfeng(a)gmail.com wrote: >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). Most of those FD clauses are superfluous for LINE SEQUENTIAL. You should have written FD INFILE1 RECORD VARYING FROM 1 TO 5000 DEPENDING ON WK-INREC1-LEN. BLOCK CONTAINS 0 is a silly mainframeism. >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. I'm happy to see you took Richard's suggestion. >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'". You are correct; I got them backwards. 0A is Unix, 0D is Mac. >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? The reasons are: 1. Characters less than x'20' (space) are Control Characters, not data. They are instructions to the file system. 2. Due to non-standardization, most file systems are generalized to handle formats from other operating systems. Most Unix programs, with the notable exception of vi, can read Windows files terminated by 0D0A. Most Windows programs can read Unix-style files terminated by 0A. The discarding of your 0Ds is a side-effect of that generalization. This assignment appears to be a 'trick question' to teach you that different operating systems use different standards. Now let's look at solutions. Bill Klein showed how to specialize the Micro Focus file system to recognize only 0A. That's specific to Micro Focus, not Cobol. A Unix flavored solution would be to run the input file through the 'tr' program before piping it into your Cobol program, like this: cat INFILE1 | tr "\r| "\v" | yourcobol | tr "\v" "\r" > OUTFILE1 Confusing, right? It is translating 0D (Ctrl-M = return) into 0B (Ctrl-K = vertical tab) before your program and translating it back after. My suggestion to parse lines yourself, recognizing only 0A, is pure Cobol. It will work with any compiler, on any machine. To handle the last sector on Micro Focus, 1. Initialize the record area to low-values (binary zeros) 2. Read 3. If return-code - '92' *> short record remember you are at end of file search backward for the first non-low-value to get sector length
From: Robert on 25 Jul 2008 22:22
On 25 Jul 2008 15:42:42 GMT, billg999(a)cs.uofs.edu (Bill Gunshannon) wrote: >In article <e5ji84te3em3ejs7bi75271mgekufiu8ri(a)4ax.com>, > Robert <no(a)e.mail> writes: >> On Thu, 24 Jul 2008 18:34:40 -0700 (PDT), taoxianfeng(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. > >Ummm... No... Unix has always used 0x0A and I would be very surprised if >AIX used anything different. > >> >> 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. > >That would depend on a number of things primary of which would be the OS. >Windows still supports FAT and FAT had two differnt kinds of text files. >One delimited by size and one that ended upon the reaching a ^Z. There >was no way I am aware of to determine which method a file used without >examining the file. This caused a lot of headaches for people writing >file transfer software as using the wrong method usually reulted in >garbage on the end of the file. 1A ceased marking end of file with MSDOS 2.0, 25 years ago. Ctrl-Z now means Undo under Windows and Suspend Task under Unix. |