Trouble overriding default padding character of NUL

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
gsherry1
Charter Member
Charter Member
Posts: 173
Joined: Fri Jun 17, 2005 8:31 am
Location: Canada

Trouble overriding default padding character of NUL

Post by gsherry1 »

Hello Forum,

I wish to produce fixed files with two columns of 5 bytes each (Char(5), Decimal(5)).

Example of what I wish to produce:

" a 1"
" b 2" etc.

I am reading in comma delimited input file as folows:
"a,1"
"b,2" etc.

I also wish to have my output be in EBCDIC, so I am using CFF for target. I have simply been unable to get the space padding to work.

1. I have attempted to use the 'Pad char' record option on the CFF to perform the padding for me using the default of space. I've also tried specifying \x20.

2. I have attempted to use the 'pad char' property on the input link of the sequential file stage (Edit Column Meta Data) and have set this to various values including space. This did not work.

3. I have changed $APT_STRING_PADCHAR to various values include 0x20, none of which had an impact on my output.

My sequential file tests always have the following output:
H:\Test\Source>od -x Sample_Padding_Out2.txt
0000000000 0061 0000 2000 3020 3030 3130 0A2E
0000000016
The 'a' value is padded with 4 NUL bytes, and the '1' value is padded by four zeros and two spaces.

My CFF tests always have the following output:
H:\Test\Source>od -x Sample_Padding_Out1.txt
0000000000 0061 0000 0000 1C00
0000000010
Here all the padding is 100% x00 bytes.


My understanding is that the Pad char and APT_STRING_PADCHAR should be padding with spaces instead of the NULL bytes, or at least for my CHAR(5) data. Is this a known bug? Does anybody have any suggestions?

Thanks,

Greg
gsherry1
Charter Member
Charter Member
Posts: 173
Joined: Fri Jun 17, 2005 8:31 am
Location: Canada

Post by gsherry1 »

Update:

Support has confirmed that the following functionalities are not working at for 7.5X2, in at least some environments:

1. Padchar functionalities on CFF and sequential file targets are not working on 7.5X2.
2. $APT_STRING_PADCHAR can be used in place of Padchar specifications, but it only works for 0x00 and 0x20 values.
3. Extra bytes are being written to fixed ascii decimal targets on Sequential file stage.

Fixes have been requested for all 3.

- Greg
Post Reply