All X'0D' lost during reading line sequential file using microfocus se
in [Cobol]
|
From: taoxianfeng on 28 Jul 2008 22:32 On Jul 29, 1:24 am, "HeyBub" <hey...(a)NOSPAMgmail.com> wrote: > taoxianf...(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- Hide quoted text - > > - Show quoted text - I'm sorry I still can't fully understand your meaning.But when I'm trying like that: FD INFILE1 DATA RECORD IS IN- REC1 RECORDING MODE V RECORD IS VARYING IN SIZE FROM 1 TO 5000 DEPENDING ON WK-INREC1- LEN. 01 IN-REC1 PIC X(5000). READ INFILE1 INSPECT IN-REC1 TALLYING WK-TMP1 FOR CHARACTERS BEFORE X'0D' The result of WM-TMP1 is 5001 added by the actual length decided by X'0A' and EXLUDING X'0D'. For example: ...0D..0D.0A (record length is 8 including 0D but 0A) Then the value of WM-TMP1 is 5007.(only 6 characters were counted) ........0A (record length is 8 exluding 0A) Then the value of WM-TPM1 is 5009.(all 8 characters were counted since no X'0D') So that means X'0D' is discarded when READing the file and the INSPECT always gives the maximium record length since it can't find X'0D'. And my question by "it probably doesn't work either" means reading the file by a given length will also discard the X'0D', though I have not tried yet.
From: taoxianfeng on 28 Jul 2008 22:50 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?
From: taoxianfeng on 29 Jul 2008 01:28 On Jul 29, 12:19 pm, Robert <n...(a)e.mail> wrote: > On Mon, 28 Jul 2008 18:23:18 -0700 (PDT), taoxianf...(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- Hide quoted text - > > - Show quoted text - The DB2 codepage is set to IBM-943 (Japanese) so a SQL2754N "cannot be converted" error happens when trying to load data with codepage 1252. Maybe I should change the DB codepage?
From: billious on 29 Jul 2008 01:50 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? LINE INPUT transfers characters from the input datastream until the next X'0D'/X'0A' (depending on system) into the input record. Hence, X'0D' and X'0A' should never appear in the input record. Problem is that the transfer merely stops at the character before the End-Of-Line (whatever it may be) - the record is not 'filled' - so any characters from a LONGER previous record are not overwritten. Hence, if you simply MOVE SPACES TO INPUT-RECORD. READ INPUT-FILE. then the data appearing will simply be the contents of the shorter next-record, filled with spaces. Now whether you move SPACES or LOW-VALUES or HIGH-VALUES or ASCII-CR or ASCII-LF or ASCII-NULL is up to you, and how you wish to process the data. You appeared to be worried about X'0D' being absent - use ASCII-CR if that suits your purpose. I last ran into that problem on a DEC/VMS machine, but it was a standard problem. Outputting such a record normally suppresses trailing-spaces, so probably spaces would be the better idea. Depends on what you want to do overall. I've assumed that you have a record something like 01 INPUT-RECORD. 03 INPUT-CHARS PIC X(01) OCCURS HOWEVER-MANY. And also that you have a copybook of constants like 01 STANDARD-CONSTANTS. 03 ASCII-NULL. 05 FILLER PIC 9(02) COMP VALUE 0. 03 ASCII-LF. 05 FILLER PIC 9(02) COMP VALUE 10. 03 ASCII-CR. 05 FILLER PIC 9(02) COMP VALUE 13. 03 ASCII-DOUBLE-QUOTES. 05 FILLER PIC 9(02) COMP VALUE 34. 03 ASCII-QUOTES. 05 FILLER PIC 9(02) COMP VALUE 39. (I do it that way - and establish other symbolic constants like this because it is implementation-independent)
From: William M. Klein on 29 Jul 2008 01:59
<taoxianfeng(a)gmail.com> wrote in message news:71e6da43-8789-4de7-8fc7-54f14fb69dbf(a)34g2000hsh.googlegroups.com... <snip> The DB2 codepage is set to IBM-943 (Japanese) so a SQL2754N "cannot be converted" error happens when trying to load data with codepage 1252. Maybe I should change the DB codepage? Is the actual mainframe data "NATIONAL" (or DBCS) data (stored in the DB2 table? If so, then it is CERTAINLY possible that the actual DBCS/national data includes X"OD" bytes within a double byte (or Unicode) data. "Converting" (or handling) mainframe DBCS/National data via Micro Focus on AIX is a VERY different issue than anything that you have mentioned up to now. If the mainframe data is NOT DBCS or National, can you find out WHY it is defined as "IBM-943 (Japanese)"? If it does include SOME actual Japanese data, can you find out if it is ALL "national" - or if it is a mixture of national and alphanumeric data. If the mainframe data includes a combination of EBCDIC and DBCS (or Unicode) data, then I think you need to be VERY careful of your "conversion" (export) procedures AND you need to make certain that "conversions" in transfer to AIX "maintains" valid data AND that you are using the proper language (NLS and codepage) settings when processing the data with Micro Focus. -- Bill Klein wmklein <at> ix.netcom.com |