There are a few issues with Mac TSM v3.7 (and v4.1.1).  Two are most
notable:
1) The packaged scheduler deamon does not work. But there is a fix for it
that seems to work fine, as far as calling the scheduler.  However, there
is one minor bug that is livable.  When the Mac is shutdown (or
rebooted), a dialog box appears saying that the scheduler deamon has
unexpectedly quit.
2) The scheduler asks for a login every time, even if
you have
passwordaccess option set to generate.  This is a problem, because the
user has to be there everytime there is a scheduler pop.  It doesn't seem
to time out and I have not found a way around it.  So, if user is not
there for scheduler pop that is in backup window, the scheduler will not
run, and there will be no scheduled backups.

I have opened pmr's for each of these problems.  Not sure of the numbers.
(I'm not at my office right now.)  Richard, I suspect that this may be your
problem.  If
so, or anyone else out there is having these problems, please let Tivoli
know.  The more people who report the problem, the better the odds
are that it will get fixed, and hopefully sooner, rather than later.

-k


On Fri, 6 Oct
2000, Richard Sims wrote:

> >We are using the ADSM Server Version 3, Release 1, Level 2.40, and we
> >recently upgraded several Macs to OS9. This n ecessitated using at least TSM
> >client version 3.7. All upgraded clients are now failing to backup. The
> >client itself appears to function correctly, and performs manual
> >backups/restores, but fails to execute scheduled backups. All clients are
> >using the scheduler daemon. Is this a documented shortcoming, or do we need
> >additional configuration?  Any ideas would be appreciated!
>
> Mike - Curious about your posting, I just installed the 3.7.2 Mac client.
>        Doing a Get Info on the Backup program and the Scheduler I notice
> that the Scheduler defaults to a memory size some 2 MB smaller than the
> Backup program.  And both are awfully modest for today's Macs.
> I notice that most Mac folks who write in with problems don't mention having
> boosted their memory allocations, so probably haven't.  Give them much more
> realistic values and see if that helps.  Also, define an error log and
> check there if further problems.
>
>    Richard Sims, BU
>

Reply via email to