Operating System - OpenVMS
1748057 Members
5287 Online
108758 Solutions
New Discussion

Re: Compiler Options and COMP values on Disk

 
SOLVED
Go to solution
Homer Shoemaker
Frequent Advisor

Compiler Options and COMP values on Disk

rx2660, OpenVMS 8.4, COBOL v2.9

 

If I store a COMP type value on disk from a program compiled using the default (IEEE) floating point format for the HP COBOL complier on an IA64, and then I recompile that same program using another (G_FLOAT) floating point format, will my new program be able to read the previously written data from disk correctly?

 

 

Some background:

 

I have a call to LIB$WAIT in an include file that exists in almost every program in our application.  It is used for handling record locks when a program is operating in batch mode.  Apparently, LIB$WAIT depends on the binary representation of a floating point number passed to it  (in G_FLOAT format) rather than on the value itself.  The simple fix is to recompile using /FLOAT=G_FLOAT.   Maybe...

 

I also have many files with a lot of existing data stored as type COMP-3.  Before I change our build tool to use the new (older) float type, I want to be sure that  I won’t be creating more problems than I’m solving.  I’d rather not have to convert all my existing data, and I’d rather not have recompile ALL my programs at once.  Maybe the compiler and RMS are smart enough that I’m worrying about nothing.  I hope so.

 

I was going to write a test program to try this out, but I wondered if anyone else had already crossed this bridge?

 

23 REPLIES 23
abrsvc
Respected Contributor
Solution

Re: Compiler Options and COMP values on Disk

You have listed 2 different issues here.  Let me address the calls to LIB$WIAT first.

 

The call has an optional parameter as defined in the manual as follows:

         LIB$WAIT seconds [,flags] [,float-type]

 

Parameter 3 defines the floating type.  So the call can handle any type of floating binary value as long as you indicate the type properly.

 

 

Second:  The issue of binary data.

 

If you know that the binary data is of a particular format, then read it as such and convert it.  Anything stored using the COMP datatype wil be in the specific format of that datatype and not directly readable into another type without conversion.  The floating types are defind as particular groupings of bits with those bits "arranged" in a particular order.  (Please note that I am being ambiguous on purpose here).  Just as a simplistic example, reading a floating binary data area (longword) into an integer variable can lead to interesting results.  As the most clear example, assume a floating zero(0).  When read into an integer, the value is NOT zero as the actual bits for a floating point value of zero include a 1 somewhat in the middle of the longword.

 

Hope this helps a bit...

 

Dan

Steven Schweda
Honored Contributor

Re: Compiler Options and COMP values on Disk

 
abrsvc
Respected Contributor

Re: Compiler Options and COMP values on Disk

RE: Steve

 

I'm sorry but you are wrong in this case.  Using the formatting capability of the printf hides the fact that the binary representation of the number is different for floating and integer.

 

I'm doing this from memory so I may be off by a bit or two, but the f_floating format is comprised of the following parts:

 

1) 1 bit for the sign

2) 7 bits for hte exponent

3) 24 bits for the fraction

 

Within the above, the exponent "value" for a zero is usually a 1 which would make bit #7 a 1 rather than a 0.  This means that the floating zero would be a 0080hex and not a 0000 as would be expected for an integer zero.

 

Similarly, the groupings of bits and how they are interpreted is different for IEEE and the VAX formats.

 

Dan

Steven Schweda
Honored Contributor

Re: Compiler Options and COMP values on Disk

 
Steven Schweda
Honored Contributor

Re: Compiler Options and COMP values on Disk

 
Dennis Handly
Acclaimed Contributor

Re: Compiler Options and COMP values on Disk

>If I store a COMP type value on disk from a program compiled using the default (IEEE) floating point format

 

This shouldn't matter since COMP (usually) only contains fixed point data, not floating point.

 

>the value is NOT zero as the actual bits for a floating point value of zero include a 1 somewhat in the middle of the longword.

 

I'm not sure what floating point type you are talking about but it isn't IEEE, unless you are talking about -0.

Or are talking about IEEE floating point decimal where there are N values of zero, where the one with all bits zero wouldn't normally be produced or used.

 

>I'm sorry but you are wrong in this case.  Using the formatting capability of the printf hides the fact that the binary representation of the number is different for floating and integer.

 

As Steven says, not hardly.  His program (with %x and union) is proof of what he said.

 

>the f_floating format is comprised of the following parts:

>1) 1 bit for the sign  2) 7 bits for the exponent 3) 24 bits for the fraction

 

Yes.  But zero is treated special, in more ways than one.

John Gillings
Honored Contributor

Re: Compiler Options and COMP values on Disk

Homer,

 

  No. Neither COBOL nor RMS "know" the data type on disk, so they can't do any conversions for you. I think Fortran had a mechanism to tell the compiler to do an on-the-fly conversion of specified fields, but I'm sure you don't want to rewrite everything in Fortran.

 

  From your description you have a large set of data files using one format and a tiny routine using the other. You want to make a major change to your data just to satisfy LIB$WAIT? Talk about tails wagging dogs!

 

  As Dan has explained, LIB$WAIT has a parameter to select the data type. That's your simplest solution. But even if we assume that wasn't available, it would be better to attack the little problem than change everything else to conform.

 

  Two simple ways to get around the problem. You could lie to the compiler, telling it the  F_FLOAT (note NOT G_FLOAT) parameter is really INTEGER and hardcode the appropriate F_FLOAT bit pattern into an INTEGER. Your code doesn't know it's floating data, so you're free to compile with IEEE for everything else.

 

Simple way to determine the right bit pattern (ie: INTEGER value), use DEBUG

 

$ run/debug any

         OpenVMS Alpha Debug64 Version V8.3-016

%DEBUG-I-INITIAL, Language: AMACRO, Module: .MAIN.

DBG> deposit/f_float r0=5.0
DBG> examin/hex r0
.MAIN.\START\%R0:       00000000000041A0
DBG>  examine/decimal r0
.MAIN.\START\%R0:       16800
DBG>

 

  So an INTEGER value 16800 will give a 5 second delay when passed to LIB$WAIT.

 

  Another way is to write a small jacket routine in whatever language you like, compiled with the appropriate floating point which performs whatever conversions are necessary (see routine CVT$CONVERT_FLOAT). If you only have one use for LIB$WAIT, you may not even need a conversion. Just write a routine called DELAY and leave the time interval hardcoded.

 

Note, G_FLOAT is as incompatible with F_FLOAT as IEEE. Passing G_FLOAT to LIB$WAIT won't work. There is another double precision floating format, D_FLOAT, which is an F_FLOAT value with an extra 32 bits of precision. This would be compatible with LIB$WAIT, but you really don't want to use D_FLOAT! I'd be aiming to migrate all programs and data to IEEE and forget the older formats ever existed.

A crucible of informative mistakes
Homer Shoemaker
Frequent Advisor

Re: Compiler Options and COMP values on Disk

Thank you, all. 

 

I really thought that I would have to change my compiler option.  But since Dan seemed to think that I could actually make the call to LIB$WAIT work, I figured I'd give it another try.  The second question would be moot, if I could get the call to LIB$WAIT to work.

 

If the attachment worked, you can see the COBOL code, compiled with the default float type on the I64,  that demonstrates the call to LIB$WAIT working.

 

But even though FLOAT-TYPE  1 thru 5 returned a NORMAL status, only FLOAT-TYPE 4 created the 5 second delay.

 

 

John Gillings
Honored Contributor

Re: Compiler Options and COMP values on Disk

Homer,

  

>But even though FLOAT-TYPE  1 thru 5 returned a NORMAL status, only FLOAT-TYPE 4 created the 5 second delay.

 

 Correct! Bits are bits. You store the value "5.0" as IEEE floating point, which is hex "40140000". LIB$WAIT interprets it as whatever data type you tell it. Interpreted as F, D, G or H float that bit pattern is 0.

 

DBG> dep/float r0=5.0
DBG> ex/hex r0
0\%R0:  4014000000000000
DBG>  ex/f_float r0
0\%R0:  0.0000000
DBG> ex/d_float r0
0\%R0:  0.000000000000000
DBG> ex/g_float r0
0\%R0:  0.000000000000000
DBG>  ex/h_float r0
0\%R0:  0.000000000000000000000000000000000
DBG> ex/float r0
0\%R0:  5.00000000000000
DBG> ex/extended_float r0
0\%R0:  5.00000000000000355705048749044295

 

 

A crucible of informative mistakes