Powerhouse feature with quad integers

[Deskin, Bob]

I believe your analysis is correct. Although we support 8 byte integers for
compatibility with COBOL, we still do our arithmetic in floating point.
Whether we use IEEE or not depends on the platform and the particular C
routines. I don't know the specific details. Regardless, calculations with 8
byte integers are always at risk. If you have a value and use it to link and
are not doing calculations, then it should work. Although displays may be a
problem because of the scaling calculation. I haven't done any specific
tests and I don't recall any issues being reported (not that I hear of
everything). I suspect that 8 byte integers are not widely used.

So specifically:

1) Yes I believe your analysis is correct
2) I don't believe that the calculation is safe for all values.
3) I don't believe you can calculate an index value in this way. However,
there's nothing stopping you from splitting it and using segments of an
index or subitems. PowerHouse gives you the flexibility in retrieval
specification. You can use the generalized linkage in QUIZ/QTP like this:

ACCESS record1 LINK item1, item2, item3 ... VIAINDEX index
  TO segment1, segment2, segment3 ... OF record2

And if you want to calculate the item list can be

(expression1, expression2, expression3 ...)

In QTP you don't need the parentheses.

This should give you the flexibility of matching up calculated segment
values. It does require that the index you're linking to has the same
segment breakdown, but that should not be a problem.

Bob Deskin              
PowerHouse Web Product Manager and Senior Product Advisor
Application Development Tools, Cognos Inc.
bob.deskin@cognos.com (613) 738-1338 ext 4205 FAX: (613) 228-3149
3755 Riverside Drive P.O. Box 9707 Stn. T, Ottawa ON K1G 4K9 CANADA


-----Original Message-----
From: Chris Sharman [mailto:Chris.Sharman@ccagroup.co.uk]
Sent: February 3, 2000 6:29 AM
To: uk.telesupport@Cognos.COM
Cc: Chris.Sharman@ccagroup.co.uk; powerh-l@lists.swau.edu
Subject: Powerhouse feature with quad integers


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