CFF dropping comp3
Moderators: chulett, rschirm, roy
CFF dropping comp3
Hi , I need your help in debug below
I have a CFF stage with a comp 3 field. Whenever a
non decimal value come in this field the whole
record dropped from CFF.
Please help me to understand.
I have a CFF stage with a comp 3 field. Whenever a
non decimal value come in this field the whole
record dropped from CFF.
Please help me to understand.
-
- Premium Member
- Posts: 1735
- Joined: Thu Mar 01, 2007 5:44 am
- Location: Troy, MI
Comp 3 is Packed Decimal. If you are getting anything other than decimal then I think there is something wrong with the cobol file definition. Or you may be getting multiple record types in the copy book.
Double check if you have single or multiple record type/s in the copy book and if your file definition is correct.
Double check if you have single or multiple record type/s in the copy book and if your file definition is correct.
Priyadarshi Kunal
Genius may have its limitations, but stupidity is not thus handicapped.
Genius may have its limitations, but stupidity is not thus handicapped.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
It's normal behaviour for DataStage.
If even one field does not conform to the metadata, then it cannot be certain that subsequent fields are being correctly parsed.
So the default behaviour for DataStage is to drop the record.
If you really want, you could read the file using a Sequential File stage, treating the entire record as a sufficiently large VarChar, and look after the parsing yourself (just to prove the point).
If even one field does not conform to the metadata, then it cannot be certain that subsequent fields are being correctly parsed.
So the default behaviour for DataStage is to drop the record.
If you really want, you could read the file using a Sequential File stage, treating the entire record as a sufficiently large VarChar, and look after the parsing yourself (just to prove the point).
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
So... we're still having fun with high/low values? When you say here you are having trouble with a "non-decimal number" in a COMP-3 field you specifically mean HIGH or LOW VALUES? Rather than going a couple of pages like before, can you post examples of these problem values? I for one would be curious what these packed decimal fields actually look like when you do an octal or hex dump of them. Can you post those, please, high and low? And some examples that work well for you (i.e. non high/low values) would be appreciated as well.
Just trying to make sure we're all on the same page as to exactly what it is we are all dealing with.
Just trying to make sure we're all on the same page as to exactly what it is we are all dealing with.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
EXAMPLES. Please. All it seems you've confirmed right now is the fact that if the metadata doesn't match the data, the record gets rejected - which as noted is standard expected behavior. Help us help you. Be precise. Show us the FD you are using and what kind of values in what fields are causing you problems.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
Craig - Here are the details
There is a column "NO' which having with below copybook detail
NO PIC S9(11)V9(2) USAGE COMP-3
When I see a record in file it showns as below on mainframe
A
C000000
100000C
(Looks like char A is on column NO)
I am reading the source file in CFF through as Decimal (13,2) and its a fixed width file.
During DS run the record with above entry getting dropped automatically.
Unable to understand why
There is a column "NO' which having with below copybook detail
NO PIC S9(11)V9(2) USAGE COMP-3
When I see a record in file it showns as below on mainframe
A
C000000
100000C
(Looks like char A is on column NO)
I am reading the source file in CFF through as Decimal (13,2) and its a fixed width file.
During DS run the record with above entry getting dropped automatically.
Unable to understand why
I can see below after file copy from mainfrmae to unix
0021360 f1f0 f2f0 0000 0100 0000 3001 f0f0 f1f0
0021400 f060 60f1 f1f0 f060 4bf0 f0f0 f04b 4bf0
0021420 f0f0 f0f0 f0f0 2d00 0100 0a00 0000 0000
0021440 0000 d50c 40f0 4040 4040 4040 4040 4040
0021460 0040 0000 0000 0000 0000 0000 0000 0000
0021500 0000 0000 0000 0000 0000 0000 0000 0000
0021520 0000 0000 0000 0000 f1f0 f2f0 0000 0100
0021540 0000 3101 f0f0 f1f0 f060 60f1 f1f0 f060
0021560 4bf0 f0f0 f04b 4bf0 f0f0 f0f0 f0f0 1200
0021600 0100 0a00
0021604
Total length of file is 104
I dont know why but - other records except above is looks simmilar but in above looks like something missing
e.g -
0021040 f1f0 f2f0 0000 0200 0000 f601 f0f2 f5f1
0021060 f060 60f5 f4f1 f160 4bf5 f3f5 f04b 4bf9
0021100 f1f8 f9f2 f8f2 1200 0100 0500 0000 0000
0021120 0000 d50c 40f2 4040 4040 4040 4040 4040
0021140 0040 0000 0000 0000 0000 0000 0000 0000
0021160 0000 0000 0000 0000 0000 0000 0000 0000
0021200 0000 0000 0000 0000 f1f0 f2f0 0000 0200
0021220 0000 6400 f0f2 f5f1 f060 60f4 f5f2 f060
0021240 4bf5 f2f0 f34b 4bf8 f4f6 f2f9 f9f2 2800
0021260 0100 0500 0000 0000 0000 d50c 40f0 4040
0021300 4040 4040 4040 4040 0040 0000 0000 0000
0021320 0000 0000 0000 0000 0000 0000 0000 0000
0021360 f1f0 f2f0 0000 0100 0000 3001 f0f0 f1f0
0021400 f060 60f1 f1f0 f060 4bf0 f0f0 f04b 4bf0
0021420 f0f0 f0f0 f0f0 2d00 0100 0a00 0000 0000
0021440 0000 d50c 40f0 4040 4040 4040 4040 4040
0021460 0040 0000 0000 0000 0000 0000 0000 0000
0021500 0000 0000 0000 0000 0000 0000 0000 0000
0021520 0000 0000 0000 0000 f1f0 f2f0 0000 0100
0021540 0000 3101 f0f0 f1f0 f060 60f1 f1f0 f060
0021560 4bf0 f0f0 f04b 4bf0 f0f0 f0f0 f0f0 1200
0021600 0100 0a00
0021604
Total length of file is 104
I dont know why but - other records except above is looks simmilar but in above looks like something missing
e.g -
0021040 f1f0 f2f0 0000 0200 0000 f601 f0f2 f5f1
0021060 f060 60f5 f4f1 f160 4bf5 f3f5 f04b 4bf9
0021100 f1f8 f9f2 f8f2 1200 0100 0500 0000 0000
0021120 0000 d50c 40f2 4040 4040 4040 4040 4040
0021140 0040 0000 0000 0000 0000 0000 0000 0000
0021160 0000 0000 0000 0000 0000 0000 0000 0000
0021200 0000 0000 0000 0000 f1f0 f2f0 0000 0200
0021220 0000 6400 f0f2 f5f1 f060 60f4 f5f2 f060
0021240 4bf5 f2f0 f34b 4bf8 f4f6 f2f9 f9f2 2800
0021260 0100 0500 0000 0000 0000 d50c 40f0 4040
0021300 4040 4040 4040 4040 0040 0000 0000 0000
0021320 0000 0000 0000 0000 0000 0000 0000 0000
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
It might help to see the metadata so that the record length can be established, then you can use that information to identify whether any data are actually missing.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.