Page 2 of 2

Re: issue with comp-3 variable movement?

PostPosted: Fri Jul 26, 2013 8:59 pm
by dick scherrer
Hello,

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

Re: issue with comp-3 variable movement?

PostPosted: Sat Jul 27, 2013 3:46 am
by BillyBoyo
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.