NUMPROC(NOPDF) VS NUMPROC(PDF) - How does they work ?

xpower · New User Joined: 07 May 2006 Posts: 35

Hello everyone,

01 A PIC X(08).
01 B PIC 9(04).
01 C REDEFINES B PIC 9(08) COMP.

I got S0C7 abend using following statements with NUMPROC(PDF) compile option .
MOVE ' a' TO A. ==> first 7 byte is space,last byte is lowercase not uppercase.
MOVE A TO C. ==> this statement results in S0C7

However, there is no abend if I use the compile option NUMPROC(NOPDF）.

what i know is that NUMPROC(PDF) will validate the sign however, the other one doesn't consider the sign.

Could anyone or expert tell me how does ' a' makes abend with NUMPROC（PDF) ? that is how does the COBOL process it in details ?

Thank you very much for anyone thinking it about !!

xpower · New User Joined: 07 May 2006 Posts: 35

Hi,

A should be 'BBBBBBBa' B means blank not character B .
in other words, if the lowercase appears in the last byte, the statement will always abend with S0C7 with NUMPROC(PDF) however when A is 'aBBBBBBB' whatever B is blank or not, the statment will not abend.
I think the point is the last byte, but i don't know how does it work or process ?

dick scherrer · Posted: Sat Mar 21, 2009 8:02 am

Hello,

Why did you use NUMPROC at all? There is typically no reason to do so - especially with the situation from the posted example.

Actually, the posted example should never be used - it is invalid. There is no continuity in the example at all. . . If the goal was to learn something, i believe the lesson learned should be that such an example is just confusing takes away from learning something worthwhile.

As a bit of a guideline: Redefines should be the same size. Binary should not be used to redefine zoned-decimal. Pix X fields should not be moved to numeric fields without first making sure they are numeric.

If you are interested in NUMPROC, look here:
publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/handheld/Connected/BOOKS/igy3pg40/2.4.35?

xpower · New User Joined: 07 May 2006 Posts: 35

Dear Sir dick，

Firstly, Thank u for your reply and useful link.
Actually it is applied in my work environment, and I am also confused
why it is designed like this. One more thing, I cannot REMOVE NUMPROC(PDF) option because it is not applied in learning but PROD. and the copybook seems not be changed. Just confused why the last byte lowercase result in abend..
Anyway, Thank you so much indeed. :)

dick scherrer · Posted: Sat Mar 21, 2009 9:29 am

Hello,

xpower · New User Joined: 07 May 2006 Posts: 35

Sir dick,

actually in prod is the value is '12345pge', the 'BBBBBBBa' is just test in the development. the copybook is defined similarly in the post. and code is same as the ones above. just the value is different.
sorry. currently i am unable to post them right now... ^-^

dick scherrer · Posted: Sat Mar 21, 2009 11:28 am

Hello,

Bill O'Boyle · Posted: Sat Mar 21, 2009 4:00 pm

Here's an example -

With NUMPROC(NOPFD), whenever two packed-decimal fields are compared, a CP (compare packed/decimal) instruction is issued. If one field has a 'C' sign-nibble and the other has an 'F' sign-nibble, a CP considers both of them "Positive". If the numeric portions of both are the same, then an "EQUAL" condition code is raised.

With NUMPROC(PFD), whenever two packed-decimal fields are compared, a CLC (compare logical character) instruction is issued instead of a CP. If one field has a 'C' sign-nibble and the other has an 'F' sign-nibble, a CLC will raise a "NOT EQUAL" condition code, which causes program logic discrepancies, even though the numeric portion of each field are equal.

I'm not a big fan of NUMPROC(PFD) and although a CLC is a more efficient instruction than a CP, I'll take the hit and default to NUMPROC(NOPFD). There's too much risk when the packed-decimal data can't be trusted and the sign-nibbles may not be the same.

Also, a CLC won't raise a S0C7 and could make things even worse further down in the code, when the "NEXT" packed-decimal instruction is issued (IE: AP) and the packed-decimal data is invalid. A CP with bad packed-decimal data will raise a S0C7 whenever there's invalid packed-decimal data in the "NEXT" packed-decimal instruction.

Regards,

Terry Heinze · Posted: Sun Mar 22, 2009 7:26 am

"Also, a CLC won't raise a S0C7 and could make things even worse further down in the code, when the "NEXT" packed-decimal instruction is issued (IE: AP) and the packed-decimal data is invalid."
Amen to that. Give me the S0C7 now and let me fix the source of the problem instead of allowing garbage to propogate further.

xpower · New User Joined: 07 May 2006 Posts: 35

Sir dick,

the copybook is (output file using these field)

xpower · New User Joined: 07 May 2006 Posts: 35

Sir Bill & Terry,

Thank you for your reply and your opinions . when should we use NUMPROC(PDF) ? here we just move one field to another one. no other process in two fields. yeah, i don't know why NUMPROC(PDF) is used. I have no choice.hehe..

dick scherrer · Posted: Sun Mar 22, 2009 11:03 am

Hello,

What is the desired result in YYYY after the moves? Does anyone have an expected value?

xpower · New User Joined: 07 May 2006 Posts: 35

Sir dick,

Thank you for your nice suggestion. I noticed that.
for this issue, maybe i guess the reason.
for example, 'a' in ebcdic table is X'81', however when it is moved to binary field, the last byte has invalid sign becuase 8 is not accept.
I just tested from 'a' to 'r' that is from (x'81' to x'99'), they are all not correct. and then testd from 's' to 'z' , 'A' to 'Z', they are all correct. because the sign is A,C,D,E (EBCDIC table: www.legacyj.com/cobol/ebcdic.html)

Thanks again.

dick scherrer · Posted: Sun Mar 22, 2009 7:21 pm

Hello,

Good to hear progress is being made

I'm still confused how 1201P3ge might be used as a number

xpower · New User Joined: 07 May 2006 Posts: 35

Sir dick

we don't care what the original value is but ensure that no abend in batch otherwise it is a nightmare. hehe.
thank you for your previous link so that i can find out the issue. :)

dick scherrer · Posted: Mon Mar 23, 2009 8:46 am

You're welcome - good luck

d