|
HP OpenVMS Systemsask the wizard |
|
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.
>Eventually, with a detached process, the process will use all of the
>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.
|