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

How often do your user's run this Opnqryf?
If it is once a week or something, 30 seg difference is no problem(Processor
load speaking).
But, if it is use continuously, why don't you create a data path for that
opnqryf so the DBMS don't have to build a temporary data path every time.
You can do this through SQL or DDS.

The performance improvement is amazing.

p.d.  You have to be careful about cost of a new data permanent data path
Vs. a temporary one.

Emilio Padilla


-----Original Message-----
From: Buck Calabro/commsoft <mcalabro@commsoft.net>
To: MIDRANGE-L@midrange.com <MIDRANGE-L@midrange.com>
Date: Thursday, March 18, 1999 9:03 AM
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
+---