>05-04-2004 12:30:29 ConsoleEventHandler(): Caught Ctrl-C console event .
>5-04-2004 12:30:39 Server date/time: 05-04-2004 12:22:18
> Sess Comm. Sess Wait Bytes Bytes Sess Platform Client Name
>Number Method State Time Sent Recvd Type
>------ ------ ------ ------ ------- ------- ----- -------- --------
> 6,461 Tcp/Ip Run 0 S 535.8 M 26.1 K Node WinNT LNASSVR1
I believe that the "Caught Ctrl-C" entry is a malaprop catch-all which, rather
than actually meaning that someone did a Ctrl-C at the console, means that the
process was externally interrupted, as can happen with various operating system
conditions involving the process. (Please, IBM, make the messages more
germane and helpful.)
A value this high for the Bytes Sent value value for an Incremental Backup is
a "red flag" which incites review of client size. The value should reflect the
catalog of Active files being sent to the client in its pursuit of the
file-by-file inspection in the Incremental. A client with a LOT of small files
can end up with an enormous list like this (and we can't be sure that it has
yet fully received the full list), which can be a great strain on its memory
resources - and may cause client failure...as in interrupted process. I would
look for indications in that operating system's log. In any case, the client's
real and virtual memory resources should be reviewed, given this load. You
might also look for any recent glut of files populating that client - which may
be the result of some user running amok, and which can be disposed of to relieve
In pursuing problem cases like these, invoking the same operation manually and
inspecting the action is a reasonable pursuit. With this client you may need to
utilize the MEMORYEFficientbackup option until its memory can be upgraded, if
your analysis shows that cause.
I would also recommend that you look into what time service that client is using
for its clock, as it seems to differ substantially from that of the TSM server.
That kind of thing confuses log analyses, and can cause things like Kerberos to
not work at all.
>I'm not sure how long this session has been open...
Do 'select * from sessions'.
Richard Sims http://people.bu.edu/rbs/