I am in TOTAL agreement with you. This particular topic should be a
SHARE/GUIDE/COMMON
project with the ADSM group heavily involved. It seems to be another case
where IBM
lives in a bubble and doesn't realize what real folk do during the day.
Like asking us
to re-ipl the machine to see if it will fix the problem.
At 03:27 PM 10/1/96 -0500, you wrote:
>Date: October 1, 1996 Time: 13:53
>From: Jerry Lawson
> ITT Hartford Insurance Group
> (860) 547-2960 jlawson AT itthartford DOT com
>-----------------------------------------------------------------------------
>This is intended as a constructive response to the posting from Mike Collins
>about Client Installation issues. Mike posted a very informative note the
>other day, and I have taken my time in responding in hopes that I would get my
>response on the same high level that he used in his post. This may wind up
>being long - for that I apologize in advance......And Pete Tanenhaus - if Mike
>is still having difficulty with the list, can you please forward this to him?
>
>
>I have documented my concerns about installation several times, but I am
>beginning to wonder if the amount of work that we have to go through to
>distribute ADSM to our customers is really clearly understood. I know here at
>The Hartford, we have approximately 500 installed users, and that number is
>growing again, after being stable for a while. I am not a PC trained person -
>my background is mainframe systems programming first, with a touch of storage
>management on the side. When it comes to being able to handle all of the plat
>forms ADSM supports, all I can say is that I am better on some (such as OS/2)
>than others (such as Windows 95), and some (Unix) I have no experience on at
>all. Still it falls on me as the project leader and house ADSM bigot to
>understand new features and products, and get them out to LAN administrators
>and PC support staff in a timely manner.
>
>One of the major pluses when we selected ADSM as our backup tool was the
>consistent approach that was applied to the initial design. This starts with
>the consistent look and feel of the clients as they are applied to each
>platform. At the same time, they are appropriately implemented for that
>platform. For example - the MAC client looks and runs like a MAC application,
>not a Windows app, but at the same time - all of the functions are implemented
>in a consistent manner, so that I don't have to learn a bunch of special MAC
>stuff to use the MAC ADSM client. The same can be said for OS/2 and Windows
>3.1. Even the NetWare client, if you look at it from a comparison to the
>other command line clients, is consistent in this manner. While my only
>exposure to Unix has been by watching someone else install the Sun client -
>the GUI seemed very consistent.
>
>The same used to be true with the installation process. All Intel (and MAC)
>clients installed in a directory called ADSM. The options file was right
>there, in the same directory. There were no problems in doing this that I
>ever ran into, outside of a minor problem with a backup copy that I think was
>resolved at V1 level 7. But then along came the Win95 client, and first it
>created a directory called ADSM32. (I am speaking about Level 3 of the 32 bit
>client - we really didn't use the NT client from level 1 and 2). This caused
>some problems for us because first of all, it was different for no apparent
>reason, and installation procedures had to be changed. Many of my customers
>used the Win3.1 client on their Win95 systems, even though it didn't support
>long file names, because they had been using the client on Win31, and didn't
>want to stop backing up their machines until the Win95 client became
>available. Also we didn't use long file names, and so applications, and perso
>nal files were probably OK. So many of my Win95 installations went over
>Win31, and we had to futz with the directories. I could at least rationalize
>this to myself in saying that what we did was not supported, even though it
>was widely known to work.......
>
>Now we get to a level change within the supported code, and also the eagerly
>awaited Win95 Admin GUI client. And what do I find? Another change in the
>installation process, and a completely different set of libraries, and nothing
>to support the cleanup process. And while I have read the response several
>times, I still do not have a good reason as to why. Here is why I say that.
>
>(I have not included Mikes responses, and our original questions, because this
>is already too long - please refer to the original note.)
>
>CLEANING UP AFTER YOURSELF.
>
>I am sorry - but there is no excuse here. IBM - you wrote the code. You know
>what the module names are. If the Microsoft programs that you are using do
>not support deleting a known set of modules from a directory that you
>suggested, then you should write a program that deletes these and cleans up
>any associated folder/programs and call it a post clean up job. It is not
>necessary to search the whole hard drive - if the default names of the
>libraries were not used, or there is not an easy way to determine that the
>customer has changed the names, then that is my problem - not yours. But if I
>have followed all of your naming conventions, you should be able your own
>conventions, and find DSM.EXE and delete it. You guys are the experts here, n
>ot me. And I have wasted an awful lot of time debugging problems that were
>traced back to having more than one copy of the same program present - it
>would probably save your support staff enough time to justify the costs.
>
>TWO OPTIONS FILES
>
>I have never wanted more than one options files. We have more than one
>server, if you count the test server, and the one I use for demos. I keep
>this separate via putting scripts together to launch the appropriate applicati
>ons and options combinations. The other 25 or so people that we have
>installed as local administrators with policy level authority never have to go
>after these servers. They do not want or need two options files - it is more
>confusing - for example - if the server name changes, I have to remember to
>change it in two places now. Just yesterday, I had to debug a problem with a
>brand new customer install with the level 5 Win95 client (the only kind I will
>do) where the LAN administrator had copied a standard DSM.OPT file to the ADS
>M directory instead of the BACLIENT directory. I think that the majority of
>people would like one options file - not two. How about leaving it in the
>ADSM directory?
>
>This also brings me to the issue of two directories. I still don't understand
>"Why". I have the OS/2 server and client (both admin and backup) installed on
>the same machine. The server is separate from the client - no problem. But
>the Admin is in the same directory as the backup client. I have no problems
>here. It works fine. There is no confusion about which modules do which. I
>still don't see why this couldn't have been done with the Win95 client. It
>would have made the whole issue of two options files go away, and the
>Microsoft install wizard should still be able to deinstall the files. Maybe I
>am being overly dense - if so tell me - I can take it - but this just seems to
>have missed the point.
>
>CUSTOMIZING THE INSTALL PROCESS
>
>I have not tried to customize the installation process yet, and so am not
>qualified to comment on this process. However - remember the old addage
>"Everything in life is like ripples in a pond - everything you do touches me -
>everything I do touches you." The last thing that someone who has set up a
>customized install process wants to hear is that the process just changed.
>That kind of activity just makes them NOT install the new maintenance until
>they can find the time to rewrite and retest the installation.
>
>AUTO DOWNLOADING of NEW CLIENTS
>
>From the conservative systems programmer in me, my first impulse is to say -
>No way - what if something is bad and the new release won't work...... But
>let's get over my conservative midwest nature and look at this in more detail.
> When you do - I think that this becomes a VERY GOOD idea. And when you start
>thinking of the consistency in approach issues that I raised before - then it
>looks even better. You folks now support what appears to be over 20 different
>client platforms. You're probably saying - that's too many to do a "download
> from the server" approach - two many variables. But if you don't do something
>like that - who will? I worked on a Software distribution project for over a
>year about 3 years ago - and at that time I would say that the market will
>never support that kind of versatility. And even with NetView DM - I wouldn't
>expect to see it today. A general product to install anything on everything
>from plain old DOS and Macintosh and NetWare to all of the Unix flavors, and
>now DEC platforms is quite a product. You have a luxury of knowing what you
>need to install, and where it should go. Again, if we decide that we need to
>change the defaults, then I think we have to take responsibility for our
>actions. I for one am willing to forego that level of individuality in order
>to get new client code distributed to all of my customers in a timely manner.
>If I can ever cut through the corporate red tape - that could be well over
>10,000 clients.
>
>This is already too long. The unfortunate part of it is that you've already
>done it. Fixing it now for the next release will cause problems with all of
>the new releases and upgrades we have done - UNLESS you are willing to commit
>to making the changes we requested and getting them into the level 6 fix so
>that we can wait for it with some certainty. For the most part, the real
>serious problems were addressed with the level 4 fixes for the API. This
>release only fixed scheduler problems for me (and not all of those) so I can
>postpone it - outside of the people clamoring for the GUI Admin. But then
>again they've waited this long.......
>
>I really am serious here - this release deserves the William Tell Near Miss
>award. It is a product that we all use daily. We all believe highly in the
>product. If you had missed the mark by a mile, we wouldn't have used the
>product at all, and no one would care. But you were close. but you missed
>the arrow. And prize that went along with this award (beside the arrow
>through the forehead) is a broken anvil. And do you know how hard it is to
>break an Anvil. I really wish you would have consulted with the people on
>the list before you had made these changes. I am always more than happy to
>provide my input (as you can tell from this note).
>
>
>If anyone else got this far - do you agree? Disagree? Should I keep quiet?
>
>*****************************************************************************
>Jerry Lawson
>ITT Hartford Insurance Group
>jlawson AT itthartford DOT com
>
>PS. Mike - if you designed the Win32 Admin client - great job - I am pleased,
>and it seems to perform well too.
>
|
