Oracle RDB 7.1-520 and Fortran Program Error

[bfraga]

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.

[abrsvc]

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]

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]

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]

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]

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.

[GuentherF]

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]

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]

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]

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