Mad for 64 bits? Your budget and needs must be vast
As if on cue after the January Strategic TV broadcast, HP opened up a
Web page that
lauds the benefits and offers some caveats about 64-bit computing on HP-UX.
But before
you develop a case of bit envy over the HP 9000 futures, keep in mind how
much those
advantages are likely to cost.
No, the dollar value of systems may not be all that much higher. But
consider that one of
the few ways to take advantage of 64-bit systems is to need -- and buy --
lots of memory.
The HP web site is fascinating, because at the same time it sells the
64-bit craze it also
dispels the notion that even a majority of HP customers need it anytime
soon.
If that sounds like the "cold, dead fish" school of marketing, well, we can
only say that
HP's being really honest about 64 bits. That might be because it looks like
HP will be
more than a year behind some of its workstation competitors in delivering
it. HP wants
you to want 64 bits -- just not too much or too soon.
For example, there's this gem on the page, getting honest about today's
demand:
"Demand for 64-bit computing is in its early stages of market acceptance.
The key market
drivers for 64-bit computing are a combination of specialized applications
and some
degree of supply-driven (i.e., vendor-based) marketing."
And in our opinion, a HIGH degree of that marketing drives today's demand,
versus any
application needs.
At this point 10 years ago, the 3000 community was chafing at the bit to
move to 32-bit
MPE from 16-bit MPE. Today's situation isn't the same, for lots of
customers. Back then,
Spectrum systems (MPE/XL or MPE/iX) were desperately needed by Series 70
customers
who were maxed out with little hope of more horsepower. To put it another
way, MPE V
was a far more worn-out horse in 1987 than MPE/iX is at 32 bits in 1997.
In 1987, HP had introduced RISC on the HP 9000s first, nearly a full year
ahead of the
HP 3000's first 32-bit operating system, MPE/XL 1.0. And even that
head-start wasn't
enough. Some who lived through a MPE/XL 1.0 production implementation had to
acquire great resume skills -- or tremendous patience watching their
mailboxes for new
versions of the operating system that would stay up through a full shift.
MPE/XL 1.0 was,
as some veterans put it, a career move.
Bruce Toback wrote us to point out that MPE/XL 1.0 was a lot more unstable
than any
MPE/iX with 64-bit capabilities might be. He's probably right. But it's
hard to argue that
a new implementation of MPE/iX wouldn't have its own shake-down cruise, perhaps
through choppy water.
After our infamous tilt at this 64-bit windmill last spring, we feel
comfortable with leaving
the HP-UX folks to do the arrow-in-the-backside pioneering with 64 bits.
Too many
people I've talked with can't weather the trials of getting a new operating
system on its
feet. Once the customer demand overtakes the "supply-driven (i.e.,
vendor-based)"
marketing, we'll need HP to get to work on delivering a full 64-bit MPE/iX.
By then, we
may have the advantage of seeing the operating system improve at somebody
else's
expense (i.e., the HP-UX customers).
We don't know of too many people anxious to try out a 1.0 version of 64-bit
MPE on
their *production* machine. Our surveys show a lot of people aren't yet
willing to install
MPE/iX 5.5, an operating system that's in its 10th year of production use.
For the next
two years, we're more comfortable thinking of IA-64 -- and it's
corresponding "Next
Generation Unix" -- as experimental.
Toback did agree that the benefits of 64-bits are likely to be smaller than
we're being
promised on Web pages and in the mainstream press. "A 32- to 64-bit
transition is less
likely to result in dramatic performance improvements for MPE/iX customers
than the
press hype would have us believe," he wrote. "Many of the steps required
for fast
business data processing have already been taken: 128- and 256-bit memory
buses,
wider and deeper caches, faster memory cycle times. Widening the CPU data
path and
increasing the address space will have a less significant effect. It
certainly isn't the case
that a transition from 32- to 64-bits will double the performance of
present systems, all
other things being equal."
Toback adds, and rightly so, that nobody can get comfortable with demanding
64-bit
MPE/iX performance until they have some idea how much faster it will be. HP
won't be
talking about that until the first 64-bit HP-UX running on IA-64 is
shipping, maybe late
next year.
Then there's the issue of true cost to get at those 64-bit advantages. HP
says on its web
page, "The main technological benefits of 64 bits over 32 is the ability to
handle a larger
address space in memory. A 32-bit processor can address about 4GB... In
contrast, a 64
bit processor has the ability to address or 18 billion GB (18 Exabytes) of
memory."
In case you're wondering how much that kind of RAM will cost, only the US
government
might not blanch at the price. HP calculates it at "well more than a
trillion dollars, about
one-sixth of 1995 US Gross Domestic Product." HP goes on to say that "users
may actually
only need 33 or 34 bits of addressing. This will meet current growth
projections, but
the cost to implement 33 or 34 bits is virtually the same as to provide 64
bits." Unless
you're paying for the RAM.
Sure, RAM prices are down, but how much are you willing to buy this year?
HP may be
right -- it seems that paying for the Year 2000 projects will be a higher
priority for many
of you. If you're interested in the Web page, it's at http://www
dmo.external.hp.com/gsy/software/64bit/64bitwp.html
Oracle's not going anywhere, for now
It only took one Oracle sales rep in California to get the 3000
customer base worried
about the future of the database on MPE/iX. One rep's comment to a 3000
customer
circulated through the Internet, asserting that Oracle was only going to
support its
database through version 7.2.3 for the HP 3000. This led to a fair bit of
piling on, as
people wondered what the purported pullout meant for the HP 3000 and why
anybody
would want to get serious about using Oracle instead of IMAGE anyway.
HP and Oracle went to work on damage control almost immediately. The two allies
whipped up a quick update on their plans for the HP 3000. The sale's rep's
comments
were based on a partial truth: Oracle is still not willing to commit to a
list of supported
platforms for Release 8. Despite what some might see in the tea leaves of
whether the
3000 is mentioned on Oracle's Web page roll call, no one using *any*
platform knows
for certain they're getting an Oracle8 ‹ not just yet.
The customer communique lauded the imminent advances for HP 3000 customers to
Oracle's 7.2.3 version, Oracle Applications 10.6.1 and Developer/2000
tools. It also
promises a 4.0 version of the Oracle Transparent Gateway and a 7.3 version
of Oracle in
the months to come. Jennie Hou, manager of the HP 3000/Oracle relationship,
passed
along an official statement about the future of Oracle on the 3000. It's a
no-news-is
good-news kind of message. The most important part of the statement, for
those worried
about Oracle's commitment, reads as follows:
"Oracle and HP remain committed to the continued success of HP 3000
customers, as
indicated by our ongoing strategic alliance and mutual investment.Oracle
has not yet
announced broad platform availability for Oracle8 database. HP and Oracle
are looking
ahead at future technologies as part of our roadmap to the year 2000 and
beyond. This
is a normal part of our ongoing product planning processes. As with all HP 3000
product investments, future plans for porting Oracle products to the HP
3000 will be
based on HP and Oracle customers' evolving business needs. This is
consistent with our
frequently stated strategy of customer focused R&D. We will provide updates
on our
evolving plans through the HP 3000 Advisor, Oracle Open World '97, HP World
'97, and
other common HP and Oracle forums."
So for now, anyway, the concern appears to be premature. Richard Gambrell
of Xavier
University had it right when he recommended that HP 3000 customers try to
hope for the
best instead of expect the worst: "By being positive about the future (and
not just the
features) of MPE/iX, we encourage others to continue use and purchase of HP3K
systems, thereby helping to insure that future."
It would appear that HP 3000 customers who want Oracle8 could speak up now
-- to
those Oracle and HP sales reps, even -- to help make delivery of the
release a reality.
Timing, of course, has always been an issue for Oracle customers. In the
past the more
advanced versions of Oracle products have been available sooner on other
platforms.
We'll have more on the Oracle status on the HP 3000, including details on
the second
sale in less than a year starting in March, in our next First Class issue.
We heard about the compilers, but not enough
HP mentioned its willingness to work on MPE/iX compilers during the
strategic
broadcast, but we still don't know what they're prepared to do about tuning
them for
the PA-RISC 2.0 chips such as the PA-8000 line. The project to do this
performance
tuning is split between the CSY Vertical Growth solution team (Rachel
Kornblau/Ross
McDonald, 408.447.6066) and the Database/Application Evolution team (Jon Bale,
447.6022).
HP's Kriss Rant told viewers that HP is working with SIGCOBOL to "explore
options" for
supporting COBOL 97 standards in a future release of the COBOL II compiler.
SIGCOBOL
members might be tempted to press for some firm commitments at the SIG's
meeting with
HP during the IPROF conference. That meeting is scheduled for 8:30 AM on
March 5.
Until IPROF, we're willing to give HP the benefit of the doubt in its
commitment to
compilers. There were specific promises on the TV show about three new COBOL II
functions (see our February issue for details). The COBOL 97 standard isn't
nailed down
yet, and a significant part of the SIGCOBOL meeting at IPROF will be
devoted to it. SIG co
chair Jeanette Nutsford reports that during that meeting the SIG will
discuss what are the
most essential parts of the proposed standard. Interex plans to mail a SIGCOBOL
newsletter with the proposed standard features by the end of February to
SIGCOBOL
members.
Support for such a wide-ranging standard is a challenge HP must face for
its COBOL II
users, and COBOL 97 might be more than HP could implement all at once. If
it were
possible for HP to get out of the COBOL compiler business tomorrow, it
might not be
soon enough for some inside HP. The hurdle is those thousands of customers
using
COBOL II on the HP 3000s, programmers and managers who enjoy its productivity
advantages over less-integrated third-party solutions. Some of HP's
managers see COBOL
alternatives as a means to deliver more of the COBOL 97 standard to the HP 3000
customers -- on a faster schedule than HP could.
MicroFocus and Accucobol have offered such alternatives for years now, but
they've been
far more popular with software suppliers supporting many platforms than HP 3000
centric shops who want fast access to IMAGE data. Fujitsu has been coy
about getting
involved with the 3000 customers by offering its PowerCOBOL product. But
however
loyal the 3000 customers have been to their platform, it hasn't been enough
for Fujitsu
to make a commitment yet. They will be making a 20-minute presentation as
part of the
IPROF meeting, between 4:30 and 5:30 on March 5. Accucobol and MicroFocus
will also
make presentations.
CSY's compiler work goes on at the SSD division in Roseville, Calif, and HP
did promise
us during a pre-briefing about the show that SSD is now part of the CSY
solutions
planning process. CSY showed evidence of that during the TV show, having
SSD's Becky
Carroll speak about getting back to work on the MPE/iX products that SSD
has held at
arm's length for many months now. Very little is likely to happen soon
without some
customer pressure (or is that focus?) being exerted at IPROF and at other
places. CSY
should be having a Customer Council meeting sometime this spring, where HP
will be
listening hard to what its former "100 Club" members want from the
division. That
Council meeting carries more weight than HP is willing to admit. What HP
really needs is
for one of its larger HP 3000 customers using COBOL II to complain about
the state of
the COBOL II compiler versus the HP 9000 tools.
CSY's Kriss Rant confirmed during the broadcast that Transact is indeed
part of whatever
compiler bounty customers may reap. NewsWire subscriber Cecile Chi says
that support
in Transact for the forthcoming IMAGE/SQL Indexed Sequential Access, which
HP has
been calling b-tree support, is one item SSD couldn't deliver too soon for
Transact sites.
Finally, Nutsford recently published a 10-point list of what she considers
to be the most
important points for HP to address in its COBOL efforts for the 3000:
"Over the last 2-3 years I have had many discussions with other MPE COBOL
users about
our future with COBOL on MPE/iX. I have now compiled a 10 point list which
I believe
summarize the key 10 most common issues. I am publishing this list to
encourage other
COBOL users to consider what is most important for the future of COBOL in our
increasingly multi-platform environments. The list is in no particular
order.
1. The compiler must generate efficient native code for MPE/iX.
2. An interpretive mode for testing would be a useful tool in speeding up development.
3. There must be no run time costs for applications developed with the compiler.
4. It must conform to the new COBOL 97 standard in a timely manner. This means the commitment must be to provide a fully implemented version of COBOL 97, including the Object Oriented features.
5. It must include the most used HP extensions. This especially means the
CALL extension
to access the HP Intrinsic library and the $DEFINE macro extension.
6. Compiled programs must be able to easily access files in the MPE and
POSIX name
space from the same program. This especially means IMAGE/SQL databases.
7. An easy transition must be provided to migrate existing HP COBOL II programs to any new compiler when any HP extensions, not implemented in the new compiler, have been used.
8. The same source code must be compilable under MPE/iX, HP/UX and Windows NT, at least.
9. There must be a GUI development environment integrated with the compiler.
10. The HP Response Centre should be able to take calls for the compiler to
avoid HP
users having to add new support contracts with another vendor. "
"It would be interesting to hear what other users believe their main
priorities are. If
anyone believes I have missed an important issue please let us all know."
You can send e
mail to Nutsford at 100026.663@CompuServe.COM.
PowerHouse gets ready for Year 2000
As part of its enhancements to the PowerHouse language, Cognos is
adding support for
Year 2000 date types in upcoming releases. Rob Collins, the product line
manager for
the MPE/iX tools, gave us this update:
"We will support some vendor specific date datatypes. At this point in time
support is
planned for HP's date format as used in MM/3000 (a modified ZONED format
where a
letter replaces the first digit and represents the century and decade). We
also plan to
support PHDATE and JDATE (also known as HPDATE on HP platforms) as a century
included date supporting years 1900 to 2027. Note that these will be
century included
dates and the PowerHouse conversion routines will handle the interpretation
of values
transparent to the user and designer.
Support for Vendor-Specific Date Datatypes
In order to support PowerHouse interfaces to third-party systems, PowerHouse will support vendor-specific date datatypes where there is a demand. As much as possible, these will supported in a generic manner across all platforms. At this time, there are three such datatypes to be supported, all derived from HP.
Both PHDATE and JDATE represent the year in 7 bits. 7 bits can represent the numbers 0 through 127. By allowing the year to represent the number of years after 1900, these datatypes can support years up to and including 2027. Dates to be supported in this manner will be described as DATE SIZE 8 at the element level. The datatype will remain as PHDATE or JDATE. Internally this will be a new century-included datatype and the conversion routines will interpret the bits accordingly. Processing of PHDATE and JDATE items that are specified as DATE SIZE 6 will not change and will continue to handle a date range of 100 years based on the default century.
A new ZONED SIZE 6 date format will be supported. The first digit will be interpreted as follows: the digit 0 represents 190, 1 represents 191, and so on up to 9 which represents 199. The letter A represents 200, the letter B represents 201, the letter C represents 202, and so on. This is combined with the other 5 digits to give a century included date, For example, 961231 represents 19961231, A00229 represents 20000229, and C50101 represents 20250101. The element will be described as DATE SIZE 8. The datatype will be CHARACTER SIZE 6 or ZONED SIZE 6 or some other new datatype or option, possible DATE as in ZONED DATE SIZE 6. Internally this will be a new century-included datatype and the conversion routines will interpret the bits accordingly. Processing of date items specified as DATE SIZE 6 with a datatype of ZONED SIZE 6 will not change."
Will these HP 3000s celebrate the millennium?
Customers were scrambling for notepads during the HP TV conference when
a list of
processors was announced that HP said definitely won't ever become Year
2000 ready.
But it's still unclear what the problems will be, aside from a lack of HP
support for the
hardware. HP reported the Series 925, 935 and 949 systems won't be Year
2000 safe.
These are some of the oldest RISC-based HP 3000s out there, and HP says there's
hardware limitations in the systems that cannot be overcome even with a
Year 2000-safe
MPE/iX release 6.0.
(For the record, there are two systems older than these in the RISC lineup, the Series 930, which only saw about a hundred systems ship, and the Series 950. HP pulled most of the 930s, the first RISC system, when the 950 came out several months later. My thanks to the MPE veterans who refreshed my memory on the actual release of the 930 during those heady Spectrum days.)
But after HP put the word out about these systems, some customers went to work testing them to see what might happen in the next decade. Just a few days ago Stan Sieler reported on the Internet that he could find no problem with the firmware in the Series 935.
"I set the clock (via ISL> CLKUTIL) to 1999/12/31 23:59, and it properly rolled over to 2000/01/01. I set the clock to 2000/02/28 23:59, and it properly rolled over to 2000/02/29.
Sieler added, "The items mentioned by some people (e.g., STREAM), are MPE/iX
problems that have been (or will be) fixed, and which you will be able to
run with no
problem on a 925/935/949 (assuming you are on software support)."
HP is taking this hardware off support in late 1998, some 10 years after it
was first
introduced. That won't keep some sites which have these systems from
continuing to
work with them. Some organizations support their own hardware, or get hardware
support from a third party source. As subscriber Terry Simpkins put it,
"Since when did
'go off support' have anything to do with the end of the useful life of a
piece of
equipment?"
Tools to help find Year 2000 code
Robelle's (604.582.1700) David
Greer pointed out a few HP 3000 programs that help
find and correcting source code for Year 2000 projects. These tools are
good at finding
in general, and need your tuning to search the application for date
handling:
1. Magnet, from Lund Performance Solutions (541.926.3800) to find what
source code
uses dates.
2. Vesoft's (310.282.0420) MPEX find function, or MPEX and Robelle's Qedit
using
Qedit's pattern-matching features.
3. Using the MPE/iX Command Interpreter and/or Qedit programming to automate
conversion of common tasks.
Greer says, "The key is knowing how your applications use, specify, and
manipulate
dates. I don't know of any automated way to handle this issue -- it's still
going to take a
lot of manual work. For example, users will still want to enter dates as
six-digits.
Assuming that you store dates as CCYYMMDD, your software will have to
assume some
cut-off date for user-entered dates. This assumption may not be the same
for all date
fields. For example, birth dates should require four-digit years, but sales
transactions
could likely use six-digit dates with a cutoff."
Swap tape: another reason to be at IPROF next month
Customers who are coming to the IPROF programmer's forum next month have
assembled the resources to offer a swap tape at the conference. This is a
tradition in the
HP 3000 community when customers come together, a collection of software
written for
the 3000 and donated among anyone who's at the conference and brings a DAT
cartridge with a program. It can simplify getting popular software such as
Samba for NT
file sharing or the brand-new Apache Web server -- because you bypass the
downloading
process and just pick up a tape.
What will be on the tape is a great collection of the latest advances for
the 3000. The
mother of many a port, Mark Klein's Gnu C++ compiler and tools, will appear
with a
newer and better packaged copy. Lars Appel's Web Starter Kit is set to make an
appearance, as well as the software from the CSY Jazz Web server such as
Java examples
for TurboIMAGE. But the great thing about swap tapes is you never know what
some
clever cohort will bring that can solve a problem for you. Some of the most
clever ones
are coming to IPROF, and OESC will be providing an HP 3000 on site to cut
tapes.
Interex has sold swap tapes in past years, but the only certain way to get
yours is to be at
the conference. It's an excellent idea anyway, since HP takes so much input
from
customers via Special Interest Groups. IPROF is SIG-heaven, three and half
days of
meetings focused on subjects such as IMAGE, MPE and COBOL.
You only have until the end of this week to make reservations at the Westin
Hotel in
Santa Clara at IPROF's $139/night rate. Interex recommends you use the
hotel's direct
number, 408.986.0700, when calling to make a reservation. Ask them not to
patch you
through to the central reservations system. Provide the agent with the
following group
number: 209098 and the name: Interex/IPROF '97.
To register for the conference, call Interex at 408.743.4640 and ask for
Leah Robertson.
Or you can go to the IPROF Web site for the schedule, details and registration
information: http://www.interex.org/iprof.html
Watch out for a clumsy MOVER
Users report that some versions of MOVER, the utility used to pack and
unpack MPE/iX
patches and downloads, are bad. Stan Sieler advised on how to check that
your version
of MOVER won't bumble the transfer:
"Do a LISTF,2 of MOVER and see what the EOF is. (You can't tell be the version
number...I've seen four different versions with the same version ID!) The
best version I've
seen has an EOF of 651. I've seen several smaller versions that have
problems."
PatchWatch: Get the latest fixes for Telnet Server/iX
An HP 3000 site in Finland delivered a fine update on the latest Telnet
fixes, as well as
some field testing of Telnet Server/iX. The PTDEDF6A patch, known as the
"C" Patch,
eliminates lost connection and ghost session bugs, among others:
SR: 4701-335208 Uninit'ed variable in Telnet Level causes connection loss
(ptdede7a)
SR: 4701-336297 Telnet Ghost Sessions with PTDEDE7A. (Fin not completed w/part
read info)
SR: 4701-336826 Hitting the Enter key in a VPLUS application results in an
extra LF
echo
SR: 4701-336842 System abort 1047 occurred while running Qedit tests over WRQ
Reflection
The customer reports,"Telnet works reasonably well, but it can be a lot
slower than
NS/VT connection. Probably the Telnet protocol has more overhead, and it
shows up
when the connection is made over crowded network routers. When using Telnet
inside
our LAN, the speed is no problem. Can't tell how much CPU load Telnet is
causing,
though."
Customers using some older Minisoft emulators (version 3.5.0 or earlier) may
encounter the following bug: When you type something, all characters will
be echoed on
the screen and sent to the host, but hitting Enter (CR, ASCII 13) hangs the
connection.
Newer versions of the Minisoft emulator have this bug fixed: there is a
separate
configuration setting to control how outgoing CR should be handled.
Watch for a VSTORE command on 4.0 to 5.5 upgrades
If you're just now getting around to moving off MPE/iX 4.0 -- support
ran out on Jan. 31,
you know -- keep an eye on your commands to VSTORE during the process. The
documentation is in error, according to subscriber Jim Phillips. He found a
nuance in
upgrading, and discovered you need to add the ;LOCAL command to your VSTORE.
Phillips says:
"The documentation says :VSTORE *TAPE;@.@.@;SHOW. When I tried
that, it listed a
whole bunch of files and said they weren't on the system, and that I should
use the
;LOCAL option. My *guess* is that VSTORE won't verify a file on the tape if
the file is not
already on disk, unless the ;LOCAL option is used, like this:
:VSTORE *TAPE;@.@.@;SHOW;LOCAL
I tried this and it did work. Interestingly enough, the :HELP for VSTORE
says
The LOCAL option is no longer needed to verify files. All files will be
verified and
displayed with their real filenames, even if parts of a file's accounting
structure do not
exist on the system.
So maybe the VSTORE from MPE/iX 4.0 is what's messed up."