We are using -
CFF stage to read EBCDIC file.
Fixed width file.
File has record types header/detail/trailer.
Detail record has column with OCCURS of type PIC S9(3)V9(4) COMP-3
CFF stage 'Records ID' defined for each record type.
CFF stage 'Record options' - Default values defined as '0' for decimal/integer.
This is working ok.
But when we remove Default values '0' for decimal/integer and make it blank, stage fails reading any record.
This works if input file doesn't have any array (OCCURS) defined in it.
How can we keep blank default values and still read file using CFF stage with OCCURS defined in file?
CFF stage issue with OCCURS and blank default values
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Re: CFF stage issue with OCCURS and blank default values
Thanks Ray. So how can we read null/empty decimal values without specifying any default values in CFF stage?
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Participant
- Posts: 3593
- Joined: Thu Jan 23, 2003 5:25 pm
- Location: Australia, Melbourne
- Contact:
Ray, the problem is that the CFF stage is forcing the use of defaults even if they are not required. Defaults in CFF can be dodgy - defaulting an empty Decimal or integer to 0 can cause trouble - for example default a flag field to 0 when it is blank or empty implies the wrong thing. The CFF is forcing the use of defaults and it is impossible to work out afterwards which rows were defaulted. It is forcing this behaviour due to the way it parses the OCCURS statement. Data without OCCURS is not complaining about missing defaults, data with OCCURS is.
Is it possible to set a decimal value to NULL in the CFF default field instead of 0?
Is it possible to set a decimal value to NULL in the CFF default field instead of 0?
Certus Solutions
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
Default processing on EBCDIC data is always a problem. The mainframe COBOL perspective -- a hard standard that teaches a quick lesson when ignored -- is to only ever default alphanumeric fields to spaces and display (non-packed) numerics to zeroes. Binary storage fields in general follow the standard with a numeric zero as the default, with packed decimal being the sore thumb that always sticks out: the storage format permits a numeric zero in each half-byte, with two consecutive zeros translating to ASCII null but should not be read as such.
The only correct solution is to go back to the process that creates the EBCDIC data and impose the standards, and not tolerate anything else. Otherwise, DataStage jobs will be rife with custom code just to handle them.
Unsolicited advice: when your upstream developers complain that you are making them do more work, you can use my rule-of-thumb: if you make me do it in DataStage, it will cost the project two or three times as much as having them do it. Make sure a manager with budget power is within earshot. Works every time for me.
The only correct solution is to go back to the process that creates the EBCDIC data and impose the standards, and not tolerate anything else. Otherwise, DataStage jobs will be rife with custom code just to handle them.
Unsolicited advice: when your upstream developers complain that you are making them do more work, you can use my rule-of-thumb: if you make me do it in DataStage, it will cost the project two or three times as much as having them do it. Make sure a manager with budget power is within earshot. Works every time for me.
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