Signed/Unsigned Decimal to Pack Decimal

[zaino22]

I have following input and I am converting it to Pack Decimal 4.

COL_1
-------
000002
000004
000000
-00002
-00024

IN Source File I read it as Decimal 5,0, and Field width property=6. In the Target seq file, I defined it as Decimal 6,0 and Packed=yes, Signed=yes
and I do get Pack Decimal 4 on mainframe but when I look at mainframe, negative values show "D" in last nibble which is good but positive values show "C" and I want "F" at the end to match current process.
Any suggestion what changes do i have to make to ge desired output?

[FranklinE]

...but when I look at mainframe, negative values show "D" in last nibble which is good but positive values show "C" and I want "F" at the end to match current process.
Any suggestion what changes do i have to make to ge desired output?

A review of the current process is important. "F" is generally used for unsigned/default-positive, not for explicit positive. "C" is generally paired with "D" for decimal values that are expected to show an explicit sign in a display format.

Packed decimal is a storage format, not a display format. Some formats permit some choice in the attributes, like having the sign stored as leading instead of trailing, but how the sign is stored is not generally configurable. In every mainframe environment I've seen, storage for packed decimal is either "C" or "D" for signed, or always "F" for unsigned/default-positive.

[zaino22]

That is correct, and thanks to you that's what I learnt the other day after reading your reply.

Current process is done in Mercator 6.7 (which is now IBM product and called Datastage TX), and I want to replace it with Datastage 8.1 code. Current process stores PD values that are Signed Negative as D and positive values as Unsigned or F. I was not sure if one PD colum can allow storage both as D and F as oppose to C and D or just F. When I looked at Mercator, it has defined Type Tree as Signed binary Pack decimal 4 so I expected either C or D not F for storage (may be I am wrong) but is it possible? If yes can we replicate this type of storage in Datastage 8.1 and if the answer is yes then how? that are the three questions?

[jwiles]

Is there a process downstream from DS (or DS TX) that depends on the numbers being unsigned ('F') and would break if they were signed positive ('C') instead?

For most math purposes, it shouldn't make a difference. For display logic (i.e. printed reports, etc.), if it's not handled correctly you might see punctuation or alphas as the last byte of a display number instead of a digit.

Regards,

[zaino22]

That is what I was trying to coordinate with downstream today but response is pending to confirm if it would make any difference. In the meantime I thought I should try and see if it can be done...

[FranklinE]

I'm sorry, I wasn't paying attention to your name. Of course we had the previous conversation. I'm tired.

I wonder if the mainframe OS might have something to do with this. There are as many "flavors" of EBCDIC as there are ASCII, and more than one way to store data.

The one thing I'm sure of at this point is using the COBOL FD choice in Table Import, and checking the DataStage settings for the packed decimal fields after importing the cfd file. From the "edit row" dialogue window for a packed decimal column:

Code: Select all

yes (signed) => use the sign of the source decimal on import or export.
no (unsigned) => generate a sign nibble of 0xf, meaning a positive value, regardless of the imported or exported field's actual sign.

This tells me -- proved by jobs I'm currently developing and testing -- that DS will always use "C" and "D" when Signed=yes is set. Table import automatically sets Signed=yes when it sees a Cobol PIC S9(4) COMP-3, and leaves it defaulted when the "S" is not in the PIC clause.

[zaino22]

As usual, FranklinE gets the honor of hitting the final nail in the question coffin. Thank you very much for taking time to import CFD, confirming theory, and sharing your results with us, much appreciated. btw on a side note Ray Wurlord is a funny guy...

[chulett]

And, as usual, I have to come along behind and clean up all your excessive quoting. Learn to love the Reply to topic button!

[zaino22]

thanks for your response as well jwiles. It was timely.

[FranklinE]

Being a bit better rested, and paying close attention to the use of the "reply to topic" button I must point out that my PIC reference was an example, not the only possible PIC. I think we'd all be busy doing extra coding if PD fields only held four-digit integers.

I've been doing mainframe systems for 20 years. I had the luck, though, that my first Cobol job was for PC platforms. I got an excellent crash course in the architecture differences between mainframe and PC, and the analogues between them. They really are very different environments, and I'm happy to offer my knowledge.