Thanks for the explanation. I have always been impressed by the folks that
support this product - knowledgeable and helpfull!!!!!!!!!
                thanks again, tom g.

> Tom, is no way to directly limit the numbr of tries. First, given the
>variety of TCPs and the platforms they operate on, and that TCPs don't
>keep historical data on failed connects, it would be impractical to have
>any sort of limiter at the TCP layer. That leaves us with the ADSM
>Schedule Prompter. The prompters sole job is to try to connect with clients
>for which there is scheduled work to do. The prompter will attempt every 60
>seconds to contact such a client until the window for the schedule elapses.
>Once the window elaoses, the related node is removed from the prompters list
>of nodes to contact. So given this, you could reduce the schedule duration
>as way of limit how long the attempts are made. Long durations are often
>only useful if your clients run in polling mode with randomization. I would
>however recommend a duration of at least 15 minutes. If the ability was
>added to have the prompter remove a node after n nbr of tries, then depending
>on what the client is using for "retry period" and "maxcmdretries" you
>may wind up with clients that don't get backed for long periods of time.
>Unless you are monitoring client success/failures frequently with the
>server  Q Event, this may go un-noticed. In some situations you may have to
>manually restart the DSMC SCHED clients to get them back on track. All in all,
>most customers prefer to know immediately when clients are failing.
> All that being said, one of the major benefits for prompting mode is if you
>frequently change schedule starttimes or durations where you would want the
>clients to be aware of the changes in a timely manner. If your schedules
>are fairly stable, or if you have problematic cients (TCP not loaded, or
>DSMC SCHED not loaded), then you may want consider polling mode. Polling
>mode leaves it up to the client to contact the server for schedule information
>and then run at the appropraite time. This would eliminate the resources usage
>from the prompter trying to contact where contact is failing.
> I hope this isn't too confusing. In summary, try adjusting durations,
>retryperiods, and maxcmdretires, to find a happy medium in terms of resources
>used. And consider polling mode where appropriate.
>
>Tom Brooks
>ADSM Development
>
>