Signed/Unsigned Decimal to Pack Decimal
Moderators: chulett, rschirm, roy
Signed/Unsigned Decimal to Pack Decimal
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?
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?
Re: Signed/Unsigned Decimal to Pack Decimal
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.zaino22 wrote:...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?
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.
Franklin Evans
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
Re: Signed/Unsigned Decimal to Pack Decimal
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?
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?
Last edited by zaino22 on Thu Mar 03, 2011 6:43 pm, edited 1 time in total.
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,
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,
- james wiles
All generalizations are false, including this one - Mark Twain.
All generalizations are false, including this one - Mark Twain.
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:
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.
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.
Franklin Evans
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
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.
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.
Franklin Evans
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872
"Shared pain is lessened, shared joy increased. Thus do we refute entropy." -- Spider Robinson
Using mainframe data FAQ: viewtopic.php?t=143596 Using CFF FAQ: viewtopic.php?t=157872