× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Vern,

There was a document (by Rick Turner) in the knowledge base that got passed
around a while back...  I think that's the one that describes this behavior.
(I think you posted it...)

I had to find it again...
http://www-912.ibm.com/s_dir/slkbase.NSF/0/06f669c96c492f6a86256d6c0064adbe?
OpenDocument

Here's the bit you posted perviously:
<BEGIN>
There's a little-known solution - turn on commitment control. Without this, 
jobs can take 3-4 times as long to finish. Here's an extract from an 
article by Rick Turner:

Commitment Control & Journaling
Though most database and other write operations are asynchronous, database 
journal receiver write operations are usually synchronous to the issuing 
job. This means the job is forced to wait (in the system's disk I/O write 
functions) for the I/O (write) to complete before it continues processing. 
The SLIC Journal functions can do the journal writes asynchronously if the 
job uses commitment control.
When commitment control is in effect, the database journal write functions 
know that file integrity is required only at a commit boundary and not at 
every record update/add/delete operation. Because of this, the database 
journal writes are scheduled asynchronously. When a commit boundary is 
reached, the database functions ensure that all pending database file I/O 
is complete before continuing.
Lab tests show that using commitment control and journaling yields 
performance almost equal to not using database journaling. If you use 
journaling but not commitment control, a job can be three to four times 
slower than when you don't use journaling at all.
"But this means I have to change my code!" you say. True, but the cost of 
the changes are minimal compared to the performance benefit. In the CL 
program that calls the batch program, specify the files that use commitment 
control and open them. Start a commit cycle in the CL program before 
calling the batch program. In the application program(s), change the file 
description to specify that commitment control is in use. Once the program 
returns to the CL program, end the commit cycle to force any pending file 
I/O to complete.
<END>

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: Vernon Hamberg [mailto:vhamberg@xxxxxxxxxxx]
Sent: Thursday, February 24, 2005 6:28 AM
To: Midrange Systems Technical Discussion
Subject: RE: SQL performance with Local journalling


I would use SETOBJACC *PURGE on the file in question between the runs. But 
the issue is probably high I/O - without journal caching, every (probably) 
change in a PF is also written to disk, using more I/O. Just turning on 
commitment control, I'm told, turns on some journal caching. If all you 
want is to improve the performance, you don't need to actually do 
commits/rollbacks. In this case, I think I'd set lock level to *CS, to 
avoid long locks - check the help for STRCMTCTL.

This information is based on my recollection of what I was told by one of 
the folks who worked on journaling at IBM, as well as the journal cache 
parameter on CRTJRN. I hope my memory is good - try it out.

Vern

At 04:49 AM 2/24/2005, you wrote:
>Hi Eric,
>
>that's why I got them to run it the other way round - i.e. with 
>journalling on first  - to try and eliminate this factor.  Is there 
>something else I should be thinking.
>
>Regards
>Evan Harris
>
>At 08:55 a.m. 24/02/2005, you wrote:
>>Maybe they need to purge the file from storage...
>>
>>When they turned journaling off and reran the query, the object was
already
>>paged into a storage pool, giving the illusion of exceptional performance.
>>
>>Use the CLRPOOL command before each run...
>>
>>hth,
>>
>>Eric DeLong

-- 
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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

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.