HP OpenVMS Systems

Ask the Wizard Questions

Language: Program blows up

The Question is:

Now the real question...

Lost QIOs!

I have a program that starts lots of detached processes.
It uses a mailbox to receive the termination messages
from these processes. The mailbox is read using a QIO with
an AST routine specified.

The program runs for weeks and weeks without a problem then
the QIO on the mailbox disappears! No errors are returned
at any stage.

Here is the code frmo the AST routine:

PRIVATE UINT ReadAst(ULONG Param)
{
	int status;
	int i;

	if (!(Iosb.Status & 1))	  	/* look at IoSb read status */
	{
		logLine("AST read error %d",Iosb.Status);
		exit(Iosb.Status);
	}

	/* Process the message here */

	i = findPID( termMessage.acc$l_pid );
	if( i == -1 )
	{
		logLine( "termination message received for already dead process" );
	}
	else
	{
		logLine( "ICON %s terminated with status %08x",
			inet_ntoa(processTable[i].tcpaddr.sin_addr),
			termMessage.acc$l_finalsts );

		/* Clear the entry from the process table */
		processTable[i].username[0] =
		processTable[i].pid =
		processTable[i].group =
		processTable[i].queue = 0;
		processTable[i].tcpaddr.sin_addr.s_addr = -1;
		processType[i] = -1;
	}

	status = sys$qio(0,MbxChan,IO$_READVBLK,&Iosb,ReadAst,0,&termMessage,sizeof(struct accdef),0,0,0,0);
	if( !(status&1))
	{
		logLine( "Failed to reissuse read on mailbox" );
		exit(status);
	}


	return(0);
}

Any clues?

The Answer is:

   Use an event flag allocated via lib$get_ef, moving away from EF 0.

   Please indicate the error status code returned -- if one is returned.
   It also appears rather unusual the termination mailbox AST is reposted
   within the routine -- are you sharing one termination mailbox for
   multiple processes?  (I would not use this particular design...)

   If I were are interested in knowing when a process exited, I would
   tend to use a solution based on the lock manager in preference to
   the termination mailbox.  This has the advantage of working across
   a VMScluster system -- this a big advantage when working with the
   cluster-wide sys$creprc support present in OpenVMS V7.0.  (While the
   process termination mailbox _is_ written across VMScluster nodes, the
   lock scheme allows any interested process anywhere in the VMScluster
   system to detect the failure via grant ASTs.)