On Dec 29, 2006, at 1:20 PM, Bell, Charles (Chip) wrote:
By the way, problem solved.
Nodename was missing from dsm.sys (Linux client). I was told this
wasn't a
problem, but client tracing showed that it was. Just FYI. :)
Good find, Chip.
The Unix TSM client defaults to using the host name a
By the way, problem solved.
Nodename was missing from dsm.sys (Linux client). I was told this wasn't a
problem, but client tracing showed that it was. Just FYI. :)
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Bos,
Karel
Sent: Thursday, December
I had the same question a couple of days ago, because I needed to
restore a password file from at least three weeks ago. (the date the
system administrator left suddenly). Luckily for me, the guy deleted
the file on the server and so the restore grabbed the latest copy in
it's archive.
Ideally
I don't see any way to get that.
The TSM server stores the backup date of a file in the BACKUPS table.
But there is no pointer to tell you which storage pool volume that
particular file is in.
WHY are you trying to get the information? Perhaps there is another
way.
If you have the file name, jus
hi all
I'm trying to come up with an sql to select the file dates in a specific stgpool
What I really need to find is the oldest date stamp of a file in a specific
onsite disk pool
any help would be great
Gary
Nicolaos -
Your session summary numbers show a good "Network data transfer rate"
for gigabit ethernet, but the "Aggregate data transfer rate" number
looks much too low.
The only way to narrow down the problem is to do the analysis there.
Your client may be experiencing file contention: unfortuna
Hi,
Thank you for that details :-)
Thats the reason why I asked for the actual jbbtools.
We've got our version from IBM support a jear ago.
We used the filemon tool to find out the right size of our notification
buffers.
In filemon.exe in our version there is only one option for the buffer size
Hi,
We found the report of IC49429 (Reference #1248198) before.
But the TSM behavior in our case is exact that which is described for a real
buffer overflow (two concurrent messages).
So the fix in 5.3.4.3 will not solve our problem.
Thank you !
Otto Chvosta
TSM-Administration
Medical Univers