Char to Pack Decimal

[zaino22]

Source file contains decimal [5,0] that I have to pad with zeros if length if less than [5,0] and convert to Pack Decimal length 4. I am reading decimal [5,0] as a Char [5] for padding reason. Once padded Then I have another Job where I read this padded field as a Char and do no use Str-to-Dec function in XFM instead I changed SQL Type type in the Target Seq file to Decimal 4, and Decimal Type properties to Packed=yes.
Example:
Input=00002
Current Output=002

wanted output=0002

Pad condition:
IF Len(Trim(InputCol))<>0 Then Right("00000":InputCol,5) Else InputCol

I have tried Fied width=4 in the target seq file but no benefit Any help will be appreciated!

[zaino22]

Update:
Okay so i got refresher on Packed Decimal. Dec 5 should be in Pack Dec 3 but if mapping requires Pack 4 then increase the SQL type on read to 7, and then select field width to 5. This way decimal 5,0 will be 7,0 and can be converted to pack decimal 4, but it did not work for me. only when i changed pack decimal 4 to 6, expected results showed up, but thats' now how it suppose to be Pack should stay 4. so issue still unresolved...

[FranklinE]

Since you mentioned needing a "refresher" on the packed decimal format, the following is intended to be simple. I've been dealing with it for many years, and I sometimes benefit from a reminder of the basics. I intend no disrespect for your technical skills.

Packed decimal is a storage format. Each integer digit is stored in a half-byte position. The general relationship between the alphanumeric format and the packed decimal is add 1 and divide by 2, always rounding up. Since packed decimal is only readable in its hexadecimal view, here is how your data would "translate". Values are ASCII.

Char(5) 00005 -- x"3030303035"

Packed -- x"00005F"

For comparison: Char(5) 12345 is Packed x"12345F"

The last half-byte is reserved for the sign: x"F" implied postive or unsigned, x"C" positive, x"D" negative.

I suggest that thinking of the storage length for packed decimal is a source of confusion. DataStage has a reliable coverage of Cobol formats, and will (for example) provide the proper storage length for a Cobol comp-3 field of any arithmetic description.

The basic answer is that your change from a 5-char numeric to a four-digit packed decimal is actually not a change at all. The storage length for a 4- or 5-digit numeric is still 3 bytes in packed decimal format. Decide how you want the field to display, and don't worry about how it's stored.

[zaino22]

FranklinE
I take no insult in learning/saying something I did not know, and and I am glad there are people such as you who are very helpful, and kind so thanks for taking time in explaning the Pack Decimal format.

instead of reading Char 5 and writing to Pack Dec 4, I wrote to PD 6, and voila I get the length what I wanted (I was checking results on Mainframe using Hex ON to see if value 00002 is really stored as 00002 IN PD) however I was not sure if that is how someone with bit more experience with PD would do.
From your response, I see this is how I should have been done. Please response if my understanding is correct, and thanks again for your response.

[FranklinE]

You're welcome. I try to keep aware that people from many different cultures read here.

I think your understanding is correct. I just want to be sure of one thing for you: your char(5) values will display as decimal(6,0) out of the packed decimal attribute. You should not have to do any zero-padding along the way, because packed decimal storage always includes leading zeros when the value being stored is less than the number of digits provided. If the requirement is to display only 4 digits, then they have a display problem and not a storage problem, and changing the storage length of the packed decimal field is not the solution.

[zaino22]

Brilliant! I learnt something new today. Thanks FranklinE keep up the good spirit you got.