>One of my customer's boxes has been running the TSM journaling service
for about 2 months now and doing backups >with no problems.  His box has
several million files on it and the journal has reduced backup times
significantly > >until yesterday when the journal service hung and blew
up.  The server at that point backed up everything on the <system, pushing
almost 140GB till we stopped it.
>The customer could not stop the journal service, it's going to take a
reboot.  His system:

>From the looks of the jbberror log it appears that perhaps the
client/server session was severed
(you would see this in the client errorlog) and that the backup didn't
complete, which in the current
client causes the journal to be invalidated and thus will force the next
backup to be a non-journal based
full incremental.

If you post your client errorlog (dsmerror.log) I might be able to
determine what happened.

That being said, I encourage you to upgrade to the 5.16.15 client as soon
as it becomes available
as this fixtest contains a significant number of journal fixes.

I also encourage you to view the Journal Based Backup FAQ Knowledge
article at the follow
location:

http://www-1.ibm.com/support/docview.wss?rs=203&context=SWI00&context=SWJ00&context=SWK00&q1=Journal+Based+Backup&uid=swg21155524&loc=en_US&cs=utf-8&lang=en+en

Hope this helps ....


Pete Tanenhaus
Tivoli Storage Solutions Software Development
email: tanenhau AT us.ibm DOT com
tieline: 320.8778, external: 607.754.4213

"Those who refuse to challenge authority are condemned to conform to it"

---------------------- Forwarded by Pete Tanenhaus/San Jose/IBM on 01/28/2004 
01:48 PM ---------------------------
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:
Subject:        My journal blew up :(



One of my customer's boxes has been running the TSM journaling service for
about 2 months now and doing backups with no problems.  His box has
several million files on it and the journal has reduced backup times
significantly until yesterday when the journal service hung and blew up.
The server at that point backed up everything on the system, pushing
almost 140GB till we stopped it.
The customer could not stop the journal service, it's going to take a
reboot.  His system:

Win2K Server
TSM Client 4.2.3
Plenty of free space on both drives
Journal service allowed to grow as large as it needs to

Our setup:
TSM server 5.1.8.1
Solaris 8

The journal files completely disappeared, he can't locate them on either
partition.  He found the jbberror.log right where it was supposed to be on
C:\, see below:

01/22/2004 11:30:07 psFsMonitorThread(tid 1860): Object
'D:\Files\~WRD0001.tmp' was deleted after notification.
01/22/2004 11:30:07 psFsMonitorThread(tid 1860): Object
'D:\Files\~WRD0001.tmp' was deleted after notification.
01/27/2004 12:55:16 NpWrite: Error 109 writing to named pipe
01/27/2004 12:55:16 NpWrite: Error 232 writing to named pipe
01/27/2004 12:55:16 NpWrite: Error 232 writing to named pipe
01/27/2004 12:55:16 NpWrite: Error 232 writing to named pipe
01/27/2004 12:55:16 NpWrite: Error 232 writing to named pipe
01/27/2004 12:55:16 NpWrite: Error 232 writing to named pipe
01/27/2004 12:55:16 NpWrite: Error 232 writing to named pipe
01/27/2004 12:55:16 NpWrite: Error 232 writing to named pipe
01/27/2004 12:55:16 NpWrite: Error 232 writing to named pipe
01/27/2004 12:55:16 NpWrite: Error 232 writing to named pipe
01/27/2004 12:55:16 NpWrite: Error 232 writing to named pipe

No real problems until yesterday morning.  He is going to apply the latest
service pack to this system tomorrow and we will be rollling out the
latest TSM client in the next week or two (we just upgraded the server in
mid-Dec).  I haven't seen anything like this either on the list or
googling around.  I hope someone can help, I don't want my customer to
lose confidence in TSM, thanks!



Michael French
Savvis Communications
IDS01 Santa Clara, CA
(408)450-7812 -- desk
(408)239-9913 -- mobile