Negative Packed Decimals

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
jzajde1
Premium Member
Premium Member
Posts: 21
Joined: Wed Jan 07, 2015 8:10 am

Negative Packed Decimals

Post by jzajde1 »

Hello All -

I am having an issue with some negative packed decimal fields in the CFF.

Job Design:
Seq. File -> Transformer -> Sort -> CFF

The CFF Stage is packing the data.
I have two amount fields within my source. Both of which are [15,2] - PIC S9(13)V9(2) Comp-3.

A source will read as followed -000000000100600
I am able to get the desired output in the view data tab on the CFF. -0000000001006.00
However, the output seems to be one (or half) a byte short. The storage length here should be 8 bytes, but it is coming out as 7 bytes.

This issue ONLY happens when there are no cents in amount columns.
I have some records which contain -0000000000010.15 and these show up as 8 bytes on the final output.

To ensure this is the issue, I manually manipulated these columns so all the records had cents following the dollar amount. Amazingly, one of our mainframe gurus confirmed that this is the issue.

Here are the Properties we have set for this column in the CFF:
Signed
COMP-3
Field Width 16
Length 15
Scale 2

Please let me know if you have any suggestions or advice!

Thanks,
Jared
FranklinE
Premium Member
Premium Member
Posts: 739
Joined: Tue Nov 25, 2008 2:19 pm
Location: Malvern, PA

Post by FranklinE »

Jared,

I'll review the storage format with you, and maybe you will see where you are going wrong.

Packed decimal is always an odd number of digits in storage, each decimal digit being stored in one half-byte position. From your example, the storage view of your first amount would be as follows, with the spaces separating each full-byte:

Code: Select all

00 00 00 00 01 00 60 0D
Note that there is never a position for the decimal point, which is always implied and set by the column definition when the data is read. The final half-byte is always reserved for the sign.

I would question the field properties immediately. The field width should match the storage format, and should be 8, not 16. Your display length is 16.

Another thing to examine is your file properties. If they are set to anything except Cobol, you may have a conflict during output.

Edit: I just realized that if you are writing in ASCII, the final byte 0D is linefeed, and that might be why you are "missing" it when the final digit is zero.
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
jzajde1
Premium Member
Premium Member
Posts: 21
Joined: Wed Jan 07, 2015 8:10 am

Post by jzajde1 »

Franklin -

You are correct...

The 0D is coming over in LineFeed (LF). When I view the file in notepad++, there is a break in record.
Is there a way to get rid of this? Or no?

Please advise!

Thank you.
FranklinE
Premium Member
Premium Member
Posts: 739
Joined: Tue Nov 25, 2008 2:19 pm
Location: Malvern, PA

Post by FranklinE »

I don't have a confident answer for you, Jared. The problem is that the file is being written in ASCII. I suppose if you write it in EBCDIC you won't have the problem, but it depends on how the file is being used from there.
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
jzajde1
Premium Member
Premium Member
Posts: 21
Joined: Wed Jan 07, 2015 8:10 am

Post by jzajde1 »

Hi Franklin,

We figured out the issue.
Instead of sending file over email we SFTP'ed the file to the mainframe server without a delimiter in the CFF stage.
The mainframe program was able to recognize the negative and positive fields.

Issue = resolved.

Thanks for your help! Always appreciated.

Jared
Post Reply