All X'0D' lost during reading line sequential file using microfocus se
in [Cobol]
|
From: Bill Gunshannon on 26 Jul 2008 09:47 In article <5f2l849u1mjm8b5aguavl6gjpluiuftn39(a)4ax.com>, Robert <no(a)e.mail> writes: > 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. Hardly. Ity is not a part of DOS, it is a part of FAT and that is till with us and probably will be for quite some time still. > Ctrl-Z now means Undo under > Windows and Suspend Task under Unix. That is just what certain applications do with it. Undo is not a Windows command, it is something the various editors understand. And You Unix example is totally dependant on the shell in use as some of them do not support job control at all. Try this experiment! On your Windows Box open a window for command.com. type "COPY CON: JUNK" type in a few lines of text. at some point, type ^Z (that's the control key and the letter "Z"). hit return. Notice you are back to prompt and you now have the file JUNK containing what you typed. Again, this is behavior of the terminal driver but basicly it is that driver interpreting the ^Z as EOF on CON: and terminating the copy. I do not expect this behavior to ever go away in the MS world as long as we have keyboards for input!! 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: Anonymous on 26 Jul 2008 10:04 In article <5f2l849u1mjm8b5aguavl6gjpluiuftn39(a)4ax.com>, Robert <no(a)e.mail> wrote: >On 25 Jul 2008 15:42:42 GMT, billg999(a)cs.uofs.edu (Bill Gunshannon) wrote: [snip] >>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. Mr Wagner, here's a little experiment you might want to try on a Windows machine: Start ==> Run ==> cmd copy con hexfile this is a test <== press Enter key ^Z <== control-Z .... and see how Windows handles what you assert is an Undo. DD
From: Robert on 26 Jul 2008 12:41 On 26 Jul 2008 13:47:04 GMT, billg999(a)cs.uofs.edu (Bill Gunshannon) wrote: >In article <5f2l849u1mjm8b5aguavl6gjpluiuftn39(a)4ax.com>, > Robert <no(a)e.mail> writes: >> On 25 Jul 2008 15:42:42 GMT, billg999(a)cs.uofs.edu (Bill Gunshannon) wrote: >> 1A ceased marking end of file with MSDOS 2.0, 25 years ago. > >Hardly. Ity is not a part of DOS, it is a part of FAT and that is till >with us and probably will be for quite some time still. > >> Ctrl-Z now means Undo under >> Windows and Suspend Task under Unix. > >That is just what certain applications do with it. Undo is not a Windows >command, it is something the various editors understand. And You Unix >example is totally dependant on the shell in use as some of them do not >support job control at all. > >Try this experiment! > >On your Windows Box open a window for command.com. >type "COPY CON: JUNK" >type in a few lines of text. >at some point, type ^Z (that's the control key and the letter "Z"). >hit return. >Notice you are back to prompt and you now have the file JUNK containing >what you typed. I did that, then looked at the file with a hex editor. There wasn't a 1A at the end. I changed one of the characters in the middle to 1A, saved it, looked at it, 1A was still in the middle of the line. Then I copied it and looked at the copy. 1A was still in the middle and there was stuff after it. If 1A designated end of file, the stuff after it would be missing. However, 'type junk' and 'copy junk con' DID terminate on the 1A. I brought up a Unix shell -- ch -- under command.com. 'cat junk' DID stop on the 1A, but vi showed ^Z and cp copied the stuff following and 'wc -c junk' counted all. More baffling, 'cat junk >junk1' copied the 1A and the stuff following. It seems 1A means end of file on the console, not on disk files.
From: Michael Mattias on 26 Jul 2008 12:55 "Robert" <no(a)e.mail> wrote in message news:u5im84d8rkk8mfioccqtv8iuklp7uvn2nb(a)4ax.com... > On 26 Jul 2008 13:47:04 GMT, billg999(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.) MCM
From: Michael Mattias on 27 Jul 2008 09:43
"Robert" <no(a)e.mail> wrote in message news:l1tn841tkan6cu73ob3lq48sgju3revd21(a)4ax.com... > On Sat, 26 Jul 2008 17:19:09 -0700 (PDT), taoxianfeng(a)gmail.com wrote: > > DB2 is mainframe, not Unix. If your files were exported from DB2, it's not > clear why 0D > appears in the middle of a record, why it needs to be preserved nor why a > row would be > split across two records. This is NOT NORMAL. This gives me a thought .... I have encountered similar problems when the data itself contained delimiter characters. Yes, it does make you think your logic, your compliler or your utilities are acting naughty, when what is really happening is, "garbage in, garbage out." Worth checking methinks. MCM |