using fortran and profor with upgraded VMS and Oracle

[robert70]

Having trouble running some fortran executables after recompile.

we have upgraded Alpha DS20E from VMS 7.3-2 to VMS 8.3 and Oracle 9i to Oracle10g

Fortan V7.5-1961-48BCD (not been upgraded)&
Pro*Fortran Release 1.8.79.2.0

compiles and links no problem as below.......
AMT:) @nretro_buildd
Pre-Compiling Pro*FORTRAN routines

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:41:59 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling NCURR.pfo

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:42:01 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling DELETE.pfo

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:42:04 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling GET_TRANSACTIONS.pfo

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:42:06 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling GET_VTRANS.pfo

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:42:08 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling GET_V_FOLIOLU_NAME.pfo

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:42:10 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling GET_V_FOLIO_RIGHTS.pfo

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:42:13 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling INITIALISE_PRICES.pfo

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:42:15 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling UPDATE_PRICES.pfo

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:42:17 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling GET_INDEX_INFO.pfo

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:42:20 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling GET_VDHIST_LIST.pfo

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:42:22 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling GET_V_FOLIO_INFO.pfo

Pro*FORTRAN: Release 1.8.79.2.0 - Production on Tue Jul 27 16:42:24 2010

Copyright (c) 1982, 2005, Oracle. All rights reserved.

System default option values taken from: ora_pcc:pccfor.cfg

Precompiling GET_V_CURR.pfo
Compiling FORTRAN routines
- Compiling NRETRO_ROUTINES
- Compiling NINDEX
- Compiling NCURR
- Compiling DELETE
- Compiling GET_TRANSACTIONS
- Compiling GET_INDEX_INFO
- Compiling GET_VTRANS
- Compiling GET_V_FOLIOLU_NAME
- Compiling GET_V_FOLIO_RIGHTS
- Compiling GET_V_FOLIO_INFO
- Compiling GET_VDHIST_LIST
- Compiling INITIALISE_PRICES
- Compiling GET_V_CURR
- Compiling NDHIST_ROUTINES
- Compiling UPDATE_PRICES
- Compiling CALC_INDEX
- Compiling RETRO
Creating library routines
- Linking NR.exe

when you run NR we get this..............

run nr

OpenVMS Alpha Debug64 Version V8.3-014

%DEBUG-I-INITIAL, Language: FORTRAN, Module: CHRCOM

DBG> go

Retrospective Update Program V1.3

Illegal USERPASS.DAT or file not found
Attempting automatic login
Commencing automatic login...
Connected.

Enter the mnemonic of the valuation portfolio, # for help or EXIT : uniuka
Mnemonic not found - please reenter.

Enter the mnemonic of the valuation portfolio, # for help or EXIT : UNIUKA

Enter start date (31-JUL-95), or latest update date [01-APR-10] : 01-MAY-10
Enter stop date [28-MAY-10] :
Delete the above dates? (Y/N) : Y
Deleting from table ...

Extracting information from database...
Initialising prices ...
G:POUND05-MAY-10 0.000000000000000E+000
Initialising transaction list ...
Initialising rights list ...
%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00000
004, summary=02, PC=0000000000040354, PS=0000001B
-SYSTEM-F-FLTINV, floating invalid operation, PC=0000000000040354, PS=0000001B
break on unhandled exception preceding CREATE_RIGHTS_ARRAY+1820 in THREAD 1
DBG>

Is their some compatability issues I have missed since the subsequent upgrades?
Any help would be greatly appreciated
Thanks

[Hein van den Heuvel]

Hmmm that's a lot of text with very little of value for us.
Showing a single compile is nice.
Showing the contents of ora_pcc:pccfor.cfg might be useful.

But looking at the run result I notice:
:
Illegal USERPASS.DAT or file not found
:
break on unhandled exception preceding CREATE_RIGHTS_ARRAY

This begs the question whether it is OK that the 'userpass' file is not found.

I also see a big fat 0 in : G:POUND05-MAY-10 0.000000000000000E+000
Is that used as a divisor?

Most importantly, since you have the source, what is the code trying to do around:
CREATE_RIGHTS_ARRAY+1820

Is there a SQL statement just before that?
Can you issue it manually (SQLplus) and check for a reasonable result?

Good luck!
Hein

[Hoff]

As Hein indicates, that's a whole lot of characters, and not all that much help.

Did you have a look at the application source code around the floating-point error, using the debugger?

Put another way, have you proved that this isn't a latent error in the code? (When I see folks pointing at the compiler or the RTL or at VMS as the trigger - and without also including details of the investigation, supporting evidence or a source code reproducer of the error - then the first spot to investigate is not the compiler nor the RTL nor VMS, it's in the application code.)

Have you enabled moderate- or gonzo-level diagnostics with the Fortran compiler? If the diagnostics are disabled or the code is being built with optimization shut off or deliberately operating with the debugger in production, then the index of suspicion of latent application bugs increases.)

Have you checked for known errors and similar errors and problem reports and minimum version details over in Oracle Metalink?

Have you looked for Fortran updates and Fortran RTL patch kits and OpenVMS patches?

[Steven Schweda]

> Is that used as a divisor?

> %SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000, Fmask=00000004, [...]

HELP /MESS HPARITH

Around here:

> [...]
> The Fmask parameter [...]
> [...]
> Bit 2 Division by Zero
> [...]

[robert70]

sorry about the lack of info

we have many fortran programs and they all are not working now since the upgrade to VMS8.3 and Oracle10g so I dont think it is problems with the code.

the userpass.dat error is ok - I've resolved this but not an issue in any case.

I am will look around for fortran/RTl updates as suggested and see if that helps me along.

the pccfor.cfg contains the single line
ireclen=100

[Steven Schweda]

> we have many fortran programs and they all
> are not working now [...]

Are they all failing with divide-by-zero
problems?

> [...] I dont think it is problems with the
> code.

Do you mean "the code" before Pro*FORTRAN
does its "Precompiling" or after?

You might wish to look at the actual Fortran
code to see what it's doing.

> G:POUND05-MAY-10 0.000000000000000E+000

Is that ("big fat") zero what you expected to
see there?

> Is that used as a divisor?

Still sounds like a good question to me.

My psychic powers are too weak to tell me
what your code is trying to do, or whether
any of its output is reasonable.

> sorry about the lack of info

More useful info would be better than an
apology.

[Hein van den Heuvel]

>> we have many fortran programs and they all are not working now since the upgrade to VMS8.3 and Oracle10g so I dont think it is problems with the code.

So then focus on the smallest possible one.
Just a single module perhaps, getting a single row from a single table.
Does that work?
Does it work from SQLplus?

How is the error handling?
Is there anything reported when nothing is returned?

Did you install a new server version only, or also the new client code? New Oracle_home?
Is there a new TNSnames.ora in place? Correctly?

>> the userpass.dat error is ok - I've resolved this but not an issue in any case.

ok. It was suspect.

>> I am will look around for fortran/RTl updates as suggested and see if that helps me along.

I doubt it. Focus on Oracle client install, TNS / Listener, and verify with known to be working components, like SQLplus or perhaps even the old 9i build code, as that is supposed to work against a 10g server.

>> the pccfor.cfg contains the single line
ireclen=100

ok. thanks for checking.

Hein

[Hoff]

What a programmer ASSUMES can (sometimes!) make a reasonable hypothesis for starting an investigation into a bug. At most. What the programmer can PROVE is interesting. What the programmer can REPRODUCE is even better.

Whether you realize it or not, this is a huge red flag:

"...so I dont think it is problems with the code..."

That the code is built with the debugger, and we don't yet know what triggered the error, and that we're still trying to sort that trigger out is another series of red flags.

Debug the code.

Isolate the problem.

Get the fix, the workaround, or the reproducer.

Or get somebody in that can provide that for you.

(There's the parallel discussion around what you want to do with and how you want to fund this application environment and maintenance going forward. That's a separate - but related - discussion that's undoubtedly underway.)

[robert70]

I have come across a fix for this !
basically added the flag /FLOAT=IEEE
on the fortran compilation
All seems fine now.
Still having problems now with some CXX progs but suspect the /FLOAT flag may solve the problem

[Patrick Aspinall]

Robert,

Check what the floating point format is set to in in your compiler symbols, it may be set to one other than IEEE.

Oracle 9i supported floating-point formats other than IEEE when running on OpenVMS, this feature was removed for 10g.

If this is a recent change you have made and you were running Oracle 9i with a floating-point format other than IEEE, you will not be able to restore data into your 10g database without running it through a wrapper that will convert the floating-point format of the input data.

[robert70]

THANKS PATRICK
how do i check what the value is set to?
a wrapper? explain to me what this is please thanks

[Patrick Aspinall]

Robert

Enter one or all of

sh sym cxx
sh sym cc
sh sym for

and look for what the '/float' qualifier is set to.

When we moved to Itanium, we were unaware that support for non-IEEE FP types had been removed from Oracle10g. Indeed, Oracle themselves seemed to be unaware of it and we spent some time going round the buoy with Oracle support.

The problem we then had was that data originally running on VAX and then Alpha (but still relying on the D_FLOAT FP type) would not work on 10g.

It was decided that since

a) We handled considerable volumes of data across many sites
b) All our DB access was done through a wrapper layer

we would update our DB wrapper code to use the

CVT$CONVERT_FLOAT

function to perform the necessary floating-point conversion on the way in and out of the database.

I'm just flagging up that if your Oracle9i setup is using a non-IEEE format you wont be able to restore any of that data into an Oracle10g database. You would have to write something to perform the CVT$CONVERT_FLOAT operation onto your data as you write it into your new database.

[robert70]

interesting stuff Patrick
sounds like we might be in for a long upgrade process!!

would the problem expalin this compile error?

$@forcomp

parameter (min_real_16 = -0.841Q-4932)
................................^
%F90-E-ERROR, The value was either too large or too small when converting to a R
EAL(KIND=16) number, and overflow/underflow occurred. [0.841Q-4932]
at line number 74 in file DAVE$DKB1:[LIBRARY7]MACH_CONSTS.DEF;10


MACH_CONSTS.DEF is in the library7 directory that we use for all our fortran programs. The programmers that wrote the code have long left the company so not sure why that particular number .841 to the power -4932 is used

[abrsvc]

The value is the limit for a VAX H_Float number. I would check to see if the parameter is defined as REAL*16.

The range for an H_float (REA*L16) number is:
0.84*10**--4932 through 0.59*10**4932

Dan

[robert70]

thanks
understood
it has been defined as real*16

[abrsvc]

I forgot to include that the floating point format for IEEE standards is slightly different than for the VAX H_Float format. This means that the accuracy and ranges are different. Check the manuals for the limits for the floating point format you are using to adjust this parameter for that limit.

Dan

[robert70]

thanks DAN
so I would have to change my *.DEF file which currently shows

c reals

real*4 max_real_4
parameter (max_real_4 = 1.7E38)

real*4 min_real_4
parameter (min_real_4 = -0.30E38)


real*8 max_real_8
parameter (max_real_8 = 1.7D38)

real*8 min_real_8
parameter (min_real_8 = -0.30D38)

real*16 max_real_16
parameter (max_real_16 = 0.59Q4932)

real*16 min_real_16
parameter (min_real_16 = -0.841Q-4932)

Update this with the correct IEEE floating point values?

Not sure where to find these but I will have a look

[abrsvc]

It would appear so. I have those values documented, but not with me. I can update this later or maybe Hoff has these values readily available?

I'm not sure why the program would care specifically without seeing the code stream, but it appears that the limits are used somewhere in the code.

An examination of the code around the failure point might give us a clue:
CREATE_RIGHTS_ARRAY+1820
Can you post the code around the above point?

[robert70]

heres the subroutine..............


subroutine create_rights_array (v_mnem, start_date, end_date, rights, sâ ¦

include 'valuation.def'


character*7 v_mnem

integer*4 num

real*8 v_tshares(500),call_price (500)
real*8 stock_price
real*8 value, cost_value
real*8 cap_value

integer*4 seconds

character*3 valuation_curr

character*9 prev_date, or_time
character*16 add_time, jc_time

character*9 cap_date (500), start_date, end_date
character*7 s_mnem (500)
character*3 c_mnem (500)
c character*3 v_curr (10)

real*8 exchange_rate_2

integer*2 status,
> date_count,
> count

record / rights_record / rights
â
seconds = -1 * seconds_in_day

value = 0.0
cost_value = 0.0


call get_v_folio_rights (v_mnem,
> start_date,
> end_date,
> s_mnem,
> v_tshares,
> call_price,
> cap_date,
> c_mnem,
> num,
> status)

if (status) then

if (num .ge. 1) then

date_count = 1
count = 1
rights.cap_date(date_count) = cap_date (count)
rights.value(date_count) = 0.0
rights.cap_value(date_count) = 0.0

do while (count .le. num)

if (cap_date(count) .ne.
> rights.cap_date(date_count)) then

date_count = date_count + 1
rights.cap_date(date_count) = cap_date(count)
rights.value(date_count) = 0.0

endif


prev_date = or_time (add_time
> (jc_time(cap_date(count)), seconds))

value = call_price(count) * v_tshares(count) *
> exchange_rate_2 (valuation_curr(v_mnem, prev_date),
> c_mnem(count),
> prev_date)

cost_value = call_price(count) * v_tshares(count) *
> exchange_rate_2 (valuation_curr(v_mnem, cap_date(count)),
> c_mnem(count),
> cap_date(count))

cap_value = stock_price(s_mnem(count), cap_date(count)) *
> v_tshares(count) *
> exchange_rate_2 (valuation_curr(v_mnem, cap_date(count)),
> c_mnem(count),
> cap_date(count) )

rights.value(date_count) = rights.value(date_count) +
> value

rights.cap_value(date_count) =
> rights.cap_value(date_count) +
> cap_value

rights.cost_value(date_count) =
> rights.cost_value(date_count) +
> cost_value

count = count + 1

enddo

rights.number = date_count

endif
endif

return
end

[Mike Kier]

Fortran 95 provides the HUGE and TINY intrinsic functions (*) to return the largest and smallest positive values representable for a given data type (KIND) and is the preferred mechanism since it is defined in the standard and is more portable between physical hardware types and underlying data representations.

The model does not assume a twos-complement implementation so the negative values are not provided.

Example:

HUGE and TINY for a REAL*16 KIND on Alpha with /FLOAT=IEEE_FLOAT returns

HUGE 1.189731495357231765085759326628007E+4932
TINY 3.362103143112093506262677817321753E-4932

(* - along with DIGITS, EPSILON, MAXEXPONENT, MINEXPONENT, PRECISION, RADIX, and RANGE for all numeric KINDS as well as EXPONENT, FRACTION, NEAREST, RESPACING, SCALE, SET_EXPONENT, and SPACING for REAL KINDS - see HELP FORTRAN INTRINSICS)

[Barry Alford]

You may be better off using the Fortran intrinsic functions HUGE(x) and TINY(x) where x is a real of the required type - REAL(16) for you

[robert70]

Mike

do you have the values for the 4, 8 and reals?

real*4 max and mins?
real*8 max and mins?

thanks

[Mike Kier]

Sure, but you can get them yourself very easily - just compile and run the following with different values for the /FLOAT qualifier on the compiler:

type *, 'TINY16', tiny(0.0_16), 'HUGE', huge(0.0_16)
type *, 'TINY8 ', tiny(0.0_8), 'HUGE', huge(0.0_8)
type *, 'TINY4 ', tiny(0.0_4), 'HUGE', huge(0.0_4)
end

For /FLOAT=D_FLOAT I get:

TINY16 3.362103143112093506262677817321753E-4932 HUGE
1.189731495357231765085759326628007E+4932
TINY8 2.9387358770557188E-39 HUGE 1.7014118346046923E+38
TINY4 2.9387359E-39 HUGE 1.7014117E+38

For /FLOAT=G_FLOAT I get:

TINY16 3.362103143112093506262677817321753E-4932 HUGE
1.189731495357231765085759326628007E+4932
TINY8 5.562684646268003E-309 HUGE 8.988465674311579E+307
TINY4 2.9387359E-39 HUGE 1.7014117E+38

For /FLOAT=IEEE_FLOAT I get

TINY16 3.362103143112093506262677817321753E-4932 HUGE
1.189731495357231765085759326628007E+4932
TINY8 2.225073858507201E-308 HUGE 1.797693134862316E+308
TINY4 1.1754944E-38 HUGE 3.4028235E+38

And ideally you would not hardcode the values in your program - use the HUGE and TINY intrinsics to initialize real variables instead of Parameters at program start-up.

Please tell me you're not using extended precision floating-point for monetary calculations...

BTW: This is on OpenVMS Alpha V7.3-2 and Fortran V7.5-1961

[John Gillings]

Robert,

Please heed Mike's advice:

"Please tell me you're not using extended
precision floating-point for monetary
calculations..."

No matter how much floating point precision you have, you WILL get calculation errors. There's nothing you can do about it, it's the nature of finite precision floating point representation. FPFPR is great for scientific and engineering work, but it just plain doesn't work for financial stuff. This is not debatable, and I don't care how long you've been doing it - you shouldn't!

If you're doing money calculations, forget all REAL types. In Fortran you can use 64 bit INTEGER types scaled to your smallest unit (cents or tenths of cents).

If you don't believe me, try this simple test... manually convert $0.10c (decimal) into 32 or 64 bit binary floating point, now convert it back.

[robert70]

Thanks Mike,
Why does the compiler not like this?

real*16 max_real_16
max_real_16 = huge(max_real_16)

Thanks
Robert