Re: tcp read errno 73
2001-07-08 11:11:27
Subject: |
Re: tcp read errno 73 |
From: |
Richard Sims <rbs AT BU DOT EDU> |
Date: |
Sun, 8 Jul 2001 11:12:10 -0400 |
>My archive takes two hours to finish and every day I get errors in my
>dsmerror.log. I would like fix this condition , so only errors are
>reported to dsmerror.log. This is the only schedule that this happens with,
>I believe this is caused by the Timeout of the session that reports the
>statistics as I do not get stats in the act log.
...
>07/06/01 05:30:54 TcpRead(): recv(): errno = 73
...
>This is the only schedule that this happens with, I believe this is caused
>by the Timeout of the session that reports the statistics as I do not get
>stats in the act log.
...
>07/06/01 04:13:02 ANR0482W Session 589 for node HERC5 (AIX)
> terminated - idle for more than 55 minutes.
>07/06/01 05:30:19 ANR0403I Session 590 ended for node HERC5 (AIX).
>07/06/01 05:30:21 ANR0406I Session 630 started for node HERC5 (AIX)
>07/06/01 05:30:22 ANR0484W Session 630 for node HERC5 (AIX)
> terminated - protocol violation detected.
>07/06/01 05:30:23 ANR0406I Session 631 started for node HERC5 (AIX)
>07/06/01 05:30:23 ANR0403I Session 631 ended for node HERC5 (AIX).
>07/06/01 05:30:24 ANR0406I Session 632 started for node HERC5 (AIX)
>07/06/01 05:30:24 ANR0403I Session 632 ended for node HERC5 (AIX).
>
>SCHEDULE LOG
>07/06/01 03:17:36 --- SCHEDULEREC OBJECT BEGIN ARCH_HERC5DB_DAILY 07/06/01
>03:17:00
>07/06/01 05:30:53 --- SCHEDULEREC STATUS BEGIN
>07/06/01 05:30:54 Session established with server SHADOW: AIX-RS/6000
>07/06/01 05:30:54 Server Version 3, Release 7, Level 3.8
>07/06/01 05:30:54 Server date/time: 07/06/01 05:30:21 Last access:
...
>07/06/01 05:30:55 --- SCHEDULEREC STATUS END
>07/06/01 05:30:55 --- SCHEDULEREC OBJECT END ARCH_HERC5DB_DAILY 07/06/01
Bob - The timed-out session does not correspond in time to the error log
entry, so that's not the cause of the TcpRead entries.
The ANR0484W message is of concern, usually relating to a problem with a
Passwordaccess Generate client password not in place.
I understand your misgivings about boosting the server Idletimeout value,
but in your case I would go ahead and boost it to cover the duration of
this long-running db archiver. Consider using the server Throughput* options
as your safeguard.
I would also recommend that you emply a Network Time Protocol facility to
synchronize the time of your systems, as the "Server date/time:" entry in
your schedule log shows the client 33 seconds faster than the server. That
is a nuisance when trying to analyze logs, but more importantly can cause
some forms of authentication to fail if the discrepancy is too large.
Richard Sims, BU
|
|
|