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
