This question was also posted on Stack Overflow and there is a good answer there from cschneid.
NUMCHECK is behaving as intended. Having a positive or negative sign in an unsigned data item is invalid data. The COBOL language guarantees no specific behaviour for invalid data, and therefore leaving it as-is can lead to differences in program behaviour from V4. To get past the abend, compile with NUMCHECK(PAC,MSG) and you will only get messages when invalid data is found. If you cannot fix your invalid data for some reason, please open a PMR if you see different program behaviour. Also, if you haven't listened already, you might find the COBOL Migration Workshop migration recordings useful.
Let me know if you have any other questions!
-----------------------------------------------------
Answered by Nicole Trudeau on Jan 02, 2019
-----------------------------------------------------
Original Message:
Sent: Wed June 17, 2020 12:26 AM
From: Yuan Jie Song
Subject: COBOL v6.2 NUMCHECK option
Disclaimer: This post is migrated from IBM Developer Answers that is no longer in use. Its original author is Zoahr, posted on Dec 24, 2018.
Hello, We can't turn off the NUMCHECK option for our new COBOL V6.2 compiler because we can't trust the content of our numeric variables. The problem is, that when we turn it on, it's not fully compatible with the COBOL 4 we had previously at our organization. Specifically - when an unsigned packed variable contains X'123C' , COBOL 4 would have accepted it and let us continue, but COBOL 6.2 with NUMCHECK(PAC,ABD) abends, and only willing to accept X'123F'. This is a real issue for us regarding assembler invoking COBOL, or reading from files and etc. Is there another option or maybe even a PTF that corrects this behavior? And can you point us to other incompatibilities like this one when NUMCHECK is on, if they exist? Thank you! Zohar
--------------------------------------------------
Question asked by Zoahr on Dec 24, 2018
--------------------------------------------------