RE: Timeslice/purge settings was: Suppress Query Status Message

[Colin Williams <Williamsc@xxxxxxxxxxxxxxxxx>]

That joblog / message thing is very true, many people are not aware that
if they turn off logging for jobs on a live machine, they can see a huge
increase in performance. I used to always ensure that logging was
switched off for users, by having separate job descriptions for users
and development staff (who get really peeved when they can't press F9 to
retrieve the previous command). The job log only tends to get looked at
when something goes wrong, so I think it logging should be only switched
on where it is appropriate.

                -----Original Message-----
                From:   Buck Calabro/commsoft
[mailto:mcalabro@commsoft.net]
                Sent:   Thursday, March 18, 1999 2:26 PM
                To:     MIDRANGE-L@midrange.com
                Subject:        Timeslice/purge settings was: Suppress
Query Status Message

                On 03/17/99 05:46:43 PM pytel wrote:

                Alexey,

                >Timeslice and Purge settings will not have any
noticable influence on
                >long-running tasks.

                This is a very interesting topic!
                Doesn't TIMESLICE come into play when you have a
compute-bound job? 
                Something like creating large GDDM graphics?  When the
job goes to disk to 
                get/put a record, it leaves the activity level, right?
Unless the job 
                occupies the activity level until timeslice end,
boosting the timeslice 
                makes no difference

                The purge setting is mostly useful in a small-memory
system, if I recall. 
                It lets you tell the system if you want the entire PAG
paged in one 
                operation at timeslice end/enter long wait.

                This leaves RUNPTY as the other parameter on the class.
Won't a job that 
                fetches thousands of pages of DASD at RUNPTY(20) will be
more of a resource 
                hog than the same job running at 50?  It'll certainly
get returned to an 
                activity level before the RUNPTY(50) job will.

                So, I guess the question here is: for a query, does the
processor time 
                required to build an access path get charged to the
interactive job, or to 
                an internal system task?

                The batch/interactive debate extends into separate
memory pools and working 
                set size.  Too often, the interactive memory pool is
sized for a smaller 
                working set that the batch pools.  This makes it easier
for a batch-type 
                job to force other jobs' storage to be paged out.  This
is not a Good Thing 
                for the interactive job's program pages that've been
paged out by DB pages.

                >Suppressing status messages can help, because sending
message to display
                >device incurs a relatively high overhead (especially
when there are many).

                Absolutely!  The same is true for writing messages to
the job log.  Any 
                time a program/job does extra I/O is a place to look for
performance 
                improvements.

                Buck Calabro
                Billing Concepts Inc (formerly CommSoft), Albany, NY
                mailto:mcalabro@commsoft.net
                +---
                | 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
+---