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.