issue with comp-3 variable movement?

Support for OS/VS COBOL, VS COBOL II, COBOL for OS/390 & VM and Enterprise COBOL for z/OS

Re: issue with comp-3 variable movement?

Postby dick scherrer » Fri Jul 26, 2013 8:59 pm


x'00' ZERO - usage is comp/comp-3

Not quite true . . . A comp-3 (packed-decimal) might contain x'00' in one or more high-order bytes. A comp-3 value will NEVER contain x'00' in the low-order byte

But could you please advice why x'40' and x'F0' also not good for COMP-3?

Because neither has a valid sign. They do not follow the rules for comp-3.

+44, PIC 9(9) COMP-3 would contain x'000000044F'. high-order bytes mean?

The high-order bytes are the bytes before the 044F.

When we do have comp/comp-3 variables in our copybooks, I should avoid this kind of INSPECT statements. Because it replaces the zeros. Am I correct? Please advice

You need to better understand the INSPECT and the implications of the various PICTUREs of the fields. I don't believe i seen an INSPECT of comp or comp-3 data. . .
Hope this helps,

These users thanked the author dick scherrer for the post:
Raj2006 (Mon Jul 29, 2013 10:12 am)
User avatar
dick scherrer
Global moderator
Posts: 6308
Joined: Sat Jun 09, 2007 8:58 am
Has thanked: 3 times
Been thanked: 90 times

Re: Re: issue with comp-3 variable movement?


Re: issue with comp-3 variable movement?

Postby BillyBoyo » Sat Jul 27, 2013 3:46 am

A COMP/COMP-4/COMP-5/BINARY field can contain any of the possible 256 bit patterns. X'40' in one of these fields is not a space, it is a binary value, of a particular magnitude depending on its position in the field.

A COMP-3 can easily contain X'40' and be valid, as long as it is not in the right-most byte. X'F0' is not valid anywhere in a COMP-3 field.

A PIC X field can validly contain any of the 256 bit patterns.

When using INSPECT, only use it for the particular fields you want to change. It would be unusual to use it for a group-item, and very unusual to use it for a group-item whose constituent fields were of different PICtures or USAGEs.

Note than any field, of any PICture, or any USAGE, can actually contain any bit-pattern. Nothing will stop that happening if that is how you code it. However, the results you get if you don't follow the conventions for PIC 9 USAGE DISPLAY or COMP-3, or for COMP-1 and COMP-2 for that matter, or for numeric-edited fields, won't necessarily be what you want.

Again, as you have shown, the COBOL compiler will do nothing to stop you putting "invalid" values into fields. Sometimes you'll get a result, although you may wonder exactly how you got that result. Sometimes you'll get an abend.

Becuase the compiler does nothing to prevent us trashing fields, we are careful how we use them, and also always validate numeric data arriving from external sources.

Get into the habit of knowing your data, data formats, and what happens when the format is not "normal" for a field. Keep bad data out of your system by knowing how to do so.

These users thanked the author BillyBoyo for the post:
Raj2006 (Mon Jul 29, 2013 10:35 am)
Global moderator
Posts: 3733
Joined: Tue Jan 25, 2011 12:02 am
Has thanked: 22 times
Been thanked: 254 times


Return to IBM Cobol


  • Related topics
    Last post