a Superior
HP 3000 Future
Jim Sartain listens, in order to build relationships on behalf of the HP 3000. The leader of one of two Cupertino-based R&D sections in the HP 3000 division (CSY) lab, Sartain manages engineers expanding some of the 3000’s newest technologies, as well as some of its oldest. Solution teams covering Internet and interoperability along with HP databases report to him, as well as groups exploring datacenter solutions, application development tools and customer support. Sartain may be best-known in the 3000 community, however, for work he led in response to a customer revolt. Once customers expressed their displeasure at a waning emphasis on IMAGE, CSY had to respond with improvements. Sartain was directly responsible for HP’s offering of an SQL interface for IMAGE, the first advance that signalled CSY’s commitment to a Customer First strategy. Sartain worked with a revived IMAGE special-interest group to revitalize the database at the heart of 85 percent of 3000s, showing a level of dedication and response matched by few CSY managers before or since. Dynamic detail dataset expansion and third-party interface work also began on his watch.
After bringing a revamped IMAGE/SQL to the customers, Sartain took an educational retreat to advance in the HP management hierarchy. Sartain’s move in 1995 from front-line IMAGE work resulted from an education opportunity he won, nominated as one of 10 HP employees in a new Master’s degree program for Management of Technology (MoT). The academics were a return of sorts for him; he began his HP career after leaving an associate professor’s post at the University of Oregon in 1983. Sartain emerged from the MoT program in 1997, acting as the US based manager of CSY’s new Bangalore, India engineering resource. CSY R&D manager Winston Prather named Sartain to his current post later that year.
Sartain has always showed strength in his ability to listen to customers and HP solution suppliers. Wirt Atmar, one of the 3000’s strongest proponents and a key advocate of IMAGE, credited Sartain with “single-handedly restoring a profound sense of trust between the users and HP. The change in attitude that Jim helped foster [as director of the IMAGE lab] was one of the primary driving forces that very much helped resurrect the HP 3000 from the grave.”
In plainer terms, we believe Sartain is
a leading reason the 3000
enjoyed the renaissance that led to its
second 25 years as a growing
HP business. We decided to turn the tables
on the CSY manager
and listen to him at the recent IPROF
conference, as CSY’s labs
outlined the advances that will be
delivered in that quarter-century.
While the scope of Sartain’s duties
prompted questions across
many technology and policy fronts, all
could well be summarized
into one: how he will use his position to
make superior listening
result in superior solutions.
You’re covering a lot of ground for
the 3000 these days. How do
you define the scope of your
responsibilities?
I’m responsible for application
development, database, Internet
interoperability and networking. We’re
all responsible for customer
support of the HP 3000, and software
delivery: mainline releases,
Express releases, PowerPatches. If
you’re wondering what that
doesn’t cover, it’s everything
but MPE. Dave Wilde is Mr. MPE,
championing the growth work. Subbu [V.S.
Subrahmanyam] is responsible
for the lab in Bangalore, which is involved
in everything Dave
and I are doing.
Software delivery is a pretty hot
issue now with the confusion
over Express 3 and PowerPatch 4 packaging
and instructions. What
can you say about how much better the
process will be for Express
5 and PowerPatches?
We’re actually rolling out a lot more
functionality in Expresses
than we’ve ever done before.
Previously most of it was in mainline
releases, and the Expresses had some new
functionality. Now we’re
not waiting for mainline releases. We have
some challenges learning
how to use this technology. We probably
need to improve it. We’re
learning about some areas where it
wasn’t designed to handle the
volume of software that’s going
through that channel.
Do you think there’s a chance that
in the future people will be
able to run a program on the 3000 that asks
simple questions and
tells them what they need to install?
We’ve made improvements in this area
with Patch/iX and Stage/iX.
We haven’t done a good job of
articulating some of the benefits
of this program to customers and to our
support organization.
It supports features that allow you to do
staging of some of the
updates offline, to save you a lot of
downtime.
We’re definitely listening to all
the feedback we’re getting from
the [3000 Internet newsgroup] on the issue,
and we want to evolve
this process. Even the media we’re
sending will be changing over
time. [Ed. Note: CSY managers referred to a
new HP corporate directive
that software updates should migrate to
CDs, possibly in DVD format,
by the turn of the century.]
How are you going to motivate
Roseville’s Computer Languages Lab
to get going on the renovation of the COBOL
II compiler? Can CSY
do something to move the process along,
like taking the compiler
out of the Software Services Division and
back into the 3000 division?
The heart of the issue is not a
relationship issue. We have a
great relationship with the folks in
Roseville. The real issue
is that we have been slow to develop a plan
for the COBOL language.
We’ve been hearing feedback on the
need to have a clearer roadmap,
and we haven’t progressed on that as
rapidly as we’d like.
We hear the need. The COBOL compiler is
used by a majority of
applications on the 3000. It’s a major
tool that’s required to
maintain the customer’s investment.
You should expect to see more
progress on the COBOL plan by HP World.
We’re not happy with the
progress we’ve made. We’ve had a
lot of other things to focus
on, like the MPE growth plan.
We’ve written that improving COBOL
II is a chance to supply better
performance overall for the 3000. Do you
see it that way?
Absolutely. Improving compiler performance,
including the COBOL
compilers, is an excellent opportunity for
improving system performance.
This is true for customer applications and
it’s also true for
the operating systems and HP subsystems.
We’ve made more progress
in the internal compiler area [such as
modcal] than in the external
areas compiler.
What’s up with C++ support?
It’s a tool in porting a real prominent
piece of Internet software that will be on
every HP 3000, and
yet CSY hasn’t put it in the full
support category. What kind
of message does that send to people
pondering potential Posix
porting projects?
It’s clear there’s more and more
use of C++. We’re using it more,
and we’re very happy with the quality
of the C++ compiler. The
support that is available is meeting our
needs, and it’s not impacting
our Netscape porting adversely. It is a
development environment,
so it’s not like a 24x7 situation
where you need immediate Response
Center support.
It’s exceeded our expectations in
terms of the quality. For the
time being, we’re comfortable with the
level of support. As time
goes by, the customer base that uses it
will continue to grow,
and we may want to revisit [the support]
question. There will
come a point where it might make sense to
provide support from
HP.
So is C++ a candidate for that
transition from unsupported freeware
to supported product, like Java/iX and
Samba/iX?
Right, and more and more you’ll see
this being our strategy. When
a new technology comes out – and we
had maybe five people here
who said they were using C++ – at that
point it’s not a serious
business issue that it’s unsupported
by HP. One thing that’s good
about this approach is that every once in a
while one of these
technologies doesn’t make it. The
worst thing that can happen
to us is when we get 20 30 customers using
some technology, and
we’re supporting it, and our efforts
go into supporting a technology
that very few people use. That takes away
from supporting a technology
such as IMAGE, MPE or networking that
everybody uses.
CSY’s own Kriss Rant asked what HP
could do to motivate ports
of Posix products to the 3000. Doesn’t
it seem like support for
the C++ compiler they’ll use would
help?
We just haven’t heard that as
being an impediment to porting.
If we started to hear that, that would
definitely raise the level
of urgency. It is surprising to see how
many companies use Gnu
C++ even when there are supported products
available. At the end
of the day, what you care about is does
your compiler work. You
prefer not to need any support.
There’s so many people working
on Gnu C++ making it better, there might be
more than working
on some commercial compilers.
Speaking of development resources, do
you think the IMAGE lab
is staffed adequately in the face of
complications that arise
from using IMAGE in the more complex world
of SQL and client-server?
We keep hearing of a limited headcount in
the HP database lab.
I think where that perception comes from is
that we’re working
more at getting the people in India
involved. People say, “I used
to work with this fellow in
Cupertino.” There was a time when
our entire lab was in Cupertino, and we
didn’t have a Bangalore
lab. Now we’ve added a sizable
Bangalore lab, and people don’t
know who those people are and don’t
know what they’re doing. They
don’t have that personal relationship.
There’s a sizable lab team, and I can’t comment on the exact number. The majority of the team is in India. We have a strong team, and you can tell by looking at all the things that were announced as having been done. [SIGIMAGE chair] Ken Sletten mentioned there were 11 things either done soon or finished. We saw presentations by Bharati [Desai of the database lab] of all the TPI enhancements, and by Tien-You [Chen] of all the IMAGE scaling going on. We also make use of third-party developers.
Basically, I say measure us on what we get done relative to needs. I think we’re doing a very good job of meeting needs, even in the IMAGE/SQL area. There’s going to continue to be things that need to be improved, to evolve in SQL and relational databases. You see improvements in those areas: the packed and zoned and signed issue that was mentioned. When an issue comes up – and that particular one has been there for eight years, by the way – it gets covered when there’s more users it impacts. I feel we’re addressing the issues as they come up, and even anticipating some of them.
With all that said, the major area you’ll see the database lab focusing on in the near future is performance and scaling. We have some major opportunities there to grow the 3000. It’s critical the database scales along with the operating system. We’ve done this before. In 1990 we did a huge number of performance improvements, and a lot of those have carried us, and we were able to coast in some areas with such a superb job in processor scaling, for example. We need to go back and make some more investments in that area. I’m convinced we have the resources we need to get the job done, and if we’re not meeting expectations, we may invest more.
We don’t think of the database lab
as being independent of the
rest of the 3000 team. We look at the whole
range of user needs,
and invest in the areas that have the
biggest needs to keep them
in balance. It does us no good to have a
superb database if the
operating system isn’t scaling, or if
the core networking capabilities
aren’t there. We’re constantly
tuning the balance of resources.
That brings up a communication issue
related to IMAGE. Why is
a large executive committee so important to
CSY’s communications
about IMAGE these days? It seems like
what’s now 29 people really
understand what’s being done, but
they’re either in HP or under
non-disclosure. Why do you think it’s
changed, and is it better
for the customer?
Other than the size, I don’t think
it’s changed. We’ve had a SIGIMAGE
executive committee for about eight years
now. We worked as closely
together in March of 1990 as we do today. I
think having a larger
executive committee has not been a bad
thing. It just means there’s
that many more people out there thinking
about the issues that
are important to the database.
The customers still have the ability to
communicate directly with
HP. Anyone who’s been around people
like Jon Bale and Bharati
Desai can see that they make themselves
very available. We have
people interact directly with us all the
time, even though they’re
not on the committee.
Well, regardless of the level of
communication between CSY and
the committee, some of what was once public
isn’t anymore.
That’s always been the case, and
it’s good in a way, because then
you can get a consensus that’s
relatively broad in an efficient
and timely manner. We’ve known all
along that the bi-annual meetings,
IPROF and HP World, weren’t frequent
enough ongoing communication
for HP and the customers.
It’s nice to have a conduit, but
it’s not the only vehicle for
getting information. There’s the
Response Center, where people
can file an SR and a lab engineer’s
going to see it.
Can you make a case for benchmarking
IMAGE/SQL, so you can show
customers new to the 3000 – like the
airlines considering Open
Skies’ solution – what
they’re getting with IMAGE?
I can see two audiences for benchmarks:
existing and new customers.
Existing customers don’t need a
benchmark to tell them they’ve
got a great solution. New customers, I
think, are more effectively
persuaded when they go to an application
provider and that provider
says, “Tell me what your business
problem is, and how many users
you have, and I’ll tell you how much
it’s going to cost to solve
your problem.” Giving them a TPC
[benchmark] number isn’t really
going to be that persuasive.
In fact, often those numbers don’t
reflect the real world. There’s
a big investment to do TPC benchmarking in
hardware and people
resources which has marginal customer
benefit.
Does a JDBC solution need to be bundled
in MPE/iX to get Java
jump-started with the customer base?
We’re taking a serious look at JDBC. There are areas where we actually anticipate needs and lead the vendors and users. ODBC was one of those areas. There are a lot of ODBC drivers today, but HP had one before other vendors knew what it was. JDBC is in the same possible category. It’s an emerging standard that may or may not make it. It may be like ADAPI, or it may be like ODBC. We think it’s very promising, but we’re not sure whether it should be something provided by HP in the beginning or whether we should work with a third-party to provide, or whether we should have a shareware solution. We’re evaluating all three alternatives. We don’t know where we want to start out on this, but we want to have something.
Inevitably, it’s better that you
end up with multiple suppliers
of this kind of solution. Even if HP
produces something, there’s
going to be some third-party out there
which does this as their
core business. They’ll do it better
than us, they’ll do it cheaper
than us. Some people, then again, will want
an HP solution. We
obviously prefer to dedicate our resources
in core areas that
nobody else can address.
What are your plans to convert jumbo
datasets to support files
greater than 4Gb? We heard at IPROF there
are no plans to do this.
I think the right way to say it would be
there are no current
plans. We’re obviously going to take
advantage of the jumbo file
capability once it’s available,
because the thing that’s growing
fastest is the IMAGE databases. The reason
it makes sense to have
big files is to support large databases,
and large files that
are extracted from large databases.
That’s why the jumbo dataset
enhancement was done from the beginning. We
needed something there
to meet the needs of aggressively growing
businesses. If the jumbo
file capability is available, we definitely
want to take advantage
of it if that is the right way to solve the
terabyte database
problem.
Is the 918DX enough of a processor for
large-scale application
development?
We have some developers who are very happy
with what they have
and are successfully using what they have.
I’ve heard other developers
that feel they need more memory or more
horsepower. There are
some ways they can get that additional
memory or horsepower at
a 52 percent discount, and that meets their
needs too. There may
be a few others for whom that doesn’t
meet their needs. They should
work with Adrian den Hartog, because he’s
very interested in getting input.
We can continue to evaluate and tweak
the program if we want.
What we should do in these cases is get
something out there, see
if it meets people’s needs. If it
doesn’t, we can tweak it some
more.
Can you do anything more for them on
support? The actual cost
appears to be more than $7,000 per year
with the machine and support,
instead of just $7,000.
We heard that, and that’s definitely
an area we’re re-evaluating.
We did work with [HP support] and we did
get some concessions.
Does IMAGE need a date/time data type in
the face of all the Year
2000 work being done?
A large number of 3000 shops have already
made the Year 2000 transition,
and they haven’t needed this data
type. It isn’t a necessary prerequisite
to solving the Y2K problem. It seems to be
less and less important
as more people successfully transition
their applications to Y2K;
they’ve just chosen a date standard
and gone with it. I’ve never
heard of it being a key issue up to this
point.
TurboStore is an HP product getting
enhancements, even though
there are third party alternatives that
provide the same or better
functionality. If CSY can justify continued
TurboStore development,
why can’t it create a 32-bit native
TurboIMAGE ODBC driver? How
do you justify not producing an enhancement
that keeps appearing
atop customer request lists?
In some cases it’s an economic matter
that it’s self funding.
There’s a revenue opportunity there
[with TurboStore]. There are
other cases where we’ve been asked to
replicate the third-party’s
functionality and not provide a better
solution. The key issue
was whether the solution was HP supported.
The problem is that
we have to pick and choose what we’re
going to support, because
we have a certain amount of support
bandwidth, and it costs HP
money. We have to judge what’s the
relative benefit of supporting
that technology versus not supporting it.
It’s always a judgment
call. It’s never black and white.
In the case of ODBC, it’s a huge
investment for some benefit,
and it doesn’t seem to make economic
sense. We have an almost
infinite number of potential customer
needs. We want to trade
off and invest in those areas that have the
biggest bang for the
buck. There’s plenty of other things
people bring up that other
suppliers don’t have. Let us work on
those.
Does every technology that CSY decides
to work on have to spring
from a customer need, or can you lead your
customers to new technology?
Everything we do should spring from a need.
The question becomes
is it an articulated need or an unspoken
need? We definitely want
to look out for some of the unspoken needs,
because that’s the
true definition of customer delight.
There’s actually a nice model
developed by a fellow in Japan named Kano
that can be used to
categorize customer needs. The model
suggests you get the most
impact by finding needs that customers
aren’t articulating. The
way you really delight people is you find
things they didn’t even
realize they wanted, but they needed. For
example, I was having
dinner in India, and who knows when it will
come. I’m bored, and
a guy comes up and says “Would you
like a newspaper to read while
you’re waiting?” I never would
have thought to ask for something
to read, but he saw I was sitting there
bored.
We have met those unspoken needs in the past. One example is PA-RISC. Nobody told us they needed a RISC architecture, but we anticipated we could have a dramatic change in the architecture that provided huge price performance improvements. People could do much better computing at a lower price. SQL is another example. People didn’t tell us they wanted relational databases. In fact, they told us quite the opposite. Quite a few customers were unsure if we should make the IMAGE/SQL investment. We carried folks along on that.
JDBC is an example of an unspoken need
from a vast majority of
customers. It’s something we’re
following and investigating. By
the time we decide to have something, it
will be there when people
finally figure out they need it.
That’s what we try to do.
Jim Sartain
HP CSY
R&D Section Manager
Copyright 1998, The 3000 NewsWire. All rights reserved.
Copyright 1998 The 3000 NewsWire. All rights reserved