RE: Journaling not practical?!?!

The link to Rick Turner's "Optimizing Batch Performance" is 

http://www-912.ibm.com/s_dir/slkbase.NSF/0/06f669c96c492f6a86256d6c0064adbe?OpenDocument&ExpandSection=2

and has more about all this. Fantastic stuff - there are 2 ZIPs, one with a 
Word doc, the other with a Freelance presentation.

-------------- Original message -------------- 
From: "Elvis Budimlic" <ebudimlic@xxxxxxxxxxxxxxxxxxxxxxxxx> 

> I second Charles' recommendation on the redbook. It's the best redbook I've 
> ever read (kudos to Larry Youngren). 
> Of course, I don't remember all of the details, but I do remember the 
> conclusion about performance overhead was about 4% for the customer that was 
> collaborating with the writing of the redbook (don't quote me on the number 
> as I'm pulling it from the back of my head). 
> Actually, I think Larry mentioned there are specific cases where journaling 
> increased performance for some customers! 
> 
> Elvis 
> 
> -----Original Message----- 
> Subject: RE: Journaling not practical?!?! 
> 
> James, 
> 
> Take a look at the "Striving for Optimal Journal Performance" redbook. 
> http://www.redbooks.ibm.com/abstracts/sg246286.html 
> 
> It's a little dated as it's from 2002, but if you want to talk about 
> journal on large systems: 
> 
> "The end-of-day routine executes more than 400 application programs and 
> updates more than 
> 100 of the 2000 journaled tables present in this shop. Banesco has 2000 
> journaled tables of 
> which 100 are heavily modified, all sent to the same journal, which 
> grows by 15GB during a 
> full two hour and 34 minute batch run. 
> 
> The application programs are primarily written in RPG, with some 
> embedded SQL statements 
> and they perform tasks typical to a banking environment, for example 
> calculating interest on 
> savings and checking accounts, updating account balances, and so on. 
> Those batch jobs 
> also populate datamarts which are used in a data warehousing 
> environment. None of the 
> application programs that are executed as part of the end-of-day routine 
> uses commitment 
> control. 
> 
> The end-of-day batch run typically generates in excess of 16 million 
> journal entries in a little 
> over two hours." 
> 
> 
> Unless your customer is running at 95% CPU usage, they should be able to 
> implement journaling with little problem. Depending on their DASD 
> usage, they might need some extra space but that's a small price to pay. 
> 
> 
> 
> HTH, 
> 
> Charles Wilt 
> -- 
> iSeries Systems Administrator / Developer 
> Mitsubishi Electric Automotive America 
> ph: 513-573-4343 
> fax: 513-398-1121 
> 
> 
> > -----Original Message----- 
> > From: midrange-l-bounces@xxxxxxxxxxxx 
> > [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of James H 
> > H Lampert 
> > Sent: Thursday, March 23, 2006 12:06 PM 
> > To: midrange-l@xxxxxxxxxxxx 
> > Subject: Journaling not practical?!?! 
> > 
> > My fellow geeks: 
> > 
> > We've got a customer claiming that their system is too 
> > big, with too many sensitive files, to journal everything. 
> > 
> > This sounds like a cop-out to me, particularly given that 
> > IBM is actively encouraging users to journal EVERYTHING, 
> > and that much of the SQL functionality won't even deal 
> > with non-journaled files unless you explicitly tell it 
> > it's OK to do so. 
> > 
> > Could anybody suggest how or why this wouldn't be a 
> > cop-out, and/or a polite way to tell them they're sucking 
> > antimatter if they think journaling isn't practical? 
> > 
> > -- 
> > JHHL 
> 
> 
> 
> -- 
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list 
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx 
> To subscribe, unsubscribe, or change list options, 
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l 
> or email: MIDRANGE-L-request@xxxxxxxxxxxx 
> Before posting, please take a moment to review the archives 
> at http://archive.midrange.com/midrange-l. 
>