Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

COBOL on IA64 usage of OTS$CVT_T_F or _D

 
SOLVED
Go to solution
Highlighted
Kay Dolle
Advisor

COBOL on IA64 usage of OTS$CVT_T_F or _D

Hi,
we are using a COBOL-Routine with OTS$CVT_T_D to convert numeric Text into comp-2 values. On our ALPHA it works fine for years, but now we tried it on our IA64. The result is on every input near 0 (p.e. 0.85...E-319). Now i tried an COBOL-example from compaq:
identification division.
program-id. OTS$CVT_T_Z.
environment division.
configuration section.
data division.
working-storage section.
01 in-char pic x(10).
01 return-value usage is comp-1.
01 return-status pic s9(9) comp.
01 dest-size pic s9(4) comp.
*
procedure division.
begin.
* for example 12.5 returns 1.250000E+01
* -12.5 returns -1.250000E+01
display 'Enter string to be converted'.
accept in-char.
call 'OTS$CVT_T_F' using by descriptor in-char,
by reference return-value,
omitted, omitted, omitted, omitted
giving return-status.
if return-status is failure
call 'lib$stop' using by value return-status.

display 'The converted value is ' .
display return-value with conversion.
stop run.
----------------------------------------------
With OTS$CVT_T_F i got the same problem.
It works fine on ALPHA (COBOL V2.8) and gives wrong results on IA64 (COBOL V2.9). The Return-Values are always 1 ("Normal").
Any idea?
Kay
14 REPLIES 14
Wim Van den Wyngaert
Honored Contributor

Re: COBOL on IA64 usage of OTS$CVT_T_F or _D

I know nothing but found this :

On OpenVMS Alpha and I64 systems, the data type depends on the /FLOAT qualifier. Refer to the HP COBOL User Manual Appendix B, describing compatibility with HP COBOL for OpenVMS VAX for information on the /FLOAT=IEEE qualifier.

http://h71000.www7.hp.com/doc/82final/6297/6297pro_119.html#d_float_sect is that appendix B.

Missing compile options ?

Wim
Wim
Kay Dolle
Advisor

Re: COBOL on IA64 usage of OTS$CVT_T_F or _D

We have used the /FLOAT=F_FLOAT qualifier, but now i tried /FLOAT=D_FLOAT and with that it works with the sample programm (OTS$CVT_T_F) and my testprogram (OTS$CVT_T_D). The cobol manual really doesn't help me to understand that...
Anyway - thanks!
Kay
Kay Dolle
Advisor

Re: COBOL on IA64 usage of OTS$CVT_T_F or _D

Sorry typing error:
we have used /FLOAT=G_FLOAT
Kay
Wim Van den Wyngaert
Honored Contributor

Re: COBOL on IA64 usage of OTS$CVT_T_F or _D

Find it confusing too. But never used the float stuff since 1984. And the memory of it was overwritten (small head and no memory protection).

Wim
Wim
Hoff
Honored Contributor

Re: COBOL on IA64 usage of OTS$CVT_T_F or _D

I don't have an OpenVMS I64 box with COBOL immediately handy to run tests on this particular case.

The old F and D formats are the VAX floating point formats; these pre-date IEEE. Alpha offers both VAX and IEEE floating point formats, and had an oft-ignored suggestion to move to the IEEE formats for best format compatibility. Itanium expects IEEE floating point.

The COBOL compiler has defaults for the floating point it generates and uses, and a called routine such as OTS$CVT_T_D or OTS$CVT_T_Z can expect a different format. Make sure your COBOL code and your OTS calls match. Here, I'd tend to expect to see OTS$CVT_T_S or OTS$CVT_T_T, or I'd expect to ask the COBOL compiler to try D or F.

Using VAX FP on Itanium is feasible, but there will often be a loss of significance and the FP calculations will be slower; the necessity for and the effects of the FP conversions will introduce various concerns.

Since you're porting code, you'll find the available porting manuals in the main shelf or in the archived shelf to be quite worth reading and considering, and/or you might want to look to bring in some help to speed the process. The source code is compatible across all three platforms, with a few wrinkles. Floating point is an area replete with wrinkles.

Here are some quick hits of things I've encountered when porting source code:

http://64.223.189.234/node/226

and yes, FP is on the list. :-)

Stephen Hoffman
HoffmanLabs LLC

John Gillings
Honored Contributor
Solution

Re: COBOL on IA64 usage of OTS$CVT_T_F or _D

Kay,

You really don't want to use D_FLOAT on Itanium, (or Alpha for that matter). On Alpha it "works", but really doesn't do what you think it does. On Itanium, as you've discovered, it pretty much just doesn't work at all!

Explanation... VAX architecture defined two double precision (64 bit) floating point types, D_FLOAT and G_FLOAT. D_FLOAT was an extension of F_FLOAT (the 32 bit floating point type). You just added an extra 32 bits of precision. Mantissa and sign, and hence range were exactly the same as F_FLOAT. This was a useful thing to do because no conversion was required between single and double precision, just ignore the extra 32 bits of precision. It also gave 3 extra bits of precision over G_FLOAT, at the expense of additional range. D_FLOAT range was the same as F_FLOAT, something like 10**+/-32.

G_FLOAT took those extra 3 bits of precision and added them to the mantissa. So, the low 32 bits of G_FLOAT did NOT match F_FLOAT, but the range was expanded significantly, at the expense of precision. Conversion between single and double precision was necessary, as was handling overflow conditions that could not exist between D_FLOAT and F_FLOAT.

When Alpha came along, only F_FLOAT, G_FLOAT and the equivalent (then) new IEEE float formats S and T were implemented in hardware. D_FLOAT was "faked" by simply gating the corresponding bits into and out of binary G_FLOAT and clearing the extended mantissa. Using D_FLOAT therefore gave the worst of both worlds, you had the limited range of F_FLOAT and the lower precision of G_FLOAT, as well as a minor performance penalty.

By the time Itanium arrived, I think it was assumed that D_FLOAT was dead and gone. There seems to be "lip service" support, but I suspect it's never been seriously tested (no offense intended to VMS engineering, but I'm sure priorities, quite correctly, lay elsewhere!). It also has a fairly significant performance penalty relative to the other formats.

All the advice in moving from VAX to Alpha says to migrate D_FLOAT to G_FLOAT. Moving from Alpha to Itanium the advice is to migrate your F_FLOAT to S_FLOAT (IEEE) and G_FLOAT to T_FLOAT (IEEE).

As you can see, using D_FLOAT is two architectures behind. I'd strongly recommend you change this code to use the Itanium native floating point formats - IEEE S_FLOAT and T_FLOAT.

Step through in DEBUG and use EXAMINE/HEX, EXAMINE/D_FLOAT, EX/G_FLOAT and EX/T_FLOAT to confirm the floating point format. If you STEP/INSTRUCTION you may see what conversions COBOL is performing to display the value.

The errors you're observing are almost certainly due to a mismatch in floating point types. Most likely the DISPLAY statement is assuming the wrong type. Remember the COBOL /FLOAT defaults have changed on Itanium. The way Itanium handles floating point assumptions is complex and rather ugly. The best way to avoid trouble is just use the native formats.
A crucible of informative mistakes
Kay Dolle
Advisor

Re: COBOL on IA64 usage of OTS$CVT_T_F or _D

For porting the application i scanned the sources for uses of "comp-1" variables.
Mostly it is used vor LIB$Wait-Calls. This calls are in over 800 Sources without param 3 (float-type). So they are all using f-float (default) and don't accept s-/t-float in that way.
So migrating to IEEE looks like a challenge, especially by this time as we're running Alpha and IA64 hardware parallel.
I'll try to fix that up with an minimum effort
with G_FLOAT in both worlds with conditional compilation of the matching OTS$-Routine.
Hoff
Honored Contributor

Re: COBOL on IA64 usage of OTS$CVT_T_F or _D

Having and porting 800 source modules can be anywhere between a trivial recompile and an intractable project; between a couple of days' effort and a never-ending boondoggle. It really depends on what's in those modules.

I did a platform port of about half that number of modules in roughly two weeks total, and a large chunk of that was setting up a multiple-architecture build and the DECdtm regression libraries, and fixing some bugs the newer compilers found. (The tool was to be common source, and was to be built on multiple architectures.)

In some cases, flipping the FP from /f/d/g to s/t is little more than a compile switch. In some cases, you have to tweak a couple of calls, or convert static or shared FP data. (Using all sorts of FP isn't a big deal, as s/t data fits right into the same storage as the equivalent f/d/g data.)

Here's an overview (numbers of bytes, precision, etc) of the various data formats found underneath OpenVMS:

http://h71000.www7.hp.com/doc/82FINAL/5841/5841pro_100.html#vms_data_types

As for your case here, the usual porting questions and caveats from the porting manuals apply.

Are you sharing FP data in a file or other static storage, or shipping FP via mailboxes or such?

What API-specific f/d/g calls are in use?

The other piece of porting to OpenVMS I64 is a careful look for alignment faults. A few is OK, but too many of those can adversely effect application performance; they're very expensive.

John Gillings
Honored Contributor

Re: COBOL on IA64 usage of OTS$CVT_T_F or _D

Kay,

>Mostly it is used vor LIB$Wait-Calls. This
>calls are in over 800 Sources without
>param 3 (float-type).

It's a fairly simple mechanical change to do a global substitute of LIB$WAIT for LIB_WAIT. You can then implement LIB_WAIT any way you want. Easy to add a float type. Your modules can then be compiled with /FLOAT=IEEE. You can also have different float types for Alpha and Itanium with the same source code. (and if you ever need to move to another platform, you've got a single point of change to implement whatever WAIT function is available).

Similarly, instead of conditionally calling some specific OTS$ routine, abstract the function required into your own routine, which you can then implement according to platform. Say, CONVERT_TO_FLOAT which you can implement as OTS$CVT_T_F on Alpha and OTS$CVT_T_S on Itanium (though I'm curious as to why you don't just let COBOL work it for you as a MOVE WITH CONVERSION?).

Application source code remains the same, you just write a few little routines to adapt it to the target platform.
A crucible of informative mistakes