I do not have a V8 installation to test this on but I suspect this is the same as on V7.5.3.
The problem you have is due to the different implementations of zoned decimal in ASCII and EBCDIC.
The value you are seeing in your file are
{ -> I for positive 0-9 and } -> R for negative 0-9.
This is because the source has overpunched the first nibble of the last byte with the hex value 'C' for positive and 'D' for negative. I assume this has come from a mainframe system (or at least something using EBCDIC)
To read these using a CFF you need to get the source file in a binary form rather than plain text.
As soon as you specify 'Character-set: ASCII & Data format: Text ' as mention above, Datastage then assumes that your file is using the ASCII zoned decimal implementation.
In this case the first nibble of the last byte is overpunched with '3' for positive values and '7' for negative values.
The numbers that you say were read correctly
Are in fact NOT being translated correctly.There is another field EARNED_PREMIUM (which is part of the Occurs) whose definition is PIC S9(6)V9(2) and it has data like "0000407P".
When I do a view data on this, the tool is unable to decode the WRITTEN_PREMIUM field data, but it is giving me signed data for EARNED_PREMIUM field (like "-000040.70").
'P' in EBCDIC = x'D7' so in zoned decimal is -7
'p' in ACSII = x'70' so in zoned decimal is -0
so in fact the value 0000407P should become -000040.77
(For some reason datastage seems to ingore the case of the overpunched character when decoding ASCII zoned decimal as upper case 'P' actually = x'50' but still displays as -0)
The best option, if possible, would be to get this source file supplied in binary rather than translated to ASCII (hopefully just a change of FTP mode), otherwise the lookup suggested may be the easiest way.
Hope that helps.