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.
Mainframe Column S9(9) COMP field to read 0 from Flat file
Moderators: chulett, rschirm, roy
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.
That will help answer most (if not all) of your questions. If they don't, post again here and I'll try to help.
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
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
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
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.
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.
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
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.
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.
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
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,
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,
- james wiles
All generalizations are false, including this one - Mark Twain.
All generalizations are false, including this one - Mark Twain.