• Subject: RE: CISC to RISC - Performance
  • From: "O'Connor, Peter H." <102736.3535@xxxxxxxxxxxxxx>
  • Date: Thu, 18 Dec 1997 09:02:46 -0500

Message text written by INTERNET:MIDRANGE-L@midrange.com

Neal writes:

>It's all a question of priority.  If the tasks Peter's code kicks off
are running at a lower priority than other work you want to run on the
system (and if this other work is interactive that's certain to be the
case, if it's batch you can change the priorities) then it should make
no difference.  Just because your 'CPU %' is 99.9% (or even better
'++++'    :-)  ) doesn't mean you can't run another job at a higher
priority than the 'hog' job/jobs and get your work done.
 <
Neal;

PC/Accelerator's jobs run in a subsystem called QINBETWEEN.  There is one
job for each THREAD.  If you have 6 TREADS running, you only have the
overhead of 6 jobs.  Each THREAD can handle one STROBJCVN after another;
DATAQ driven not JOBQ.  Each THREAD can be given for example 100 libraries,
600 in total for this example because of 6 THREADS.  You only have the
overhead of 6 jobs, great for performance.  Asychronous transaction
processing is the MOST efficient method of processing.  There is no
overhead of even producing JOBLOGS for 600 object conversion because there
are only 6 jobs, 6 PAGS and no SBMJOBs.  If 600 libraries were to be
converted the IBM method,  you would have 600 joblogs, 600 PAGS and 600
SBMJOBs, much more overhead.

QINBETWEEN  style process is used by Fidelity to process trades. 
QINBETWEEN actually process transactions at SAW, a large company in the
Bond Market.  Why do these financial institutions use asychronous
processing?  Because it is efficient.  Less overhead.

THREAD  jobs run at a PTY of 50.  Since Charlie the Tuner is active, it is
performing dynamic tuning during the conversion period.  If a interactive
user(s) hops on, Charlie recognizes that and adjust the interactive pool by
giving it more storage.  When the interactive user is finished, Charlie
removes the storage from QINTER.

99.9% of the Machine Pools are set at the wrong storage size during a
conversion causing bad performance. The main reason for this is that the
person who is in charge of the conversion does NOT know the first thing
about performance tuning. Charlie adjust the Machine Pool to optimize
performance.  If the machine pool is sized wrong, other pools will have bad
performance.  This has been a known fact ever since S/38 days.

To get back to the original comment, it does not make any difference if
other jobs start because of the (A) priority system, (B) the QINBETWEEN
method of processing  and (C) because of Charlie the Tuner if active.  I
hope this explains the method of process.

The reason SEABOARD was able to do all the restoring while object
conversion was taking place were (A), (B), and (C).  Neal is 100% 
correct!!!!!!

Peter H. O'Connor
PAE Inc.
7 Riverway Rd.
Salem, MA 01970-5343
978-744-8612(T)
978-745-7945(F)
e-mail 102736.3535@compuserve.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to "MIDRANGE-L@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 thread ...


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

This mailing list archive is Copyright 1997-2019 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 here. If you have questions about this, please contact [javascript protected email address].