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



According to the following redbook:
http://www.redbooks.ibm.com/redbooks/pdfs/sg246286.pdf

the call looks pretty easy.

<snip page 87>
4.2.2 Journal recovery ratio (JORECRA)
The journal recovery ratio is implemented as a count of journal entries to
be processed. The
ratio establishes an upper limit on the number of journal entries which
will need to be
examined and applied/replayed if the machine were to terminate abnormally.
This recovery
ratio controls the aggressiveness of background SLIC tasks which sweep
changed journaled
object pages (such as SQL rows) out of main memory and onto disk. Set it
too small and you
end up consuming substantial quantities of CPU, IOA write cache and disk
bandwidth
sweeping instead of doing useful production work. Set it too high and you
risk longer IPL
recovery processing. The higher the ratio, the less frequently journaled
objects get written
and the better the run time performance. The default value is 50,000. That
means on average
you can expect that an abnormal IPL will have to examine and replay 50,000
journal entries
and visit 50,000 SQL rows before the IPL step completes. You can change
this value by
invoking the Change Recovery Ratio API. For example:
Call QJOCHRVC 100000
You can specify a recovery ratio ranging from 10000 up to 2 billion.
For most shops who care more about reducing journal performance overhead
than about
extremely fast IPL recovery (perhaps because they have a second iSeries
server as their HA
standby machine) and who have a substantial amount of main memory, the
50,000 default is
probably too aggressive, thus it may make sense for such shops to bump this
recovery ratio
up to at least 250,000.
A gradual trickle of changed pages from main memory to disk is far less
disruptive to other
applications sharing the same disks and IOA than a massive memory flush.
</snip page 87>


Manual page:
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/index.htm?info/apis/qjochrvc.htm


----------------------------
Bryan Dietz
Aktion Associates



midrange-l-bounces+bdietz=aktion.com@xxxxxxxxxxxx wrote on 08/05/2005
05:30:43 PM:

> Has anyone created a CL Wrapper for the QJOCHRVC API ...
>
> Kenneth
>

>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.