|
midrange.com
David
John said that they had already made the decision to use journalling,
therefore his question was whether commitment control was too great an
additional overhead and I responded to that.
I do agree that journal receivers can grow quite rapidly and therefore good
housekeeping ractices must be applied to ensure that they are detached
regularly and saved offline.
Rob Dixon
----------
> From: David Morris <dmorris@plumcreek.com>
> To: MIDRANGE-L@midrange.com
> Subject: Re: Commitment Control
> Date: 13 July 1998 22:56
>
> 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 >>>
> John
>
> 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
> control.
>
> 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 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
+---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
