Andy, no I don't know why that couldn't be sent to me. (I'm still trying to
figure this stuff out, also). One thing though might be that it's
DSanders AT massmutual DOT com (instead of my name, twice??)
I apologize for putting specific CML stuff out here,but I tried to send a
couple of mails to you and when you didn't get them (or reply), I thought
that this might be a good way to contact you. I certainly need your
knowledge of this CML system to help me get familiar with your processes.
Can I ask you your reasons for not setting up a "nextpool" for the archive
pool?? As you probably heard, there is a special need to do "full" backups
of possibly up to 30 servers. The retention period needs to be long
duration and I suggested to Wendy that we use the archive function. I also
had suggested to her that we would probably need to expand the size of the
archive DASD pool so that we can get faster concurrent data transfer. We
updated the threshold for that archive pool and had to use the "tapepool" as
the nextpool. Based on your knowledge of the environment here at CML, what
would your recommendations be to get over this unusual requirement? Thanks
for your help!!!!
On Wed, 28 Feb 1996 05:40:23 PST Andrew M. Raibeck wrote:
>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?
|
