> Guys,
> 
> Sorry, please ignore me - the reason that it is not updating the 'last
> backup start/completed date/time' is nothing to do with journaling,
> but because the backup script seems to be backing up a particular
> filespec/directory path of the filespace, rather than the whole drive,
> therefore I will never get an updated date/time. Doh - sorry, I'll
> make sure I check everything out before posting next time...
> 
> Whilst I'm here though, I notice in the journaling files directory
> that one of my files - tsmG__jdb.pag - is *huge*. Well, around 850MB.
> I did an incremental backup with the journal engine engaged (only 10
> minutes - *so* much better), and it remains at 850MB. I would have
> expected this to have been decreased somewhat... Am I right in
> guessing that the size of this file will grow to the largest size
> required, but won't shrink again when not needed? Is there anything I
> can do to shrink it?
> 
> Rgds,
> 
> David McClelland
> Global Management Systems
> 
>  -----Original Message-----
> From:         David McClelland  
> Sent: 29 September 2003 14:18
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Journaling - not updating 'Last Backup Start/Completion
> Date/Time'
> 
> *SMers
> 
> Hurrah! I now have 4 consecutive days worth of successful journal
> backups!
> 
> Instead of my 12,000,000 million object filespace taking nearly a
> whole day to process, with journaling turned on I've managed to get
> this down to anything from 10 minutes to 1.5 hours depending upon how
> many files have changed - significantly better :o) Thanks guys!
> 
> *However*, one thing strikes me - I look at the output of a `query
> filespace <JOURNALEDNODENAME> f=d` and refer to the 'Last Backup
> Start' and 'Last Backup Completed' date and time stamp, and these now
> don't ring true. In fact, they appear to point to the last successful
> full incremental backup that I performed prior to enabling journaling.
> 
> 
> Am I correct in assuming that TSM doesn't count a
> journaled-incremental as a full backup when it comes to looking at the
> `filespaces` table? I'm sure quite a few guys out there use the output
> of this for some reports...
> 
> Rgds,
> 
> David McClelland      
> Management Systems Integrator 
> Global Management Systems     
> Reuters       
> 85 Fleet Street       
> London EC4P 4AJ       
>       
> Telephone     +44 (0)207 542 4670     
> Mobile        +44 (0)7711 120 931     
> E-mail        david.mcclelland AT reuters DOT com     
> Reuters Messaging     david.mcclelland.reuters.com AT reuters DOT net 
> 
> 


--------------------------------------------------------------- -
        Visit our Internet site at http://www.reuters.com

Get closer to the financial markets with Reuters Messaging - for more
information and to register, visit http://www.reuters.com/messaging

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.