Dave Sanders asked:

>Reading the discussion on client polling vs. server prompted, prompts ME to
>ask what are the considerations for choosing one over the other.  Andy, why
>had you chosen polling at CM (it's not easy figuring out what someone else
>had designed)?

Actually I didn't choose to use client polling at CM. My scheduling method of
choice is server prompted, and in fact this is how I set up scheduling for the
majority of CML's clients. The reason for this choice is that the server lets
the client know when it is ready to accept the connection, as opposed to the
client initiating the event. Why is this better? Well, under normal circum-
stances, it is probably just as good. However, if the server is disabled for
some reason, or the MAXSCHEDULEDSESSIONS limit has been reached, the client
won't know this, and will try to initiate the event anyway. The randomization
setting can help avoid the MAXSCHEDULEDSESSIONS exceeded problem, as well as
prevent the server from getting flooded at one time with a bunch of session
initiations. The MAXCMDRETRIES and RETRYPERIOD are client options that can be
used to determine how many times the client should retry a scheduled event that
fails, and the interval between retries, respectively. These can come into play
for a variety of reasons (like if the server is down, or a polling client tries
to establish the MAXSCHEDULEDSESSIONS+1 session, as well as other reasons). I
like server prompted mode because it's "cleaner".

There are cases however, where I set up client polling. But it wasn't by
choice. Server prompted works *only* for DOS, Novell, OS/2, and UNIX clients,
and only when they use COMMMETHOD TCPIP.

So at CM, for Windows and non-TCP/IP clients (like some of the OS/2 machines
which use LU 6.2) I had to go with client polling.

I hope this answers your question.

Andy Raibeck
ADSM Level 2

p.s. Dave, I tried mailing this to DSanders AT DSanders.massmutual DOT com and 
it got
     rejected as undeliverable. Any idea why?