From: taoxianfeng on
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.

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

From: William M. Klein on
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


From: Richard on
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".

From: taoxianfeng on
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: Robert on
On Sun, 27 Jul 2008 15:57:17 GMT, "William M. Klein" <wmklein(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)?

There are no such DB2 types. The corresponding types are INTEGER and DECIMAL. They would
be in display format when exported by any utility.

>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?

Taoxianfeng's 0D and 0A are in strings -- database type VARCHAR, Cobol PIC X. We know that
because he said "I have to count the quotation marks to determine if a record is
divided into several lines and combine them together." Strings are bounded by quotes;
numbers aren't. He is saying there was a 0A in a string.