HP3000-L Archives

March 1995, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bill Lancaster <[log in to unmask]>
Reply To:
Bill Lancaster <[log in to unmask]>
Date:
Mon, 20 Mar 1995 23:45:21 PST
Content-Type:
text/plain
Parts/Attachments:
text/plain (66 lines)
This is a particularly interesting topic to me.  I have contended for
sometime that the capability to have multiple stream queues is *very*
desirable.  That way, you can limit, for example, how many AP jobs are
running with a separate control over how many GL jobs are running.  This
has always struck me as a fundamental requirement.  To that end, I had
extensive conversations with various CSY'ers regarding the possibility of
us adding value to MPE with a cooperative relationship regarding our
Q-Xcelerator (mild plug alert).  This simple product provides the same
basic functionality that Workload Manager provides with one very
significant difference:  Q-Xcelerator works, via AIF's, sitting on top of
the system dispatcher while the Workload Manager is, in effect,
enhancements TO the dispatcher.
 
Doug Perry and Susan Campbell were the main architects of the Workload
Manager, and in my opinion, did a terrific job.  I believe that they more
than met their charter of providing more extensive, dispatcher level,
process control.  We did an early beta of the WM and, after the usual
early product glitches, got it to work as advertised.  By the way,
Narinder Sandhu was also involved extensively in the project and was
quite a help.
 
In a meeting that I had with Doug and Susan at Interex in Denver, several
points were brought up.
 
  1.  This multiple STREAM queue capability was the only item in the
SIGMPE top ten to not be funded.
 
  2.  There will be some advanced capabilities that the user may require
which should definately NOT be performed by the dispatcher (for reasons
of overhead).
 
  3.  There are definately some advanced capabilities that the user may
require that are best performed by products which sit atop the dispatcher.
 
(2) and (3) appear redundant but they really should be considered
separately.  If you think about it, it really makes sense that you don't
want the dispatcher to have to evaluate, every cycle, issues such as time
of day, threshold exception, multiple STREAM queue and so on.
 
This is why it makes sense to have both the Workload Manager AND another
tool like our Q-Xcelerator or Unison's KLA product.  This is exactly why
HP decided to make a Workload Manager AIF available.  Makes sense to this
point.  Where this idea breaks down is that the end user must purchase,
at full price from HP, the Workload Manager product (5-10k) AND the third
party product.  This is a complete departure from previous AIF's where
the vendor bought the rights to use an AIF and the customer only had to
buy the third-party product.
 
All of the dialog regarding the question of whether or not the capability
exists in a third-party product is essentially meaningless to the product
managers and marketing types at HP.  The technical people (Vance,
Paivinen, Fairchild, Perry, Campbell etc) do appear to consider that as
an important issue, but as several third-party vendors can attest, that
may not be enough.
 
Why am I saying all of this now?  It's not just a fit of pique.  Rather,
as a warning to the user to not expect the Workload Manager to go any
further that it already does.  It doesn't make sense, from a technical
perspective, for WM to receive much more in the way of enhancements.
Also, don't expect HP to enhance the dispatcher to specifically perform
multiple STREAM queue's.
 
Bill Lancaster
Lund Performance Solutions
[log in to unmask]

ATOM RSS1 RSS2