Complex Flat File Stage(DS 7.5) - Decimal data types

[bsreenu]

Hi,

I'm getting a some error while reading decimal data in CFF stage. Here is an example:

Column=Salary Decimal (5,2) Sign on Trailing

Currently this column is configured as
Cobol layout= PIC S9(3)V9(2) Sign is trailing
Record type= Variable
Data format= text
Character Set= ASCII

1)
Input data= 9875}

Expected output= -987.50

2)
Input data= 1234I

Expected output= 123.49

Issue: CFF stage is unable convert the last character. FYI, I'm able to read the same data using Seqiential file stage. Why not CFF?

Error: Field "Salary" has import error and no default value;
data: {9 8 7 5 7d}

Am I missing anything?

I would appreciate your help.

Thanks..!

[bcarlson]

Is your input binary-EBCDIC?

We have several instances where we are pulling in non-COMP'd numeric fields from EBCDIC files. We import them as binary, not text, and leave the character set as EBCDIC. The target field is decimal (x,y) {zoned} and that takes care of it.

To mark it zoned, go to the Column Meta Data screen and click Decimal Type in the Properties panel. In the right-hand set of options, select packed and set it's option to "no {zoned}". There is an additional option for packed for sign position (leading/trailing), but we don't normally set that beacuse the default is trailing.

If you set the field to text, all DS will do is do a straight conversion from EBCDIC to ASCII. For all bytes but the last, that is not an issue. However, for signed non-COMP'd fields, the last byte is split between the number and the sign. Normally a '0' in EBCDIC is xF0. However, when using this zoned format (like S9(3)V9(2)), the last byte will be set to C0 for a positive number or D0 for a negative number.

For example, normally the value 98750 would be F9F8F7F5F0. But since it is negative and zoned, the EBCDIC values are F9F8F7F5D0 instead. If you do a straight EBCDIC to ASCII conversion, F9F8F7F5 converts to 9875, but D0 converts to '}'.

When you tell DataStage that it is binary-EBCDIC zoned, then it knows how to handle that last byte - converting it to an ASCII '0' and making the completed number negative.

Hope this helps. You have no idea how many times I have had to have this explained to me. I am a Unix person and barely know how to spell MVS let alone understand mainframe/COBOL datatypes and programming.

Brad.

ps. I have a chart that I keep for handling these kinds of conversions:

Code: Select all

Torrent/DataStage - COBOL Datatype  Mapping

PIC 9(02) - uint16 / int16 {text} or string[2, padchar=' '];
PIC S9(02) - int16 {text} or string[2, padchar=' '];
PIC 9(9)V99 or S9(9)V99 - decimal[11,2] {zoned};
PIC S9(9)V99 COMP-3 - decimal[11,2] {packed};

[bsreenu]

Thanks Brad..! Thanks for your informaion.

But my input is Text-ASCII. I still don't know how to fix it in CFF. So I'm handling this data using seqiential file stage. And I'm not sure CFF stage can handle if the file has five different variable length records (or segments). Any help would be great.

[bcarlson]

So you have an EBCDIC file on the mainframe that is transferred to Unix. What mechanism do you use to convert from EBCDIC to ASCII? If you are using FTP or NDM or some generic conversion, that would explain why you are getting the '}' character in your input field.

Generic EBCDIC to ASCII conversion are only valid if there is no numeric data outside of PIC X-type or PIC 9-type fields. Signed fields, like you are seeing, throw off the conversion. The first several bytes convert just fine until you get to the last byte where it is split between the number and the sign. A generic converter does not know how to handle that.

My suggestion is to use DataStage to handle the EBCDIC to ASCII conversion - that way you have complete control over all fields and how they are converted.

Brad.

[bsreenu]

Thanks Brad..!

We are getting the file from a unix system (as FTPed) from a different source. We do not have any control the way we are getting the file from different source. I'm able to convert these decimal data to actual display format using sequential file stage. But I could not do this using CFF stage.

[bcarlson]

I just thought of another possibility - although you may not need it now that you have it working via the Sequential File stage.

Convert your text field back to EBCDIC and reconvert back to numeric using the non-packed zoned decimal format.

Just a thought. Glad you got it working!

Brad.