I'd like to echo Dave Hendrix's comments on the ever-changing solaris
installation. I just got to this myself, and it is indeed very
frustrating. I don't see any good reason for having moved dsm.sys and
dsm.opt from /usr/sbin to /usr/bin. I suppose next you'll want to move
them into /etc or something. Please be aware that when things like this
change, they can impact sites which are attempting to build a reasonably
automated installation process. If you make a change, IBM, think it
through - thoroughly. If there's a ___ good reason for the change, and
you're pretty certain that you won't change your mind again, then make the
change. Otherwise, leave it the way it is. Thanks. ..Paul
At 08:35 AM 12/16/98 -0700, you wrote:
>Christian,
>
>Correct, there was not a solaris "subdirectory". solaris was a link to
>the sol25 or sol26 subdirectories (depending on the OS level you installed
>to). You removed the sol25/sol26 directories. We have HA clusters
running
>the ADSM software and must set the DSM_XXXX environement variables. V3
>REQUIRED you set DSM_DIR to /opt/IBMadsm-c/sol25 or ../sol26. Since you
>put ../solaris there as a link to whichever, we used that for DSM_DIR.
>
>All of the support wrapper scripts which we have written (starting the
>scheduler daemons, restarting backups, restoring files, automated
>installation) had to set these environment variables. For HP and AIX, it
>was very simple and very CONSISTENT. If you look at the chronology of the
>solaris client from V1 to V3, you'll see just how INCONSISTENT IBM has
>been.
>
>I would take it farther than changing things in PTFs. Changing things
from
>version to version is not a good idea either. All that it really entailed
>for me was changing the environment variable file which sets these things.
>And yet, now I have to maintain 3 different sets of these: 1 for an old
>cluster that needs to stay at v2 for external reasons, 1 for pre 3.1.0.6
>versions and 1 for 3.1.0.6. Now if I have people who need to install this
>software and they are building client configurations from a template
>directory, they can shoot themselves in the foot trying to install if they
>choose the wrong "version". (I wont even go into changing the location of
>dsm.opt and dsm.sys from /usr/sbin to /usr/bin). NOTHING like this
happens
>on the other platforms.
>
>This is not a show stopper issue, but I have been using solaris clients
>since V1. I overlooked this from v1->v2, then v2->v3. Now, I guess since
>no one complained about the inconsistency, you've started changing WITHIN
>versions: 3.1.0.5->3.1.0.6. Well, I'm complaining. It's time for you
guys
>to figure it out once and for all and let it be.
>
>Thanks,
>
>David Hendrix
>dmhendri AT fedex DOT com
>
>
>
>
>
>Christian Bolik <bolik AT DE.IBM DOT COM> on 12/16/98 06:18:52 AM
>
>Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
>
> To: ADSM-L AT VM.MARIST DOT EDU
>
> cc: (bcc: DAVID HENDRIX/216832/ITD/FEDEX)
>
>
>
> Subject: Re: Stop changing Sol clients
>
>
>
>
>
>
>
>
>
>
>
>David,
>
>I understand your frustration to a certain extent. But what do you mean
>with "change the rules on installation"? Ever since V3 GA the
installation
>rules for the Sun clients have been identical. The only change introduced
>with 3.1.0.6 was that the package structure was simplified by removing the
>wrapper script from /opt/IBMadsm-c and move the real binaries that used to
>be in the sol251 or sol26 subdirectory (for V3, there never was a solaris
>subdirectory), to the installation base directory. This was done
>specifically to make the Sun packages become more consistent with the
>other UNIX ADSM client packages.
>
>I'm sorry to hear that this internal change that did not affect the
>installation procedure nor the usage of the ADSM client on Sun apparently
>broke some of your scripts that obviously relied on the internal package
>structure of the ADSM client. Maybe if you could be a little more
>specific as to what problems the new package structure caused for you
>we would be able to help.
>
>Anyway, I agree that modifying the internal package structure as part
>of a PTF release was not a good idea. We'll take care to not let this
>happen again in future PTF's.
>
>David Hendrix wrote:
>>I am getting really tired of IBM CONSTANTLY changing binary/directory
>>locations for Solaris clients. How about this chronology:
>>
>>Version 1: /opt/IBMadsm-c
>>
>>Version 2: /opt/IBMDSMba5 ap5 blah, blah blah
>>
>>Version 3: /opt/IBMadsm-c/solaris
>>
>>Version 3.1.0.6: /opt/IBMadsm-c/solaris isn't there anymore.
>>
>>This is ludicrous! HP hasn't changed. AIX hasn't changed. For some
>>reason, those in the solaris camp can't quite decide WHERE they want to
>put
>>the software. Get your act together and stop changing these locations.
>It
>>makes my job that much harder because you change the rules on
>installation,
>>which then screws up all my scripts.
>>
>>Can you tell I'm upset IBM?! It's one of those small things which bugs
me
>>to no end.
>
>Best regards,
>
>Christian Bolik
>IBM SM IT Software Development ADSM, Mainz
>
|
