Powerhouse feature with quad integers

[Chris Sharman]

We're using Alpha VMS 7.1, PH 7.10G3.

We have the following structure in our invoices & credits:

    Item                                 Type            Size  Occ  Offset
    INVOICE-LINE-KEY                     INTEGER UNSIGNED   8           24
    .INVOICE-LINE-CRD-CNT                INTEGER UNSIGNED   2           24
    .INVOICE-LINE-NUMBER                 INTEGER UNSIGNED   2           26
    .INVOICE-NUMBER                      INTEGER UNSIGNED   4           28

If you're not aware of VMS bit ordering, -crd-cnt is the least significant word
of -key, and invoice-number is the most significant longword, so that

invoice-line-key = (invoice-number*65536+invoice-line-number)*65536+
						invoice-line-crd-cnt

In the credits file, the -crd-cnt field is 1 for the first credit for the line.
If it's a partial credit, there may rarely be a 2nd credit for the same line.

In the invoice file, the field is always zero.

I've always linked using:

(a) access credit-lines link &
	((invoice-number*65536+invoice-line-number)*65536) &
		to invoice-line-key of invoice-lines

and I've never observed any problems.
A colleague used:

(b) access credit-lines link &
	((invoice-line-key)-(invoice-line-crd-cnt)) &
		to invoice-line-key of invoice-lines

and discovered that he 'lost' a lot of first credits this year, although he got
some second credits, and the same code (unchanged for some time) worked fine on
all credits last year.

I'm inclined to put this down to the documented PH behaviour of converting all
numbers to double floats for calculations. I believe it uses D-floats (approx
56 bits precision), but (OpenVMS Programming Interfaces page B-9) is limited to
G-float precision (approx 53 bits) on Alpha. IEEE T floats are also 53 bits
precision.

As our invoice numbers were near 2M last year (fits in 21 bits), and are now
somewhat bigger (probably just over 21 bits), it would appear that the
low-order bits of -crd-cnt are at risk from rounding (21 + 32 = 53).

Question 1: is my analysis correct ?
Question 2: is the multiplicative expression (a) safe, given that it should
		always result in zeroes in the lowest 16 bits, or are we
		going to encounter problems here too ?
Question 3: If not, is there a safe technique or workaround ?

This has actually been observed in Quiz, but is obviously an issue for all
three PH ADT components, and may presumably be an issue for other platforms.

Thanks
Chris
_______________________________________________________________________
Chris.Sharman@CCAgroup.co.uk		http://www.ccastat.demon.co.uk/
CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancashire, PR2 9WS.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.