I am getting inconsistent results when comparing 2 large packed field numbers for equality. When the same numbers are small packed fields, the compare works. Can someone using MF FOCUS with a release higher than 7.11 give this code a try and post the results here?

Thanks

et


DEFINE FILE CAR
AMT1/P17.7 WITH COUNTRY= IF COUNTRY EQ 'ENGLAND' THEN 4.18000
ELSE 5.18540;
AMT2/P17.5 WITH COUNTRY= IF COUNTRY EQ 'ENGLAND' THEN 4.18000
ELSE 5.18540;
AMT3/P15.7 WITH COUNTRY= IF COUNTRY EQ 'ENGLAND' THEN 4.18000
ELSE 5.18540;
AMT4/P15.5 WITH COUNTRY= IF COUNTRY EQ 'ENGLAND' THEN 4.18000
ELSE 5.18540;
MSG1/A10=IF AMT1 EQ AMT2 THEN 'EQUAL'
ELSE 'DIFFERENT';
MSG2/A10=IF AMT3 EQ AMT4 THEN 'EQUAL'
ELSE 'DIFFERENT';
END
TABLEF FILE CAR
PRINT COUNTRY AMT1 AMT2 MSG1 MSG2
IF COUNTRY EQ ENGLAND OR FRANCE
END


COUNTRY AMT1 AMT2 MSG1 MSG2
------- ---- ---- ---- ----
ENGLAND 4.1800000 4.18000 DIFFERENT EQUAL <======== Msg1 should be equal
FRANCE 5.1854000 5.18540 EQUAL EQUAL

Well I'm not on Main Frame...but since you have no answers...works fine in WebFocus 7.1.6
and comes out with the correct messages.

My understanding is that you cannot compare PC with MF here, as packed fields cannot exist on the PC, they are, I believe, D fields in disguise, packed field being a MF only format.

I think that a packed field of P17.7, given a value of 4.18000 would actually hold, internally, 4.1800000. And, because it would hold the trailing zeroes, would therefore be unequal to a P17.5 holding 4.18000 internally, like comparing an alpha of '4.18000' to '4.1800000'. Whereas with a D field, this would not occur as it would not hold the trailing zeroes.

This post sparked a memory from over 15 years ago, something similar I'm sure, and Noreen was my saviour then.

Alan

I thought the same thing - that Packed does not exist on the pc - because originally pc-FOCUS used double precision for everything, but if you take a hold file and hexedit it you will see the pc now has genuine packed fields...

John

Your right John. PC now has packed. And if you look at the HEX for the P17.5 versus the P17.7, you will see they are held differently.

I think on the MF it is this that skews the comparison. Remember, packed field do not hold a decimal point or where it is, only a sign. Which is why you cannot change a P8.4 to a P8.2 in the MFD, but can change a D8.4 to D8.2.

Still wonder whether the PC packed is converted to D on the PC for calculation and comparison.

This message has been edited. Last edited by: Alan B,

wf uses double to hold all numeric results of calculation, but I think a simple assignment or comparison will respect the format on the pc but perhaps not on the mainframe. Another explanation might be on pc doubles are IEEE vs IBMs own format on mainframe.

Without going into the depth of the expression compiler assignment of the different versions of packed fields to a common format and then comparison should work since either a simple comparison will be made or the same conversion error on conversion to double will arise.

eg

VAL1/P15.4 =
VAL2/P15.2 =
TESTVAL/P15.4 = VAL2 ;
TEST/I4 = IF TESTVAL EQ VAL1 THEN ....

Thanks to all who tried to replicate this on a non mainframe product platform. I was fairly certain that this was a mainfame problem only. I believe mainframe Focus internally stores packed fields as 8 or 16 physical bytes. Something with a usage format of P1 would have an actual of P8. A usage format of P17 would have an actual format of P16. The compare seems to always work for the small packed fields. Large packed fields became available starting with mainframe release Focus 7.0 which came out just before Y2K. The 7.11 release we are on is among the earlier of the 7 series of releases when large packed fields were still a new feature. I was just wondering whether this goes away in a later mainframe release and I had thought I would get a quicker answer by a post here than opening a case. In addition, the Focus community here (at least running on the mainframe) would be made aware of a problem that could potentially have serious consequences. This is the type of problem where the compare is right most of the time but once in a while is wrong with no warning.

I guess there are not many active posters here still using mainframe Focus.

Thanks again to all.

et

Your test passes on all post 7.1.1 MF FOCUS realeases I have available (latest production is 7.3.8, with 7.6.2 about to come out). 7.1.1 is now 6 years old, so I'm not sure about its maintainability....

Edward Wolfgram

The IBM mainframes store large number as internal floating point. The is similar to scientific notation (things like 6.0223 x 10 23) except everything is in Hexadecimal, and it always store the maximum number of significant digits.

The result is fuzzy in precision. This is the root of the “old” Negative and positive zero issues.

In this case the 4.18000 is being stored with some fuzzy in the non-display significant digits to the right of the zero's. If you make the number of display decimal place the same or change the 4.18000 to 4.18001 everything works as we humans expect.

Jim Morrow
Web Focus 7.6.10 under Windows 2003
MVS 7.3.3

Just to clarify:

Generally speaking, IBI products under the s390 MF architecture and successors (z/arch) store packed numbers as packed numbers, either 8 or 16 bytes. In fact, it is *only* the MF that supports packed fields natively, and all other architectures use an IBI developed packed format that is not s390 packed decimal, but has the same behaviour. Thus, not just FOCUS, but also WEBFOCUS and EDA servers under the MF use internal native packed decimal. Only LINUX 390 servers do not use packed, because the code used is really more like the UNIX code base than the MF code base.

Edward Wolfgram
IBI Development

Thanks alot Edward.

I had suspected that this was an "anomaly" with what was then a fairly new feature. I never intended to request a fix for this as long as it was fixed in a newer release. This was another reason why I was hesitant to open a case. You are preaching to the choir here about getting off of 7.11.

Et