WCB (Window Control Block) structure documented anywhere?

[Mark Corcoran]

John, thanks for your reply.


>If you're stuck in HIB state, I'd be guessing at a timing issue with $HIBER/$WAKE revealed by moving from VAX to Alpha.
>Do you have any idea where the code was asleep?

I looked at the PC in SDA with EXA/INST, and it was reported as being in PROCESS_MANAGEMENT.

I've got a feeling that it's not really "stuck" in HIB, it's just that it really is hibernating, because it's doing nothing.

i.e. the application code simply omits to do a $DEQ in some circumstances, so basically, it got some input, processed it, encountered an error, got the exclusive lock, wrote details of the error to the error log file, didn't release the lock, and is now waiting for more input to process.


>Something to check... Are there any LIB$WAITs? Remember that by default LIB$WAIT is expecting F_FLOAT, but the new default floating type for FORTRAN is /FLOAT=IEEE. Passing an IEEE float as the argument for LIB$WAIT won't wait the correct period.

Useful information...

As indicated elsewhere, the development has long since been outsourced, but we do have access to the sources - the problem is trying to work out which module(s) in which CMS library/ies is/are used to build the .EXE, so I can't readily tell if they are using LIB$WAITs.

Last time I touched Fortran was at least 10yrs ago, and that was looking at someone else's code, and understanding the basics to see where something needed to be changed (i.e. I'm not a Fortran programmer by any means; C is my (main) bag)

Mark

[John Gillings]

Mark,

>the PC in SDA with EXA/INST, and it was
>reported as being in PROCESS_MANAGEMENT.

I would hope so. By definition, a process in HIB state must be in $HIBER which is inside module PROCESS_MANAGEMENT. QED!

It's not where it is NOW that matters, it's where it came FROM that you need to know. From SDA use SHOW CALL, then SHOW CALL/NEXT, examining the return addresses to trace back up the call stack. SHOW IMAGE will give you the base addresses of any shareable images. You should be able to determine the routines, match the address to an image by comparing the ranges, subtract the base address to get the image offset and find the routine in the link map.

(you do have a link maps, yes? Always use LINK/MAP/FULL/CROSS. Back when disk space was costed in dollars per KB there was a reasonable excuse not to generate link maps but today it's cents per GB, so there's no excuse not to).

Even better, use LINK/DSF and SET PROCESS/DUMP=NOW. When you ANALYZE/PROCESS tell it where the DSF file is and use SHOW CALL to give you the module, routine and line numbers.

>I can't readily tell if they are
>using LIB$WAITs.

That's what link maps are for! With /MAP/CROSS it will show all references to LIB$WAIT.

[Robert Gezelter]

Mark,

Processes stuck in HIB are often sitting in HIB waiting for an event (pardon the anthropomorphism).

Your last posting indicated that the code may have taken an error path. The question is: Which error path?

Infinite HIBernation is often caused because the program "thinks" it scheduled an event, but because of an error, did not actually issue the request successfully. This is the equivalent of a device driver waiting for an interrupt for an operation that it never actually issued.

If this is the case, one is looking for a code path that thinks it issued an IO, timer, or other request, but did not in fact do so.

Debugging traces of processing are invaluable. A dump might be useful, but if the information was in a stack frame, which has since been overwritten, it is gone (readers can guess why I mention that particular possibility -- hint: c local variables are on the stack).

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