CFF dropping comp3

techsavy · Post by **techsavy** » Sat Jun 06, 2015 2:36 am

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.

priyadarshikunal · Post by **priyadarshikunal** » Sat Jun 06, 2015 5:01 am

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.

techsavy · Post by **techsavy** » Sat Jun 06, 2015 11:26 am

But still I didnt understood why its dropping the whole record.

So is that a rule if a non decimal number passed to a COMP 3 then whole record would be dropped? Is that a normal behavior?

ray.wurlod · Post by **ray.wurlod** » Sat Jun 06, 2015 8:05 pm

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).

techsavy · Post by **techsavy** » Sun Jun 07, 2015 1:38 am

Thanks Ray, but why then an comp filed with high/low value read and dont make the whole record dropped.

And a COMP 3 field with high/low value dropped the whole record.

chulett · Post by **chulett** » Sun Jun 07, 2015 2:03 pm

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.

techsavy · Post by **techsavy** » Sun Jun 07, 2015 10:59 pm

Craig Its not only high or low value. When ny source
Field contains a char value (hex representing) then also
the record getting dropped

chulett · Post by **chulett** » Mon Jun 08, 2015 4:50 am

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.

techsavy · Post by **techsavy** » Mon Jun 08, 2015 8:43 am

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

chulett · Post by **chulett** » Mon Jun 08, 2015 9:31 am

We (and you too) need to see the octal or hex values, not their 'display' values. Do an "od -h" (octal dump in hexidecimal) against the file and post it here.

techsavy · Post by **techsavy** » Mon Jun 08, 2015 9:53 am

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

ray.wurlod · Post by **ray.wurlod** » Mon Jun 08, 2015 6:06 pm

The line numbers alone will tell you that something is missing. Investigate what is not in the file compared to what's received from the mainframe.

techsavy · Post by **techsavy** » Mon Jun 08, 2015 11:19 pm

quick question..
Yes, something is missing. but how to read this? how to know which column value is missing. Please help

ray.wurlod · Post by **ray.wurlod** » Tue Jun 09, 2015 1:28 am

No idea.

You're not showing us the same data in each file. "Looks like" they may be, but the same they're not.

ray.wurlod · Post by **ray.wurlod** » Tue Jun 09, 2015 1:30 am

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.