Datastage CFF component converting ! to ] in char field

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
elinzeyjr
Participant
Posts: 9
Joined: Thu May 11, 2017 9:18 am

Datastage CFF component converting ! to ] in char field

Post by elinzeyjr »

Hello Everyone.

I have a requirement to take a file which is ftp'd from the mainframe (os390) to our unix server and load it into greenplum.

The job consists of :

complex flat file component -----> transformer -----> GP connector.

The file consists of hex, packed, and ascii data that is why it is ftp'd from the mainframe to the unix box as binary. This is a one to one mapping between source and target. The CFF is set to byte order Big-endian due as needed for the hex values being passed.

All of the source fields are being loaded to the target greenplum table as expected except for one ascii field for one of the records. This is a 30 byte character field on the source file 'PIC X(30)'. The value in this particular field is as listed below (first line ascii, second/third hex values):

CHEAPER THAN DIRT!
CCCCDCD4ECCD4CCDE5444444444444
38517590381504993A0000000000000

When viewed in CFF, the value is showing as:

CHEAPER THAN DIRT]

For some reason, the exclamation point is being converted to a bracket and this value is being populated into the greenplum target table.

We have tried changing the source filed to varchar, byte order to little-endian/native-endian but issue still remains. All other values in this column are being viewed/populated correctly.

Any suggestions you may have would be appreciated.
UCDI
Premium Member
Premium Member
Posts: 383
Joined: Mon Mar 21, 2016 2:00 pm

Post by UCDI »

sounds like an encoding / locale issue. Check the source locale/character set, and use that to see if it works. A lot of character sets seem to have only minor differences in symbols area, causing the data to be mostly correct but not quite.
Post Reply