Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Oracle RDB 7.1-520 and Fortran Program Error

bfraga
Occasional Advisor

Oracle RDB 7.1-520 and Fortran Program Error

Hello,

I'm with the following problem.
I had an AlphaServer (DS20) with OpenVMS 7.3-2 and Oracle RDB 7.0-63.
I needed to upgrade the RDB version to 7.1-520, so I've installed this new version without uninstalling version 7.0-63 first, it is multiversion.
I've converted the databases, updated the logical names, I did everything in the manual to work with multiversion.

Almost everything worked, now I have a problem with some programs written in Fortran that uses the function SYS$HIBER. This program starts a thread and enter the hiber state waiting to run again with the timer, it works with RDB 7.0-63.
When the program uses the RDB 7.1-520 the program executes the thread and then exits the hiber state, it does'n keep running waiting for the timers.

I've uninstalled version 7.0-63 but the problem continues. I've recompiled the program using the 7.1 precompiler and libraries and it didn't work. I've another AlphaServer with the same configuration and in this server the program works, and i can't find what it's diferent in my server!

I've made some tests with the program and detected that if I change all ROLLBACK command to COMMIT the program works with version 7.1, but I can't do this.
12 REPLIES
abrsvc
Respected Contributor

Re: Oracle RDB 7.1-520 and Fortran Program Error

A few things to check first:

1) Make sure that you have the same patch levels of the system components as the system that works.

2) Post here the releveant code segments showing what you are attempting to do. We can not see that here.

3) Post the code that implements the $HIBER/$WAKE.

Dan
bfraga
Occasional Advisor

Re: Oracle RDB 7.1-520 and Fortran Program Error

I've made a simple program to test the instalation, it only declares the database, opens a transaction, executes a rollback and hibernate. If I change the rollback to commit it works! With rollback it executes and exits.

PROGRAM TESTE

IMPLICIT NONE

INCLUDE '($SYSSRVNAM)'

EXEC SQL INCLUDE SQLCA

INTEGER*4 STATUS

CHARACTER*32 CHS_TABELA,
1 CHS_CAMPO

C.... Declara o banco

D type *,'.... Declaring Database ....'

EXEC SQL DECLARE LOCAL ALIAS FILENAME BD_BDG

C.... Declara a transacao

D type *,'.... Declaring transaction ....'

EXEC SQL SET TRANSACTION READ ONLY
1 RESERVING BDG_REMOCAO_PH,BDG_EVENTOS_REMOCAO_PH
1 FOR SHARED READ

C.... Executing ROLLBACK

EXEC SQL ROLLBACK

C.... Hibernating!

STATUS = SYS$HIBER()

type *,'STATUS:', STATUS

END
Hoff
Honored Contributor

Re: Oracle RDB 7.1-520 and Fortran Program Error

This looks to be two separate albeit related errors.

One is a spurious $wake over in the Oracle code somewhere. Usual suggestions apply: call Oracle, log bug, enjoy the benefits of the requisite support contract, etc.

The second error is within the code here, and specifically in that the code doesn't expect to receive spurious $wake calls.

The debugger has long been a source of spurious wakes or spurious stalls for some eons, though that (mis)behavior was updated in a "recent" release. (I'm not sure if you're before or after that change, off-hand.)

When writing defensive code while working with these particular "un-reentrant" process state management calls, I tend to go as far as deliberately inducing spurious $wake calls with the addition of a $schdwk call in the program. Yes, that's hideous. Yes, the code should be perfect. Yes, all the calls should be balanced. Yes, any programming purists will scream. But if the calls aren't balanced or if there's a race somewhere or if there's a $wake that gets eaten somewhere, then this will magically unwedged the stuck (missed-$wake) application. And yes, the $schdwk will also test the spurious $wake path.
GuentherF
Trusted Contributor

Re: Oracle RDB 7.1-520 and Fortran Program Error

From the descriptiom of $HIBER:

"If one or more wakeup requests are issued for the process while it is not hibernating, the next hibernate call returns immediately; that is, the process does not hibernate."

Means, a process always has to check for a condition when it comes out of $HIBER to know that this is the expected wakeup.

If I remember right there was a fix in Rdb code to make sure that $WAKEs within Rdb are not stuck on a $HIBER.

Bottom line...you have to make modifications in your code around the $HIBER calls.

Something like:

Use a boolean which is set false before the $HIBER call loop and set true in the code doing the wakeup call. As long as the boolean is false the program calls $WAKE again.

/Guenther
John Gillings
Honored Contributor

Re: Oracle RDB 7.1-520 and Fortran Program Error

Getting $HIBER/$WAKE synchronisation correct can be tricky. There are several things you need to concern yourself with...

Realise that $WAKEs are system wide. Any process (with sufficient privilege) can $WAKE any other process. Also any thread of execution within the process can issue a $WAKE. You therefore need to protect yourself against spurious $WAKEs. This is usually done with a flag to indicate the state of the event you're waiting for. Something like:

flag=FALSE
RequestEvent

...

DO WHILE (NOT flag)
$HIBER
ENDDO

Code that finalises the event looks like:

flag=TRUE
$WAKE


Now you need to consider that other threads can also $HIBER waiting for their own $WAKEs. These may consume your $WAKE, leaving your $HIBER sleeping forever (hopefully the code that sees your $WAKE will correctly deal with being woken prematurely).

You can protect other threads from getting stuck by issuing a $WAKE after being woken yourself (add a $WAKE after the ENDDO above). A "big hammer" protection would request a recurring $SCHDWK which will generate a periodic $WAKE just in case one gets lost. This makes your $HIBER loop poll every so often, but with a sufficiently long schedule (say, several minutes), the cost is negligible. If some other thread consumes your $WAKE, and doesn't issue another, worst case you'll need to wait the schedule period.

This all assumes the other threads are protected against spurious $WAKEs. One would hope that commercial software like RDB would be coded correctly.
A crucible of informative mistakes
GuentherF
Trusted Contributor

Re: Oracle RDB 7.1-520 and Fortran Program Error

Oops, thanks John for providing a more correct example. I had my HIBER and WAKE calls mixed up in the description. Well somehow bugs have to get into software, eh?

/Guenther
Hoff
Honored Contributor

Re: Oracle RDB 7.1-520 and Fortran Program Error

I've tended to use a work queue for the tasks pending the mainline, where the $wake adds work (via AST or such), and waking up attempts to pull some work off the queue, else it dozes off. That's probably overkill here, but...

Make sure any read-modify-write flag variables you might implement for John's approach are interlocked correctly if you have ASTs or threads flying around, and particularly if you are sharing those variables among threads or among AST and non-AST contexts. (If not, you can end up needing that $schdwk call.)
Kjell Carlsson
Frequent Advisor

Re: Oracle RDB 7.1-520 and Fortran Program Error

Don't use $hibernate within a process which accesses RDB ver. 7.1 and later. Oracle uses $wake. The simplest work around is to use event flags.

Also lib$wait will not work together with RDB 7.1 in the hibernate mode. You must use the event flag mode.

//kjell
labadie_1
Honored Contributor

Re: Oracle RDB 7.1-520 and Fortran Program Error

Hi

>>>I've another AlphaServer with the same configuration and in this server the program works, and i can't find what it's diferent in my server!

Check the SYS patch is at the same version on both Alphas.
The last one is 21
VMS732_SYS-V2100
bfraga
Occasional Advisor

Re: Oracle RDB 7.1-520 and Fortran Program Error

The sys patch isn't the same. In the server that works is V6.0 and the other is V17.0.

In the Alpha that works:

DEC AXPVMS VMS732_UPDATE V20.0
DEC AXPVMS VMS732_FIBRE_SCSI V16.0
DEC AXPVMS VMS732_UPDATE V17.0
DEC AXPVMS VMS732_PCSI V5.0
HP VMS TDC V2.3-15
DEC AXPVMS VMS732_FIBRE_SCSI V13.0
DEC AXPVMS VMS732_UPDATE V13.0
DEC AXPVMS VMS732_PCSI V3.0
DEC AXPVMS DNVOSIECO03 V7.3-2
DEC AXPVMS VMS732_VMSMUP V1.0
DEC AXPVMS VMS732_SYSINI V1.0
DEC AXPVMS VMS732_LINKER V1.0
DEC AXPVMS VMS732_DRIVER V1.0
DEC AXPVMS TCPIP_ECO V5.4-154
DEC AXPVMS VMS732_GRAPHICS V2.0
DEC AXPVMS VMS732_XFC V1.0
DEC AXPVMS VMS732_RMS V2.0
DEC AXPVMS VMS732_F11X V3.0
DEC AXPVMS VMS732_FIBRE_SCSI V4.0
DEC AXPVMS VMS732_SYS V6.0
DEC AXPVMS VMS732_UPDATE V3.0
DEC AXPVMS VMS732_PCSI V1.0
CPQ AXPVMS CDSA V2.0-109
DEC AXPVMS DECNET_OSI V7.3-2
DEC AXPVMS DWMOTIF V1.3-1
DEC AXPVMS OPENVMS V7.3-2

In the Alpha that doesn't work:

DEC AXPVMS VMS732_UPDATE V20.0
ORCL AXPVMS RDBJDBC72 V7.2-5V386O
DEC AXPVMS JAVA142 V1.4-24P5
DEC AXPVMS JAVA142 V1.4-24P2
DEC AXPVMS JAVA142 V1.4-24
DEC AXPVMS VMS732_FIBRE_SCSI V16.0
DEC AXPVMS VMS732_UPDATE V17.0
DEC AXPVMS VMS732_PCSI V5.0
DEC AXPVMS VMS732_LAN V6.0
DEC AXPVMS VMS732_COPY V2.0
DEC AXPVMS VMS732_F11X V6.0
DEC AXPVMS VMS732_HYPERSORT V1.0
DEC AXPVMS VMS732_SYS V17.0
DEC AXPVMS VMS732_FIBRE_SCSI V15.0
DEC AXPVMS VMS732_UPDATE V16.0
DEC AXPVMS VMS732_PCSI V5.0
HP VMS TDC V2.3-15
HP VMS TDC V2.2-108
HP VMS T4 V4.0
HP VMS TDC V2.2-108
DEC AXPVMS VMS732_UPDATE V14.0
DEC AXPVMS VMS732_PCSI V3.0
CPQ AXPVMS CDSA V2.0-109
DEC AXPVMS DECNET_OSI V7.3-2
DEC AXPVMS DWMOTIF V1.3-1
DEC AXPVMS OPENVMS V7.3-2
DEC AXPVMS TCPIP V5.4-15
DEC AXPVMS VMS V7.3-2
bfraga
Occasional Advisor

Re: Oracle RDB 7.1-520 and Fortran Program Error

I did the loop in the $HIBER function like it was suggested and it works.
John Gillings
Honored Contributor

Re: Oracle RDB 7.1-520 and Fortran Program Error


>I did the loop in the $HIBER function like
>it was suggested and it works.

So, that means your first $HIBER around the loop ate some other thread's $WAKE. Therefore you need to add a $WAKE after you've seen your event complete, otherwise the other thread will hang waiting for the $WAKE that you consumed.

A crucible of informative mistakes