You are right, there are some backward restrictions in tsm... Most notable, the 
users stanza in dsm.sys on unix, and then every user being able the set DSM_DIR 
and create his own dsm.sys the way he likes it.... That is btw the second way 
to avoid having anything to do with the logfiles as defined in the global 
dsm.sys.


On 22 nov 2010, at 22:22, Steve Harris wrote:

> Hi Remco
> 
> Thanks for your suggestion, I hadn't thought of that and it does work
> nicely
> 
> However, the fact that it does work merely underlines my point that the
> original restriction on overriding the log location with the DSM_LOG
> environment variable is essentially pointless and just makes things
> unnecessarily complex for no good reason.
> 
> Regards
> 
> Steve.
> 
> 
> On Wed, 17 Nov 2010 23:24:23 +0100, Remco Post <r.post AT PLCS DOT NL> wrote:
>> How about: alias dsmadmc=dsmadmc -errorlogname=~/dsmerror.log ?
>> 
>> Wouldn't that do the trick?
>> 
>> --
>> 
>> Gr., Remco
>> 
>> On 17 nov. 2010, at 22:46, Steve Harris <steve AT STEVENHARRIS DOT INFO> 
>> wrote:
>> 
>>> Time for a bit of a rant.
>>> 
>>> <rant>
>>> I have a new 5.5 server on Solaris.  For reasons that I understand even
>>> if
>>> it does make my life more difficult, I am not permitted to have root
>>> access
>>> on this box, and the Solaris guys have determined that they want the
> TSM
>>> client log files on /var/adm/log/tsm
>>> 
>>> So dsm.sys has
>>> 
>>>  errorlogname       /var/adm/log/tsm/dsmerror.log
>>>  errorlogretention  14,d
>>> 
>>> This is fine for the root user, but when I log in to use dsmamdc  I get
>>> 
>>> ANS2036W  Pruning functions cannot open one of the Tivoli Storage
> Manager
>>> prune files: /var/adm/log/tsm/dsmprune.log. errno = 13, Permission
> denied
>>> 
>>> No big deal, I know this is not a problem and happily ignore it.
>>> 
>>> However, I have some scripts that my operations people are going to
> use,
>>> and these invoke dsmadmc multiple times per script to do whatever is
>>> needed.  Each time the ANS2036W message appears.  yes I'm aware that
>>> there
>>> is a work around for this change errorlogretention to S, run dsmadmc to
>>> create the dsmerror.pru file and then change permissions.  Someone with
>>> root access needs to do that.
>>> 
>>> Much simpler would be to just allow the DSM_LOG environment variable to
>>> override the dsm.sys specification, but it cannot.
>>> 
>>> There is NO reason not to allow this.
>>> 
>>> Given that I can set DSM_DIR and DSM_CFG to point to any arbitrary file
>>> and also symlink to the message catalog file  I can override the system
>>> options files however I please.  Its just damned annoying to have to.
>>> </rant>
>>> 
>>> TSM being complex, difficult and obscure keeps me in work, but its not
>>> doing anything for this wonderful product in the marketplace.
>>> 
>>> Steven Harris
>>> TSM Admin,
>>> Paraparaumu, NZ
>>> 
>>> 
>>> 
>>> 

-- 
Met vriendelijke groeten/Kind Regards,

Remco Post
r.post AT plcs DOT nl
+31 6 248 21 622