All X'0D' lost during reading line sequential file using microfocus se
in [Cobol]
|
From: Richard on 28 Jul 2008 00:14 On Jul 28, 3:42 pm, Robert <n...(a)e.mail> wrote: > On Sun, 27 Jul 2008 12:01:23 -0700 (PDT), Richard <rip...(a)azonic.co.nz> wrote: > >On Jul 28, 3:10 am, Robert <n...(a)e.mail> wrote: > >> On Sun, 27 Jul 2008 01:21:51 -0700 (PDT), taoxianf...(a)gmail.com wrote: > >> >Do you mean it would be impossible for us to get the 0D if Micro Focus > >> >simply discarded it? > > >> It's impossible when using LINE SEQUENTIAL. > > >> >I can't understand your "DB2 is mainframe, not Unix". It should be a > >> >series of cross-platform databases though each of them may different > >> >from each other.This is the documentation of DB2 for Unix: > >> >http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp > > >> For many years, DB2 on Unix was called UDB -- Universal Data Base. Evidently, IBM recently > >> changed the name to DB2. > > >You are wrong. The name of the product is, and has been, "DB2 > >Universal Database" which is available on z/OS, OS/390, iSeries, AIX/ > >Unix/Linux and Windows. Other products are "DB2 Connect" and "DB2 > >Warehouse Manager". > > In this book (published 2000), our friends in AS/400 land refer to it as UDB/400.http://books.google.com/books?id=lqtc0c3UjIMC&pg=PA1&lpg=PA1&dq=buy+u... """Preface. ... One reason for that success is the system's integrated database management system known as DB2 Universal Database for AS/400 (UDB/ 400).""" Also AS/400 is not Unix. > Mainframe DB2 is written in PL/S; the non-mainframe version is written in C++. Although > functionally similar, they are different code bases. > > FWIW, I've never worked at a Unix shop that used DB2/UDB, and that included several AIX > shops. Wal-Mart and one other used Informix, the other ten used Oracle. I get the > impression DB2 users are clinging to their mainframe origins.
From: William M. Klein on 28 Jul 2008 00:36 I now can guess at your problem. If you look at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dsnapj11/2.3.3 You will see that the "normal" COBOL equivalent of VARCHAR is: 10 var. 49 var_LEN PIC 9(4) USAGE COMP. 49 var_TEXT PIC X(n). This means that the length field is stored as a bINARY field. Therefore, a X"0D" would occur for a 13 byte VARCHAR field. I don't know how you (your organization) is getting the data from the DB2 table, but you need to do something to EITHER convert the binary length field to display OR to not create (try to create) a line sequential file. -- Bill Klein wmklein <at> ix.netcom.com <taoxianfeng(a)gmail.com> wrote in message news:4f379b88-5332-46f9-b9f6-5506401ef969(a)q28g2000prh.googlegroups.com... On Jul 28, 12:57 am, "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote: > Have you replied yet to the question: > > Does the DB2 table include any fields defined as Packed-Decimal or Binary > (possibly COMP, COMP-3, COMP-5)? > > If so, then using Line Sequential files is almost CERTAINLY not the way to go. > > Line Sequential files are INTENDED for "display" data. > > (Record Sequential files are FINE for binary and packed-data). > > If your original data doesn't include any binary or packed data, can you tell > us > what type of field INCLUDES the X'0D" data - and what it is intended to be - > as > data? > > -- > Bill Klein > wmklein <at> ix.netcom.com I know that Line Sequential files are for 'text' data. And all the 0D comes from VARCHAR field(in several tables since I tried several programs). So I guess(not very sure) the data contains only Japanese characters and no binary data.As I said before, the data's origin is mainframe DB2. But I can't determine the 0D exists in the mainframe DB(since I can't access it), or is injected during the data transportation to AIX DB2, or something else. Then I'm unable to explain what it is intended to be - acautally my boss said the 0D should have no essential meanings and it's probably OK even being discarded. He said that the effect will be finally evaluated at the test phase. That' all guys. I just wanna have a rest now. Thank you for all your patience and kindness.
From: taoxianfeng on 28 Jul 2008 06:07 I'm sorry it's not like your imagine. Varchar is handled with such a structure ONLY in SQL embedded program(.sqb,etc). The field length and real content will be stored into it when fetching a cursor or some other way. BUT now I'm just writing a pure cobol source matching some "special" text file. You can do a experiment to see how is a varchar field exported(into DEL format) - only the characters. I can't show my data but some records contain no 0D and some have lots of 0D spreading the whole varchar field. They are not the binary-form field length. On Jul 28, 1:36 pm, "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote: > I now can guess at your problem. > > If you look at: > http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dsnapj11/2... > > You will see that the "normal" COBOL equivalent of VARCHAR is: > > 10 var. > 49 var_LEN PIC 9(4) USAGE COMP. > 49 var_TEXT PIC X(n). > > This means that the length field is stored as a bINARY field. Therefore, a > X"0D" would occur for a 13 byte VARCHAR field. > > I don't know how you (your organization) is getting the data from the DB2 table, > but you need to do something to EITHER convert the binary length field to > display OR to not create (try to create) a line sequential file. > > -- > Bill Klein > wmklein <at> ix.netcom.com<taoxianf...(a)gmail.com> wrote in message > > news:4f379b88-5332-46f9-b9f6-5506401ef969(a)q28g2000prh.googlegroups.com... > On Jul 28, 12:57 am, "William M. Klein" <wmkl...(a)nospam.netcom.com> > wrote: > > > > > > > Have you replied yet to the question: > > > Does the DB2 table include any fields defined as Packed-Decimal or Binary > > (possibly COMP, COMP-3, COMP-5)? > > > If so, then using Line Sequential files is almost CERTAINLY not the way to go. > > > Line Sequential files are INTENDED for "display" data. > > > (Record Sequential files are FINE for binary and packed-data). > > > If your original data doesn't include any binary or packed data, can you tell > > us > > what type of field INCLUDES the X'0D" data - and what it is intended to be - > > as > > data? > > > -- > > Bill Klein > > wmklein <at> ix.netcom.com > > I know that Line Sequential files are for 'text' data. > And all the 0D comes from VARCHAR field(in several tables since I > tried several programs). So I guess(not very sure) the data contains > only Japanese characters and no binary data.As I said before, the > data's origin is mainframe DB2. But I can't determine the 0D exists in > the mainframe DB(since I can't access it), or is injected during the > data transportation to AIX DB2, or something else. > > Then I'm unable to explain what it is intended to be - acautally my > boss said the 0D should have no essential meanings and it's probably > OK even being discarded. He said that the effect will be finally > evaluated at the test phase. > > That' all guys. I just wanna have a rest now. > > Thank you for all your patience and kindness.- Hide quoted text - > > - Show quoted text -
From: Michael Mattias on 28 Jul 2008 08:58 >I can't show my data but some records contain no 0D and some have lots >of 0D spreading the whole varchar field. They are not the binary-form >field length. Well, that simpifies things. If the data contain x0D (or x0A, depending on any available record delimiter character settings supported) you cannot get it with a COBOL program treating the file as 'line sequential'. You'll have to find another way, period. MCM
From: HeyBub on 28 Jul 2008 12:24
taoxianfeng(a)gmail.com wrote: > umm...it probably doesn't work either. Do you think X'0D' will be > handled differently > under this way? > > I will have a try. Thanks. Sure it'll work. INSPECT {record name} TALLYING {record-length} FOR CHARACTERS BEFORE X'0D'. > > On Jul 27, 6:07 am, "HeyBub" <hey...(a)NOSPAMgmail.com> wrote: >> taoxianf...(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 |