Converting Real numbers with IEEE format to G_Float format

[A.W.R]

Hi,

We are trying to migrate an Oracle application from OpenVMS Alpha to OpenVMS Integrity.

With Oracle on OpenVMS Integrity the real numbers are stored in IEEE format.

All the application code is compiled using G_Float, and we do not want to change this as it will impact on communications with the PLCs.

Is it possible to convert IEEE format numbers to G_Float format numbers easily?

Thanks
Andrew

[Volker Halle · Accepted solution]

Andrew,

I64VMS $ help rtl cvt$
RTL_Routines
CVT$
Additional information available:
CVT$CONVERT_FLOAT CVT$FTOF

Volker.

[Robert Gezelter]

Andrew,

Yes, the conversion can be done in a quite easily and fully supported way.

I completely agree with Volker, the CVT$ routines are the appropriate answer. However, if you are converting significant data, I recommend a careful read through the appropriate manual in the documentation set.

I have done this within applications dynamically for at least one client. There are even faster ways of doing this, but doing it safely requires knowing the ranges of the input/output data.

An important question to ask at this point is: Is the floating point format truly relevant to the PLCs? Or is the data actually just converted to text at some later point.

It may be a piece of missing context, but there may not be a need to preserve the G_Float in this situation. In general, since all of the code will be recompiled in any event, why is there a need to preserve the G-float?

I will put it another way. If the code is inherently sensitive to low-order precision issues between IEEE T and VAX G, then a more careful review of the code prior to switching platforms is recommended (such a sensitivity is not common, but it can exist).

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

I'd focus not on the database here, as that component of this conversion is fairly easy and fairly controlled and controllable. You'll have that solved in fairly short order.

(For instance: you might be able to do an XML export, and then an XML import for the conversion. Or yes, you can roll your own conversion code and call the cvt$ routines. This if you want to rebuild and reset and re-organize the internal database structures and contents yourself.)

The "fun" here is probably going to be the PLC. These widgets tend to be far more persnickety than typical OpenVMS or Oracle code.

You're probably looking to preserve the code operating in the PLC, which means you'll be performing on-the-fly conversions to chat with the device. (Been there, done that. Communications with the older PLC iron is particularly "fun".)

IEEE T Float to VAX G Float will incur some processing overhead, though the PLCs tend to be yet slower. And between the database and the faster processors typical of Itanium, I'd tend to doubt you'll see any conversion-related slow-down here.

Where you'll want to take great care is with the precision; differences in the low-order bits of the converted values, either way. This can cause match-equal applications tests and some regressions to fail, and it can cause the PLC to be confused.

Do you have the original ladder-logic or whatever the source code was loaded into the PLCs? (I know you don't want to convert your PLC "firmware", but you should take a look at it and see what it's actually doing with the FP values, and if slight changes in precision will send it "off the rails".)

The other thing you will want to look at -- and I'm recalling my days dealing with PLCs, and what you had to do -- is a careful look for alignment faults. Some of the code constructions that can be used to interface with PLCs might well generate these, and these faults can be a performance nightmare on Itanium when they arise in sufficient quantities. See other discussions of alignment faults, or most any OpenVMS I64 performance discussion for details.

(And yes, there's some overlap here and over in comp.os.vms. The OpenVMS community isn't that large.)

Stephen Hoffman
HoffmanLabs LLC

[Shael Richmond]

We have gone through the same thing. It's a pain but it works. We tried to convince Oracle to continue supporting G_Float but that was a lost cause.

It's not the database it's the Oracle client that changed. The numbers already get converted from some Oracle format to IEEE. If you use the 9i client on a 10g database you don't have to worry about IEEE conversions.

We can't go totally to IEEE because of DECForms and Codasyl DBMS. So we went through any code reading or writing to Oracle and added a subroutine to convert the floating point formats. We controlled it by a logical so it would still work on the Alpha's. As the other's have said it's a simply LIB$CVT.

On the good side we were able to take an Alpha Oracle 10g database and just copy the datafiles to Integrity. We found it was easier to migrate Oracle from 9i to 10g on the Alpha side instead of exporting and importing all the data.

[A.W.R]

Hi,

Thank you all for your time and responses.

It is really appreciated to receive advice from those that there have come across similar issues.

I am never sure where is the best place to post these type of queries.

I did post these as well on the Oracle forum, but got no response.

Thanks
Andrew