Nicholas -

Your posting doesn't say what was seen in the TSM server Activity Log
for the client problem period: I would expect that this was reviewed,
but would help to know what was in there.  (The message most commonly
relates to the server having consciously dropped the session, as
during task priority preemption.)

If all of your problem schedules are Polling type, try at least one
Prompted type, or vice versa, where practical, to see if that cures
the symptoms, which will help point out the issue.

If there is no evidence that the server terminated the session, then
review the client dsmerror.log for any clues.  If still nothing, then
something in between caused communication loss, which is to say the
networking elements.  I would perform some intense DNS tests ('host'
command, 'dig' command, or the like) to verify that your local DNS
servers are not failing you.  If you suspect any DNS issues which you
cannot debug, consider using IP addresses rather than netnames in
your options files, to assure being able to contact the server.
Beyond that, there can be intrinsic communications issues.  One
really insidious cause of TCP session problems can be where someone
has misconfigured a computer on that server subnet to have the same
IP address as your TSM server.  Your networking people could help
track that down, or just look for a known change in your environment
when the problem started happening.

You may have to perform active debugging: Set up a moderately looping
ping command monitor from client to server, which will alert if there
are no responses or inconsistent responding IP addresses found.  That
will test basic connectivity between client and server network
addresses.  If that looks good, but problems persist, then you want
to go further to assure the ability to contact the server port within
that computer, so I would set up a moderately looping, timed 'dsmc
query session' monitor from client to server, and alert if inability
to contact or very long waits to contact.

If going through a firewall or service rate arbitrator, then that can
be its own can of worms.

   Richard Sims