All X'0D' lost during reading line sequential file using microfocus se
in [Cobol]
|
From: Robert on 27 Jul 2008 11:10 On Sun, 27 Jul 2008 01:21:51 -0700 (PDT), taoxianfeng(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. >And the data is EXPORTed from db2 on AIX(Actually comes from mainframe >DB2 since it's a migration project). > >But I have to admit the data is quite unusual.Fortunately I have >handled X'09' correctly with EXPANDTAB=OFF. Users entered tabs to make columns line up on a monospaced display. Those tabs probably won't work the same way on your new platform. Same for the carriage returns and line feeds.
From: Anonymous on 27 Jul 2008 12:05 In article <1s2p84d2u4k2lfhh72bmpe2hepb7f3n0cu(a)4ax.com>, Robert <no(a)e.mail> wrote: [snip] >For many years, DB2 on Unix was called UDB -- Universal Data Base. >Evidently, IBM recently >changed the name to DB2. Mr Wagner, you betray yourself as a COBOL programmer; I first worked with an IBM product called DB2 on a mainframe in 1987 and the product was first released (according to http://en.wikipedia.org/wiki/IBM_DB2 ) in 1983. COBOL programmers, at times, seem to have... different ideas of 'recently'. DD
From: Robert on 27 Jul 2008 23:42 On Sun, 27 Jul 2008 12:01:23 -0700 (PDT), Richard <riplin(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+udb&source=web&ots=7JOfYeQgsE&sig=38qWI4siZc8_hxGkSAUP_RLHZ3Y&hl=en&sa=X&oi=book_result&resnum=10&ct=result#PPP1,M1 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: Robert on 28 Jul 2008 23:19 On Mon, 28 Jul 2008 18:23:18 -0700 (PDT), taoxianfeng(a)gmail.com wrote: >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? Code Page 1252 is hex load from filename of del modified by codepage=1252
From: Robert on 29 Jul 2008 00:22
On Mon, 28 Jul 2008 19:50:25 -0700 (PDT), taoxianfeng(a)gmail.com wrote: >On Jul 29, 10:31�am, "billious" <billious_1...(a)hotmail.com> wrote: >> "Robert" <n...(a)e.mail> wrote in message >> >> news:kpeh84lkodm0ksj8hub80dsc28h9ojmtn4(a)4ax.com... >> >> >> >> >> >> > 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. >> >> MOVE ALL X0D TO FD before the READ. >> >> Old programmers' trick.- Hide quoted text - >> >> - Show quoted text - > >Move before the read? Could you explain it with more detail? Thanks a >lot. >How can I move X'0D' since I don't know where and how much of them >will be in the record? He meant initialize the record area so the tail of the last block would be filled with x'0D'. Spaces would be a better choice. I would do it like this: select input-file assign to INFILE1 record sequential file status file-status. fd input-file. 01 input-record. 05 input-byte occurs 512 pic x. 01 file-status pic x(2). 01 pic x. 88 end-of-file value 'y' false low-value. 01 pic x. 88 last-sector value 'y' false low-value. 01 pic x. 88 in-quotes value 'y' false low-value. 01 pic x. 88 end-of-record value 'y' false-low-value. 01 sub-in pic 9(4) binary. 01 sub-out pic 9(4) binary. 01 output-record. 05 output-byte occurs 512 pic x. set end-of-file, last-sector, in-quotes to false open input input-file perform read-sector perform until end-of-file set end-of-record to false move spaces to output-record move 1 to sub-out perform until end-of-record or end-of-file evaluate input-byte (sub-n) also true when space also not in-quotes move low-value to input-byte (sub-n) when x'0A' also not in-quotes set end-of-record to true when quote also not in-quotes set in-quotes to true when quote also in-quotes set in-quotes to false end-evaluate if input-byte (sub-n) not equal to low-value move input-byte (sub-in) to output-byte (sub-out) add 1 to sub-out if sub-out greater than length of output-record display 'Record too big ' output-record call 'abort' end-if end-if add 1 to sub-in if sub-in greater than length of input-record perform read-sector end-if end-perform [do something with output-record] end-perform close input-file exit program. read-sector. if last-sector set end-of-file to true else move spaces to input-record read input-file at end set end-of-file to true end-read move 1 to sub-in evaluate file-status when '92' set last-sector to true when not = zero and not end-of-file display 'Read error ' file-status call 'abort' end-evaluate end-if. |