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



Jay,

If you don't know what they are (I don't recognize them either), don't
touch them!  You can back into what they do by matching up the routing data
on the routing step that uses the class with various system job descriptions.

Timeslice values should not be driven by the speed of the main processor or
the amount of Interactive CPW that you have purchased!

The purpose for timeslices is to determine what is the maximum time a task
has access to an activity level (being resident in memory) before you make
it compete to keep it.

It is generally a bad thing if a routine interactive task has to give up
its activity level before it concludes.  Someone running a "batch-like"
task in Interactive is another story.  Some application software packages
have very long code paths that take awhile to complete.  Others have very
short code paths & will complete in a much shorter time.  The times also
vary with the number of tasks that are resident in memory at once!  The
correct timeslice values for Interactive can vary greatly between systems.

Like any other performance tuning issue, the important issue is the goal
that you are trying to reach &  what you are willing to give up to reach
that goal.

Are you tuning because Interactive performance is slow?

If CFINT has kicked in (& the you are unwilling to buy more processor),
optimizing your interactive performance is probably the best step.  CFINT
slows down your entire machine.

Do you have Interactive jobs that transition from active to
ineligible?  That is a sign that they are exceeding their timeslice at a
time when your main memory is over committed.

Sorry for the scattershot answer, but tuning is like seeing a doctor ...
what do you say after saying AAAHHHHHHHHH????

Hope this helps!

John Myers
IBM Certified Specialist - IBM iSeries Technical Solutions Design
IBM Certified Specialist - Advisor for e-Business
Strategic Business Systems, Inc.
17 S. Franklin Turnpike, Ramsey, NJ 07446  USA
E-mail: mailto:jmyers@sbsusa.com   Phone: +1 (201) EASY 400   x131
Web:    http://www.sbsusa.com      Fax:   +1 (201) 327-6984

Free Sports League Management - Powered by AS/400
      http://www.ScoreBook.com

Get and route intelligence from your IBM AS/400 web site - WebSurvey/400
      http://www.WebSurvey400.com

At 02:29 PM 2/8/2002, you wrote:

>I have been tuning a 730 system that someone had sorely messed up. They
>had QINTER class with a time slice of 4000 milliseconds and had left
>QBATCH at 5000 milliseconds. They affectionately call CFINT001 and
>CFINT002 'dumb and dumber' for obvious reasons, as they were continiously
>kicking in. They classes are running at 200 and 1000 respectively and the
>paging faults look much better and CFINTXXXs are less of a distraction.
>
>Continuing on the same tack, there are other classes that seem to have
>defaults that seem to be way high for todays Risc machines.
>
>Here is a list of those classes and timeslices:
>
>Class                   Timeslice
>QPWFSERVER              3000
>QP0LBIOD                2000
>QP0LLCKD                2000
>QP0LMNTD                2000
>QP0LNFSD                2000
>QP0LRPCD                2000
>QP0LSTATD               2000
>QSPCICLS                1000
>QSYSCLS                 2000
>QSYSCLS07               2000
>QSYSCLS10               2000
>QSYSCLS20               2000
>QSYSCLS25               2000
>QSYSCLS35               2000
>QSYSCLS50               2000
>
>Obviously they aren't as big as hitters as QINTER and QBATCH. Has anyone
>played with these classes and have any recommendations?
>
>Thanks,
>
>Jay
>
>p.s. IBM looked at there performace data and said 'it was running within
>design limits' and did not make any recommendations. ahhhhhhh




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.