Re: sqlldr flaking out on ZONED and DECIMAL data

no, zoned and decimal are portable; the last character is the sign. binary (computational-3) integers and reals are "endian" sensitive, and yes, those have to be converted before sqlloader is used if the platforms have different endian arithmetic.

--
--
Dave Mausner, Dir. Bus. Intell., Braun Consulting Inc.
v. 312-984-7178 f. 312-984-7033 c. 312-YAK-FOX-4
"Andrew Hardy" <nobody_at_spam.from.news.AdvanticaTech.com> wrote in message
news:98q0ci$4q5$1_at_sun-cc204.lut.ac.uk...


> Zoned is of the form:


>     value    POSITION(n)    ZONED(precision, scale),

>

> Decimal is of the form:

>     value    POSITION(n)    DECIMAL (precision, scale)

>

> but... I don't think that ZONED or DECIMAL are portable datatypes i.e. you

> may have problems taking them from one platform to another due to little

 and


> big-endian differences.


>

> Andy

>

>

> "Mike Moore" <hicamel_at_mail.home.com> wrote in message

> news:7fWr6.34240$zV3.2587774_at_news1.frmt1.sfba.home.com...

> > I am not sure if there is something wrong with sqlldr or something wrong

> > with my data. This is because I don't know what "exactly" sqlldr is

> > expecting to see. Frankly, the documentation is poor in this area. What

 I


> > need is to see hex values for what is acceptable in ZONED or DECIMAL


 fields.


> >

> > I have created the data using SQL on an IBM mainframe from an IDMS


 database.


> > Then I FTP the file onto my PC. Some of the fields are ( using COBOL

 terms


> > here ) SIGNED ZONED DECIMAL, UNSIGNED ZONED DECIMAL, and COMP-3. I can't


> > seem to get any of these to work in a consistent manner.

> >

> > All that I need to know is what SQLLDR is expecting to see when for

 example


> > you

> > use something like:

> >

> > my_element position(1,6) zoned(6,2),


> >

> > thanks,

> > Mike

> >

> >

>

>