topic Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER in Operating System - OpenVMS

VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Veli Körkkö — Wed, 20 Jul 2005 08:35:40 GMT

I have just upgraded one cluster to new software levels

VMS V6.2 V7.3
UCX/TCPIP V4.2 V5.3 with eco 4
Motif V1.2-4 V1.2-6
RDB V5.1 V7.0-81

etc

Now one customer app using RDB fails. Specifically it returns from SYS$HIBER when it
should not and now process is looping.

Our test system was built to almost same software levels except that we used then latest RDB, i.e. V7.0-73. And this same
app worked fine.

If customer takes RDB stuff away from app, the SYS$HIBER stuff works just fine.

Is anyway aware of some "feature" with RDB influencing SYS$HIBER usage?

_veli

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Antoniov. — Wed, 20 Jul 2005 09:06:34 GMT

Veli
try to find some clue in vms wizard
http://h71000.www7.hp.com/wizard/index.html

Antonio Vigliotti

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Ian Miller. — Wed, 20 Jul 2005 09:44:13 GMT

I have heard of problems with RDB and HIBER on AlphaVMS where the process did not wake up when it should (wake was lost) but not where the process was woken when it should not.

Programs that use HIBER should be designed to cope with spurious wake ups.

It does appear that RDB does use HIBER. In what mode is the process waiting (user, super, exec, kernel )?

There is a wake pending flag in the PCB for a process which will cause it to return from a SYS$HIBER straight away. The flag is set if a wake is done before the hiber.

Are there any scheduled wakeups for this process?

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Uwe Zessin — Wed, 20 Jul 2005 09:46:52 GMT

That sounds like the "gratituous(sp?) wakeup problem".

It means that an application must be able to deal with extra $WAKEs it did not expect.

I think it is written somewhere in the doc set, but I haven't done real VMS programming for quite some time, so I don't remember where it could be, sorry.

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Antoniov. — Wed, 20 Jul 2005 10:18:23 GMT

In vms wizard I read about some trouble with HIBER and threads.

Antonio Vigliotti

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Robert Gezelter — Wed, 20 Jul 2005 10:54:39 GMT

Veli,

More detailed troubleshooting is in order.

When using $HIBER, spurious $WAKEs are definitely a possibility.

The details of the incidents need to be reviewed in depth, including a review of the application's sources.

- Bob Gezelter, http://www.rlgsc.com
(an extensive user of HIBER/WAKE and related services)

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

John Gillings — Wed, 20 Jul 2005 14:54:53 GMT

_veli,

$WAKEs can come from anywhere. If your application cares about being woken up from the "right" place, you need to code some mechanism to confirm the wakeup.

Properly written code should be able to handle any number of $WAKEs without any problems. For example, RUN/INTERVAL=delta-time will cause a $WAKE at delta-time intervals. At worst, this should cause your process to consume a bit more CPU time.

This is a general principle in any code that deals with events signalled by $WAKE, $SETEF or any other "broadcast" mechanism. You need something that positively identifies that the specific event you're waiting for has occurred. All asynchronous system services use an IOSB for this purpose.

For example:

Declare a flag variable:

global woken

Sleep code:

woken=false
...
code to "prime" the event
...
while not woken do
$hiber()
end while
$wake(,)

Wakeup code

woken=true
$wake(,)

This assumes the $WAKEs will come from the process itself. If they're from an external process, the flag is a bit harder to implement. Sometimes the confirmation can be implicit, for example, the presence of a packet on a work queue. Also note that there is an extra $WAKE after the sleep loop. That's because you may have consumed someone else's $WAKE while iterating the loop. The extra $WAKE also assumes that OTHER people's code can also deal with spurious $WAKEs.

Also remember that if there is a pending $WAKE, $HIBER will return immediately. Only one pending $WAKE is "remembered". If it's important that your code really sleeps, you can code it like this:

$WAKE(,) ! Force pending $WAKE
$HIBER() ! Consume pending $WAKE
$HIBER() ! Sleep
$WAKE(,)

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Chris Barratt — Thu, 21 Jul 2005 05:21:51 GMT

This problem is well documented in the Rdb release notes (with suggested workarounds) and has been for a while.
I believe that in some some recent versions it became more prevalent...I remember seeing some people on the Rdb list server encountering it after upgrade to a more recent version.
I think the others have pretty much covered what is written their, though...basically it's a problem when the HIBER calls have not been used correctly.
Cheers,
Chris

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Veli Körkkö — Thu, 21 Jul 2005 11:15:49 GMT

The help was very valuable. Customer recoded their application to use essentially

$WAKE
$HIBER
$HIBER
$WAFE

and today another VMS system was upgraded to VMS V7.3 also.

_veli

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Ian Miller. — Fri, 22 Jul 2005 02:36:25 GMT

Veli, it would be better if they checked for something to do when they return from HIBER and do nothing if it was spurious. The other technique often used is a scheduled wakeup to catch the case when a wake is lost and there is something to do.

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Robert Gezelter — Fri, 22 Jul 2005 13:30:23 GMT

Veli,

The use of two $HIBERs in a row will, at some unpredictable point in the future, lead to an applications hang.

The program needs to internally set a flag, do the $WAKE, and check the flag when it falls out of the $HIBER to ensure correct operation.

Any other solution will lead to odd behavior, which will be very difficult to diagnose.

- Bob Gezelter, http://www.rlgsc.com

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Veli Körkkö — Sat, 23 Jul 2005 02:34:31 GMT

well, the

$wake
$hiber
$hiber
$wake

is just simplified and there is more stuff around actually

the actual wake in this case came from external
source, i.e. from another process, so the original code was (using same simplified)

$hiber

The original code appeared to work fine
with DEC RDB V5.1 (VMS V6.2) and on test
upgrade using RDB V7.0-73 (VMS V7.3)

Actual production upgrade was to RDB V7.0-81 (most otherwise same stuff). One could say that this was bad practise and would be most correct to say so.

With latest RDB the problem was that
the called $hiber returned immediately
causing program looping. There was apparently
a pending wake always. And apparently this was caused by RDB (V7.0-81) and there is even some text in RDB release notes about issues with programs using $HIBER/$WAKE

So, why in this particular case program should work just fine is because in sequence

LOOP:
$wake
$hiber
$hiber
$wake
ACTUAL WORK HERE
goto LOOP

the first $wake/$hiber should be effectively
just some overhead but clearing away the pending $wake so the subsequent $hiber
really now hibernates and only returns once the external program running in another process context targets this process with a $wake.

Now tha last $wake is there to put back the pending $wake so that overall situation
is maintained, i.e. there is the pending wake

Change of RDB version was based on recommendation from Oracle support to customer and mostly customer decision though I did not resist that much after all so part of the blame is of course mine.

_veli

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Robert Gezelter — Sat, 23 Jul 2005 22:32:08 GMT

Veli,

The presence of the pending $WAKE cannot be relied upon, that is precisely my point.

- Bob Gezelter, http://www.rlgsc.com

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Veli Körkkö — Sun, 24 Jul 2005 02:35:13 GMT

The code in question is most likely traditional sequential flow, single threaded stuff.

In that kind of situation, I would expect
that after

$wake

we do have a pending wake which the subsequent

$hiber

would "consume". Therefore no more pending wakes (from within the program itself) unless the
external program running in other process context just issued. Anyway I assume that the other program will wake up this program periodically or as otherwise deemed necessary.

_veli

Re: VAX/VMS V7.3, RDB V7.0-81 and app using SYS$HIBER

Robert Gezelter — Mon, 25 Jul 2005 06:49:58 GMT

Veli,

The double HIBER represents a "latent bug", a workaround which will fail at some point in the future when the behavior of another piece of code is corrected.

The correct (safe) code works in either case:

/* Create a work queue, with the listhead ADDED to only from the AST level, which is the code that does the WAKE */

at process level, the correct code is:

/* We are here when we are idle at the process-state */
while (YES){
if QUEUE NOT EMPTY {
/* perform processing */
....
}
else { $HIBER }

Please note that the above recycles correctly in the event that a spurious WAKE occurs, it merely re-HIBERs. If there is work in the queue, it is processed. Thus, changes in the outside world do not impact the code (see some of my related DECUS/ENCOMPASS/HPWorld presentations at:
"Threads and Events", HP Enterprise Technology Symposium 2002, http://www.rlgsc.com/hpets/2002/1228.html
"Introduction to AST Programming" Compaq Enterprise Technology Sumposium 2000, http://www.rlgsc.com/cets/2000/435.html, and
others via my presentations page at http://www.rlgsc.com/presentations.html.

- Bob Gezelter, http://www.rlgsc.com