Peter and I reserve the right to respectfully disagree with each other.
But he's still a great guy.


At 11:40 AM 12/16/97 -0500, O'Connor, Peter H. wrote:
>Message text written by INTERNET:MIDRANGE-L@midrange.com
>Al states about CISC to RISC object conversion :
>>The downside of that it that it could tend to flood a slower CPU.  This is
>essentially the design that Peter O'Connor uses with his PC Accelerator
>product.  It gets the job done with a significantly lower elapsed time, but
>by flooding the CPU with work, you can't do much of anything else.  
>Well, Al is only partically correct!!!!!!!!  PC/Accelerator uses an
>asynchronous tasks to do object conversion in the background and not the
>IBM SBMJOB method.   The number of THREADS is different depending on
>processor and memory.  So on a slow processor, PC/Accelerator would NOT use
>as many threads.   Also, there are two methods,  restricted state and
>non-restricted state.  Non-restricted state, other jobs can be done at the
>same time.  Flooding the CPU is a perception.  If running the system at
>92-95% of CPU is Flooding, than about 75%  of the 400's are flooded.   
>Seaboard Corp. in Shawnee Mission, Kansas did an upgrade using
>PC/Accelerator on a replace-a-releae.  IBM's EUA calcuated that the object
>conversion would take 60.28 hours to run.   PC/Acceleator did the job in 5
>hours and 2 minutes!!!!!!!!!  That is a savings of 55 hours.  Remember, it
>had to do files and program objects. Even if fooding did occur which it did
>NOT, that is not a bad savings, 55 hours.  I have printed output  to
>confirm those statistics.  If any one wants Seaboards telephone number, let
>me know.
>Al also states:
> < It gets the job done with a significantly lower elapsed time, but by
>flooding the CPU with work, you can't do much of anything else.>
>Some how, Seaboard got over 1,000 damaged objects.  PC/Acceleator notified
>them of the damage in some of the libraries.  Bob Babich told me  that they
>were able to restore from tape all the damaged objects at the same time as
>PC/Acceleator was converting the rest of the system!!!!!!!!!  If one goes
>by the above quote from Al, Bob Babich would NOT of been able to do all
>that restoring while PC/Acceleator was working!!!!!  By the way restoring
>is a processor hog and if PC/Acceleator was using all the CPU, Bob could
>NOT of restored all those objects but he DID.  
>Using  Burlesque in PC/Acceleator, Bob was able to strip down two large
>libraries (6,234 & 7,371 programs).   PC/Acceleator was able to do object
>conversion of 22 libraries at the same time while Al/IBM's method could
>only do 2 large libraries at same time.  Burlesque works on object
>conversion 10 times faster.
>When I was out in Rochester testing  an unannounced OS release,  4
>developers were working on some of my problems at the same time I was
>converting 210,000 programs in 1:45 minutes.  Not Bad!  If nothing else
>could be done these developers did not know it.  
>In most cases, by the time a consultant/CE/SE leaves the computer room,
>drives to the hotel and gets into bed.  PC/Acceleator has finished up the
>work.  It is also interesting that of the hundreds and hundres of users,
>know one has complained about so called FLOODING.  
>Al is correct 99% of the time.  However, he is NOT correct this time.
>Peter H. O'Connor
>PAE Inc.
>7 Riverway Rd.
>Salem, MA 01970-5343
>e-mail 102736.3535@compuserve.com

Al Barsa, Jr.
Barsa Consulting, LLC
400 > 390

Phone:  914-251-9400
Fax:    914-251-9406

| 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 on our policy page. If you have questions about this, please contact [javascript protected email address].