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
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
Kay Dolle
Advisor

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

@Stephen:
Now we're using _F for Alpha and _G for IA64 with no "/FLOAT" qualifier on Alpha and "/FLOAT=G_FLOAT" on IA64.
Before: _D on both with the same qualifiers.
We're using a "/nomember_alignment"-qualifier only for C-source-compilation and a "/NOALIGN" for Fortran. Is that ok?

@John:
Yes, the substitution of LIB$WAIT with an own module ist an (good) option. I'll have to refresh my TPU-knowledge for writing a script to update all MMS-Files. But most of them are generated with tpu, so it shouldn't be a problem.

So thanks @all for your help and have a nice weekend!
Kay
Hoff
Honored Contributor

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

I'd recommend that you monitor your code for alignment faults. I'd monitor. I'd not assume. (I've seen a few weird and obscure cases trigger zillions of these over the years, and zillions of alignment faults in a hot code path can make a speedy Integrity box into, well, something about as speedy as an old VAX box.)

Here's an overview of alignment faults and an estimate of the costs of same: http://64.223.189.234/node/160

In isolation, I'd suggest moving off of VAX floating point on OpenVMS Alpha (for common code and for cross-compatibility), and I'd recommend moving off of VAX floating point on OpenVMS I64 (as it is a non-native FP format, with all that entails).

In isolation, I'd look to either align the structures or use the member alignment pragmas that are available within C, and not the /NOMEMBER_ALIGN qualifier; the qualifier effective, but is also is a very large hammer.

Your particular situation is almost certainly unique, and there could conceivably be reasons where you want or need to use VAX floating point or where you want to use big hammers on your C code.

In general, reducing or avoiding alignment faults and avoiding unaligned data structures in frequently-used code paths and moving to the IEEE floating point formats are often among the low-hanging fruit of application performance and tuning.

Stephen Hoffman
HoffmanLabs LLC
Kay Dolle
Advisor

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

How to monitor alignment faults?
I found http://h71000.www7.hp.com/doc/82FINAL/6549/6549pro_030.html
Is that SDA and FLT stuff on our utility-cd? Or do we have to buy a license for that?
Is there an other way for an analyse?
What ist an alignment fault? Is that every time the program moves data from one kind of float to an other and has to map it correctly?
Do we get an alignment fault by calling an RTL-Routine (p.e. OTS$CVT_T_G while using FLOAT=G_FLOAT, or LIB$WAIT while accessing it with an Cobol "comp-1"-value)?
Btw. we don't store float at any time!
Hoff
Honored Contributor

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

[[[How to monitor alignment faults? ]]]]

Look around at various of the presentations around the network. See below for two articles from VTJ. There are other postings around the network that can be found with Google.

[[[I found http://h71000.www7.hp.com/doc/82FINAL/6549/6549pro_030.html]]]

That chapter of that manual looks to be fodder for a bug report. IMHO, that particular chapter does not approach the traditional OpenVMS documentation quality.

[[[Is that SDA and FLT stuff on our utility-cd? Or do we have to buy a license for that? ]]]

The core tools for this are typically included with and installed with OpenVMS. (A couple of command-level tests on your box should show the tools to be present.)

[[[Is there an other way for an analyse? ]]]

There are various ways to look for alignment faults. See below.

[[[What ist an alignment fault? ]]]

At its simplest, when data being accessed is not naturally aligned.

http://h71000.www7.hp.com/doc/82FINAL/5841/5841pro_047.html

[[[Is that every time the program moves data from one kind of float to an other and has to map it correctly? ]]]

No.

[[[Do we get an alignment fault by calling an RTL-Routine (p.e. OTS$CVT_T_G while using FLOAT=G_FLOAT, or LIB$WAIT while accessing it with an Cobol "comp-1"-value)? ]]]

Probably not, though the answer depends on how the particular data is stored and access. Run the fault monitoring and see.

[[[Btw. we don't store float at any time!]]]

Store or exchange or compare? I'd be moving toward IEEE FP shortly after learning that. On Alpha and I64.

If all the code here is doing with FP is working with the timer routines that keep getting mentioned within this thread, I might well replace the whole processing with one of the APIs that use integers.

Here's some reading material:

http://h71000.www7.hp.com/openvms/journal/v9/index.html#faults

And if all the FP was strictly for timers and was replaced with integer-based timers, I'd still monitor an OpenVMS I64 application for alignment faults.


Kay Dolle
Advisor

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

Thanks!