>When a prompted mode B/A client contacts the server the IP address is
>"registered" and stored on the server. When it is time to prompt (ping)
>that client, the IP address is used. If the IP address changes for that
>client, then the client must be stopped and re-started in order for the new
>IP address to be "registered" with server. This is the only way the server
>can know about new IP address. Polling mode clients are not registered with
>the server. Also, if a "prompted" mode client is changed to "polling" mode,
>the IP address is removed from the server registration table.
>
>Failed schedule causes: 1) The fact that one or more files get skipped
>or for some reason get marked as failed, when other files have succesfully
>been backed up does NOT cause the schedule to be marked as failed. Any many
>cases where a client backup thousands of files ther may be files for which
the
>backup failed. It would not make since to fail the schedule since in fact
>the schedule was executed and the client completed its backup. This is why
>there are sched and error logs for the client. These errors are different
>than a schedule error. 2) At the end of the start duration for a given
>schedule, the schedule manager looks for nodes associated with the schedule
>which never "started" (probably caused by the client scheduler not being
>active at the known IP address). These get marked as "missed". At the same
>time this "check" is performed the schedule manager also checks for nodes
>which are in a "started" or "re-started" state. For these nodes, there is
>check done to determine if there is an active session for the node/schedule
>combination. If there is no session (most likely caused by some sort of
>timeout) then the schedule is marked as "failed" in the server schedule
>event table. Here is the "catch": Although the client may-reconnect after
this
>time and complete the activity, the event table will NOT be updated to note
>this. This case is what most administrators might be seeing. There has to
be
>some sort of garbage cleanup for clients that never do re-connect.
>If you see a lot of this, you should consider updating your IdleWait and
>commtimeout periods to longer values. Also consider a longer duration for
>the schedule.
> While the duration is used for a start period and not the time the
scheuled
>activity must comlpete in, the end of the duration is used as a sanity
>check for prompted sessions that have "disappeared".
>
>Tom Brooks
>ADSM Server Devlopment