| Title: | DEC BASIC Conference |
| Notice: | SSB Kit Now available - Note 2.29 |
| Moderator: | TLE::HAYNES |
| Created: | Wed Sep 15 1993 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 210 |
| Total number of notes: | 976 |
Just a word of warning on PACKED DECIMAL data porting VAX to ALPHA.
A customer I was working with (Staples) for RMS file tuning, claimed
keyed file access was broken on the Alpha. Using the `exact' same
key value 80000002613 the VAX would find a record, the Alpha would not.
As we drilled down, we found that on the VAX, then code tried to read
a record with key binary key value "00003C61 20000008" whereas the
ALPHA probed the file with "00003F61 20000008". Now those C and F
represent a trailing + sign, with the C being the preferred representation.
(See BASIC Userguide Chapter 18, Datatypes or RMS Ref Man XABKEY XAB$B_DTP)
Turned out that the VAX 'normalized' the decimal data somewhere along
the way in during a move (They are still drilling down further) whereas
the Alpha presented teh data exactly as read in from the IBM provided file.
The workaround was easy. Just assign the data into a decimal variable
before performing the lookup. They where LIB$MOVCing into a map
field to do the GET ... KEY ... = key_field. The secondary advantage
of using a field outside the MAP for the key is that basic will not
nuke the value with zeroes after the failed get, making debugging harder.
Oh, the customer added insult to injury by having the RMS key defined
as STRING. Thus every bit was signifant. Had the key been defined as
packed decimal, then I suspect a match would have been made (did not
verify).
hth,
Hein.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 210.1 | TLE::PUDER | Those who do not know LISP are doomed to reimplement it. | Thu May 29 1997 14:00 | 9 | |
Thanks for the information. It doesn't sound like there's anything we
can do in the compiler or RTL to catch this, since they avoided letting
BASIC know that the data was decimal.
Glad to hear that at least some customers are not afraid to use decimal
where appropriate. I don't suppose they are savvy enough to use decimal
instead of float for monetary values, too?
:Karl.
| |||||
| 210.2 | EPS::VANDENHEUVEL | Hein | Wed Jun 04 1997 11:38 | 70 | |
> The workaround was easy. Just assign the data into a decimal variable
Actually, the customer did not manage to express themself clearly.
Moving between identically defined decimal fields did NOT normalize
on the Alpha, where it used to do on the VAX. Their current workaround
it to convert to string and back to decimal. I did some handwaving
towards the customer that Alpha having a clever compiler recognized
the input and output where the same and could do a simple move.
[Well... simple... it pulls the old unaligned magic out of its hat]
The VAX used a MOVP and it normalized the + sign to a "C" nible.
It is not clear to me whether this could not be called a bug.
It is definetly is a change in behaviour worth knowing.
Hein.
SOURCE:
MAP (CSHSUM) &
STRING CSHSUM_STORE = 3%, &
:
DECIMAL (5,0) CSHSUM_SALPERS, &
DECIMAL (10,0) CSHSUM_MEMBER, &
STRING CSHSUM_MEMBER2 = 10%
Allocation information for MAP CSHSUM
Name Offset Size Type
CSHSUM_REC 0 84 Static string
:
CSHSUM_CASHIER 60 5 Static string
CSHSUM_SALPERS 65 3 Decimal
CSHSUM_MEMBER 68 6 Decimal
919 DECIMAL(10,0) PRIMARY_MEMBER, &
1351 THEN
1352 PRIMARY_MEMBER = CSHSUM_MEMBER
1353 SECOND_MEMBER = ZERO_MEMBER
on VAX:
->ne 1352: MOVP S^#10,L^CAN_MKT_BP_CASH_CVT\CSHSUM_MEMBER,B^53(R11)
on APLHA:
F6E0001B E548 BNE R23, L$956 ; R23, L$956
E54C L$957:
63FF0000 E54C TRAPB ;
47FAD418 E550 MOV 214, R24 ; 214, R24
B31D0020 E554 STL R24, 32(FP) ; R24, 32(FP)
A7630090 E558 LDQ R27, 144(R3) ; R27, 144(R3) ;
2CBB0044 E55C LDQ_U R5, 68(R27) ; R5, 68(R27)
2CFB0049 E560 LDQ_U R7, 73(R27) ; R7, 73(R27)
237B004A E564 LDA R27, 74(R27) ; R27, 74(R27)
48BB06C5 E568 EXTQL R5, R27, R5 ; R5, R27, R5
48FB0F47 E56C EXTQH R7, R27, R7 ; R7, R27, R7
44A70405 E570 BIS R5, R7, R5 ; R5, R7, R5
48A21685 E574 SRL R5, 16, R5 ; R5, 16, R5
A4DD0550 E578 LDQ R6, PRIMARY_MEMBER ; R6, 1360(FP)
48D81626 E57C ZAPNOT R6, 192, R6 ; R6, 192, R6
48A7F625 E580 ZAPNOT R5, 63, R5 ; R5, 63, R5
44C50406 E584 BIS R6, R5, R6 ; R6, R5, R6
B4DD0550 E588 STQ R6, PRIMARY_MEMBER ; R6, 1360(FP)
| |||||
| 210.3 | where did it come from? | TLE::PUDER | Those who do not know LISP are doomed to reimplement it. | Thu Jun 05 1997 13:08 | 10 |
Well, the Alpha version of the compiler is making a good optimization
based on a reasonable assumption. Emulating a MOVP would be much slower
that a simple sequence of MOVs, especially when we have no reason to
expect any benefit from the extra work.
My next question is: how did the non-normalized decimal number get into
the system? (GIGO). It is at that interface that the compiler or user
program should have insured that the value was normalized.
:Karl.
| |||||