Dave, thanks for that feedback, much appreciated.
And yes, we intended it to default to a maximum size of 25 MB. In most
situations (not all, depends on volume of work), we figured that was a good
size to contain many days worth of data without requiring explicit action
to enable the pruning.
Bac
I'm using the term "rotate" loosely. Unlike other log files, which prune
older contents based on size and age, when the dsminstr.log reaches the
configured maximum size, the file is renamed to dsminstr.log.bak and a new
log is created.
At least on RHEL 6.8, the dsmc command that triggers the rota
Hi David,
What is this "rotating" of logs you refer to? Is this related to log
retention and pruning?
dsminstr.log is managed in a fashion similar to dsmerror.log with regard to
user permissions and file locking. Is this causing a problem? Or are you
just making an observation?
Yes, please open
Hi Gary,
Yes, "always on instrumentation" was added to the client in 7.1.6. This
change is documented here:
http://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.6/client/r_new_for_version.html
Note that instrumentation is of negligible (near zero) impact to
performance. Having it enabled by def
Yes, they turned it on by default in 7.1.6 and changed configuration from a
testflag to a new option (ENABLEINSTRUMENTATION):
https://www.ibm.com/support/knowledgecenter/SSGSG7_7.1.6/client/r_new_for_version.html
One more pain point when supporting client operations for non-root users (log
file
Tsm client 7.1.6
Os rhel 6.8
Tsm server 6.3.4
Looks like client instrumentation is defaulted to on.
Is this new?
No flags in my dsm.opt or dsm.sys.
Step back.we have a winner.
This is the command that worked:
Objects: sh /nz/kit.7.2.1.1-P1/bin/daily_tsm.sh
No quotes, but needed the 'sh'.
No permission changes.
And the ./nzbackup worked as well
Thank you all very much!
-Original Message-
From: ADSM: Dist Stor Ma
