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

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!