- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: Compiler Options and COMP values on Disk
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2011 11:28 AM
12-19-2011 11:28 AM
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?
Solved! Go to Solution.
- Tags:
- COBOL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2011 11:42 AM
12-19-2011 11:42 AM
SolutionYou 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2011 12:10 PM
12-19-2011 12:10 PM
Re: Compiler Options and COMP values on Disk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2011 12:21 PM
12-19-2011 12:21 PM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2011 12:39 PM
12-19-2011 12:39 PM
Re: Compiler Options and COMP values on Disk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2011 12:46 PM
12-19-2011 12:46 PM
Re: Compiler Options and COMP values on Disk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2011 12:56 PM - edited 12-19-2011 01:07 PM
12-19-2011 12:56 PM - edited 12-19-2011 01:07 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2011 12:56 PM
12-19-2011 12:56 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2011 01:35 PM
12-19-2011 01:35 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-19-2011 04:02 PM
12-19-2011 04:02 PM
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