  Debugging TCP/IP Client? 
 The Question is:
 
Sorry if this isn't an appropriate question.
 
Below is a piece of macro code inside my tcp_client.mar source.  I am
running the Compaq TCPIP version 5.0a
 
When I run this (I have watched in debug), if the process on the other end
of the socket stops responding, my qio never times out.  Eventually, with a
detached process, the process will use all of the resources and the system
hangs.  Just for reference, t
his is not a problem caused by this version of VMS or TCPIP, since we have
had the problem for a few years now with older versions of VMS and
Wollengong Pathways as our TCP product.  We just finally have time to look
at it.
Obviously, if it's taken this long to get to, it's not a mission critical
item.  We just have very careful procedures for starting and stopping these
processes.
 
I wanted to change the qiow_s to just a qio_s, and add a setimr and wflor
call.  However, I'm having problems getting these to work, and my manuals
don't have an example of these calls so that I can be sure I have good
parameter values and placement.
 
The easy answer would be to give me a link to the on line macro manual that
would have these.  However, if you wanted to suggest a better way of solving
my 'hang' problem that would work too.  My business constraint is that the
tcpip routines have to be i
n macro, and the applications staff is not going to change the calls, so I
can't add any parameters going in and out of the macro routines.
 
Here's the code piece, and thanks in advance for your time.
 
         Maggie Waters
         System Admin.
         Express Scripts   St. Louis  MO
         Silver Support routing code 1755
         ST. LOUIS GS140 ALPHA
	 Software Access # 1151057
 
 
READ_NET:
        $QIOW_S FUNC=#IO$_READVBLK,-    ;
                CHAN=CHAN,-             ;
                IOSB=IOSB,-             ;
                P1=(R9), -              ;    R9 points to input buffer
                P2=R10                  ;    R10 is length of buffer
        BLBS    R0,10$                  ; do we have a calling error
        BRW     99$
10$:    MOVZWL  IOSB,R0                 ; do we have an IO problem
        BLBS    R0,20$
        BRW     99$
20$:
        MOVZWL  IOSB_CHAR_CNT,(R6)      ; pass buffer length to caller
99$:    RET                             ; RETURN to caller
 
 
 The Answer is:
    Since TCP/IP is a "connectionless" protocol, if an I/O operation is
    already pending at the time the intended recipient starts ignoring
    requests, the sender will have no way of detecting the condition and
    the I/O will remain pending indefinitely.
 
&gt;Eventually, with a detached process, the process will use all of the
&gt;resources and the system hangs.
 
    The first suggestion would be to impose appropriate quota limits on the
    process to prevent it from consuming resources to the point of a system
    hang. Usually it's better to have the process terminate with an EXQUOTA
    of some type than lose the whole system!
 
    Second suggestion - to implement a timeout on a $QIO for a device which
    doesn't implement the IO$V_TIMED function modifier, use "crossed ASTs".
    Something like:
 
 
    	$SETIMR(daytim=timeout,reqidt=uniqueID,astadr=CancelIO,astprm=ipchan)
    	$QIOW(chan=ipchan,...astadr=CancelTimer,astprm=uniqueID)
 
    Where the AST routines are
 
        routine CancelIO(p1)
    	   $CANCEL(chan=p1)
        end
 
    	routine CancelTimer(p1)
    	   $CANTIM(reqidt=p1)
    	end
 
    Notice that we're still using a $QIOW, so there's no need to mess with
    $WFLOR. If the timer expires first, routine CancelIO will kill the I/O
    operation and the $QIOW will terminate with a status of SS$_CANCEL or
    SS$_ABORT depending on the exact state of the I/O at the time. If the
    I/O completes first, the CanclTimer AST will fire, cancelling the
    timer. Since we're using ASTs, they are automatically synchronized.
 
