ADSM-L

Re: TSM 3.7.2.0 NT Client Problems - Updated

2000-05-18 10:31:48
Subject: Re: TSM 3.7.2.0 NT Client Problems - Updated
From: Sean Duffy <sduffy AT TORSEL.ALCATEL DOT COM>
Date: Thu, 18 May 2000 10:31:48 -0400
I have just installed 3.7.2.01 client on my PC as a test

will let you know what problems I encounter

Sean Duffy
Alcatel Canada, TA

TSM 3.7.1.0 Server

mailto:sduffy AT torsel.alcatel DOT com

At 09:52 AM 5/17/00 -0400, you wrote:
>Hi folks,
>
>        This is an update on the following issues I raised on Monday,
>May15th.  I have done additional testing and will update each point below.
>
>        I'm seeing a lot problems reported on TSM 3.7.2.0 and I thought I
>would throw this one in the mix.  I have the 3.7.2.0 client installed on my
>workstation (IBM 365 PC running NT 4.0, service pack 6.0A) for testing.  I
>did a scheduled backup using the options file below.  I have also included
>the schedule and activity log extracts, the error log, the "show options",
>and  the "show inclexcl" output to illustrate my points.
>
>        My PC is a single processor system and is a few years old (like me,
>it's getting slower).  This will have some impact on the processing times,
>so I'm not going to get into that one again.  I will post new copies of the
>options and log files but not the "show" results; I'm sure we can figure
>those out by ourselves.  The schedule log will be shortened to show the
>stats and not the boring file by file blow of backup.
>
>1.      This produced the expected extra sessions for the new resource
>option, but the extra sessions didn't terminate until the inactivity timer
>popped on the server.
>
>                I still saw up to 10 sessions active but most were in the
>idle state; they all successfully terminated at the end of the client backup
>- naturally nothing ever works the same twice.  On a second test, I cut the
>sessions back to 4 (number of "hard" drives + 1) with the same results.
>
>2.      The client backed up extensionless files that should have been
>excluded - as best I can see.
>
>3.      The client failed to exclude files that are specifically excluded
>(see netuser.dat entry) - I'm not that blind yet.
>
>                These two items were purely my misuse of the Include/Exclude
>directives.  I had directives ending in "*.*" which (as was properly pointed
>out to me) means any file with a dot in its' name.  Files without extensions
>won't have them (duh!).  Because I had "Included" a higher level directory,
>the file ntuser.dat (maybe I am that blind already - I misspelled it before;
>darn dyslexic computers) was a backup candidate but failed because it was
>busy.
>
>4.      The backup registry options has been removed from the tool bar and
>(apparently) placed under the System Object icon in the Backup/Restore
>windows.
>
>                Thanks to Andy Raibeck (a darn good source in my book), this
>is confirmed as being the case.  Apparently I haven't read enough docs yet
>or I missed the announcement somewhere.
>
>5.      The backup seemed to take longer than normal.  I first deleted all
>my backup files and started as effectively a new client.  The negotiation
>time seemed excessive and some of the client sessions seemed to stay in an
>"idle waiting" state for the duration.
>
>                I think this may be attributed to the age of the client host
>to some extent.  I still noticed most of the client sessions were in idle
>states however.
>
>6.      There seem to be an unusual number of lost/reconnect session errors
>in the log file.
>
>                While there were not as many session lost/reconnect errors
>in my last test, I did experience one test session where the out of sequence
>verb and protocol errors (yes, they are still there) became a problem and I
>had to terminate the backup test.  I still see some errors about getting
>stream info that may be (guessing here folks) NT related issues.
>
>7.      When using the GUI backup window to display file lists, I would see
>the prior file list when requesting a new (large) directory file list.  The
>window would revert to the prior display list after completion of the new
>file list - without displaying the new file list.  When I re-selected the
>new one I wanted to see, it would display correctly.
>
>        I think this one is also my ineptitude.  What I was doing was
>clicking on the folder for a tree branch (WINNT for example) instead of the
>expansion icon (+).  This would cause the client to go off and walk the
>branch for its' structure and generate the list.  When the list was
>completed, since I hadn't selected the expansion icon, the files list pane
>remained the same and the cursor returned to the proper point in the left
>panes' tree display.
>
>        At least I didn't see the same behavior again and this was the only
>explanation I could come up with.
>
>        These are just the "first glance" issues I have noticed on the
>backup.  On the restore side I have noticed:
>
>1.      There are now two version of the registry backed up - one for the
>machine name (under Registry) and another one for the machine name (under
>Registry.sav).
>
>                This is apparently due to a difference in client level
>processing.  If I remember correctly, the version 3 client used the
>sub-directory with the ".sav" extension in the "adsm.sys" directory.
>Apparently, the new version 7 clients dropped the extension and created a
>new directory.
>
>2.      There appeared to be similar problem in the files display flashing
>back to a previous display.
>
>        My fault again, see #7 above.
>
>        In short, I see a major problem with the processing of the
>include/exclude directives and the file list displays.  These issues make me
>wonder, again, about the quality of the TSM vs. IBM products.  I wonder if
>we have made a mistake by jumping on the TSM bandwagon so early and I also
>wonder more and more about the quality testing of the TSM product.  I know
>that the same group that was in ADSM is supposed to be behind the TSM
>product, but I don't see the quality that was there - or I'm looking closer
>than I used to.
>
>        I'll eat crow on most of these issues, but I still think that there
>are some quality issues with the new product.  For now, I'll attribute them
>to the organizational change (even though that should have nothing to do
>with them) and not scream too loudly when minor bugs walk out of the
>woodwork.  I understand from other sources that Tivoli is putting together a
>kind of "quality assurance team" to address our concerns with product
>quality.  Hopefully, that will improve the product and boost our confidence
>back to where it was with ADSM.
>
>        Thanks for taking the time to wade through this and for all the help
>from those who replied (both users and Tivoli).  I have to go find recipes
>for crow now, so I'll see you guys around.
>
>
> <<dsm.opt>>  <<Sched-test-log.txt>>  <<dsmerror.log>>
>New versions of above logs/file.
>
> <<dsm.opt>>  <<DSMSCHED.LOG>>  <<dsmerror.log>>
>
>        Gary L. Ison
>        Governor's Office for Technology
>        101 Cold Harbor Drive
>        Frankfort, Ky.   40601
>        Phone:  (502) 564-8724
>            Fax:  (502) 564-6856
>E-mail: Gary.Ison AT mail.state.ky DOT us <mailto:Gary.Ison AT mail.state.ky 
>DOT us>
>
>Attachment Converted: "C:\Eudora3\attach\dsm1.opt"
>
>Attachment Converted: "C:\Eudora3\attach\Sched-test-log1.txt"
>
>Attachment Converted: "C:\Eudora3\attach\dsmerror2.log"
>
>Attachment Converted: "C:\Eudora3\attach\dsm2.opt"
>
>Attachment Converted: "C:\Eudora3\attach\DSMSCHED1.LOG"
>
>Attachment Converted: "C:\Eudora3\attach\dsmerror3.log"
>
<Prev in Thread] Current Thread [Next in Thread>