Mainframe Column S9(9) COMP field to read 0 from Flat file

suja.somu · Post by **suja.somu** » Thu Feb 07, 2013 11:26 pm

I am creating a fixed Flat file in Datastage, with a value 0 for a column . Can mainframe application read a fixed width flat file with a value zero(0) for a column with datatype S9(9) COMP. Also, can -1 or 0 ( zero) value be populated to S9(4) COMP?

What conversions in datastage , do I need to make for the file to be processed in Mainframe.

If this has been already discussed , let me know the thread.

FranklinE · Post by **FranklinE** » Fri Feb 08, 2013 9:56 am

Your general discussion help is in the FAQ viewtopic.php?t=143596

That will help answer most (if not all) of your questions. If they don't, post again here and I'll try to help.

suja.somu · Post by **suja.somu** » Wed Feb 20, 2013 6:00 pm

Frank,

For the Mainframe DB2 column say PERSON_ID is s9(9) COMP.

My requirement is to populate zeroes in to the fixed flat file for the column.

I gave the datatype for the column(PERSON_ID) in Datastage sequential file as CHAR(9). Populated 9 zeros in it in a fixed flat file in ASCII format .

The mainframe application is not accepting this value in the correct position. Could you please help me , how to fix this issue .

What is the length I should specify and how to zeroes to populate in that field.

Thanks in advance.

Suja

FranklinE · Post by **FranklinE** » Thu Feb 21, 2013 9:58 am

Suja,

The easiest approach is to work "backwards" from your mainframe data format requirement.

COMP format is binary. For your example, the storage allocation for a nine-digit signed binary is 4 bytes.

DataStage handles this for us. If you create or import a table definition under the COBOL FD sub-menu, defining the column in the table definition will generate the correct column attributes, including the fixed-width.

suja.somu · Post by **suja.somu** » Thu Feb 21, 2013 10:12 am

Frank,

thanks for the explanation.

I imported of the COBOL copybook in the same way as you had mentioned. when it imported the
S9(9) COMP field is imported as INTEGER(9)
S9(4) COMp field as SMALLINT(4).

So I am not sure, why datastage converted this way.

FranklinE · Post by **FranklinE** » Thu Feb 21, 2013 12:39 pm

Suja, others can more knowledgeably comment, but my understanding is that the various "types" of integer reflect the physical storage space to be allocated to them. A reflection of that is the limit to the absolute value that can be stored in each without truncation.

DataStage, indeed any such environment, is simply working to provide the most efficient use of space. The differing types reflect that. In any case, COMP and integer are both binary formats.

Edit: I should add that COBOL FD imports are not always perfect. You might need to make small adjustments, but they should be obvious to you the first time you use one.

jwiles · Post by **jwiles** » Thu Feb 21, 2013 12:53 pm

Franklin is correct in that the type of integer reflects the storage space it requires. In this case, it is based upon the number of digits in the COBOL PIC(#) COMP clause.

1-4 digits (PIC 9(1) - 9(4) COMP) is a SmallInt (2-bytes)
5-9 digits (PIC 9(5) - 9(9) COMP) is an Integer (4-bytes)
10-18 digits (PIC 9(10) - PIC 9(18) COMP) is a BigInt (8-bytes)

This is how the COBOL program will store them internally, and DataStage recognizes that and imports them appropriately.

Regards,