Scanning a Packed decimal value

cdaniel_el · New User Joined: 12 Jun 2006 Posts: 9 Location: OH, USA

Hi
Is there any ways to scan a comp-3 variable in a grp of variable knowing its index and offset.
The main purpose is..for one of my friends program, he need got a SOC7 abend...since his input received packed decimal value among the numeric grp item.
Now he needs to drop the packed decimal values and need to process all the numeric data...is there any way to do it. pls let me know

Thx
Dan

DavidatK · Posted: Tue Jun 13, 2006 1:09 am

Dan,

I'm a bit confused as to what you need to do.

Can you give an example of what you need? I'm sure it's doable.

Dave

cdaniel_el · New User Joined: 12 Jun 2006 Posts: 9 Location: OH, USA

Hi Dave,
Actually one of my friend had a problem, wherein his input file started receiving packed decimal instead of the regular numeric values. Actually he got this strange values from the upstream systems, which is beyond his control.

Now the challenge hear is he need to identify the variable as numeric or packed decimal. If its gonna to be a packed decimal he will drop off (using CONTINUE stt), if its going to be a numeric value then he needs to do the regular processing.

Can u pls throw in some light on how to scan the same.

Thx
Dan

ap_mainframes · Posted: Tue Jun 13, 2006 8:50 am

I am still not sure whats the problem here, but all I understand is we need shud not process some data when its PD , and process it when it is numeric ( ZD ).

I have got a question, Why do you need to 'drop' the variable when it is PD.You can declare a normal numeric variable (say 9(9)).and move the input variable in to this and use this variable hence forth.
Even if its an ZD or PD, it will take care.

ap_mainframes.

cdaniel_el · New User Joined: 12 Jun 2006 Posts: 9 Location: OH, USA

the project requirement forbids me to neglect the variables with PD. We need to process only the ZD values. Is there any ways to find out?

sunnyk · New User Joined: 20 Oct 2004 Posts: 59

Well it's a bit tough to decode this problem, but i feel that if by any chance you can check for the last character/position of the COMP-3 then you can make out whether it's PD or not. Like we 'll have D or F in the last position to indicate whether it's -Ve or +Ve which is not the case with normal numeric/numeric edited fields. So we 'll check for D or F or if there are more chars in PD to indicate +ve or -ve values in last nibble and proceed further.

I guess you can try exploring more on this and in timebeing i 'll try thinking on code for the same.

Regds
Sunny

sunnyk · New User Joined: 20 Oct 2004 Posts: 59

I forgot to mention C denotes +ve, D denotes -Ve and F denotes unsigned. I guess there are no more symbols denoting anything else in COMP-3.
So we 'll check for above three chars in last nibble of PD field which i think is a tough job(as we can't break byte into nibble in COBOL program) , but just give it a thought. There may be an easy solution for the above scenario.

But i fail to understand even if the values are coming as PD also, whats the problem in that??? Can you clarify.

Regds
Sunny

sunnyk · New User Joined: 20 Oct 2004 Posts: 59

Check if the following link is of any help to you:

www.simotime.com/cblbit01.htm

Regds
Sunny

cdaniel_el · New User Joined: 12 Jun 2006 Posts: 9 Location: OH, USA

Hi Sunny
Again i am hunting around for a solution to find out the presence of PD, is there any ways to do it is my basic concern. Because thatz my requirement. This is purely driven on business.

dneufarth · Posted: Tue Jun 13, 2006 10:11 pm

What's being dropped - the elementary field value, the group item, a record?

You can always loop thru an item checking each position for values x'F0' thru x'F9' and bypass processing if all values do not fall in that range (at least if no signing is involved).

cdaniel_el · New User Joined: 12 Jun 2006 Posts: 9 Location: OH, USA

Hi Dave,

Again the main concern over here is that we are having 11 million records. It would pose a severe threat to the performance issues as we go abt finding this way about.. may be i am not too sure. My pbm over here is that the position of the PD is unsure it might sprout in any position within the range of variable's. I am looking for a way wherein i shouldnt tamper the performance. My main pbm over here is the upstream systems is from a different company and they wont abide by any norms or error's for that matter.

dneufarth · Posted: Tue Jun 13, 2006 11:28 pm

Then it is only possible on your end to test for valid fields (isnumeric or whatever) on the known layout and type of the fields as you expect them to be. When a nonconforming field is found, you bypass that record or dump it to a 'suspense' file for future diagnostics/validation resolution.

cdaniel_el · New User Joined: 12 Jun 2006 Posts: 9 Location: OH, USA

Thx Dave,
But this again is leading to a performance issue. i am gonna try the other way round. Will drop the solution sooner....Thx everyone

Rgds
Dan

venkatm99 · New User Joined: 01 Jun 2006 Posts: 23 Location: Sinagpore

hi

move the comp3 field to alphanumeric feild .
replace all spaces with zeroes
move data in alpha numeric to numeric feild..do numeric validation

if not numeric..its a comp3

pl correct me if Iam wrong

cheers

venkat

sunnyk · New User Joined: 20 Oct 2004 Posts: 59

How can you say if the data is not numeric it's COMP-3 as COMP-3 also passes the IS NUMERIC condition/test.

Regds
Sunny

cdaniel_el · New User Joined: 12 Jun 2006 Posts: 9 Location: OH, USA

Precisely, COMP-3 also passes the numeric test. That shudnt be the way.

Rds
Dan

venkatm99 · New User Joined: 01 Jun 2006 Posts: 23 Location: Sinagpore

hi

I think my assumption is wrong.

I thought when comp-3 feild moved to alpha numeric it will move some junk

Sorry friends

cheers

venkat