ADSM-L

Re: [ADSM-L] Disparate Client Options

2010-01-05 19:51:13
Subject: Re: [ADSM-L] Disparate Client Options
From: Robert Clark <robert_clark AT MAC DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 5 Jan 2010 16:50:19 -0800
If I was going to whinge on about the differences between the Windows
and UNIX clients, I would want all of the Windows config options
moved into proper dsm.opt and dsm.sys files.

The lack of dsm.sys and dsm.opt is likely what lead to there being
command line options for the windows binary in the first place.

I would want no settings to be in the registry. I would also want
someone at Tivoli to confirm everything ends up the same whether the
install is done through the GUI Wizard or through dsmcutil.

With regard to doing dynamic things on UNIX, there is typically
something better available than a DOS shell, so echoing a few lines
into a temporary file that contains the process ID and using that is
not hard enough to complain about. Heck, even cleaning up the temp
file when you're done isn't too hard.

I hear the Mac client has stopped putting settings in resource forks,
and has gone to text config files.

[RC]

On Jan 5, 2010, at 7:53 AM, Nick Laflamme wrote:

Does it annoy or hinder anyone else that the "tcpserver" and
"tcpport" options supported by the Windows version of dsmadmc
aren't supported by the Unix clients?

This seems to be a  deliberate choice by IBM; the 5.5.2 levels of
the client make a point to quit with an error message if I try to
use them; in the 5.5.1 level, my attempts to use them are merely
ignored.

I want them so I can have scripts issue QUERY SERVER commands
against a central server and use that output to connect to new (or
existing) TSM servers I maintain. Apparently, in the Unix world,
I'm supposed to keep dsm.sys up to date on every Unix server on
which I might run my scripts instead of dynamically specifying
these parameters. Part of it is because of the number of servers on
which I might access these scripts; part of is because we
anticipate rolling out waves of new servers in the future as we
retire older servers. Either way, the thought of keeping dsm.sys up
to date just so I can run administrative scripts is annoying, to
put it mildly.

Anyone else with me on this?

Thanks,
Nick