>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