• Subject: Re: Commitment Control
  • From: David Morris <dmorris@xxxxxxxxxxxxx>
  • Date: Mon, 13 Jul 1998 15:56:39 -0600

Rob & John,

I would hold off on Journaling until you have time to fully understand the 
environment.  Some areas to consider are your save/restore procedures, disk 
availability, whether temporary transaction files are to be journaled, data 
areas, etc.  I have seen the opposite of Rob's experience.  We had a consultant 
decide that to support an invoicing procedure we needed to journal all of the 
updated files.  He didn't take the time to understand the process.  It took 
quite a bit of time to sort out the mess that was created when our disk 
overflowed because some high volume transaction files were included in the 
journal.  These files were merely de-normalized views of order files.  Long 
running one-time updates and file conversions from acquisitions have also 
caused those journals to fill our disk (which is quite substantial)  because 
Journaling was not taken into consideration.

In summary I wouldn't approach Journaling casually and should not be an 
afterthought.  It is very useful if used correctly.  Journaling will not make a 
poorly designed system any better, and will end up costing more than it saves.

David Morris

>>> "Rob Dixon" <rob.dixon@erros.co.uk> 07/13 9:13 AM >>>

I am amazed that anyone should try and talk you out of this.  If he wins
the day, just pull the plug during the update and let him sort it.   

If you are already journalling, with both open and close images, then the
extra overhead is not that large.  It does mean more records written to the
journal receiver and the %age increase will depend on the number of records
written to the journal receiver per transaction.  If you are going to treat
all 500 records as a batch then the additional number is very small unless
you commit for each record.  Does each record result in multiple updates? 
If so you could set the commit size to the number of updates per record,
but I usually set this to 30 records. 

I have been journalling with commitment control for all files since /38
days and I have NEVER had to restore a file, except once for a disk failure
(/38) and when moving to a new machine.  We get excellent response times. 
If you want to minimise unplanned down time, I recommend commitment

Rob Dixon

> From: John Hall <jhall@hillmgt.com>
> To: MIDRANGE-L@midrange.com 
> Subject: Commitment Control
> Date: 13 July 1998 13:47
> We are in the midst of doing some conversions to old software.  One of
> the programmer/consultants we brought in is arguing against setting up
> commitment control.  I feel that it is a feature we should be using. 
> He feels that there may be too much overhead on the system.  We are
> going to enable journaling on all these files anyway. 
> We are on a Model 170 2164.  We just moved from an F10 so we can afford
> some overhead in processing time.
> What is the general feeling on this ?  If we are posting a batch of 500
> records should we commit on every record, every 10th record or after the
> entire batch ?
> I think it may be a case of lack of knowlege on his part but I would
> like some other opinions.
> John L. Hall
> Home Sales Co.

| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].