IBM Mainframe Forum

I got curious about how the hardware treats P'-0' so I tried a few tests'.

CP =P'-0,=P'+0' yields condition code 0. This was sort of expected

ZAP DWORD,=P'-0' (DWORD is defined as D'0') yields X'0---0C'(e.g., PL8'+0') This was not expected; i was expecting PL8'-0'.

CVB 0,=PL8'-0' Since there is no such thing as F'-0' in System/360 binary notation, I was expecting an interrupt, but the result was F'0', though this result is perfectly OK.

I then turned to Principles of Operation to see what it would say. As it turned out, it says nothing. While I was reading about ZAP, the manual talked about overflow in ZAP. It took me a couple of minutes to realize how you can get an overflow in ZAP: ZAP ONEBYTE,=P'255' will result in overflow provided ONEBYTE is, in fact, one byte.

Sorry, I know it is a bit old. Did you try the multiply? Seems it should preserve your minus zero. From a POP "The sign of the product is determined by the rules of algebra from the multiplier and multiplicand signs, even if one or both operands are zeros." So a minus zero multiplied by a plus anything (even zero) should give you a minus zero!

I think dividing your minus zero by anything positive will also preserve it. For the add packed, it specifies that the sign of the value zero in the result is made positive. Substract is a negative add, so does the sign thing on the zero as well (although not specific in the description).

So, multiply and divide can preserve the negative sign. Add and Subtract specifically make the sign positive. The "move", I guess because it is zero-and-add, sets the sign to positive.

Would seem a funny mixture, but since the compare treats the positive and negative zero as equal, it shouldn't matter, should it? I guess despite the "rules of algebra" we humans just never think of zero being negative. It also implies that IBM, without stating in the POP what they are, have something they think are the "definitive" rules of algebra.

Ergo, in the rules of algebra, minus zero exists. Beyond my maths education...

No, I never tried MP or DP.

Why I was interested in your post was because I once saw a minus zero on a record. It was someone else's system, and they had a problem. I noticed the minus zero, but couldn't see it being related to the problem, so said nothing and quietly checked what happened to it (in Cobol). It behaved exactly like zero, so I ignored it, but with that sort of slightly (very slightly after the checking) worried feeling that I didn't know how it could have come about.

Now I do, or can guess. The online system generating the record I saw was written in Assembler. I'd say it multiplied a negative number by zero.

Hello,

Where this has "bitten many in the butt" is when the field is used a key or part of one. . .

Some products/processes will not generate a negative packed-decimal zero. If the key was created with x'00000D', it will be a "not found" when a x'00000C' is presented to the read. . .

Personally, i cringe whenever i see a packed-decimal value in a key/index. . .

dick scherrer wrote:Personally, i cringe whenever i see a packed-decimal value in a key/index. . .

I'm with you there. How about binary representation of decimal values, even more especially from non-IBM to IBM, and vice versa?

I'm hardly an expert here, but I see three issues with a packed decimal value in a key or index -

• binary 0s in high order digits.
• Negative values won't sort properly.
• Alternate sign representations.

There are similar issues with binary data.

• Binary 0s in high order bytes.
• Negative values won't sort properly.
• The -1 issue (e.g. X'FFFFFFFF', F'-1').

However, a character (not "zoned" decimal) representation of numeric data is not without problems. Sorting of negative data is probably the most severe. Perhaps dick scherrer can let us know about the issues he sees with this kind of data.

Hello,

I'm hardly an expert here

I'm not either, but we have a couple of them lurkikng about who are not shy. . .

but I see three issues with a packed decimal value in a key or index

binary 0s in high order digits.

If done (which i work dilligently to avoid) the lengths need to be the same.

Negative values won't sort properly.

They should sort correctly if defined as packed-decimal rather than some other data type (i.e. character, binary, etc).

Alternate sign representations.

On all of the systems i've worked with, packed-decimal data has a C, D, or F sign.

There are similar issues with binary data.

Yup, i agree. When binary data is to be a key, my PMs have insisted that the number not be signed (must always be positive). Prevents various "opportunities". . .

On the sort, we tell it the data type of each lump of data we are sorting on, and the package does the rest. Even our positive and negative packed zeros will at least end up together.

File file keys I was thinking. In the back of my mind, there is something about a VSAM keyed file, or some part of it, that won't cope with packed or binary data. Can't remember the details, but I remember smiling a satisfied smile at that.

If we try to search whatever keyed methods are left with a key of packed minus zero, which logically matches packed plus zero but won't find the hit, that is where we'd have a problem. I'd never thought of that before (only seen the minus zero the once in my life) but I always hated people trying to use non "display" (in a broad, not terminological, sense) keys for direct access.

dick scherrer wrote:...

Alternate sign representations.

On all of the systems i've worked with, packed-decimal data has a C, D, or F sign.

Well, right there you have an alternate sign (F and C both represent a positive packed decimal number). I don't think I've ever seen an A, B, or E packed decimal sign. I've also seen just C, D and F. A sort program will handle all this quite well, but keys are strictly unsigned binary.