Traffic continued to climb on the HP 3000 newsgroup/mailing list in the past month. Although a strong technical core group was away from their desks for the week of the IPROF conference, a record 1,600-plus messages crossed during the short month of February. A massive message imploring readers to repent about their religious beliefs cluttered up the list, evidence that the free-for-all newsgroup access was working, perhaps too well. List members then complained in numerous messages about the original posting, and one even copied the whole message in his complaint. It prompted a note on etiquette from list administrator Joe Geiser which said in essence, when garbage pops up, let it float by. Just delete it and go on, because nobody can control a worldwide newsgroup. That’s actually some of the marvel of the Internet: no controls make for the most complete exchange of information.

HP’s IA-64 timeframe for 3000s

One of the most interesting messages on the newsgroup in February came in a single-message thread from Adager’s Ken Paul. HP had made a presentation at the Rocky Mountain User Group, and Paul tracked down some details on when users can expect to see IA-64 HP 3000s, as well as what HP plans to do about 16-bit 3000 code compatibility on 64-bit 3000s.

The answers came from Dave Snow, the product planning manager in the HP 3000 division. He said, “HP’s existing PA-RISC architecture has not run out of steam yet and will provide several generations of improved chips over the next two to four years (the PA-8500 through the PA-8900).” Snow then explained the transition from PA-RISC to IA-64:

“Our first IA-64 step is providing support for platforms that initially support next generation PA-RISC processor chips, but can be updated in the future to IA-64 processors via board replacements. CSY expects to begin to release these platforms in a PA-RISC mode in the 2001-2002 timeframe. We believe that PA-RISC chips through this timeframe will meet our customers’ performance and pricing needs. It also lets customers decide when to roll these new platforms to IA-64 since they will support both PA-RISC and IA-64.

“Our second step is to complete the port of MPE/iX to the IA-64 architecture. We are still planning this, but do not expect this to occur any earlier than 2002 (and perhaps later). The determining factors are both when customers will really need the added performance, and reduced pricing of IA-64 along with the reality of development schedules.”

Finally, Snow commented on whether that Classic-3000 code you’ve got from the 70s and 80s will run on IA-64 hardware without any changes; “We have an intent to allow Classic 3000 binaries to run on IA-64 platforms. This will use a combination of the Classic 3000 to PA-RISC emulation/Object Code Translation tools and the new PA-RISC to IA-64 dynamic translation tools. Although it is our intent to do this, our investigations have not completed and some obstacles may appear.”

Only consultants are outdated on 3000

The largest thread of the month fell into a category that’s described as “non-technical” in some places, since it didn’t relay specifics on coding or administration tips. A manager noted that he’d read a consultant’s report that had anointed the HP 3000 as “based on a 25-year old architecture with correspondingly dated performance.”

Like throwing a live wharf rat into a room full of alley cats, the statement led more than a score of posters to pounce. Comments ranged from attacks on consultants “Sounds like a segue into an attempt at selling an opposing machine,” and “Consultants almost always have an agenda, like almost everyone else. Their bad-mouthing one product or another may be nothing more than a part of their gentle tutelage to get their clients to move in some pre-determined direction,” to explanations of why the consultant was ill-informed: “Do the consultants mention Unix? It’s actually older than MPE. And, for hardware architectures: the Intel x86 architecture (Win 95, Win 98, and Win NT, except for Alpha-based) is older than the PA RISC architecture!”

One of our favorite comments came from Birket Foster, who pointed out that lots of 3000s work hard at a lot of big line companies (he mentioned Hertz, Southwest Airlines, Warner Brothers and Sony). Foster then added, “The consultants typically don’t have to live with the results of the reports — you do! The first failure of the server that leaves all the users waiting for it to come back online may well negate all the ‘savings’ from cheap hardware.”

Comments on pricing, Cognos-style

Careful reading of the 3000 list is in order to find what’s being discussed. A thread labeled “CSY Direct, February 1999” had a hot topic hidden inside: the high cost of using Cognos Powerhouse products, and what customers were forced to do to migrate. It was the second-longest thread of the month, producing few defenses of the pricing practices at Cognos.

Jon Backus of Beechglen Development, a strong HP 3000 resource, relayed a private message he’d received from a Cognos customer after last fall’s Cognos User Group meeting. Backus quoted the customer as saying: “At HP World…when asked about pricing and concerns that they would follow the trend to price the product too high for everyone but large corporations with deep pockets, they responded, “We are not a charity. We have to please our stockholders.”

This drew a comment from Tom Brandt, who noted, “Many companies, such as HP (for the most part) please their stockholders by pleasing their customers. Cognos has apparently chosen another strategy, which is their right. However, if their pricing strategy drives down sales and revenue as buyers exercise their right to go elsewhere, their stockholders will start asking just what in hell is going on.”

Outside of the fiscal discussion of the Cognos products, some customers in the thread traded notes on how they might go elsewhere. Ewart North reported, “A UK University had this problem with the “C” company many years ago. They then decided no more development in “Q...” etc., and promptly bought a runtime license for the software for the existing small machine. All new development was then done using other tools but the existing “Q..” code continued to run until eventually replaced.”

Richard Gambrell then noted a flaw in the idea, and a business opportunity: “That isn’t a bad idea, but for many shops it would require a painful conversion to “complied” [PowerHouse], but not nearly so painful as the alternative. If combined with some timeshare access to a [PowerHouse] development machine for the occasional necessary maintenance (when re-writing just will take too long), it might really be a winner.”

The subject seemed to stretch into talk about the Cognos impact on the growth of the HP 3000. One customer commented that upgrade costs for the software were stalling a hardware upgrade: “The software works, gets the job done, but I’m not too happy about being held hostage on our current hardware because of the cost of moving the “C” product to another CPU.”

Identifying sessions by IP address

Terry Simpkins asked how he could get “show sessions” information from a specific remote site with its own unique IP address. One answer came from John Krussel, who wrote: “This may be a little crude but it should do the trick. You can put in any part of the IP address and it shows all matching sessions.

PARM IPMASK
SETVAR IPLIST_LENGTH,LEN(‘!IPMASK’)
PURGE WORKFILE>$NULL
BUILD WORKFILE;REC=-78,1,F,ASCII;DISC=1000;MSG FILE WORKFILE=WORKFILE,OLD
LISTF CI.PUB.SYS,8>*WORKFILE
SETVAR IPLIST_NUMBER_OF_RECORDS,FINFO(“WORKFILE”,19) ECHO
WHILE IPLIST_NUMBER_OF_RECORDS > 0
INPUT IPLIST_RECORD_LINE;< WORKFILE
SETVAR IPLIST_IP_STRING,STR(‘!IPLIST_RECORD_LINE’,63,!IPLIST_LENGTH)
IF ‘!IPLIST_IP_STRING’ = ‘!IPMASK’
ECHO !IPLIST_RECORD_LINE
ENDIF
SETVAR IPLIST_NUMBER_OF_RECORDS,IPLIST_NUMBER_OF_RECORDS-1 ENDWHILE
DELETEVAR IPLIST_@

Jeff Kell, curator of the list, SIG-MPE chairman and the ever-present advocate of Posix on the 3000, noted a simpler way to do the IDs:

“I can’t resist but relate this back to my personal push for Posix smoothing. The above can be done in the shell with:

shell/ix> showip 123.145.167

where showip is a 1-liner script: callci “listfile ci.pub.sys,8”|grep $1

But with MPE CI-pipes it could also be just the

listfile ci.pub.sys,8|/bin/grep !ipmask