We are also experiencing your problem #1.  We began seeing it immediately
after moving from version 4.1 to version 5.1.1.4.  In our case, it happens
inconsistently as well, and across multiple platforms--I've seen it on our
Novell, Windows, and Solaris clients for sure.  We have a PMR open that has
been escalated beyond level 2; the response I got from the developers via
level 2 was that "if the client cannot report to the server that the backup
has failed, the server won't presume it." (paraphrased)  It has been
recommeded to me that I use the dsmsched.logs or the activity log rather
than relying on the q ev output to verify backups.

What server version did you upgrade from, and what client versions are you
seeing this on?  I'd be interested in comparing notes.

Thanks,

Kathleen





                    "Gill, Geoffrey
                    L."                    To:     ADSM-L AT VM.MARIST DOT EDU
                    <GEOFFREY.L.GILL       cc:
                    @SAIC.COM>             Subject:     Version 5.1.5.1
                    Sent by: "ADSM:
                    Dist Stor
                    Manager"
                    <[email protected]
                    T.EDU>


                    10/30/2002 10:45
                    AM
                    Please respond
                    to "ADSM: Dist
                    Stor Manager"






Although I could write forever on the problems I'm having with backups on
this version I don't have the time or the patience. An update though on
some
things I'd like to pass along. Let me start by saying all I did was upgrade
and all hell broke loose.

1.      q ev on backups, the morning after, shows a status if "In Progress"
for many nodes. It's inconsistent as to which nodes it hits. That call is
at
level 2.
2.      Level 3.1 clients reporting FAILED. Well, not just reporting, they
are starting then stopping with ANR0530W. Sure they're of support so I've
told them to upgrade.
3.      Schedule reporting MISSED on many servers yet it looks like a
portion of those have actually completed. There is information in the log
with the typical session end statistics. Both 2 and 3 are on a separate
call
to TSM.
4.      One thing I have noticed is that many sessions are on idle wait for
over an hour and are terminated. I see at least 50 of them last night.
ANR0482W Session 5375 for node CP-MIS-FIN01 (WinNT)terminated - idle for
more than 60 minutes.

I don't know about anyone else but I'm on a gig and have maxsessions set to
60 and maxschedsessions set to 48. I didn't have any problems with this
setting while on any previous version of TSM.

So far the only suggestion anyone from TSM has made to me is to change this
setting. Resource Timeout 60, it was set to 20. Before I did that I had 30
or more backups that were missed each night since the upgrade. Now, well
what is missed and reported failed is very strange to say the least.

If ANYONE had any suggestions or ideas please let me know. In the mean
time,
my suggestion is not to upgrade to this version.

Geoff Gill
TSM Administrator
NT Systems Support Engineer
SAIC
E-Mail:    <mailto:gillg AT saic DOT com> gillg AT saic DOT com
Phone:  (858) 826-4062
Pager:   (877) 905-7154