All X'0D' lost during reading line sequential file using microfocus se
in [Cobol]
|
From: William M. Klein on 28 Jul 2008 12:49 Besides the comment that Line Sequential just won't work, you really SHOULD contact the "owner" of the data on the mainframe. If the data itself actually contains X"0D" (or any other X"0?" or X"1?" data), you should VERIFY with the owner that they think this is "valid" data. Personally (especially with the manager's comment that these can be "ignored") I am guessing that there is a problem somewhere in the extraction and transfer process. It certainly is POSSIBLE that this is "valid" data - but it is also possible that it is a symptom of another problem that needs correcting. -- Bill Klein wmklein <at> ix.netcom.com <taoxianfeng(a)gmail.com> wrote in message news:a9c0db14-398e-47ef-a705-59e8b9657ba1(a)j22g2000hsf.googlegroups.com... 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: Rick Smith on 28 Jul 2008 13:25 <taoxianfeng(a)gmail.com> wrote in message news:a9c0db14-398e-47ef-a705-59e8b9657ba1(a)j22g2000hsf.googlegroups.com... [snip] > 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. [snip] A bit of research (google using: site:ibm.com db2 +aix +hex) shows that a HEX function is available (in DB2 V9) that may be used during EXPORT to convert the characters in the VARCHAR column to hex display. Using this function would seem to simplifiy the problem with having control character values as data.
From: Pete Dashwood on 28 Jul 2008 21:01 "William M. Klein" <wmklein(a)nospam.netcom.com> wrote in message news:rMmjk.347471$I42.44563(a)fe04.news.easynews.com... > Besides the comment that Line Sequential just won't work, you really > SHOULD contact the "owner" of the data on the mainframe. That would be the CEO of the company, according to some recent posts in CLC... :-) Pete. -- "I used to write COBOL...now I can do anything."
From: taoxianfeng on 28 Jul 2008 21:16 On Jul 29, 1:49 am, "William M. Klein" <wmkl...(a)nospam.netcom.com> wrote: > Besides the comment that Line Sequential just won't work, you really SHOULD > contact the "owner" of the data on the mainframe. If the data itself actually > contains X"0D" (or any other X"0?" or X"1?" data), you should VERIFY with the > owner that they think this is "valid" data. Personally (especially with the > manager's comment that these can be "ignored") I am guessing that there is a > problem somewhere in the extraction and transfer process. It certainly is > POSSIBLE that this is "valid" data - but it is also possible that it is a > symptom of another problem that needs correcting. > > -- > Bill Klein > wmklein <at> ix.netcom.com<taoxianf...(a)gmail.com> wrote in message > > news:a9c0db14-398e-47ef-a705-59e8b9657ba1(a)j22g2000hsf.googlegroups.com... > 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 -- Hide quoted text - > > - Show quoted text - I'll take your suggestion seriously. It's really necessary for me to check the validity of the data before writing the program and discussing with you all.
From: taoxianfeng on 28 Jul 2008 21:23
On Jul 29, 2:25 am, "Rick Smith" <ricksm...(a)mfi.net> wrote: > <taoxianf...(a)gmail.com> wrote in message > > news:a9c0db14-398e-47ef-a705-59e8b9657ba1(a)j22g2000hsf.googlegroups.com... > > [snip] > > > 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. > > [snip] > > A bit of research (google using: site:ibm.com db2 +aix +hex) > shows that a HEX function is available (in DB2 V9) that may be > used during EXPORT to convert the characters in the VARCHAR > column to hex display. Using this function would seem to simplifiy > the problem with having control character values as data. Well, it's really a fantastic method! All data is successfully outputted. There's only one more thing: I need to import the matched data back to the table, so I'm searching the way to convert the HEX displayed varchar column back. Would you mind give me a bit more hint? |