Additionally, take advantage of the variables that the MAIL program
recognizes:
MAILSMTPHOST
MAILFROM
MAILTO
MAILCC
MAILBCC
MAILSUBJECT
Using them will help shorten your run line.
Call-compatible subroutines, utilities help Unix behave like the MPE/iX environment
By Charles Finley
Let's look at methods to migrate applications from HP 3000s. One tool is to making subroutines and routines call-compatible, to let existing business logic work on other platforms.
Various utilities and subroutines can help a migrated application run on the target system. Examples include the automated data structure mapping of KSAM files to an indexed file system of the target computer and the export and import of KSAM data. This can be accomplished, for example, using either the Informix C-ISAM or bytedesign’s D-ISAM file system.
An MPE-compatible print queue manager which also operates on Unix platforms can enhance the limited capability of printer and print job control on Unix systems. This manager can provide an emulation of the MPE spooler in addition to functionality such as:
• Printer management by forms and paper stock
• Operator control and intervention
• Multiple and partial file printing
• Post-submission modification of print job characteristics
• Print file review and display
• Physical and virtual printer support
• Dynamic modification of printer characteristics
• Application Program Interface for direct printer control
• Automatic and transparent network operation
In addition, a batch job manager can provide functionality that is otherwise very limited on a Unix system. The batch job manager presents a centralized and more powerful point of control over the batch environment and gives capabilities very similar to those on MPE.
Porting of non-COBOL applications
This series has emphasized COBOL migration, since that is the primary development language on the HP e3000. It is also possible to port Fortran, Pascal, C, SPL, RPG, and BASIC third-generation languages, as well as fourth-generation languages Powerhouse and Speedware.
Fortran 77 and Pascal porting are dependent on the capabilities of the compilers and their runtime libraries on the target platform. Both Fortran and Pascal have some hidden dependencies on the MPE file system that must be addressed prior to porting. C/iX is perhaps the most portable language on the HP e3000.
There are two versions of BASIC on MPE: Business Basic and Basic/3000. They are both somewhat of a challenge to port because they are unique dialects and also have MPE file system and intrinsic dependencies built in. SPL is surprisingly portable thanks to the SPLASH compiler from Allegro Consultants (www.allegro.com). It is capable of changing SPL to C code. RPG should be translated to either C or COBOL in order to move it to another platform. Finally, products from the fourth-generation language vendors Cognos and Speedware are perhaps among the easiest applications to port. They run on a number of different platforms and their code is quite portable.
It is sometimes desirable to move away from some of the older languages to one that can be more easily enhanced or supported. Translators either exist or can be built to translate many of the third-generation languages to C, C++, Java, or even Visual Basic. Moreover, translators could potentially be built to translate some of the more obscure discontinued languages such as Business Report Writer to C or Java. There has also been some interest expressed in translating Powerhouse or Speedware code to Java or C++.
Optimizing terminal operation and screen management
The standard migration procedure for VPlus form files is to convert them with the same character-based look and feel. Migration of VPlus forms files provides a significant opportunity for application enhancement. The block-mode look and feel of VPlus is an area in which modernization to a GUI and its capabilities can give positive benefits. Several packages are available to accomplish this on the HP e3000. Migration to Unix, however, involves:
• Automated translation of the VPlus forms files to a format readable on the target platform.
• Preservation of the editing specifications for these forms.
• A management utility to maintain and enhance these migrated forms on the target platform.
• A call-compatible library of VPlus intrinsics.
Since the goal is to achieve as close to a 100-percent automated migration as possible, all possible editing specifications and editing constructs must be supported. The call-compatible library of intrinsics must support all VPlus functionality to avoid any manual changes to the COBOL code.
Terminal support on Unix is handled by the termcap and terminfo utilities. The termcap scheme was developed to support vi, the screen-oriented visual display editor (or very interesting editor) for Unix. The termcap file contains descriptions of the features supported by the terminal (how many lines and rows, whether the terminal supports backspace, etc.) and ways to make the terminal perform certain operations (clear the screen, move the cursor to a given location, etc.).
As more and more terminal types appeared, terminfo and its associated curses library were developed. Terminal descriptions in terminfo are essentially compiled versions of a textual description and can be located faster at run time. Again, terminfo performs typical operations (clear the screen, move the cursor) on a wide variety of terminals. The curses library provides functions that give added ability, such as setting raw mode and setting echo on and off.
The limitation of curses is that it was designed for character-based terminals, while today the trend is toward pixel-based graphics terminals supporting graphical user interfaces. Curses screen performance also has some limitations in terms of unnecessary screen clearing and cursor movement.
Screen management technology has been enhanced for character-based terminals to provide high levels of performance. This involves low-level routines to use escape sequences to control cursor positioning, highlighting, graphics and line drawing, and display of data. These routines are designed to maintain logical buffering of before and after images of the screen, as well as optimization of screen attributes, screen positioning, and data display and capture.
The implementation of a GUI solution for VPlus screens can involve the use of advanced terminal emulators running in a Windows environment as a front end to the character-based IO and screen control routines. With these emulators, it is possible to incorporate capabilities such as hypertext help and copy and paste. Modernization involves the use of window objects such as message boxes, dialogue boxes, text boxes, list boxes, scroll bars, tool bars, and image displays.
The Unix COBOL vendors have integrated GUI screen developers and managers into their compiler products as front ends. This can involve a fair amount of reengineering and time to produce a solution if there are a large number of VPlus forms files to migrate and no automated tool.
Finally, solutions now exist to migrate VPlus forms files automatically to advanced GUI management systems. These are graphical PC-based client-server application development systems. Migrated forms will run as true window clients on PCs under Microsoft Windows or on X terminals and workstations under OSF/Motif. These tools clearly will give the most advanced modernization capabilities and functionality available. With their development interfaces, text/input fields can be replaced with typical graphical user elements. The front end will automatically map the appropriate GUI objects to VPlus screen elements.
Conclusions
Tools are available to migrate existing MPE COBOL II applications to Unix or Windows, as well as more modern COBOL development environments. The use of these tools presents the best opportunity for a successful migration. The suggested strategy is to migrate using automated tools and utilities. This approach minimizes risk and development and deployment time and costs.
If there is a need to enhance the application, it is best to port the entire application using the existing methods of use. This provides for an immediate test environment for the newly changed system and allows for parallelism in testing and future development.
By Neil Armstrong
Our development environment at Robelle was quite unusual, in that we had a single job stream, which launched all of the necessary compiling and testing steps for each product. So if I wanted to compile and run the entire test suite for Suprtool, I just have to issue a single stream command, :stream jrelease.suprtool
If I wanted run the Qedit test suite, then I just have to stream the qedit jrelease with the command :stream jrelease.qedit
There’s a problem though: the individual job streams that test each product can only run single threaded. Each job must complete before the next one begins, so we have to keep the job limit perfect all the time. This also means that we couldn't run the Qedit and Suprtool test suites simultaneously.
This has always been a problem, as sometimes people or jobs alter the limit incorrectly, which means that multiple jobs would stream at the same time, causing test jobs to fail and results to be incorrect. This could mean losing a night’s “productive” testing, as the job streams are generally streamed in the early hours of the morning, after the nightly backup. So if you had just made a major change to a module of Suprtool, you wouldn’t know the impact of that change for another day.
Mike Shumko suggested that we try to implement jobq’s for our environment, to address this problem. Without knowing what jobq’s really were, I naturally volunteered for the job in the hope that I could alleviate this dependency we had on the job limit.
What I hoped jobq’s would do
Without even reading about jobq’s I thought they were a way to have job streams operate in specified queues, and thus be independent of jobs in other queues and the main job queue.
The Commands
To start using jobq’s immediately, you need only do two things:
- create the jobq with the newjobq command, and
- change the !job card in your job stream to use the jobq that you built.
So to create the jobq for the Suprtool job streams I used the newjobq command. I only wanted one job to run at at time in this jobq so I specified a limit of 1:
:newjobq suprtool;limit=1
Then I changed all of the job cards to have the “;jobq=suprtool” at the end:
!job jtest01,user.acct,suprtest;outclass=lp,3,1;inpri=7;jobq=suprtool
Since I have MPEX, I used the MPEX %qedit command to make a global change to all jobs:
%qedit [email protected]@,append “;jobq=suprtool” “!job”
This will open each file that qualifies, and append to the job card line the jobq specification. Voila, Suprtool now could run in its own jobq independently!
There are some other useful commands associated with jobq’s:
:listjobq JOBQ LIMIT EXEC TOTAL HPSYSJQ 3500 8 10 SUPRTOOL 1 0 0 QEDIT 1 0 0 RANDMISC 1 0 0
The purgejobq command (:purgejobq suprtool) will allow you to remove any jobq’s that you’ve defined.
Showjob ;jobq will show you the jobs with the jobq in which they are running in. A detail line from that output would look as follows:
:showjob ;jobq JOBNUM STATE IPRI JIN JLIST JOBQ INTRODUCED JOB NAME #J4567 EXEC 10 S LP SUPRTOOL WED 11:48A JTEST01,USER.ACCT
You can also alter the jobq that a job is running in with the altjob command, by typing :altjob #j4567;jobq=qedit
The Practice
Since it took me only a few commands to create and change all the jobq’s on our development system, I had everything changed to take advantage of the jobq’s in short order.
So I started testing running jobs associated with the Qedit and Suprtool test suites at the same time. I quickly discovered that each jobq requires that a slot be open in the global jobq in order for the job to run. I found an explanation in the newjobq command documentation:
“The global limit takes precedence over individual queue limits. That is, even if a jobqueue has a slot available, if the overall limit has been reached, jobs have to wait till one of the jobs finish or the global limit is increased. When a global slot becomes available, the next job is picked from among the eligible jobqueues (those which haven’t yet reached their individual limits).”
I hadn’t expected this; however, it merely meant that I needed to expand the job limit to some huge value. In retrospect, I should probably have created a separate jobq for our regular background jobs, like inetd or the apache webserver. That way I could create a small job to periodically check that queue, to ensure that all the required background jobs are “up,” and take appropriate action if a job has failed.
Maintenance
To my surprise, I found that after a “start norecovery” on this system, all my jobqs were missing. Again, the newjobq command help revealed what had happened:
“The job queues persist across reboots, provided a START RECOVERY is done. Any other system starts will cause the job queues to be deleted and they will have to be created again.This command is available in a session, job, or in BREAK. Pressing [Break] has no effect on this command. This command is not allowed in the SYSSTART file.”
We have a command called Startall, which is used to start all of the system jobs, so I put the newjobq commands in this command file to insure all of the jobq’s were built with the proper names and limits:
setvar hpmsgfence 2
newjobq suprtool;limit=1
newjobq randmisc;limit=1
newjobq qedit;limit=1
This way I am assured that the jobq’s always exist when we restart the system.
Problems
Personally, I have found no unexplainable problems with the new jobq feature; however recent traffic on the 3000-L mailing list did showcase this query from David Knispel:
“We ran out of disk space over the weekend. Now my JOBQs are screwed up. When I do LISTJOBQ for HPSYSJQ, it shows 6 EXEC but only a limit of 3 and total of 3. When I do a SHOWJOB, only 3 jobs show for this queue. I’m having the same problem with other queues also. Any way to fix this without bouncing the system?”
To which Richard Bayly from HP responded:
“The patch you are after is: MPELXC2B - 6.5; MPELXC2D - 7.0; MPELXC2C - 6.0 but superseded by MPELXL7A.”
Are jobq’s for you?
In conclusion, I do find the new jobq feature quite valuable, as it gives me a tool to break up my jobq’s logically if not physically. I am able to manage some groups of jobs more easily and have more jobs working concurrently, getting more out of my HP e3000. If you have problems with concurrency, or having jobs run when they shouldn’t, then perhaps implementing jobq’s is the way to go.
Included software, tested job offers some disaster recovery
By Wirt Atmar
We have been using one of our HP 3000 Series 918s to shadow our primary development 918, using the MPE-to-MPE FTP capabilities of MPE. The purpose of doing this wasn’t to eliminate tape backups, but rather to ensure that if we lost one machine — and all of the recent backup tapes that tend to lie around it — we’d have another duplicate machine, completely ready to run at a moment’s notice in a completely separate building, far enough away where the possibility of both being destroyed by fire was highly unlikely.
Firstly, the job is extremely simple — and of course free. Indeed, there’s nothing complicated about any of it, nor are there any costs other than a few minutes’ time. The job is constructed as shown below, streaming itself to run at 3 AM every morning:
!job ftpxfer,user1.acct1,group1
!ftp 192.168.1.1
user user1.acct1,group1 psw,psw
prompt
mget *
quit
!set stdlist=delete
!eoj
!job ftpxfer,user2.acct2,group2
!ftp 192.168.1.1
user user2.acct2,group2 psw,psw
prompt
mget *
quit
!set stdlist=delete
!eoj
!job ftpxfer,user3.acct3,group3
!ftp 192.168.1.1
user user3.acct3,group3 psw,psw
prompt
mget *
quit
!set stdlist=delete
!eoj
!job ftpxfer,user4.acct4,group4
!ftp 192.168.1.1
user user4.acct4,group4 psw,psw
prompt
mget *
quit
!set stdlist=delete
!eoj
.
.
.
!job ftpxfer,manager.sys,manager
!pause 90
!stream ftpjob.manager.sys;at=03:00
!set stdlist=delete
!eoj
The primary development machine is running MPE/iX 5.5 PowerPatch 7, and the shadower running MPE/iX 5.5 PowerPatch 4. The primary machine has only 4Gb of disk; the shadower has 8Gb. There is a 10Mbit LAN between the two machines.
The backup of the primary machine onto a DDS-2 drive takes about 45 minutes to make a full CSLT/store copy of all files (approximately. 3.5Gb), using hardware compression, but there’s no need for us to transfer all of the user files from one machine to the other on a regular basis. The seven jobs represented in the jobfile above transfer only the regularly active development and corporate accounts and their databases. These seven jobs represent about 2.5Gb worth of material.
My initial experiments indicated that transfers across the LAN were just about as fast as DDS/compression on backups. That still seems to be true. A complete CSLT/store backup of the primary takes about 45 minutes; the transfer of about half that material across the LAN takes 23 minutes.
There is a caveat in that 23-minute number, however. That transfer rate occurs when we allow all seven FTP jobs to run in parallel. A 10Mbit LAN is the equivalent of six T1 lines. If the seven jobs all run in parallel, we seem to consume about 60 percent of the LAN’s bandwidth — leaving the equivalent of two T1s available for all other internal traffic, and that seems more than enough. While this intense internal traffic is flowing, normal terminal communications or Web page draws seem unaffected.
However, with all seven jobs running simultaneously, the disks on both machines are being exercised to their maximums, to the point that I consider it excessive wear on the disks. They’re really clattering. Thus, we now set the job limit to just one above the background jobs, so that the seven jobs execute in single file; however, doing this increases the transfer time from 23 minutes to 64 minutes.
A good portion of a single-file’s FTP bandwidth (dead-time) is consumed in just the negotiation between the two machines. Once the file transfer begins flowing, the data moves at a good speed. When all seven jobs are running simultaneously, whatever dead time on the LAN is left over by one job is filled in by one or several of the others. Nevertheless, the excess wear on the disks doesn’t seem worth the additional 40 minutes you save, especially at three o’clock in the morning.
I’ve tried multiple FTP syntaxes, but the one used in the job above seems by far to be the most certain. However, it only transfers MPE-named files, but that’s all we currently use, so it’s not a problem for us. IMAGE databases, KSAM files, and all “regular” files transfer with no problem. Symbolic links transfer, but seem to lose their “symbolicness” in the process. HFS files don’t transfer at all, using this syntax and the MPE version we’re currently on.
I’m also planning on upgrading both machines to 6.5. Once that’s done, we’ll be able to use Jeff Vance’s new Store-to-Disk option. If my understanding is correct, the great advantage of doing this is that we’ll be able to get all of the advantages of using the STORE command and assemble the store material into one file that can be FTPed between the two machines, and then RESTORED on the shadow.
However, I’ve never been particularly fond of partial backups, but in order to make the STD option work well, that’s what we’ll have to do. The FTP jobs above transfer every file in the specified groups and accounts, regardless of the recency of their modifications.
One final note: FTPing 2.5Gb of files between the two machines does not have the same impact on users as does a STORE-like backup does, where all of the files are marked for some time for exclusive access. Only one file at a time is locked as the MGET process walks through the file list. That attribute can obviously be either good or bad, depending on individual circumstances. Nonetheless, using the simple job that I’ve outlined above, that is the current behavior.
Overall, I’m quite tickled as to how it’s working. If we should lose the primary machine, we are (nearly) guaranteed of having a perfect replicate machine, available and ready to go, in building three.
State-of-the-art security is possible using tokens, agents and RSA secure servers with MPE/iX
By Andreas Schmidt
This article describes a way to build a security barrier around your HP e3000. It is based on material offered by Security Dynamics (www.rsasecurity.com), and on my own HP 3000 experiences in a project to roll out a Two-Factor Token Authentication to all platforms for a big company in the chemical industry, one which chose NT and HP 3000 systems as pilots.
Background
Today it’s a risk to trust only static passwords. Some studies have shown that approximately 60 percent of big companies have detected a security violation in the last two years, and more than 80 percent still use static passwords, especially to connect to the network. So it’s a good approach not only to rely on static MPE security, or third-party security solution passwords, but also to introduce a Two-Factor Token Authentication.
Two-Factor Token Authentication
Authentication is the process to verify the identity of users. On the Internet, cookies can provide automatic authentication for user names and passwords having been registered at a site, especially with SSL (Secure Socket Layer) encryption for things like credit card information.
On intranets, the authentication could happen with simple passwords, along with tokens or smart cards, or with biometrics that utilize the individual’s physical characteristics such as finger-print or retina.
Because passwords can become cracked or sniffed on the WAN/LAN, all methods using static authentication are not secure. The Two-Factor Authentication requires two factors before an user will gain access to a network or system:
• The person needs to have something: a token which produces a tokencode. Such a tokencode will change about every minute.
• The person has to know a PIN. This Personal Identification Number is unique and only valid for the physical token the person possess.
If an individual needs access to a server or a network component, they must log on to an Authentication Server or Agent and enter the PIN and the actual tokencode. As soon as the token has been recognized by the logon name and the Authentication Server has accepted the code combination, it cannot be used a second time. A sniffer has no chance to use the same combination of PIN plus tokencode.
The vendors of such authentication environments (server, agents, and tokens) ensure that each authentication token is unique and it is impossible to predict the value of a future tokencode by recording prior tokencodes. Thus when a correct tokencode is supplied, there is a high degree of certainty that the person is the valid user in possession of the physical authentication token and the remembered PIN.
One environment provider is RSA Security Dynamics, offering a SecurID Server, Agent, and Tokens.The heart is the RSA ACE/Server, the authentication engine on the network. It runs on different Unix flavors and Windows NT or 2000. This server is the management component of the RSA SecurID product family, used to verify authentication requests and to administer policies for enterprise networks.
All network components which should become authenticated must be defined on this server and become RSA ACE/Agents. When a person attempts to access a protected system, this software agent initiates an RSA ACE/Server authentication session instead of a basic password session. (This is true for Unix and NT, but not in this case for MPE, as we will see later.)
The user is required to enter the user name and instead of a static password, the current tokencode from the authentication device (the token) plus the PIN. The agent software hashes the information supplied by the user with additional data known only by the protected device (agent platform). It then transmits portions of the hashed information to the RSA ACE/Server, which approves access when the information is validated. The user is granted access, and this is logged onto the Server as well.
The last component is the physical device the user possesses, the authenticator or token. Many forms are offered. The one most used is a key fob: a device with a built-in chip and an LCD window to display the tokencode, small enough to be attached to a key ring. Others are credit card look-alike devices. The latest edition is software for palmtops generating the actual tokencode. Using any one of these devices, a person must possess them to authenticate, employing the same patented algorithm for encrypting and hashing the tokencode.
Authentication Advantages
Having installed such a system on all devices before access for an individual is granted, the security of a company’s network will be drastically improved. The four primary benefits are:
• Enterprise Authentication: Only those persons can access the devices when they are authorized to possess and use a token and PIN.
• Access Control: This is essential to protect against outsider attacks or malicious employees.
• Evasion of Attack: Hackers will try to unexpectedly gain access to a network. The Server identifies threat conditions, which are reported to the logs and alert the system manager.
• User Accountability: Damage may be done using an employee’s password without the knowledge of that employee. However, by logging the authentication process which requires PIN and tokencode, it provides more assurance of employee involvement in any unauthorized activities. The knowledge of this and of the comprehensive logging helps employees recognize their accountability for information security, so that their behavior is more secure.
The HP e3000 Agent Solution
The chemical company, which CSC is providing with IT services, decided to roll out Two-Factor Token Authentication over all platforms within one year. NT and MPE were selected as pilots: NT because of the large number of servers running that environment; and MPE because of the thinking that this platform might be different from all others and more difficult to implement. However, the company also recognized the importance of running its 3000-based Order Fulfillment Process with a lot of different outside partners.
RSA’s first attempt to develop an agent for MPE was very simple: A token had to become configured for a combination of MPE-USER-ID.MPE ACCOUNT. This combination could not be reused on another token. It was not possible to use wildcards or to add SESSION-IDs or MPE-GROUP to have a complete logon string. Because of the MPE characteristic to share logons (on all levels of capabilities) this version of the agent was not what we were looking for. (More drastically: This agent could not function for the MPE platform).
The second attempt was much better: everything was changed to the chemical company’s already-existing Security/3000 setup. Now Security/3000 invokes the RSA Agent to contact the RSA Server. It transmits either the SESSION-ID or the MPE-USER-ID as the name of the token. If the token is known and allowed to access the HP 3000, the agent asks the user for the current tokencode plus PIN.
This agent also functions without Security/3000 by adding some lines to the System’s Logon UDC. This drops some additional functions in combination with Security/3000, like verifying a user profile in any case (SESSION-ID,MPE-USER-ID.MPE-ACCOUNT is defined as allowed logon in Security/3000, all others will be refused before starting anything), but it will work.
One thing is essential: The RSA Agent for MPE does not replace the MPE password process like it does for Unix or NT! It is activated first when the HELLO string has been entered and the MPE password hurdle has been passed (Account, User, and/or Group Password) and (as an option) the basic check within Security/3000 for profile existence is passed. Now any other logon UDC functions are invoked, and this activates the RSA Agent.
Having Security/3000 in place is a good idea to replace the session passwords (if any) by supplying the tokencode.
Not having session names in place, the RSA Agent will add an additional password. I do not recommend eliminating the MPE password — it’s still a fence around your system and is needed for batch security (depending on the streaming security you have in place).
Having activated the RSA Agent, a logon sequence will look like Figure 1. The setup within Security/3000’s SECURCON.DATA.VESOFT file is shown in Figure 2.
Figure 1
SYSTEMA:hello paul,manager.sys ENTER USER (MANAGER) PASSWORD: xxxxxxxxxxx HP3000 Release: C.55.00 User Version: C.55.00 FRI, JUN 9, 2000, 7:34 PM MPE/iX HP31900 C.05.08 Copyright Hewlett-Packard 1987. All rights reserved. ************************************************************* This is a private computer facility. Access to it for any reason must be specifically authorized. Unauthorized access to this computer facility will expose you to criminal and/or civil proceedings. All information contained in this computer system, including messages, is the property of the company. The company reserves the right to access and disclose all information sent through or stored in this computer for any purpose. ************************************************************ ******************************************** You are at: Bad Homburg SYSTEMA Series 960 ******************************************** Enter PASSCODE: PASSCODE Accepted Welcome! You are now signed on. END OF PROGRAM SYSTEMA:
Figure 2
(* Setup for the RSA ACE SecurID Agent on HP3000 *) (* ============================================= *) (* Usersets if needed and wanted for later use *) $DEFINE-USERSET MPESEC & @[email protected] (* SEC/3000 Session Names to identify individuals *) (* 1st line: all Online Logons *) (* 2nd line: Accounts secured with MPE Methode *) (* 3rd line: general Exceptions *) (* 4th line: AM user of MPE Methode (2nd Userset) *) $FORBID "MPE('/var/ace/sdshell ![DWNS(HPJOBNAME)]') <> 0" "SDI ACE Failed" @.@&ONLINE-LDEV=20-LDEV=21-& !MPESEC-& @.TELESUP-SYSTEMB,XEALRMON.XFER-M,@.XFER-S,@.XFER !MPESEC&ONLINE&CAP=AM (* MPE UserIDs to identify individuals *) $FORBID "MPE('/var/ace/sdshell ![DWNS(HPUSER)]') <> 0" "SDI ACE Failed" !MPESEC&ONLINE&CAP<>AM (* Needed for both Methods *) (* Exception Line: general Exceptions *) $FORBID "IVAR(';SECURID',1) = 1" "Invalid SecurID PASSCODE" @.@&ONLINE-LDEV=20-LDEV=21-& @.TELESUP-SYSTEMB,XEALRMON.XEXFER-M,@.XFER-S,@.XFER
Here are our detailed notes on the Security/3000 configuration.
$DEFINE-USERSET: If in your current setup you identify individuals by their session name or their MPE-USER-ID, it’s a good idea to define a userset for later use.
$FORBID: in this section for all accounts, where the session name is used to identify an individual, the sessionname is downshifted (convention in defining the token on the ACE Server), and the program /var/ace/sdshell, the RSA MPE agent, is executed. If the program’s error code is not equal to 0 the logon is rejected. This will happen if the tokenname the ACE Server received is not allowed to get access to this HP 3000 Server, or is not known at all.
This $FORBID process must be executed for all sessions (but not for batch logons) except console and remote console. (If the network is down, the agent cannot authenticate with the ACE Server) The exception is for all accounts identifying the individual by the MPE-USER-ID, and some special accounts like TELESUP or EDI accounts (here:XFER).
The second userset within this $FORBID statement includes all Account Managers using the MPE-USER-ID as identifier. Here it’s assumed that individuals share one AM logon like MANAGER or MGR and are distinguishable by the SESSION-ID. The next $FORBID defines the same setup for accounts where the MPE-USER-ID is used to identify an individual. The MPE-USER-ID is used for the ACE Server Authentication process. This is needed for all session logons in these accounts except the AM logons.
The third $FORBID checks a variable named SECURID. The ACE Agent sets this variable. If the tokenname is known and allowed for this server, but the code transmitted is wrong (PIN and current tokencode for the token identified by !HPJOBNAME or !HPUSER), the logon is rejected with the error message “Invalid SecurID PASSCODE” (variable SECURID is 1). Otherwise, the logon is accepted (and logged as successful on the ACE Server like all unsuccessful attempts as well), and the individual gains access to the HP 3000. This check must take place for all sessions except those on the two consoles and the general exceptions.
This setup is proven and stable. Because of Security/3000’s flexibility, it’s almost possible to build up any other existing security concept, as long as the current setup already distinguishes between individuals. If this is not the case for any reason, it’s obvious that this must be changed first because of the characteristic of all authentication processes.
A similar setup is possible within a System’s Logon UDC if Security/3000 is not in place. It will become more complicated (some IF clauses, etc.) and will require more effort in changing the setup. But it is possible because of the simple logic of the ACE Agent and ACE Server:
Do I know the name of the token transmitted ?
NO: “SDI ACE failed.”
Is this token allowed for that network component ?
NO: “SDI ACE failed.”
YES: “Enter PASSCODE:”
Is the right PIN and tokencode transmitted ?
NO: “Invalid SecurID PASSCODE.”
YES: “PASSCODE accepted”
Access granted!
What if the ACE Server and/or the network is not available for any reason, so that no authentication could take place? In this case, a system manager must use the specific parameter to bypass the system’s logon UDCs and disable this authentication security. Because of this, it’s highly recommended to switch off the ENFORCE LOGON UDCS setup in SYSGEN (enforcelogonudcs OFF), but to have a hard-to-guess password on all MPE-USER-IDs with SM (only one, I hope).
Also, it’s obvious that in this case the only password remains the MPE-USER-ID password (and/or ACCOUNT password). It’s probably a good idea to prepare a new SECURCON.DATA.VESOFT configuration file in advance, which will be needed in this case.
For our chemical customer it’s not probable that this will happen: A second ACE server is in place with an automatic switchover if the first is not available, and the network topology is redundant. Nevertheless, for smaller companies this may become an issue. It’s not expected that RSA will port its ACE Server software to MPE to avoid such problems, if only MPE is in use.
Rollout to an HP e3000 platform
Assuming that your company wants to have such an authentication for MPE, it’s important to plan this in great detail. There are some dependencies which need to be observed.
Depending on whether you want to keep existing naming conventions to distinguish between individuals (a convention like six letters of surname plus first letter of first name) which is used for SESSION-IDs or MPE-USER IDs, or if you want to create a new one for naming the tokens (like randomized names out of a name generator), you need to make changes more or less within the HP 3000 security setup. Remember, such an authentication may be used on a company-wide level serving all platforms in place (Mainframe, Midrange, PC, Network components) and that one individual possesses only one token for all platforms. This token name is unique and usable on all platforms.
In any case, you’ll need a complete inventory of individuals accessing the HP 3000, including all their individual logons. This list could be created out of Security/3000 itself. It needs to be consolidated and expanded with the individual’s token name. If a new naming convention will be used, all MPE logon profiles (SESSION-ID,MPE-USER-ID.MPE-ACCOUNT) must be changed accordingly.
It may also be the case that the existing logon characteristics (!HPUSER, !HPJOBNAME) are used within application configuration and setup. In this case this must be changed in parallel. And first the Authentication Process on MPE system level itself must be activated.
Lastly, everybody will cry if they used automatic logon scripts: They no longer work! Whether such scripts were allowed in the past (containing passwords) depends on your setup. If so, you have to convince the users that this behavior was never secure. If not, you can be sure that nobody will continue to use such scripts — at least no longer to supply the tokencode (but probably the PIN, which is not recommended)!
You may work on an application-per-application basis, but this will negatively affect individuals who work in more that one application. (For example, in Application A the SecurID token is already needed, but in Application B it still uses the old method.)
Don’t underestimate this effort! It’s very easy to understand the process, but it is hard to roll this out in a living production environment, possibly serving many different user locations. It’s possible, but it needs a dedicated and experienced project management team to deal with all the different groups involved: techies, network people, security admin people, HR, the token vendor, application support, user help desks, user supervisors, end-users and more. People management may become more important than technology management!
Summary
Two-Factor Token Authentication is a state-of-the-art process to avoid static passwords. RSA Security Dynamics provides an MPE Agent for this purpose which worked perfectly for us with Security/3000, but also with basic MPE security. The technical approach is not simple, but manageable. The main problems may arise during the rollout because of human behavior in keeping known procedures and avoiding changes, especially for security. But to stay on HP 3000 into the future, the effort is worth it, especially for better security.
Back in 2005, November was still a month bleeding in the red ink of memory. You can use shorthand and say "November 2001." Or you can say the day that HP's 3000 music died. The date of November 14, 2001 still marks the start of the post-HP era for MPE/iX as well as the 3000 hardware HP sold. It took another two years to stop selling the PA-RISC servers the company had just revamped with new models months before the exit-the-market announcement. PCI-based N-Class and A-Class, the market hardly knew ye before you were branded as legacy technology.
For a few years, I stopped telling this story on the anniversary, but in 2005 I cut a podcast about the history of this enterprise misstep. HP lost its faith in 2001 but the customers hadn't lost theirs and the system did not lose its life. Not after November 14 and even not today. Not a single server has been manufactured since late 2003, and even that lack of new iron hasn't killed MPE/iX. The Stromasys emulator Charon will keep the OS running in production even beyond the January 2028 date MPE/iX is supposed to stop keeping accurate dates.
Red Letter Days were so coined because they appeared on church calendars in red. They marked the dates set aside for saints. In 1549 the first Book of Common Prayer included a calendar with holy days marked in red ink; for example, Annunciation (Lady Day), 25th March. These were high holy days and holidays. The HP 3000 came into HP's product line during a November in 1972. November is a Happening read the banners in the HP Data Systems Division. No day of that month was specified, but you might imagine it was November 14, 1972. That was a Tuesday, while the 2001 date fell on a Wednesday. A total of 1,508 weeks of HP faith.
Something important happened in that other November of 29 years later. Hewlett-Packard sent its customers into independent mode. Those who remained faithful have had a day to mark each year, logging the number of years they've created their own future. It's 20 and counting as of this year.
He saw nothing, nothing
From October, 2001
Just weeks before HP started to brief its vendor partners about the 3000 futures cut-off, customers asked about it. In a public forum of a webinar, the 3000's vendor relations manager, its product planning manager, as well as its customer spokesman said they knew nothing about the 3000 leaving HP's fold.
The questions surfaced in an October, 2001 broadcast. On November 14, the company released public statements. I was briefed on Nov. 9, and vendors leaked their notifications during the first week of November.
If nobody on that October Webinar knew about ending the 3000 business line, HP was certainly keeping its decision held as closely as a riverboat gambler's hand. Or perhaps a certain German sergeant on TV was the template for the answers.
After a few minutes of questions about support for disk mirroring, boot drives greater than 4Gb and other chestnuts often asked, HP began to address a number of questions about the impact of the merger on the 3000 product line. Customers asked about a published report in Network World magazine, wondering if the system was likely to survive the merger.
“I sure wish I knew the answer to that,” said Kriss Rant, CSY’s manager in charge of developer relations and a division veteran. “I don’t know any more than you do.”
“Whenever there’s a large merger like this, the press has a field day,” host Stachnik added, “speculating on exactly what it’s going to mean. I can tell you that nobody in the 3000 business has received any marching orders from Compaq or upper HP management that OpenVMS, MPE or any other operating system is supposed to survive or not. There’s been no decisions made on that. Don’t give too much credence to it.”
Platform Planning Manager Dave Snow noted that HP did a “total roll of our product line in February, and we’re delivering multiple processor support. I certainly think you can expect there will be support of MPE for many years to come.”
Other questions on the merger got a broad brush answer from Stachnik. “The correct answer at this point is, ‘We really don’t know,’ ” he said. “There are lots of open questions about whether that merger is even going to happen. The SEC needs to look at it, and there’s been all sorts of speculation in the press.
"How it’s going to impact the 3000 — we simply don’t know at this point. We’ve gotten no marching orders one way or the other, and I’m not anticipating we’re getting them anytime in the near future.”
Recommendation includes five-year support guarantee, two more years of new sales
Hewlett-Packard proposed a new chapter for its oldest business computer on November 14, one that advises customers to transition away from the HP e3000 over the next five years. The announcement from 3000 division general manager Winston Prather and marketing director Christine Martino included news of a confirmed date for end of HP support and a halt of new sales in a little less than two years’ time.
HP said it will stop selling new systems on Oct. 31, 2003, ending its distribution of more than three decades of the most reliable business computer in the HP lineup. The company’s contract with North American distributor Client Systems - a company doing business exclusively in the HP 3000 line - has been extended for two more years. The computers will clearly be in service for quite awhile after that date, however, as HP is promising full customer support for the systems through the end of 2006.
“This really is about concluding that it’s time to advise customers of the long-term trend,” said Prather. “It has nothing to do with cost savings or downsizing. This is an advisory type of announcement.”
HP briefed the NewsWire several days in advance of the worldwide announcement to the general press. The announcement included news that HP will provide free unlimited HP-UX licenses for all customers who own the new A-Class and N-Class servers, and transform those systems into equivalent HP 9000 computers. And in the meantime, HP intends to continue selling the system, and upgrading it with projects that have already been announced. It will present papers and communicate with customers at Interex conferences during 2002, and continue its Webcast series with a January broadcast on transition.
“From a CSY perspective and a support perspective, it’s business as usual for the next two years,” Martino said. “It’s time for customers start their planning to move to a platform that will serve their businesses better in the future. HP recommends that customers begin transitioning off the HP 3000 to alternate HP platforms.” HP will be releasing an overview White Paper in the first of a series, “HP e3000 Migration Considerations,” from its Web site. More detailed white papers on transitions to HP-UX will be released in the future.
There’s even a silver lining in the announcement for some HP 3000 customers. The end of support date for MPE/iX 6.0 has been extended by six months to October, 2002, making it easier for companies using the HP 3000 9x7 systems to remain on the platform. HP stops support of that hardware in April, but software support for the systems has been extended as part of the transition. Series 939 and 959 system support has been extended to December of 2003.
The company is also notifying all of its customers on current support contracts by letter. Prather said the division started to brief its top-tier customers on November 9. “They were not surprised, and they really appreciated HP being able to tell them what we see as the future role of the platform,” he said. “At the same time they really love the platform, so there was some sadness in transitioning from the platform.” Prather said these top-tier customers “already have a multi-OS strategy, so they’ve been evolving their applications over time. It is a stake in the ground, but the CIOs I talked to were appreciative of hearing what the future holds.”
No layoffs or downsizing in the CSY division is being planned, nor are any additional technical development operations going to be shifted away from the California 3000 labs. The product has often been pointed to as a profitable part of the HP lineup, but CSY officials said profits didn’t enter into the decision to stop selling the systems two years from now.
The end of the CSY division seemed even fuzzier, despite its announcement of a date for the end of support. “When we get to the point where HP doesn’t need a CSY organization to support the 3000 customers, then we wouldn’t have a division,” Prather said. “We will staff the division to make sure we have whatever resources we need to meet our commitments, and we are committed through December, 2006. We will ensure from both a CSY perspective as well as our support organization and field support we have the staff we need.”
HP will also be helping continue the transition after the end of the support period. “After that, [CSY] employees will transfer to other businesses to continue the transition as well,” Prather said. HP hopes to capture HP 3000 business in its NetServer and HP-UX platforms, but recognizes that competitors will be targeting the customer base. “We will need to earn their business,” Prather said.
HP’s plans on database migration were less specific at the announcement. Prather mentioned HP Eloquence, a revision of the HP IMAGE database that’s been running on HP 9000 servers for more than a year, as an option for companies migrating their home-grown systems. Other customers should look to their application providers, Prather said, for advice and support on how to transition away from the platform. Martino and Prather said a “decline in the ecosystem” surrounding the 3000 prompted the move - and denied that the impending HP-Compaq merger had any effect on the decision to write HP’s last chapter in the 3000 community. CSY made the decision sometime after the last HP World conference, according to Prather. The general manager, who has spent his entire career managing technical and business advances for the platform, said he was saddened by his decision.
“I’m sad, because I’ve been involved in this forever,” he said. “But I feel confident we’re doing the right thing for customers. I can stand up in front of any customer and explain why we’re doing this,” Prather said. “It’s a recognition in general that we’re not going to be able to reverse the trends.” Martino said sales have been declining for the product, although the month of October, HP’s close of its fiscal year, was a record one in North America. She added that the division’s staff has been “going through stages of grief” over the decision. But despite CSY’s melancholy approach to the news, the division remains well in place trying to sell new 3000s to the community over the next 24 months. The immediate future holds no changes for companies relying on the system, HP said.
“We picked these dates that we’ll guarantee availability for customers, and we don’t have any plans to review those dates. We knew that the next question customers would ask is, ‘How long will this be a safe environment?’ That’s why we gave them these dates.” As proof of the safety, HP plans to continue with all of its announced enhancements for the system except moving it to the IA-64 platform. The ongoing PA-8700 project, which is delivering a chip that is expected improve performance another 30 percent over current top ends, will be delivered as promised. HP will also release new A-Class systems during the next two years, offering a performance bump for those low-end servers as well.
HP will also be releasing MPE/iX 7.5 next year, although the future releases of the operating system will be limited to Express updates beyond that, according to Prather. Native Fiber Channel will still be released, along with support for the new Ultrium tape systems and va7400 disk arrays. Possibilities of selling the business to another company and helping to create an Open Source movement to extend MPE’s life still may hold some potential for Prather. “We have a very diverse set of customers,” he said, “and in briefing our top-tier accounts, this doesn’t come up. I don’t believe doing any of that [Open Source] will change any of our recommendations for customers. I feel strongly that the ecosystem is starting to erode, and that right thing to do is move to another platform, hopefully an HP platform.”
But “having said all that, we will try to understand how we can help the evolution of MPE. If it is valuable to customers, we want to understand how we can help them.” Selling the source code for the operating system, as HP once did for the earlier generation of MPE, is also a possibility, “but I want to understand to who, and for what purpose.”
In the meantime, HP expects that a lively market is about to emerge around migration consulting and tools for the platform. “I have a feeling the third-party community will spring to life quickly to develop tools to help with the migration. I think a number of the partners in the ecosystem will look at this as an opportunity. This could bring the ecosystem to life for the transition period.”
When a string of parties around the world commemorated the HP 3000 on Oct. 31, 2003, it might be easy to think the system was experiencing some kind of death. HP, for one, was pressing the system into continued use after that date, as the company continued its role as one of the biggest users of a system that’s was coming off its price list. Chris Gauthier, who operated the GCG Data training and documentation service behind the Terix HP 3000 support operations, drew on his internal experience with HP’s datacenter configurations to report that the 3000 remained responsible for a sizable share of HP’s business operations on the day it came off the list.
“The last moment to enter an order for a new HP e3000 computer will be at the end of this month,” Gauthier wrote in 2003, “Halloween, 11:59 PM PST. On top of that, in true — but ironic — Halloween fashion, several critical HP-internal e3000 systems will be assigned the duty of committing their own product families' “obsolescent suicide” at midnight that night. These mission-critical 3000s will dutifully carry out their product removal orders, as they always have before — because it's what they've been told to do, with no hard feelings and absolutely no remorse.
“Then, at 12:00 a.m. on November 1, several other critical HP internal systems will immediately start to reflect the e3000 product removal from the HP Corporate Price List (HP-CPL). It's kind of funny in a dark-humor way, because all of these HP mission-critical systems are either themselves HP 3000s, or have a critical link with one or more mission-critical HP 3000's somewhere else in the world.
“For example: WWOMS is the HP internal order management systems around the globe. These HP 3000 systems are located in specific geographic locations around the globe to gather new regional sales orders. The global WWOMS systems will take their last 3000 orders, up to 12:00 their local time, and send those final purchases to "HEART" at HP Corporate in Palo Alto (see below). Very few HP order processing humans actually touch WWOMS directly anymore, because most of them use front-end GUIs written for Windows and Unix.
“HEART is the HP Corporate Accounts Receivable and report-generating system. It is made up of several 3000s and 9000s in Palo Alto. These systems will see the last 3000 orders generate revenue for HP. HEART will also generate the last end of month/year reports that reflect new HP 3000 sales, and allow HP to publish their end of year results to the world. PATSY and IQS are the HP parts availability systems and quoting systems respectively. Now all HP 3000 parts will be reflected in these databases with “obsolete” and “end of support” dates.
"CONRAD is the HP configuration and manufacturing rules engine for the factory. All shop-floor rules for making new 3000 systems will cease to be updated and become archive. SPORTS / IBS is the support contract management and installed-base systems respectively. As with PATSY, IQS and CONRAD, they will immediately reflect obsolescence and end-of support dates for the whole HP 3000 product line. Okay, enough now. There are many more systems, but you get the point.”
Gauthier noted that getting together on the evening of Oct. 31 to toast the 3000 in 2003 was an appropriate celebration. ”Mind you, this is not a wake,” he said at the time. “It’s definitely a celebration: a celebration of all the great friends and souls that help make — and will continue to make — the 3000 and The HP Way live on, long after HP ends up vacating both these “now obsolete” spaces."
By Dave Lo
Perl is an interpreted language that is the brainchild of Larry Wall. He continues to develop and guide the language, which, through the help of the net community, is available on virtually every computer platform, from Apple’s Macintosh to MPE.
Perl, officially known as either Practical Extraction and Reporting Language or Pathologically Eclectic Rubbish Lister, is a popular language for implementing web page CGI scripts, processing string data, even system administration. The official Perl web site is www.perl.com.
However, Perl is much more than a sometimes-odd-looking web scripting language. It has enough power to be a full programming language. One glance at some of the O’Reilly Perl books will testify to that (Perl for Bioinformatics, Perl for System Administration, Perl for Website Management).
If you think of perl as a shell-like programming language that evolved from quick-and-dirty handling of text, lists, associate arrays, and regular expressions, then you’re already thinking Perl. Let’s dive in!
Scalar variables
0 # Perl has no line numbers, they’re here for reference only
1 $num = 123;
2 $str = “abc”;
3 print “number=$num string=$abc”;
Line 0 is a single-line Perl comment, which are similar to Unix shell comments. There are no multi-line comments.
Perl is not a strictly typed language, so a variable can hold either numeric or string values. Also, no declarations of variables are needed before they are used. Line 1 and 2 assign a number and a string. These type of variables are known as scalar variables (they hold a single primitive value), and their names are prefixed by a $ sign. One characteristic of Perl is that all variables names have a prefix character such as $. This may seem strange, but not when you think of similarities to Unix shell scripts.
List variables
1 @list = (12.3, “abc”, 4..6);
2 foreach $i (@list) {
3 print “$i\n”;
4 }
5 $count = @list;
6 print “There are $count items\n”;
Another fundamental variable type in Perl is List. Line 1 shows the assignment of a list variable, whose name is prefixed with a @ sign. A list variable is like a 1-dimensional array. But unlike strictly typed languages, a list in Perl can contain mixed types of data. Here, the list contains 5 values: the number 12.3, the string “abc”, and numbers 4, 5, and 6.
Lines 4-6 are a typical way of looping through all the items in a list, using the foreach construct. In line 5, notice that literal strings in double quotes can contain variables that are dereferenced.
Line 7 may initially look like an error (assigning a list variable to scalar variable), but it is a common occurrence in Perl and shows an important concept: context. Think of context as fancy type-conversion. Here, because the left-hand-side of the assignment is a scalar variable, the right-hand-side must also be scalar. So the list variable is “evaluated in a scalar context”, which does the convenient thing of returning the number of items in the list. You’ll discover that Perl has many of these types of conveniences built-in.
We could also have accessed the list in a traditional array-like fashion by numeric indexing. Like C, Perl starts array indexes at 0.
9 for ($i=0; $i<@list; $i++) {
10 print “$list[$i]\n”;
11 }
Note in Line 10 that we prefixed the list with a $. This is because list[$i] is a scalar value, so a scalar prefix is needed. Another important point is that scalar and list variables names are in different namespaces. This means you can simultaneously have a $abc scalar variable and @abc list variable. Use this feature carefully, otherwise you end up write hard-to-understand code such as $abc = $abc[$abc].
Hash variables
A powerful feature in Perl are hashes (otherwise known as associate arrays). Hashes are like arrays that are indexed not by sequential numbers, but by string value. It is a simple way to store key-value pairs.
$review{“Monsters Inc.”} = “funny and original”;
$review{“Harry Potter”} = “true to the book”;
$review{“Lord of the Rings”} = “also true to the book except for Arwen”;
Here is an example of parsing a string similar to those commonly returned from an HTML form:
1 $line=”option=1&company=Robelle&product=Qedit,Suprtool”;
2 @pairs=split(/&/,$line);
3 foreach $item (@pairs) {
4 ($name, $value) = split(/=/,$item);
5 $form{$name} = $value;
6 }
7 @list = keys(%form);
8 foreach $name (@list) {
9 print “$name = $form{$name} \n”;
10 }
In Line 2 and 4, the split function takes a regular expression (although we are using it here just for a simple string search) and a string, finds the substrings that are separated by the regexp, and returns a list of those sub-strings. So in Line 2, we are looking for the substrings separated by an ampersand &. Split returns this list of three strings:
option=1
company=Robelle
products=Qedit,Suprtool
In Line 4, the split works in a similar way to break up “option=1” into a list of two elements (“option”, “1”). Notice that Perl allows simultaneous assignments of several variables. The assignment puts the first element in $name and second element in $value.
In Line 5, the assignment to a hash looks almost like assigning to an array assignment, except that curly braces are used instead of square brackets
In Line 7, the keys function returns a list of all the key values in a hash (“option”, “company”, “product”). Notice that a hash is prefixed by a % sign when used in hash context. If you wanted to get all the values in a hash, you would use the values function, which would have returned (1, “Robelle”, “Qedit,Suprtool”)
Perl on MPE/iX
Perl for MPE/iX is available for download from the HP Jazz Web site: jazz.external.hp.com/src/hp_freeware/perl/. Perl was ported to the HP 3000 by Mark Bixby. Here are some notes on Perl/iX from the Jazz Web site:
“The following prerequisites apply to Perl on MPE/iX: MPE/iX 6.0 or greater. This software has not been tested on versions earlier than 6.0. Approximately 325,000 sectors of available disk space.” Perl has been linked to use the shared libraries /lib/*.sl and /usr/lib/*.sl; if these libraries are missing or have restrictive permissions then Perl will not run. These libraries are a standard part of MPE FOS starting with 6.0. If for some reason you are missing these libraries, you can recreate them by logging on as MANAGER.SYS and then running the shell script /PERL/PUB/mpebin/LIBS.hp3000.
Integration With MPE
A few MPE-specific modules are starting to become available for Perl. The following is a partial list; none of these are bundled with this distribution, so if you want to play with them you’ll have to download and build them yourself:
MPE::CIvar — Ken Hirsch’s interface for MPE/iX JCWs, CI variables, and the HPCICOMMAND intrinsic. Please see invent3k.external.hp.com/~MGR.HIRSCH/CIvar.html for more info.
MPE::IMAGE — Ted Ashton’s interface for MPE/iX TurboIMAGE databases. Please see search.cpan.org/search?dist=MPE-IMAGE for more info.
Web Resources for Perl
These include www.perl.org, the Perl user community; www.perl.com, O’Reilly’s official Perl home; and www.cpan.org, the Comprehensive Perl Archive Network for perl distribution, doc, modules. If you have trouble installing packages from CPAN, read Ken Hirsch’s installation tips at invent3k.external.hp.com/~MGR.HIRSCH/cpan.html
O’Reilly books
• Learning perl - A good introduction to the language
• Programming perl - Known as the “camel book”, it is the definitive Perl reference written by the authors of Perl
• perl cookbook - Solutions for common operations. For example, Problem: How to do something to every word in a file?
Solution: Split each line on whitespace:
while (<>) {
for $chunk (split) {
# do something with $chunk
}
}
By Bob Green
With HP announcing its latest sunset for the HP 3000 in 2007, I thought some of you might be feeling nostalgic for some history. The original 16-bit HP 3000 (later called “the Classic”) was released in 1972 and re-engineered into a 32-bit RISC processor in the 1980s.
Background (1964-1969)
The HP 2000 Time-Shared Basic System (1968) was HP’s first big success in computers. The 2000 line was based on the 2116 computer, basically a DEC PDP-8 stretched from 12 to 16 bits. HP inherited the design of the 2216 computer when it acquired Data Systems, Inc. in 1964 from Union Carbide. The 2000 supported 16 to 32 time-sharing users, writing or running BASIC programs.
This product was incredibly successful, especially in schools. The original 2000A system was created by two guys working in a corner: Mike Green, who went on to found Tandem much later, and Steve Porter, who also went on to found his own computer company. Heavy sales of the 2000 brought the computer division of HP its first positive cash flow, and with it the urge to “make a contribution.” The engineers and programmers in Cupertino said to themselves, “If we can produce a time-sharing system this good using a junky computer like the 2116, think what we could accomplish if we designed our own computer.”
Abortive First Try (1969-1970)
The project to design a new computer, code-named “Omega,” brought new people into the Cupertino Lab, people who had experience with bigger operating systems on Burroughs and on IBM computers. The Omega team came up with a 32-bit mainframe: It was stack-oriented, had 32-bit instructions, data and I/O paths, eight index registers, up to 4 megabytes of main memory, up to four CPUs sharing the same memory and bus, both code segmentation and data segmentation, and a high-level systems programming language instead of Assembler; it was capable of multiprogramming from the start, and had support for many programming languages (not just BASIC as on the 2000).
The Omega was designed to compete with big CPUs. But Omega looked too risky to management. HP would have had to borrow long-term funds to finance the lease of machines to compete directly with IBM. So it was cancelled. Some of the Omega architects left HP, but most stayed. “Several people who remained took to wearing black-velvet armbands, in mourning for the cancelled project,” according to Dave Packard in his 1995 book, The HP Way.
The 16-Bit Alpha (1970-71)
Most of the Omega team were re-assigned to the Alpha project. This was an existing R&D project to produce a new 16-bit computer design. The Omega engineers and programmers were encouraged to continue with their objectives, but to limit themselves to a 16-bit machine. Alpha was Omega squeezed into 16 bits: 128 KB of main memory (max), one index register, and Huffman coding to support the many address modes desired (P+- for constants, DB+ for global variables, Q- for parameters, Q+ for local variables, and S- for expression evaluation).
Same People, Smaller Hardware, Bigger Software
The original design objectives for the Omega Operating System were limited to multiprogrammed batch. The Omega designers put off time-sharing to a later release that would be supported by a front-end communications processor. The cancellation of Omega gave the software designers another year to think of features that should be included in the Alpha Operating System.
As a result, the software specifications for this much smaller machine were now much more ambitious that those for the bigger Omega. They proposed batch, time-sharing and real-time processing, all at the same time, all at first release, and all without a front-end processor.
The instruction set of the Alpha was designed by the systems programmers who were going to write the compilers and operating system for the machine. The prevailing “computer science” philosophy of the day was that if the machine architecture was close to the structure of the systems programming languages, it would be easier to produce efficient, reliable software for the machine and you wouldn’t need to use Assembler (that is, a high-level language would be just as efficient and the code would be much easier to maintain).
The Alpha was a radical machine and it generated infectious enthusiasm. It had virtual memory, recursion, SPL instead of Assembler, friendly MPE with consistent batch and online capabilities instead of OS-360 with its obscure command syntax, variable-length segments instead of inflexible pages, and stacks instead of registers. The Alpha was announced as the HP 3000 with a fancy cabinet of pizza-oven doors, available in four colors. Prospective users were assured that it would support 64 users in 128 KB of memory.
Harsh Realities (1972-73): 200 Pounds of Armor on a 90-Pound Knight
I worked at Cupertino at the time and was assigned to coordinate the production of the ERS (External Reference Specifications) for the new software. I was as excited as everyone else. The first inkling I had that the HP 3000 was in trouble came in an MPE design meeting to review the system tables needed in main memory. Each of the ten project members described his part of MPE and his tables: code segment table, data segment table, file control blocks, etc. Some tables were memory-resident and some were swappable. When the total memory-resident requirements were calculated, they totaled more than the 128 KB maximum size of the machine.
MPE wouldn’t fit, so everyone squeezed: The programmers squeezed in 18-hour days, seven days a week trying to get MPE to work. Managers were telling their bosses that there was no problem, they just hadn’t had a chance to “optimize” MPE yet. When they did, the managers maintained, it would all turn out as originally promised. So marketing went on selling the machines to the many existing happy users of the HP 2000. As the scheduled date for the first shipment approached, the Cupertino factory was festooned with banners proclaiming “November Is a Happening.”
The first HP 3000 was shipped November 1, 1972 to Lawrence Livermore Hall of Science in Berkeley, California. But it was incomplete: It had no spooling, no real-time, etc. It supported only two users, and it crashed every 10 to 20 minutes. Customers who had been promised 64 terminals and who were used to the traditional HP reliability became increasingly frustrated and angry.
Eventually the differences between the HP 3000 reality and the HP 3000 fantasy became so large and well-known that there was even a news item in Computerworld about it — the first bad press ever for HP. Bill and Dave were not amused. The product was withdrawn from the market for a short time.
Struggling to Restore Lost Credibility (1973-74)
Hewlett-Packard had no experience with bad publicity from low-quality products. Paul Ely was brought in from the successful Microwave Division to straighten out the computer group. The first priority was to help out the existing HP 3000 users, the ones who had trusted HP and placed early orders. Many of them received free 2000 systems to tide them over until the 3000 was improved. The second priority was to focus the programmers’ energy on fixing the reliability of MPE.
Once the HP managers realized the magnitude of the 3000 disaster, the division was in for lean times. Budgets and staffs that had swollen to handle vast projected sales were cut to the bone. Training, where I worked, was cut from 70 people to fewer than 20 in one day. HP adopted a firm “no futures” policy in answering customer questions (a policy that lasted for years after the HP 3000 trauma, but was forgotten by the time of the Spectrum-RISC project). The new division manager was strictly no nonsense. Many people had gotten in the habit of taking their coffee breaks in the final-assembly area, and kibitzing with the teams testing the new 3000s. Ely banned coffee cups from the factory floor and instituted rigorous management controls over the prima donnas of the computer group.
By continuing to work long weeks, the programmers managed to reduce MPE crashes from 48 a day to two, and to increase users from two to eight. Marketing finally took a look at what the 3000 could actually do, and found a market for it as a replacement for the IBM 1130. They sold the 3000 as a machine with more software capability than an IBM 1130 that could be available to a number of users at once instead of just one. Eventually the 3000 became a stable, useful product. To my mind, this happened when someone discovered the “24-day time bomb” bug. If you kept your HP 3000 running continuously for 24 days (2^31 milliseconds) without a shutdown or a crash, the internal clock register would overflow and the system would suddenly be set back by 25 days!
The Comeback: Fulfilling the Promise (1975-76)
The original 3000 had a minimum usable memory size of 96 KB and a maximum of 128 KB — not much of an expansion. The Series II went beyond that 16-bit limitation by adding “bank” registers for each of the key pointers (that is, code segment, data segment, and so on). Thus the Series II could support up to 512 KB, a much more reasonable configuration for the software power of MPE.
The choice of SPL as the HP 3000 machine language instead of Assembler truly began to pay off now in an avalanche of excellent software: The IMAGE database (again, two guys working in a corner: Jon Bale and Fred White) was soon joined by compilers for COBOL and RPG, a screen handler, and other tools to support transaction processing.
Concurrent, consistent batch and time-sharing was now a reality and the goal of concurrent real-time was finally dropped as unrealistic. The HP 3000 hardware now matched the software written for it. Business users discovered that the 3000 was great for online transaction processing; they dragged Hewlett-Packard firmly into the commercial information processing world.
At last, with the Series 64 in 1982, the 3000 reached the original target of 64 users on a single machine.
P.S. For another interesting history of the HP 3000, read HP’s Early Computers, Part Three: The Strongest Castle: The Rise, Fall and Rise of the HP 3000 by Chris Edlar
Whip up tasty dishes with ample applications using this scripting language
By Curtis Larsen
Something I’m sure I share with other HP 3000 folks is a love for technology that solves problems in some straightforward yet elegant manner. After all, this is why we all continue to use our HP 3000 systems (and probably why we chose them in the first place).
Especially exciting, though, are the new technologies that further extend our systems and solve even more problems. I can remember eagerly reading each new “Communicator” for the enhancements list, and my personal favorites – upgrades to the Command Interpreter. I’d be excited to try out each new function and new “FINFO” parm. (When the JOBINFO function hit the streets I was practically singing.)
As much fun as I have with the CI though, I recognize that every programming language has its limitations. So HP 3000 programmers have used various different languages available such as COBOL, Business Basic, or VESoft scripting – or a combination of them — to solve larger tasks. Each language brings its own flavor and abilities to the programming table, and when POSIX scripting was added to the ingredients, a wonderful curry resulted. Like a great curry, you can still see, smell and taste each individual ingredient, but they all contribute to a sum greater than the parts.
Some of the new flavors the POSIX world gives us are the Bourne, BASH, C, and Korn, shells, as well as public-domain C, FORTRAN, Assembly, and Basic compilers. It also gives us the newer interpreted scripting languages such as Perl, Java, and Python.
Now chances are good you’ve heard about Perl and Java, but how much do you know about Python? Ahhh… let’s start opening some of those spice jars, shall we?
Python is a fast, extensible, object-oriented scripting language created by Guido Van Rossum and named after the ’70’s British comedy troupe and television show “Monty Python’s Flying Circus”. (It’s too good to make up folks. If that doesn’t begin to spell “curry” to you, I don’t know what does.)
Python and Perl are very similar in capabilities —what can be done in one, can also be done in the other – it’s just that their approaches to those capabilities differ. Perl leans towards terse syntax, and many small “add-in” modules, while Python (if not verbose) leans more towards self-describing syntax and fewer, larger, “add-in” modules. Both can be written in Ye Olde Top-Downe style, or by using objects and methods in the newer Object-Oriented style of programming — pick the sauce that suits you. Both languages have been ported to almost every OS imaginable (and a few that weren’t). Python also uses OOP syntax similar to Java with it’s “Object<dot>Method”. This similarity to Java comes in very handy, but more on that later.
One quirk that Python people have to get used to though is the indenting. The beginning of a text line is significant in Python, and indicates dependence. Now, now – I heard that agonized cry, like you had just eaten too much pepper. Trust me on this one – like a pepper you may find it hard to swallow at first (especially in one large bite), but if you come to it slowly, you’ll learn to appreciate the subtleties and grow just as addicted to it. And let’s be reasonable – if you can start a significant line of COBOL at a certain column for twenty-odd years, you can handle a little reasonable indenting.
Rather than explain Python’s syntax in detail though, I’ll point you to the Python web site where you can really chew on it. The main plate is at www.python.org, and many other links can be found from there for general consumption.
Ok, so let’s say you buy into it for now – you’re at the MPE table checking out the various Python dishes for appearance and aroma before biting into one. A wise course of action, but while some of the offerings can be a bit exotic, I’ve found nothing unattractive. You can find an incredible list of Python applications at “The Vaults of Parnassus” (www.vex.net/parnassus) — here are a few that might be of interest to you in combination with an HP 3000:
• “ZOPE”: An extremely powerful Web-application creation utility — and then some!
• “Gadfly”: A powerful Python-based SQL engine – see its Web page for details.
• “Peercat”: Web-based aggregate data collector. (Usually news items, but…)
• “Scanerrlog”: A script to meaningfully parse Apache’s “error_log” file to HTML, etc.
• “txt2html.py”: Converts various ASCII formats to HTML.
• “inpim.py”: Calendar/To-Do app w/cross-system sync. Budgeting subsystem, too.
• “PyBook”: Searches, downloads, and displays Project Gutenberg books.
• “Roundup”: Issue tracking system with web,CLI, and e-mail interfaces.
• “RoutePlanner”: A highway trip planner.
• “Pyrite”: Allows Palm Pilot synchronization.
• “PyPsion”: Similar application for Psion PDAs.
• “web2ldap.py”: Full-featured web-based LDAPv2+ client.
• “flad”: Create, read, and write INI-like config files.
• “ODBC Socket Server”: Access Windows ODBC sources via XML TCP/IP interface.
• “Python-DSV”: Parses CSV, TSV, etc. files, guesses string encoding, etc.
And more CGI scripts than you can shake a kebob stick at.
This list just scratches the surface, since there are far more HP-useful Python applications than can be shown here, and due to its ease of use and power, more people are sitting down to the “Python picnic” each day. There are many Python applications that could have a strong impact on your regular MPE recipes, and more are continually arriving. Look over the list above – ever want to directly use your HP data with a Palm Pilot? Send and receive data from an ODBC source directly from a batch job? Map the shortest routes to clients? Check on the weather before shipping a product there? Many more possibilities exist!
Python includes very good support for XML (including XML-RPC and SOAP), LDAP, and offers an interesting native object persistence (or “object pickling”) to a file, so that you can save an object and its properties, freezing it for cooking another day.
Although the “original” Python was written in C, a newer version of Python named “Jython” has been written using Java. In addition to running native Python scripts, this version also permits use of the native Java objects and features from within Python. Looking (and reading) very similar to Java, you can actually code something very quickly using Python for later export to Java, etc., treating Python as a sort of RAD language. So whether you think of Python as a “C food” entree, or as a side dish to chew on with your morning “cup of Java,” you’ll find it both digestible and flavorful. You can use a little or a lot, spread it thinly or plaster it on thickly – whatever suits your taste and mood.
I’ve only used the C-based Python on my HP system, but you could give Jython a whirl. The C version is a bit dated but runs quickly, while the Java version is very current, but starts a tad slower. It just depends on what you want to use Python for, and whether or not you’ll need some of the newer functions and modules.
Probably the thing that really excites me personally about Python is its “dictionaries,” or what Perl calls “hashes.” Folks who use these types of variables almost always get hooked on them. For example, you can create a dictionary named “D”, and store a value in it using a string key named “info” which might look like this: D[“info”] = “555-1212”. Now whenever you say ‘print D[“info”]’ you’ll get “555-1212”. It’s like using an array, but without the limitations of an array — you don’t need to preset a dictionary, worry about internal structure, use only numbers, or know how many “elements” it will have. You can even dynamically store a dictionary within another dictionary (and so on) to get some incredible depths of sophistication. Suddenly a “simple scripting language” allows fast use of tables and three-dimensional databases. (And it pulls up those values just as quickly!)
For an HP 3000-specific example of using Python dictionaries, I combined a VESoft Security/3000 report with a quick Python hack – er – script to show me the last date any terminal in a given date range was used, then print those results sorted by terminal. Sure, I could have coded it all some other way, but using the report as input to a filtering script was simplest for me, and gave me the results I wanted very quickly. Figure 1 below shows the script (be gentle).
Figure 1
import fileinput,
string # These modules provide some
# nice extra methods for file
# and string handling, etc.
x = " "
# Inits: Not needed, but. . .
hist = {}
totals = {}
for line in
fileinput.input(): # Loop thru each report file
r =
string.strip(line) # line (given as the parm)
if r[0:5] ==
"Logon": # Detail record? Process
it.
rdate =
"0" + string.strip(r[07:14]) # Load our work
variables
rdate = rdate[-7:]
rdev =
int(string.strip(r[23:27]))
rlogon =
string.strip(r[27:62])
rname =
string.strip(r[63:94])
hist[rdev] =
(rdate, rlogon, rname) # Load the ‘history’
dictionary
# using the LDEV # as the key
if rdate
<> x: # Print each new date as we
go
x = rdate
print rdate
#
Initialize the ‘totals’ dictionary logon count at first
use
if not
totals.has_key(rdev): totals[rdev] = 0
totals[rdev] = totals[rdev] + 1 # Add one to the logon count
keylist = hist.keys()
# ‘keylist’ contains seen LDEVs
keylist.sort()
# BAM! Now it’s a sorted list
for ldev in keylist:
# for each LDEV we saw. . .
rdate, rlogon,
rname = hist[ldev] # load some work vars, and:
print "%04u
%5u %7s %s" % (ldev, totals[ldev], rdate, rlogon)
This script assumes that a chronologically-ordered list of LDEV logons will show the most recent logon for every terminal (with any luck, hey?), and records every logon for each LDEV. Each successive assignment overwrites the previous value used by that LDEV key, so the last logon for each LDEV key is the last value kept. Additionally, the script counts each time that LDEV key was seen, so that you have an idea as to how often the terminal is used. This little script could easily be adapted to record other information, like the first logon, or whatever else you might need.
I hope this helps whet your appetite for the Python language, and that you will give it a try – again, there’s far more to the language than can be described here. Many thanks to Joseph Koshy at HP Bangalore for bringing Python to MPE/iX, and to the HP3000-L list for assistance. You can see what Koshy is doing in his spare time to port Python v2.x by visiting the Python/iX web site on Sourceforge: pythonix.sourceforge.net. For a copy of Jython, head on over to www.jython.org and download a copy.
Go ahead — join the Python/iX groundswell now, and get your piece of the Python.
Curtis Larsen has been working with HP 3000s for 11 years, and believes that, given enough time, any application can be written using the CI. He currently works for Covance Laboratories, in Madison, Wis.
By Bob Green
Commemorating the Oct 31, 2003 “wake” for the HP 3000, Robelle are devoting our NewsWire column to some history. Our story of the original 16-bit HP 3000 (1972-1976) is told on our Web site.
After initial development, the HP 3000 grew and prospered. From 1974 to 1984, HP continued to produce more powerful 3000 hardware running more capable software. Each new model was compatible with the previous version and a joy to install.
But the pressure was on to switch to a 32-bit architecture, as other manufacturers were doing. So HP announced a radical change: a new 32-bit hardware for the 3000. The project was code-named Spectrum. As a 3000 consumer and 3000 vendor, Robelle was excited and concerned about the prospect of a new hardware architecture. Certainly it would be wonderful to have more powerful processors, but what about the disruption to our steady incremental, risk-less progress?
The first notice we took of the Spectrum appeared in our December 1984 customer newsletter, with continuing news to follow for the next four years (my retrospective comments are included as “In Retrospect”).
December 12, 1984
The first Spectrum machine will be an upgrade for the Series 68. Other size models will follow soon after, since HP is working on different Spectrum CPUs in three divisions at once (in the past, all 3000 CPUs came out of one division). This first Spectrum can be expected in the first half of 1986.
In Retrospect: Please make a note of that 1986 promised delivery date, and remember that HP faced serious competition from DEC and others. Customers who loved the 3000, but had outgrown the power of the system, were demanding more capable models.
Spectrum is based on the RISC concept, modified by HP Labs. RISC stands for Reduced Instruction Set Computing. Such a computer has no micro code, only a small number of key instructions implemented in very fast logic. The original Berkeley RISC machine had only 16 instructions. Spectrum has more than 16, but not many more. HP selected the instructions for the fast base set by studying typical application mixes on the existing HP machines. Other functions will be done via subroutines or co-processors (e.g., a floating-point processor, an array processor, or a database processor).
In Retrospect: The actual number of instructions in the Spectrum turned out to be about 130, not 16, but they were all simple enough to run in a single clock cycle. HP was the first computer company to go with the RISC philosophy and the only major one to risk the firm by converting all their computer models, both technical and commercial, to a single RISC design.
June 11, 1985
HP’s new Spectrum machine will have both Native-Mode software and 3000 software. The first Spectrum machine to be released will have 3-10 times more computing power than a 68, about 8-10 MIPS in Native Mode. Programs copied straight across will run about twice as fast as on a 68, and those that can be recompiled in Native Mode should run 6-8 times faster. Much of MPE, including the disk portion of the file system, has been recoded in Native Mode. Since most programs spend most of their time within MPE, even programs running in emulation mode should show good performance (unless they are compute-bound).
In Retrospect: The expectations were building in our minds: these machines would be much faster than our current models!
Spectrum will use much of the new operating system software that had been written for Vision, which saves a great deal of development time. Spectrum will use 32-bit data paths and will have a 64-bit address space. Forty Spectrum machines have been built and delivered for internal programming, but product announcement is not likely before 1986.
In Retrospect: Vision was an alternative 32-bit computer project at HP, using traditional technology, which was cancelled to make way for the RISC design from HP Labs. Invoking Vision re-assured us that this project is possible, that progress is being made. It was now six months after the first announcement of the project.
August 16, 1985
According to an HP Roundtable reported in the MARUG newsletter, “Most of what is printed about Spectrum is not to be trusted. Spectrum will be introduced at the end of 1985 and delivered in Spring 1986. There are 40-50 prototypes running in the lab and the project team consists of 700-800 engineers. HP will co-introduce a commercial version and a technical version with the commercial version fine-tuned to handle many interactive users, transaction processing, IMAGE access, and the technical version will be structured for computational programs, engineering applications, and factory automation. HP will eventually offer a choice of MPE and Unix. Most software will be available on Spectrum at introduction time and over time all software will be available.”
In Retrospect: HP tried to dispel rumors, but still predicted 1986 for delivery. HP would produce two Spectrum lines: the Unix line for technical users and the MPE line for commercial users, using the exact same hardware.
“The following describes what will be required to convert – Least: restore files and IMAGE databases as they are and run. Next: recompile programs in native mode. Next: change over to new IMAGE database system. Next: change source code to take advantage of RISC.” Robelle Prediction: Spring 1986 for a Spectrum that will reliably run existing MPE applications is not an attainable release date.
In Retrospect: The new relational HPIMAGE database mentioned here was cancelled much later in the project, after a brief encounter with end-users. I don’t remember much about HPIMAGE, except that a lot of work went into it and it didn’t succeed as hoped. TurboIMAGE ended up as the database of choice on the Spectrum. Without any inside information, but based just on past experience and common sense, Robelle tried to inject some caution about the 1986 release date. During the original traumatic HP 3000 project, Dave Packard “sent a memo to the HP 3000 team,” according to Chris Edler. “It was only two lines long and said, essentially, that they would never again announce a product that did not then currently meet specifications.” The division listened for over 10 years, but eventually, people forget….
September 20, 1985
From a Spring 1985 UK conference: Most existing peripherals will be supported and it will be possible to use networking software to link existing model HP 3000s to Spectrum, with the exception of Series II/III and 30/33. These would need a Series 37 or other current range machine to act as a gateway to Spectrum.
From an HP press release: “100 prototype models were already being used internally for system development as of April 1985.”
HPE, the new operating system for the commercial Spectrum is a superset of MPE. It will have two modes of operation: Execute mode (HP 3000) and Native Mode. The switch between the two will be made on a procedure call, but there will be some programming work needed to translate parameters when switching.
In Retrospect: Execute mode was eventually called Compatibility Mode and switching between modes turned out to be major CPU bottleneck in the new system, albeit one that would be removed over time.
The Spectrum is rumored at this time to provide 32 general-purpose registers to the user program and a virtual data space of 2 billion bytes.
December 30, 1985
From Gerry Wade of HP: The name of the Spectrum machine, when it comes out, will not be Spectrum. Another company already has that name. Spectrum will use the IEEE standard for floating-point arithmetic and will also support the HP 3000 floating point. Each data file will have a flag attached to it that tells which type of floating-point data it contains (the formats are not the same).
In Retrospect: The file flag idea never happened, although the TurboIMAGE database did introduce a new data type to distinguish IEEE floating point. Information on implementation details is starting to flow, which helps us believe that the project is on schedule and likely to deliver the more powerful servers we desire.
June 16, 1986
In reporting on Joel Birnbaum’s Spectrum presentation, the HP Chronicle had these observations: “Comparisons with Amdahl and DEC mainframes in slides showed areas where the Spectrum computers topped the larger machines’ benchmarks. ‘Even with un-tuned operating systems software, it’s significantly superior to the VAX 8600,’ Birnbaum said.”
In Retrospect: Joel was the HP Labs leader who was the sparkplug of the RISC project, building on research that he had done previously at IBM. In retrospect, we can see that Joel was talking about the performance and delivery of the UNIX Spectrum, not the MPE version, but customers took this as a promise of vast performance improvements in the very near future. It was now past Spring 1986 and the promised new 3000 machines were nowhere in sight. In fact, HP has not yet announced the new models and pricing. This was the first slippage in the project, barely noticed at the time.
July 20, 1986
Many people have been asking, “What is Robelle doing about Spectrum?” HP has invited us to join its Fast Start program for third parties and we have agreed. This program gives us pre-release access to Spectrum information and actual systems. We have visited Cupertino and run our software on the new machines. We are confident that all of our products will operate properly at the time that Spectrum is officially released.”
In Retrospect: Since Suprtool and Qedit were essential to the large 3000 customers that HP was targeting, HP asked Robelle to start porting and testing our products on the new systems. But to do that, we had to sign a Non-Disclosure Agreement, the most draconian one we had ever seen. We used careful wording in our announcement above. From this date on, until years later, we could not tell our customers anything useful about the new machines. HP was especially sensitive about their reliability and performance.
When we arrived in Cupertino to do our first testing, we found the prototype Spectrum systems crashing every few minutes and running slower than our tiny system 37. We were appalled. Nothing in HP’s public statements had prepared us for the state of the project. I had personally gone through a similar situation with the original 3000 in 1972-74, and I wondered if upper management at HP knew how terrible things were. I thought about talking to them, but our NDA also prohibited us from talking to anyone at HP.
The Unix versions of Spectrum, on the other hand, seemed to be humming along nicely, showing that it was not a hardware problem.
By Bob Green
Last month I presented the first half of our history of the PA-RISC 3000 development, using excerpts from our old customer newsletters, supplemented with new comments (My comments are shown below prefaced by “In Retrospect”). By 1986 we reached the point where Robelle was allowed to experiment with a prototype MPE system at the migration center and were aghast at how slow and unreliable it was. And since the Unix versions of Spectrum seemed to be humming along nicely, the problem seemed to be software, not hardware.
September 11, 1987 Newsletter:
First Spectrum Shipments: Rumor has it that HP shipped the first four 930 machines on Friday, August 21st, with more to follow every week thereafter. As of press time, we have been unable to find out whether ordinary mortals are allowed to touch these machines (as opposed to those who have signed non-disclosure agreements).
In Retrospect: Due to the NDA, over a year passed with no Spectrum news in our newsletter. The project was now 18 months past the original promised delivery date, but was still far from completion. Many people wrote articles, about the Spectrum, mostly based on marketing hype from HP, but no one broke the embargo on real information. We were all terrified. The MPE group had dug themselves into a very deep hole, and no one wanted to be the one who caught the eventual backlash.
October 19, 1987 Newsletter: The Spectrum Song
Orly Larson and his database singers performed again at the Interex show, including their hit, “The Spectrum Song:”
If it takes forever, we will wait for you
For a thousand summers, we will wait for you
‘Til you’re truly ready, ‘til we’re using you
‘Til we see you here, out in our shops!
From the HP Management Roundtable: Schedule for Shipping Spectrums — “We are shipping equally around the world. Our first shipments went to both North America and Europe. We are acknowledging availability for 930s and 950s through December at this time … We expect by the end of November to be able to have acknowledged the entire backlog.”
In Retrospect: HP continued to spin the “shipments” of Spectrums, without mentioning that these were not finished products. The models were 930 and 950 and the operating system was called MPE/XL, changed in later years to MPE/iX when POSIX was integrated into MPE. By this time, HP was worried about their stock price also and did not want any negative news in the financial press, no matter how accurate. As shown by the next Q&A at the roundtable…
Early 930/950 “Shipments”
Question: “Are the 930s and 950s being shipped or not? In public you tell me they are shipped. In private, however, I hear from both users and HP that these machines are still covered by non-disclosure agreements and that access to these machines is very restricted, even when in customer sites. What is the story?”
Answer: “MPE/XL architecture is very, very new. There’s a million new lines [of code] that go into MPE/XL, and a lot of software sub-systems as well. And so we are being extremely cautious in how we proceed at this point. We’re going through what we call a slow ramp-up through the remainder of this year and going into large shipments in 1988. The reason for that is that we want to fully test out the system capability in a large number of customer environments and we want to make sure that the information on what’s going on in there and the people involved are protected from outside folks who either benevolently or not benevolently would like to find out what’s going on.
I’m sure we’re going to run into some problems along the way that haven’t been encountered in our earlier phases of testing. We haven’t really hit these machines with full production pressure yet. We know from experience that when you do that, you uncover things that you could never uncover in testing, even though extremely rigorous. [Rumor has it that the customers receiving Spectrums now are not allowed to put them into production until 1988.]”
In Retrospect: Early Spectrum customers called us to ask which version of Suprtool and Qedit they needed for their new systems, and whether there were any problems that they should be aware of. But legally, we could not even admit that we knew of the existence of the new servers. So we came up with the following wording: “If you had a new 3000, and we are not admitting that we know anything about a new 3000, you should be using Suprtool version 3.0 and Qedit version 3.6. On this hypothetical system, it might not be a good idea to hit Control-Y while copying a file from any other HP 3000. We can’t tell you what will happen, but you won’t like it.”
February 12, 1988 Newsletter
Spectrum Finally Leaves the Nest: Hewlett-Packard has officially released the 930 and 950 Spectrum computers, finally abandoning the protection of non-disclosure agreements. We have heard from several sources that the 930 and 950 attained Manufacturing Release during the month of January. This means that people who received “Control Shipment” Spectrums can now put them into production and let outsiders use them. You no longer need to sign any restrictive agreements to get a 930/950. It also means that we users can now compare notes on what the MPE/XL systems are good for.
Interestingly, we didn’t hear about the Manufacturing Release (MR) of the Spectrum from Hewlett-Packard itself. As far as we can determine, HP kept this event very quiet — no press conferences or splashes of publicity. Even some HP people in Cupertino were not aware that MR had occurred. Just because the 930 and 950 are released does not automatically guarantee that you can get one. Given the huge backlog of orders that HP has, it will make “controlled shipments” for a while, picking sites whose expectations match the state of the machines.
In Retrospect: Users had been following Spectrum for almost four years and you could see that we were eager for the release of the product. The MPE lab had grown to hundreds of engineers and technicians and hundreds of Spectrum servers. The amount of money being plowed into the project was awesome. Anyone with any kind of skills was being hired as a consultant, in an attempt to get the situation under control and begin shipping revenue-generating servers. But we were premature in our February proclamation of Manufacturing Release, an HP corporate milestone that requires signed confirmation that the product passes the performance tests set for it in the design specifications.
March 31, 1988 Newsletter
Spectrum Is Released but Not Released: In our last news memo, we reported that MPE/XL users were now removed from non-disclosure restrictions and allowed to put their Spectrum machines into production. In the last month, that news has been confirmed by many sources.
We also concluded, and reported, that MPE/XL had obtained MR (Manufacturing Release). That is untrue. MPE/XL has apparently obtained SR (System Release), but not MR. “System Release” seems to be a new category of release, created just for MPE/XL. We have heard from some new 950 customers who did not need to sign a non-disclosure agreement. However, one customer reported that before HP would allow him to order, he had to sign a document stating that he had no specific performance expectations. On the other hand, we heard from a school that recently went live with 35 student sessions and had great response times (“the machine is coasting along at 10 percent PCU utilization”).
In Retrospect: In order to stem the rising tide of bad expectations, HP released the MPE systems even though they could not pass the testing department. And the performance was still poor in many cases, less than the non-RISC 3000s being replaced, although excellent in a few other cases.
Non-disclosure restrictions are not lifted for everyone. Sites that are beta-testing subsystems which were not released with the initial MPE/XL system are still restricted. Also, third-party FastStart companies such as ourselves are still restricted from passing on any performance or reliability information that we obtain from HP. We face no restrictions regarding performance information received from our customers, so please call with your experiences.
Non-disclosure continues – HP is picking their initial customers carefully and coaching them to only pass on the good news about their new systems. We are still frustrated to not be able to pass on our ideas about how users can improve the performance of the Spectrum.
October 12, 1988 Newsletter
Gary Porto at Childcraft reports that with MPE/XL 1.1 the problem of a serial task in a batch job hogging the system is not so bad as it was with 1.0. This problem can occur with SUPRTOOL, QUERY, or any long serial task. The batch job still hogs the system, but at least people can get a minimum of work done. With 1.0, they couldn’t even get a colon! Gary reports that he has 65 on-line users on his 64-megabyte Series 950 and that the performance is pretty good — as good as his Series 70.
In Retrospect: On the 4 year anniversary of the project, HP released version 1.1 of MPE/XL, which made the systems much more useful, but still not up to the original promised performance of 1984. However, the promise of the “Precision Architecture” (HPPA) was there, as certain tasks were amazingly fast.
By this time, HP salesmen were getting irritated with us for not giving our customers any kind of endorsement for the switch to the 930/950. But our NDA was not cancelled until Manufacturing Release. Finally, the sales force convinced HP Cupertino to send us a signed release from our NDA. I don’t know when MR eventually happened.
From the UK’s HP World magazine: Early MPE/XL Migration Results. London Business School is not a typical installation. Much of their software is written using double precision floating point Fortran which benefits considerably from the Precision Architecture. MIS Director Gordon Miller says “Our straight line performance is up considerably — one program runs 40 times faster — but the performance gains are very application dependent and cannot be accurately forecast beforehand.”
Keith Howard of Collier-Jackson in Tampa, Florida participated in the Spectrum beta testing and upgraded from a Series 58 to a Series 950 — quite a leap. One application was found to be 6% slower due to constant switching between compatibility and native modes, but in most circumstances the machine was five to ten times faster than the Series 52 and one batch job ran 53 times faster!
Glaxo Export has temporarily deferred delivery on its second and third 950 systems due to implementation problems on the initial machine.
HP promises performance improvement for Precision Architecture over the next five years of 40-50 percent per year. Some of this will be achieved by further tuning of MPE/XL — version 1.1 is said to be at least 20 percent faster overall.
In Retrospect: As with the original 3000 project, the birth of the Spectrum was traumatic, expensive and embarrassing. But it paid off. HP was able to roll out better servers for the 3000 line on a regular basis for the next 10 years.
Despite the numerous expansions and revisions to the HP 3000 hardware and software, upgrades have been painless. Even the conversion to the PA-RISC design was backward-compatible and reasonably painless (if you ignore the slipped schedules). Often the user just rolled the new system in on a Sunday, plugged it into the power, reloaded the files, and resumed production. The original 1974 MPE Pocket Reference Card is still useful; everything on it works under MPE/iX version 7.5, except the Cold Load instructions. I have programs that I wrote in 1972, for which the source code was lost years ago, and they still run in Compatibility Mode.
When asked for an eulogy for the 3000, my reply was, “A great IT platform: reliable, affordable, flexible, easy to operate, and easy to program. And every release compatible with the previous for over 30 years. Perhaps some future OS team will adopt these same goals.”
The system is down – the hard drive is toast – and you may have to restore your IMAGE database from yesterday’s backup. In the past, this is the scenario that typically got HP 3000 system managers interested in the transaction-logging feature of the TurboIMAGE database.
But now, as a result of the Sarbanes-Oxley law (SOX), IMAGE Logging is also being used to create audits for data changes. Managers who have never used transaction logging before are now enabling it to create an evidence trail for their SOX auditors.
Here is an example from Judy Zilka, posting to the 3000-L newsgroup:
“As a requirement of Sarbanes-Oxley we are in need of an HP 3000 MPE system program that will automatically log changes to IMAGE data sets, KSAM and MPE files with a user ID and time/date stamp. We often use QUERY to change values when a processing error occurs and the user is unable to correct the problem on their own. The external auditors want a log file to be able to print who is changing what and when.
George Willis and Art Bahrs suggested IMAGE Transaction Logging:
Judy, we have enabled Transaction Logging for our TurboIMAGE databases coupled with a reporting tool known as DBAUDIT offered by Bradmark. For your other files, consider enabling a System Level logging #105 and #160. The LISTLOG utility that comes with the system can extract these records and provide you with detail or summary level reporting.
Hi George & Judy:
Yep, Transaction Logging will meet the requirements for Sarbanes-Oxley and HIPAA for requirements relating to tracking “touching” data.
Also, remember you must have a corporate policy relating to this tracking and either a SOP or a formal procedure for reviewing the logs. The SOP or procedure needs to address what constitutes normal and abnormal activity with regards to reviewing the logs and what action to take when abnormal activity is noted.
— Art “Putting on the InfoSec Hat “ Bahrs
P.S. The fines for not being able to show who did what and who has access to what can be very, very eye-opening! Of course these comments only apply to the US and businesses linked into the US.
So what is IMAGE logging?
First of all, it is not the same as “system logging” or system “logfiles.” These record MPE system activities such as logon and file open, and have their own set of commands to control them. You can see in George’s answer above that he suggests system logging to track KSAM and file changes.
IMAGE logging is a variety of “user logging” and is a part of the TurboIMAGE database application. Once enabled, it writes a log record for each change to a database. There are three programs that can be used to report on those database log records:
LOGLIST (a contributed program written by Dennis Heidner; I am not certain what the current status of this program is).
DBAUDIT (a product of Bradmark; in the spirit of SOX disclosure, I must admit that I wrote this program and it was a Robelle product before we sold it to Bradmark!)
AuditTool 3000, from Summit Solutions (www.sumsystems.com), created for ERP system logging and expanded to work with any 3000 application.
Setting Up IMAGE Logging
A number of MPE Commands are used to manage IMAGE logging; see the MPE manual at docs.hp.com/en/32650-90877/
index.html
:altacct green; cap=lg,am,al,gl,nd,sf,ia,ba
:comment altacct/altuser add the needed LG capability
:altuser mgr.green; cap=lg,am,al,gl,nd,sf,ia,ba
:build testlog; disc=999999; code=log
:getlog SOX; log=testlog,disc ;password=bob
:comment Getlog creates a new logid
:run dbutil.pub.sys
>>set dbname logid=SOX
>>enable dbname for logging
>>exit
:log SOX, start
:log SOX, stop
You can use the same Logid for several databases. For a more detailed description, see Chapter 7 of the TurboIMAGE manual, under the topic “Logging Preparation.”
IMAGE Logging Gotchas
Although the basics of user logging are pretty straightforward, there are still plenty of small gotchas. For example, Tracy Johnson asks about backup on 3000-L
“If when backing up IMAGE Databases that have logging turned on and you’re not using PARTIALDB, shouldn’t the log file get stored also if you store the root file? This question also applies to third-party products that have a DBSTORE option.”
He continued, “One problem I’ve been having is that since a log file’s modify date doesn’t change until it is stopped, restarted, or switched over, one might as well abort any current users anyway, so any log files will get picked up on a @.@ “Partial” backup, because DBSTORE and “online” (working together) features won’t do the trick. Because even though a root file’s modify date gets picked up on a Partial backup, the associated log file’s isn’t.
Then Bruce Hobbs pointed out that there is the Changelog command to close the current logfile before backup (which ensures that its mod-date is current and that it will be included on the backup) and start a new logfile.
Later Tracy ran into another interesting gotcha regarding logging and the CSLT tape
“If you use IMAGE logging, always make your CSLT the same day you need to use it! (Or make sure no CHANGELOG occurred since the CSLT was made. Thanks be to SOX...which forced IMAGE logging.)
“We added so many log files identifiers for each of our production databases it reached the ULog limit in sysgen of 64 logging identifiers. So, per recommendations of this listserv (and elsewhere,) I had to update the tables in sysgen and do a CONFIG UPDATE this weekend to bring it to the maximum HP ULog limit of 128. Not a problem. Stop the logging identifiers with “LOG logid,STOP” Shut down the system and BOOT ALT from tape. System came up just fine — UNTIL it was time to restart logging! Every logging identifier reappeared with old log file numbers a few days old. (We do a CHANGELOG every night and move the old log file to a different group.) I scratched my head on this one for half of Sunday.
<Epiphany Begin> Then it occurred to me, the Log file numbers the system wanted were from the day the CSLT was created. I had made it before the weekend, thinking it would save me some time before the shutdown! </Epiphany End>
Therefore:
a. Logging Identifiers retain the copy number on the CLST tape in the case of an UPDATE or UPDATE CONFIG.
b. Logging Identifiers on the system retain the NEXT log file they need to CHANGELOG to.
So if one needs to use a CLST to load and you’re using Image Logging, remember to use it just after you create it, or make sure no CHANGELOGs occurred since it was made.
This may effect some sites as they may believe their CPU is a static configuration and only do a CSLT once a month or once a week. In the case of an emergency tape load, to save some heartache rebuilding image log files, they may need to do a CSLT every day.
By Scott Hirsh
After having been immersed in networked storage, I’ve had a lot of time to think about infrastructure architecture. The first lesson is that storage (along with networking) is the foundation of an IT architecture. So it stands to reason that an infrastructure that’s built to last will begin with external storage, ideally from a company dedicated to storage with as much heterogeneous operating system support as possible.
What you get from an external storage platform that supports multiple operating systems is the ability to change vendors, hosts, and operating systems with a minimum of fuss. Yes, a migration of any kind is not without its pain, but it’s a lot more painful when all hardware and software is tied to one vendor. That’s a lesson everyone reading this should have learned by now.
Furthermore, these independent storage players have extensive expertise in supporting multiple platforms, including migrating customers from one to another. And frankly, unless you’re contemplating a non-mainstream operating system, networked storage is an excellent investment because it is a best practice for storage vendors to provide ongoing support for any operating system with critical mass.
For example, any HP 3000 users running on Symmetrix will have no problem using that same storage on HP-UX, Solaris, Linux, Wintel, and many others. If you’re running on internal disk, you’re stuck with HP-UX, best case — not that there’s anything wrong with that.
Here are some quick guidelines that recap the concept of minimizing transfer costs:
Start with a networked storage platform that supports as many operating systems as possible. This is the foundation layer for your IT infrastructure.
The best Total Cost of Ownership in IT is based on consolidation. However, that doesn’t necessarily imply homogeneity. It’s a matter of degree. It’s a matter of physical location as well.
Software drives hardware. Choose DBMS, applications, tools based on support for multiple operating systems and hardware. Be cautious regarding any decision that locks you into one vendor. For example, SQL Server-based solutions, which only run on Wintel, will have higher transfer costs than Oracle.
Keep your vendors honest, but at the same time don’t underestimate the value of a true partnership. One company I consulted for dropped HP after learning that HP felt they “owned” them. Any time one side thinks they have the other over a barrel, there’s bound to be trouble. We’re all in this together.
The Glue That Holds It All Together – You
In the new, defensive, minimum transfer cost environment, IT departments take on the role of systems integrator. That’s the catch for designing maximum flexibility into your environment. The IT staff must make everything work together, and be prepared to shift gears at a moment’s notice. To me, that’s the silver lining to this otherwise dreary story of no loyalty and diminishing options. More than ever, it’s the people who make the difference.
Back in the day, hardware was expensive and people were not. Today, if you're still using your own hardware on-premise, the hardware is cheap and the people are expensive.
Perhaps the greatest legacy of the HP 3000, and what will ensure our continued leadership in IT, is the hard-earned knowledge of what’s a best practice and what is not.
By Scott Hirsh
In the years since HP’s end-of-life decision for the HP 3000 has worn off, was it a “worst practice” to be an HP 3000 user over its final vendor life? What could we have done differently, and how do we avoid painting ourselves into a technology corner in the future?
The key is a concept that vendors understand intimately – transfer cost. Transfer cost is the cost of changing from one vendor or platform to another. For example, switching phone carriers involves low transfer costs. You hardly know it happens. But changing from one operating system to another – say, HP 3000 to Solaris – means high transfer costs. Vendors try to make transfer costs high, without being obvious about it, to discourage customers from switching to competitors.
It is your job to identify potential transfer costs in your technology decisions, and to keep them as low as possible. One way to lessen risk to spread the risk over multiple platforms and vendors. Trust no one, and always have a Plan B.
This means making the assumption that everything that has been happening – vendor consolidation, commoditization of hardware and the subordination of operating system to DBMS and application – will continue unabated.
The days of the “HP shop” are long over. Even if you've decided to standardize on HP, Sun, IBM, you should do so with the knowledge that one day you may need to switch gears abruptly. In other words, these companies are noted for their legacy hardware, which you must be prepared to dump for another brand with as little pain as possible.
Start with a networked storage platform that supports as many operating systems as possible. This is the foundation layer for your IT infrastructure.
The best Total Cost of Ownership in IT is based on consolidation. However, that doesn’t necessarily imply homogeneity. It’s a matter of degree. It’s a matter of physical location as well.
Software drives hardware. Choose DBMS, applications, tools based on support for multiple operating systems and hardware. Be cautious regarding any decision that locks you into one vendor. For example, SQL Server based solutions, which only run on Wintel, will have higher transfer costs than Oracle or Sybase solutions.
Keep your vendors honest, but at the same time don’t underestimate the value of a true partnership. One company I consulted for dropped HP after learning that HP felt they “owned” them. Any time one side thinks they have the other over a barrel, there’s bound to be trouble. We’re all in this together.
We now know more than ever that there is no loyalty on either side of the bargaining table. The IT culture of planned obsolescence has accelerated, and any hope that a technology vendor will watch out for the customer is laughable at best. Ironically, in the computing arena, it’s IBM who seems to protect its customers the best. The shop I managed for 12 years was an IBM System 3 to HP 3000 Series III conversion. Who could have imagined?
Mix and Match
For the longest time I enjoyed being an HP 3000 user and an HP customer. Rather than see the HP 3000 as a “proprietary” platform that I was locked into, I looked it as an integrated platform where everything was guaranteed (more or less) to work together — unlike the emerging PC world where getting all the various components to work together was a nightmare.
But around the time that HP decided commercial Unix was the next big thing, the concept of heterogeneous computing was reaching critical mass. As discussed in my last column, the glory days of the HP 3000 were just too easy. IT decision makers seemed to have a complexity death wish, and we live with this legacy. Consequently, the way to lessen risk today is to spread the risk over multiple platforms and vendors. Trust no one, and always have a Plan B.
This means making the assumption that everything that has been happening for the past few years – vendor consolidation, commoditization of hardware and the subordination of operating system to DBMS and application – will continue unabated.
Separation of OS and Hardware
When the concept of hardware independence first manifested itself in the form of Posix, I was intrigued. Is this too good to be true, the user community having the upper hand on its technology destiny? Perhaps not the holy grail of binary compatibility among Unix flavors, but a quick recompile and hello new hardware. Well, it was too good to be true and nobody’s talked about Posix lately that I’ve heard anyway.
Likewise for Java. Write once, run everywhere — slowly. Yes, there are lots of handy applets and specialized tools that are Java based, but many of these Java applications use “extensions” the scourge of openness.
Two main operating systems that facilitate hardware independence are Linux and Windows. Each has its issues, from the standpoint of transfer costs. Linux, of course, comes in several flavors; all based on the same kernel, but tweaked just enough to derail binary compatibility. (Can’t we all just get along?) And Windows is from Microsoft, who knows something about locking people in then shaking them down. But while these two options are not without their problems, they represent at least the short-term future of computing.
Of the two hardware independent operating system solutions, Linux seems to me the better story. Clearly the flavor is a major decision, with Red Hat having the most support from major hardware vendors. But I have seen other distributions – notably SUse – adopted in large organizations, so don’t necessarily assume only one choice. The idea is not to turn this into “Linux everywhere” discussion, but to illustrate the concept of Linux as a means of avoiding being painted into a corner.
But will everything run on Linux? No. You almost certainly will need some kind of Windows presence, although I do business with some companies who absolutely, positively want nothing to do with Windows (and Microsoft). But that’s not typical. Most of us in IT resign ourselves to doing at least a little business with Microsoft.
Microsoft, however, has shown itself to be the boa constrictor of software companies. They never stop squeezing, especially when they know they have your critical applications. The hardware independence story is good, but Microsoft substitutes software dependence. Proceed with caution.
But the principle here is that even if you choose an operating system that only runs on one vendor’s hardware, you can at least mitigate the risk by choosing a DBMS and applications that can be transferred to another hardware and OS if necessary.
Newswire Classic
March 2005
After board demands CEO’s resignation, 3000 sites ponder new future
The CEO who hawked change as HP’s new mission — and so sparked the 3000’s exit from the company’s lineup — has left HP in a resignation that made some customers hope for a change in HP to alter the 3000’s fate.
But HP’s board of directors, after demanding Carly Fiorina’s resignation on Feb. 9, have shown no signs of changing the company’s commodity and consumer-driven strategy, one which hurried the 3000’s HP exit.
Interim CEO Bob Wayman told stock analysts the next CEO will need to march to the tune Fiorina composed during the five-plus years she headed the company.
The company won’t change because its board hasn’t changed much. Venture capitalist Thomas Perkins came on board in early February, but the list of directors includes a group of officers who have approved Fiorina’s plans to grow HP. The board said it removed its CEO and chairman because she did not execute HP’s strategy well enough. The company’s earnings growth has disappointed analysts in recent quarters.
Wayman said during an analyst briefing that the board is looking for a CEO to work with the current strategy: Offering a broad portfolio of products while operating a printer business integrated with the rest of HP.
“While they won’t preclude any open discussion on a new CEO’s view of what the future strategy should be,” Wayman said, “we are looking for a CEO who also embraces that strategy, in all probability.”
Fiorina, who earned $44 million in signing bonuses to join HP in 1999, left the company with a $21.1 million payout. Her contract also provides $50,000 in job counseling services, a point of irony that didn’t escape HP 3000 customers who have seen careers ended or altered after the 3000’s cancellation.
“She was the executioner,” said John Dunlop of 3000links.com “She chopped and pruned product lines and employees. Unfortunately for the HP 3000 community, the HP 3000 was one of the early casualties. Thus she became the name synonymous with the death of the HP 3000.”
Another customer said Fiorina represented a strategy of judging a customer by what they’ve bought lately. The 3000 customer has been expected to buy what HP produces after it said it won’t offer the HP 3000.
“Carly was viewed by many to be of the mindset that our value as customers was limited to our wanting to buy what HP had to sell,” said Russ Smith of credit union Cal State 9. “It was not that our value was inherent as customers, period — and that HP should produce what we need.”
The majority of customers were realistic about how much change would filter down to the HP 3000 issues that remain at the company. “HP now has bigger problems such that this issue won’t even be on the radar,” said John Wolff, the CIO at LAACO, Ltd and vice-chair of OpenMPE. “Not only did they break the HP 3000 product line, but Carly broke the whole company — 60 years to build it, six years to wreck it.”
Fiorina was the first CEO ousted from HP in such a public manner: Stories of the forced resignation aired on all major US TV networks; HP called a press conference to explain on the day it removed Fiorina. She was not the first to leave involuntarily, though. Another HP CEO, John Young, “was politely retired when Dave Packard came back out of retirement to put the company back onto the right path in October, 1992,” Wolff said. “Young was paid $1 million for ‘unused vacation time.’”
An enterprise change?
Some 3000 customers said they were hopeful a better enterprise server strategy would emerge under a new CEO. The majority of customers responding to a spot poll by the NewsWire reported they were migrating away from the server, a position that has them considering HP’s server alternatives. For many, the damage has already been done.
“We lost all faith in HP’s strategy some time ago,” said Don Baird, president of EnCore Systems. “We do not rely on anything HP except our 3000s, which we are replacing with non-HP solutions.”
HP’s change of heart is having an impact on a choice of vendor for migration sources. At the Anchorage, Alaska light and power utility, systems analyst Wayne Johnson is moving to Windows — but HP’s moves with the 3000 make the utility wary.
“Part of my company’s fear has been the HP 3000 is going away, so let’s steer clear of any other HP product,” he said. “Could the change mean that the HP 3000 will be resurrected and not meet its demise in 2006? Our Windows platform is not HP.”
Some drew a direct link to Fiorina’s strategy and the slide of HP’s enterprise business. “HP lost its personality under Carly. Their niche was solid, reliable computing platforms, not PCs and not iPods,” said John Lee of reseller Vaske Computer Solutions. “Hopefully, the new CEO will re-focus the company on its core strengths, one of which used to be enterprise computing.”
Even those moving to HP’s Unix systems want to believe more change in management is on the way. “I really hope the shakeup continues down the line,” said a long-term HP 3000 manager who wanted his name withheld. At his firm, HP 9000s are replacing HP 3000s. “Maybe we can get back to a point were the customer and our needs come first, and the profits and sales will follow,” he said. “Since the Compaq-HP merger, the quality of our service programs and sales support have dropped.”
The CEO’s departure won’t change much for Pivital Solutions, a company that signed on for the last year of HP’s authorized 3000 sales and now offers third-party support for the server and MPE. “The only hope I still loosely hold is that they will sell off the enterprise systems group before they run it into the ground,” said president Steve Suraci.
Operator seeks operations whiz
HP’s executives say the company now needs a CEO with better operational skills. Its top sales officer Mike Winkler, quoted in a published report from the recent Goldman Sachs Technology Investment Forum, said HP’s fortunes would rise with a CEO like Lou Gerstner, the IBM leader who came in to turn around that company in 1992. In that same year, HP’s founders Bill Hewlett and Dave Packard asked LaserJet czar Dick Hackborn to take the CEO reins from John Young. Hackborn wouldn’t leave his home in Boise, Idaho to take the job and retired a year later.
But Hackborn, an operator behind the scenes in most of HP’s business choices since his retirement, played the lead role in bringing Fiorina to HP after the company felt it missed out on the Internet boom during CEO Lew Platt’s watch. Another report, published in the wake of the Fiorina ouster by BusinessWeek editor Peter Burrows, says Hackborn acted as the catalyst to spark the board’s removal of Fiorina.
Now Hackborn and the rest of the HP board will try to find an operational, COO style of CEO. HP will change CEOs because of Fiorina’s inability to execute, not over her direction. “She had a strategic vision and put in place a plan that has given HP the capabilities to compete and win,” HP’s press release assured investors.
The strategy which Hackborn has pulled HP into — commodity sales like printers, with less direct customer contact — relies on resellers and outside distributors to stay in touch with all but the largest customers. Typical HP 3000 shops, working for small and medium-sized businesses, say they have not felt much contact with any HP operation except its support group.
“Working for a small company, I don’t feel that I or my company has ever been part of an ‘enterprise systems strategy,’” said John Bawden of health insurance provider QualChoice, an HP 3000 shop. “Generally we are ignored unless we have the energy and the need to go to HP for something.”
Continue reading "Carly's exit sparked new hopes for 3000" »
During the 1990s, Shawn Gordon wrote a column for the NewsWire on VeSOFT products and reviewed software for us. He also left the 3000 world for the novel pastures of Linux, long before that OS was a commonplace IT choice. His departure was an example of thinking ahead. Along those lines, Gordon's got a classy article from his website about Daylight Saving Time. DST is a failed experiment that costs everyone more money. California, where the HP 3000 was born, is on the path to eliminating DST. Arizona and Hawaii are already non-DST states.
DST became a thorn in the side of 3000 shops because it had to be accommodated with customized code. The cutover days, into Saving and then out of Saving, were different every year. A handful of clever jobstream hacks lurched systems into and out of time zones that were working perfectly until the law said every zone had to shift forward. Or back.
Here's Shawn's article, as polished as all of his offerings have been in both software and writing. You can write your US Representative to get this clock switching put away for good. The US Senate already is hearing a bill about this, although it's the misguided solution to make DST permanent. The alleged Saving has only been going on since HP first made 3000s. Since HP's given up on that, maybe the US can give up on Daylight Saving.
By Shawn Gordon
One might think that the societal contributions from New Zealand mostly consist of the band Crowded House and sheep-based products, but it is New Zealand entomologist George Vernon Hudson that we have to thank or curse for modern Daylight Saving Time (DST). Benjamin Franklin is often credited with the idea, but it is based on a satire he wrote in 1784 about Parisians rising late in the day. Hudson authored and presented a paper in 1895 to the Philosophical Society proposing a 2-hour shift. This was entirely due to him working a “shift schedule” and not having enough daylight left after work during certain times of the year to collect bugs. His proposal was entirely self-serving. If he couldn’t get the time off, he’d force society to change.
Shortly after, and totally independently, the prominent English builder and outdoorsman William Willett noted in 1905 how many Londoners slept through the beautiful summer days, and as an avid golfer, he also didn’t like playing at dusk. Willett is often wrongly credited as the man who came up with DST. Again, totally self-serving and a desire to control other people's behavior. Willett was able to get Parliament to take up the proposal but it was rejected, he continued to lobby for it until his death in 1915.
DST wasn’t formally adopted by anyone until WWI in 1916 as a way to conserve coal, but again, this only controlled behavior, it didn’t change time. The same results could have been had by just starting everything an hour earlier. After the war, DST was abandoned and only brought sporadically, notably during WWII, but did not become widely adopted until the 1970s energy crisis.
In 1973, President Nixon changed the US to year-round DST, which of course was silly, everyone could just start earlier. The act was repealed when it resulted in a marked increase in school bus accidents. A study done by Stanley Coren of the University of British Columbia in 1991 and 1992 showed an 8 percent jump in traffic accidents on the Monday following the “spring forward” time change. After some jumbling around for a couple of years, it was finally settled in 1975 to the last Sunday in April through the last Sunday in October. Making changes to computer clocks in those days was not trivial and this was an enormous burden in the budding technology sector.
In the mid-1980s, the Sporting Goods lobby and associated lobbyists were able to convince Congress to extend DST to the first Sunday in April, which increased DST from six to seven months of the year in 1986. Computers were now far more prevalent and the change had an even larger impact and cost that everyone just had to eat. Simply having to change the clock twice a year was an enormous burden.
The systems I worked on at the time required the computer systems be restarted to change the clocks, which meant making sure all batch processing was completed so you could have a quiet 20 minutes or so to restart the systems in the middle of the night, which required a human being be sitting there.
In 2007, as part of the Energy Policy Act of 2005, DST was extended another 4 weeks so that the United States and Canada are now on it almost two-thirds of the year. The claim was that this additional 4 weeks would save 0.5% electricity per day for the country, enough to power 100,000 homes. There is a provision in the act to revert to standard time if those savings didn’t materialize. A 2008 study examined billing data in the state of Indiana before and after the 2006 change to DST and showed an increase of 1-4 percent due to the extra afternoon cooling and increased morning lighting costs.
All public safety claims made in the 1970s by the US DOT have been discounted by later empirical studies by the NBS. Similar claims by Law Enforcement of reduced crimes were also discounted as the sample set was too small (two cities) and did not allow for any mitigating factors.
In November 2018, California passed Proposition 7 which repealed the Daylight Saving Time Act of 1949 that approved the clocks in California to stay in sync with changes made at the federal level. This is the first step in allowing California to either (sensibly) cancel DST altogether like Arizona and Hawaii, or (foolishly) staying on DST year-round. If a state as large and influential as California were to abandon DST altogether, you would likely see a lot of adoption across the US and possibly the end of this silly practice altogether. The people that think year-round DST is a great idea, don’t remember when we did it before.
Arbitrarily changing something like the clock has huge effects and costs across society, as previously noted. Major systems can go down from bad date calculations. There was an outage in Microsoft Azure on leap day 2012 because of a simple date math bug. Politicians and lobbyists are oblivious to these costs and concerns and blithely change the clocks around as though they are some Olympian Gods that command time itself.
Ultimately, it is the arrogance of politicians that seem to think they are creating or giving you an extra hour of daylight, when in fact they are just controlling everyone’s behavior. There is no energy savings, quite the contrary. It doesn’t improve public safety, it does none of what it is purported to do. What it does have is a deleterious effect on public health and safety. A negative impact on kids performance in school, as many studies show that kids do better in school by starting later in the day and DST is contrary to that.
DST mandates massive hidden costs and dangers in adjusting delicate computer software systems. Modern life does not require DST. Our lighting energy costs are trivial compared to our other usages like computers and TV. Flexible work arrangements and a global economy makeshift work mostly a thing of the past. It’s time to move to the 21st Century and drop this anachronistic legislative holdover that was developed by arrogant and self-serving men. Write your Senators and your Representatives and let them know what you think.
Photo by Darwis Alwan from Pexels
December 2004
Editor's note: Strobe abandoned its emulator project before Stromasys released its Charon emulator for PA-RISC in 2012. Strobe was the first to announce officially, though.
Strobe commits engineering time to design HP 3000 replacement
3000 support now stands by for the next seven years and beyond. Applications continue to work on HP 3000s. The base of MPE experience is adequate, with IT pros ready to pass on 3000 skills and employ what they know. The only thing missing for the HP 3000 afterlife is new hardware — and if a Pacific Northwest company succeeds on its mission, new 3000 systems won’t be missing for long.
Strobe Data, a company with almost 20 years of experience building hardware emulators, has revealed that it has started design on an HP 3000 emulator. Mike Penk, the engineer who just completed Strobe’s software-only product that emulates Digital’s venerable PDP-11 systems, is leading Strobe’s efforts. The end result will let PC hardware act as if it’s a system with HP’s PA-RISC CPU at its heart, the processor that drives both HP 3000s as well as HP’s older Unix systems.
The newest Strobe project will take several years to deliver its first version. Strobe’s president and founder Willard West said his company’s business experience in emulator lifecycles tells him there’s no rush to complete a product before HP leaves the 3000 support arena. In fact, the lack of vendor support for discontinued systems has been a part of the Strobe business model.
Used HP 3000s will still be in the market by 2007, but West says his company has never considered used systems as competition for Strobe emulators. Price won’t help used systems compete, he believes, even if they sell for a fraction of an emulator.
“If a customer’s going to buy used product, he can probably buy it for 10 percent of what our product will sell for,” West said. “But it’s used, and who’s going to support it? I just don’t see that the used market will be viable two years from now.”
After gathering data on the 3000 market last year, Strobe seemed poised to start design of a product they’ve built for other platforms. The company waited until the summer of 2004 had passed before tossing its hat into the homesteading ring.
“The need [for an emulator] has developed, and nobody has stepped in to address that need,” West said. “We have a solution that we have been working on, in various flavors, since 1985.”
No HP dependency
Design and testing of an HP 3000 emulator stood at the heart of early plans by advocacy group OpenMPE. Prior board members reasoned that without replacement hardware available to the market, the 3000 platform couldn’t maintain a mission-critical profile. Emulation — where a software suite or a hardware-software combination transforms a PC processor into accepting HP 3000 instructions — dominated OpenMPE and homesteading discussions until late 2003.
OpenMPE even worked to get HP to declare its intent to offer an emulator-level license for MPE/iX, available beyond 2006. HP managers from the HP 3000 division offered a letter of intent to demonstrate their commitment to support an emulator with such a license.
But OpenMPE activity during the past year has focused on getting a limited license from HP to use the MPE source code in development outside HP. In the group’s latest strategy, 3000 hardware would be plentiful, while MPE/iX will need continued care after HP shut down its MPE/iX labs. HP has said it won’t decide on such third-party licensing of MPE source until the second half of 2005.
Stobe’s project doesn’t depend on anything that HP might decide. West said keeping MPE/iX static, with no further development beyond HP’s efforts, works for a marketplace accustomed to reliability.
“I kind of see OpenMPE going in the wrong direction,” West said. “People are homesteading because they have a reliable piece of software and reliable hardware. When people start talking about changing either one of those, they get nervous. What assurance do they have that the OpenMPE group has the resources to do this?”
Understanding software
Although Strobe’s aim is to create a product that processes MPE/iX commands exactly like an HP 3000, Strobe’s efforts could require more intimate knowledge of MPE’s internals than the company has on its staff today. The emulator itself is likely to be a software product at first, running on an Intel Pentium chip and using Linux to manage system operations. This design follows the model Strobe used in its most recent emulator, a software suite called Osprey/MP that mimics the Digital PDP-11 hardware.
Performance challenges might push Strobe to incorporate custom-designed hardware in its emulator, West said. “We may build a PA-RISC hardware platform eventually,” he said. “If the customers need more speed than say, a 4Ghz dual Pentium-4 can give them, we’ll have to turn to the hardware implementation.”
Strobe sells hardware products which emulate the HP 1000 servers, used for real-time applications, as well the Data General Eclipse servers and those PDP-11s. Strobe recommends its customers use server-class PCs with top-grade memory and storage when emulating these business-class servers.
HP’s letter of intent for licensing MPE/iX on an emulator requires customers to use HP computers, although engineers at HP say there’s no way for MPE/iX to check what kind of PC is executing the 3000 applications’ instructions.
In the meantime, HP has said that it will transform HP 9000s into HP 3000s on a limited basis, which would keep even more sites on HP-built hardware. West is unconcerned about HP’s latest offer, one that might be available only to the largest of HP 3000 users.
“Can I kiss them for doing that?” he asked. “They’re keeping those customers in stasis for me when they do that.” Staff at HP’s own IT operations have been asking about how to compare HP 9000 models to 3000 counterparts, so HP’s IT shops could continue to use transformed 9000s for business-critical MPE/iX applications.
Those software applications extend the lifespan for an emulator product, West said. “There’s lots of things that can happen to software,” he said, “like it’s not documented, or the people who wrote it aren’t around anymore. There’s lots of reasons to homestead.”
Bootstrapping work
Strobe says it has several customers who have offered it seed money to start work on an HP 3000 emulator. Rather than raising capital to start development, Strobe can use profits from its emulator business to begin work. “I have a company, a foundation of an income stream,” West said. “I can make the commitment and then have the money flow in.”
Some of the most extensive work on the project will involve managing IO streams between storage and the emulated processors. West said enlarging the volume size an operating system can handle is the problem his company has most frequently encountered.
Strobe will build an execution engine for the PA-RISC instruction set, an effort that “will take no more than 30 percent of the effort” on the project, West said. Most of the challenge of making software stand in for a computer lies in virtualization: the redirection of peripheral data into and out of the core processor. IO instructions are trapped and passed to the host, so disc drive models are emulated in software under Windows or Linux.
Strobe’s emulator will only be aimed at supporting the 32-bit mode of the HP 3000 and HP 9000. A version that runs Linux will come first, to prove the PA-RISC emulation concept, West said. Unix is likely to follow, and then the Strobe emulator will have to mimic the “BIOS switch,” as West called it in shorthand, which tells MPE/iX that it can continue booting on the hardware.
The MPE nuances that make HP’s PA-RISC computers become HP 3000s lie closer to the end of Strobe’s emulator project. West believes his company will have access to 3000 experience by then.
“When we get to the point where we want to run MPE as a test, I have great confidence that HP, with that [MPE/iX] license, will tell us how to implement that switch,” West said. “We’ll certainly have experience in the operating system by the time the product is up and running.”
Newswire Classic
By Ken Robertson
[Ed. Note: Bob Green of Robelle reminds us that both MPE and Unix have scripts, but there are a number of differences. To explain, he offers this article written when Ken Robertson was at Robelle.]
Before MPE/iX, there was a run-time environment for the MPE/V class of HP computers called the Command Interpreter (CI). This MPE/V CI had limited programming capability, with If/Else constructs and numeric variables limited to values between 0 and 65535. The basic interface of the MPE/V CI (Command Interpreter) was ported to MPE/iX machines, and beefed up so it would be usable as a run-time shell.
The MPE/iX command interpreter has a generous command set, pushing the shell into the realm of a true programming tool. Its ability to evaluate expressions and to perform I/O on files allows the end-user to perform simple data-processing functions. The CI can be used to solve complex problems. Its code, however, is interpreted, which may cause a CI solution to execute too slowly for practical purposes.
Command files are a collection of commands in flat files, of either variable or fixed length record structure, that reside in the MPE or POSIX file space. Basically, command files are what you could call MPE Macros. Anything that you can do in the CI interactively, you can do with command files, and then some. You can use command files in situations that call for repetitive functions, such as re-compiling source code, special spooler commands, etc. Command files are also great when you want to hide details from the end-user.
A command file is executed when its name is typed in the CI, or invoked from a command file or programming shell. Just as in program execution, the user’s HPPATH variable is searched to determine the location of the command file.
MPE Scripts Versus Unix Scripts
For the average task, the MPE scripting language is easier to read and understand than most Unix scripts. For example, command line parameters in MPE have names, just like in regular programming languages.
Of course, there are several script languages on Unix and only one on MPE! On Unix you can write shell scripts for any of the many shells provided (C shell, Bourne shell, ksh, bash, etc). Although there is also now a Posix shell on MPE, most scripts are written for the CI. Several third-party tools, such as Qedit and MPEX, emulate HP scripting and integrate it with their own commands.
A command file can be as simple as a single command, such as a Showjob command with the option to only show interactive sessions (and ignore batch jobs):
:qedit /add 1 showjob job=@s 2 // /keep ss /e :
You have created a command file called SS — when you type SS you will execute showjob job=@s
On MPE, the user needs read (r) or execute access (x) to SS. On Unix you normally must have x access, not just r access, so you do a chmod +x on the script. This is not necessary in MPE, although, if don’t want users to be see the script, you may remove read access and enable execute access.
Structure of a Command File (aka CI script)
A script is an ASCII file with maximum 511 byte records. Unlike Unix, the records may contain an ASCII sequence number in the last 8 columns of each line. The command file consists of 3 optional parts:
1. Parameter line with a maximum of 255 arguments:
parm sessionnumber
parm filename, length=”80”
2. Option lines:
option nohelp,nobreak
option list
3. The body (i.e., the actual commands)”
showjob job=!sessionnumber
build !filename;rec=-!length,,ascii
In MPE scripts, there is no inline data, unlike Unix ‘hereis’ files.
Parameters
Notice in the example above that parameters are used with an exclamation (!), as opposed to the $ in Unix. The same is true for variables. Parameters are separated by a space, comma or semicolon. All parameter values are un-typed, regardless of quoting.
In a typical Unix script, the parameters are referenced by position only ($1, $2, $3, …). In an MPE script, the parameters have names, as in the function of a regular programming language, and can also have default values. In Unix you use $@ for all of the parameters as a single string; in MPE you use an ANYPARM parameter to reference the remainder of the command line (it must be the last parameter).
Here is a script to translate “subsys” and “err” numbers from MPE intrinsics into error messages. The subsys and error numbers are passed in as parameters:
parm p_subsys=108,p_error=63
setvar subsys hex(!p_subsys)
setvar error hex(!p_error)
comment the hex conversion allows for negative numbers
comment the #32765 is magic according to Stan!
setvar cmd “wl errmsg(#32765,!subsys);wl errmsg(!error,!subsys);exit”
debug !cmd
As you can see above, the Setvar command assigns a value to parameter or to a new variable. But there are also system pre-defined variables. To see them all do Showvar @;hp. To get information on variables, do help variable and to get help on a specific variable, say hpcmdtrace, do help hpcmdtrace (set TRUE for some debugging help).
In most MPE commands, you must use an explicit exclam ! to identify a variable: build !filename
However, some MPE commands expect variables, and thus do not require the explicit !. For example, Setvar, If, ElseIf, Calc, While, and for all function arguments, and inside ![expressions].
Warning: variables are “session global” in MPE. This means that if a child process, or scripts, changes a variable, it remains changed when that child process terminates. In Unix you are used to the idea that the child can do whatever it likes with its copy of the variables and not worry about any external consequences.
Of course having global variables also means that it is much easier to pass back results from a script! And this is quite common in MPE scripts.
Options
Options allow you to list the commands as they are execute (option list), disable the Break key (option nobreak), enable recursion (option recursion), and disable help about the script (option nohelp).
The script body below shows active process information. This example shows many of the commands commonly used in scripts: If, While, Pause, Setvar, Input and Run. Other commands you will see are Echo, Deletevar, Showvar, Errclear.
WHILE HPCONNSECS > 0 IF FINFO("SQMSG",0) PURGE SQMSG,TEMP ENDIF BUILD SQMSG;REC=-79,,F,ASCII;TEMP;MSG FILE SQMSG=SQMSG,OLDTEMP SHOWQ;ACTIVE >*SQMSG SETVAR PINLIST "" WHILE FINFO("SQMSG",19) <> 0 INPUT SQLINE < SQMSG IF POS("#",SQLINE) <> 0 THEN SETVAR PIN RTRIM(STR(SQLINE,47,5)) SETVAR PINLIST "!PINLIST" + "," + "!PIN" ENDIF ENDWHILE IF FINFO("SPMSG",0) PURGE SPMSG,TEMP ENDIF BUILD SPMSG;REC=-79,,F,ASCII;TEMP;MSG FILE SPMSG=SPMSG,OLDTEMP SETVAR PROC "SHOWPROC PIN="+"!PINLIST"+";SYSTEM >*SPMSG" !PROC WHILE FINFO("SPMSG",19) <> 0 INPUT SPLINE < SPMSG IF POS(":",SPLINE) <> 0 THEN ECHO !SPLINE ENDIF ENDWHILE PAUSE 30 ENDWHILE
Handling Errors
In most Unix scripts, if a step fails, you check for an error with an If-conditional and then take some action, one of which is ending the script. Without an If, the script continues on, ignoring the error.
In MPE, the default action when a step fails is to abort the script and pass back an error. To override this default, you insert a Continue command before the step that may fail. You then add If logic after the step to print an error message and perhaps Return (back 1 level) or Escape (all the way back to the CI).
continue build newdata if cierror<>100 then print "unable to build newdata file" print !hpcierrmsg return else comment - duplicate file, okay endif
You can set HPAUTOCONT to TRUE to continue automatically in case of errors, but this can be dangerous. The default behavior at least lets you know if an unexpected problem occurs.
User Defined Commands (UDC)
UDCs are like Command File scripts, except that several are combined in a single “catalog” file. They are an older feature of MPE, so you may see them in older applications even when scripts seem like a better solution. The primary reason that they are still useful is that they support Option Logon, which invokes the command when a user logs onto the system.
From our archives of 2003, a report on devices to house and attach storage to a 3000. These arrays are still in the wild, available from resellers. And they're quite a bit less expensive than nearly $55,000.
HP brings new RAID array, JBOD enclosure online
HP 3000 to get access to systems using Ultra320 disks
HP 3000 customers looking for RAID disk storage and newer enclosures for Just a Bunch of Disk (JBOD) configurations have two new products to consider. HP is introducing an upgraded VA7110 virtual array for the HP 3000, a 45-disk configuration, up from the 15-disk 7100 arrays. Like its 7100 predecessor, the 7110 supports RAID 1+0 and RAID 5DP (double parity).
HP’s 3000 hardware manager Kriss Rant said the device leverages performance improvements from HP’s VA7410 virtual array into a lower-cost unit, at a price point “which is the sweet spot of the older 7100 arrays, the low-end of the midrange,” according to Rant.
Pricing before discounts shows the VA7110 coming in at slightly higher prices than the 7100, $54,984 for a 7110 with four 36Gb disks and a 512Mb cache, versus $48,354 for the same configuration in a 7100. Prices drop slightly per Mb of storage when comparing the 7100 fully loaded versus a 15-disk 7110.
The 7110 operates with both MPE/iX 7.0 and 7.5, using an SCSI to Fiber Channel router on 7.0 and native Fiber Channel in 7.5 implementations. The new array supports the 146Gb 10,000 RPM drives from HP, and the vendor says in some cases this array can double the performance of the 7100. The total capacity of the 7110 can run as high as 6 terabytes, and the unit accepts 15,000 RPM drives of 36Gb and 73Gb, and 10,000 RPM drives of 36Gb and 73Gb, in addition to those 146Gb drives.
HP 3000 JBOD choices will be expanding to the DS2110. It’s a fully compatible replacement for the DS2100, the current JBOD enclosure supported under MPE/iX. The older 2100 is coming off the HP price list on July 15. While the 2110 supports the newer Ultra320 SCSI disk mechanisms, those drives are also limited to the 80Mb/second support constraints of MPE/iX. But the device will let HP 3000 customers use a wide range of disk devices from HP, including HP’s Ultra160 SCSI disks.
The 2110 supports mixed disk capacities, and HP 3000 sites can load it up with as much as 584 Gb of capacity in a 1U enclosure. It can be used with a PCI disk array controller as a low-cost RAID solution.
HP’s introducing the DS2110 to ensure a steady stream of disk mechanisms for the enclosures, since it’s discontinuing its Ultra160 disks. The newer Ultra320 disks can negotiate down to Ultra160 IO cards.
While HP 3000 customers can’t use more than 80Mb/second of this bandwidth today, Rant said the project to upgrade MPE/iX drivers to accept all of the Ultra320’s 320Mb/second of bandwidth “hasn’t dropped off the engineering prioritization list yet.”
The HP 3000 has been misunderstood and unconsidered for much of its lifetime. The confusion has been deliberate sometimes, and just awkward at others. The latest miscue is a replay of bad information from a reputable news source, USA Today. It might come as a surprise that a vaunted national newspaper would care about a computer first sold in the 1970s. As it turns out, that start of sales was at the heart of the 3000's mention.
This computer was never a PC, as stated in the article Common Myths About Industrial Automation, Debunked. In 1972, hardly anything was for sale as a personal computer. The 3000, of course, is a minicomputer and didn't emerge for sale until 1974.
Common Myths About Industrial Automation, Debunked
It might not be as dramatic to call a $571,000 system a minicomputer or a business server. Just about any useful business computer of the 1970s was a five-figure investment in those early days. Not so for PCs.
The fantasy from USA Today was compounded in IOT for All, a tech advisory website about the Internet of Things. "When technologies first hit the market, people pay a premium. Think of the personal computer. The first small(ish) business PC from Hewlett-Packard, the HP 3000, cost an inflation-adjusted price of $571,791 in 1972."
IOT went on to say, "Luckily, automation has moved on from the super-new, ultra-expensive technology bracket and into the mainstream. It’s much more affordable to install automation equipment in a factory today. Companies will see ROI much faster than in years past through a combination of better, more refined technology and very reasonable price tags. The benefits are cyclical—automation lowers the price of goods while it increases labor productivity.
And from USA Today, here's the source of the mistaken identity of the 3000.
What was the price of a computer sold the year you were born?
1972
• Notable computer: HP 3000
• Price tag: $95,000
• Inflation adjusted price: $571,791
USA Today went on to say, "Hewlett-Packard's 3000 was the company's first foray into smaller business computers. The original 3000 was generally considered a failure, but the company would go on to make 20 different versions of the 3000 through 1993."
And there's where the truth settles in: The 3000 was a failure in its first release, so much so that the vendor offered 2116 servers (the ancestor of the 3000) as a replacement for the few that were shipped into the wild. Of course, HP offered business computers smaller than IBM, but the 3000 was the biggest business computer the company had ever created.
The Listserve software says there’s 363 of us on this mailing list, so here’s a simple question to you all. Which company are you paying to help support your 3000s — or your MPE server (since the latter can be a Stromasys box)? Self-maintainers, go ahead and brag.
I want to provide an option for rebooting an HP 3000 remotely using LDEV 21. How do I do it? Can I using a modem and landline or an IP address to get to LDEV 21?
Gary Stephens replies
Yes, you can use a modem on the remote support port set to auto answer. This will definitely work. It was more about controlling access to the console remotely. I recall one site that had a modem with a remote call-back to a known inbound number that was effective. Upon answer you were prompted for a U and P that had a dial-back associated with it. Ultimately it's all down to risk and your appetite for change.
Even though HP this week announced its Insight Online enhancement for enterprise support, the changes won't be of help to 3000 owners. The remote management technology, designed to improve response times, is another example of new support products HP won't deliver to the MPE sites it's retained over the eight years since the server's sales ended.
After a full year of absence from the HP 3000 community, the support arm of Hewlett-Packard has been disappearing from customer choices for 3000 maintenance. Hardware is the only public offer that the company pushes on its old clients, according to reports from the field. But HP hasn’t retracted its reach entirely for the insurance-only support dollars backed by a declining set of resources.
“Most people have aligned themselves with an independent provider at this point,” said Pivital Solutions president Steve Suraci. His shop that’s completely devoted to supporting MPE/iX and HP 3000 systems runs across straggler accounts when customers say they’re in the last 18 months of a migration and therefore stick with HP. But it’s a rare encounter by now, at least in public.
“It’s not as much as it had been,” said Pivital Solutions president Steve Suraci. “In this new year I had two customers come to me that they never received a message from HP on support renewal — for the first time ever. In other cases I’ve continued to see HP.”
The departure of HP support options still comes as news to a few customers. Last month a manager running 3000s at fuel-pump manufacturer Gilbarco queried the 3000 newsgroup for an update. "Our HP 3000 maintenance contract is up for renewal on June 30th, but HP have told us that they will not be renewing the contract," he said. "Is this commonplace across the globe?"
Software support for the systems is just about non-existent, at least on a public basis, Suraci said. “It’s really just been limited to hardware aspects of support.”
Newer CPUs and chassis are most likely to make it onto HP’s supported devices list. N-Class or A-Class servers might be offered from a local sales office as supportable items. MOD 20 storage units are another example of cherry-picked items that would match only a small part of an independent support vendor’s coverage lineup.
But that HP coverage can be wildly uneven. “A lot of times they’re supporting the disk arrays, but not the drives in the arrays,” Suraci said. HP offered to support just one of the two internal disk drives in a customer’s Series 928, and not the internal tape drive.
In a case such as that, a service call could devolve into determining which disk drive may have failed, with the case ending with a report of unsupported devices. Lower-end 3000 systems are rarely on an HP support account by now. Higher-end accounts are more likely to fall into the HP folds after years of more extensive attention.
Inside VESOFT covers tips and techniques you can use with VESOFT’s products, especially MPEX.
Some pretty sophisticated job scheduling abilities are inside MPEX/Streamx. They don’t get talked about often, but they are really very cool to use if you don’t already have a scheduler. Since this does rely on Streamx, it will be necessary for you to own Security/3000 for it to work. The SHOWJOB was enhanced to support this, a new command (SHOWSCHED) was added to give direct support, and a new parameter was added to STREAMX, ::SETSCHEDULE, that does some basic interfacing.
First let’s take a look at the SHOWJOB command below.:
Syntax: %SHOWJOB [mpe showjob parameters]
[;JOB=@A]
[;NOSEC]
Examples: %SHOWJOB JOB=@A
%SHOWJOB SCHED;NOSEC
%SHOWJOB [email protected];*LP
%SHOWJOB
JOBNUM STATE IPRI JIN JLIST INTRODUCED JOB NAME
#S2 EXEC 20 20 WED 7:41A SHAWN,MANAGER.SYS
#J3 EXEC 10R LP WED 7:43A BACKG,MANAGER.VESOFT
#S3 EXEC 2 2 WED 8:05A SHAWN,MGR.SMGA
3 JOBS:
0 INTRO
0 WAIT; INCL 0 DEFERRED
3 EXEC; INCL 2 SESSIONS
0 SUSP
JOBFENCE= 6; JLIMIT= 2; SLIMIT= 40
JOBNUM STATE R SCHED-CONDITION SCHEDULED-INTRO JOB NAME
#A1 SCHED + SMTWRFA 0:10 FYIMAIL8,MGR.SMGA
#A2 SCHED + -MTWRF- 0:15 DAILY,MANAGER.SYS
#A3 SCHED + S-----A 0:35 DISCLEAN,MANAGER.SYS
#A4 SCHED + -MTWRF- 1:30 BACKUP,MANAGER.SYS
#A5 SCHED + WHENEVER BETWEEN(HPDAY,2,6) AND... DBTREND2,MANAGER.SYS
#A6 SCHED + WHENEVER (HPDATE=1) REPORT,MANAGER.SYS
#A7 SCHED FRI 9/16/94 10:00 TESTSCHD,MANAGER.SYS
7 STREAMX SCHEDULED JOBS.
The MPE :SHOWJOB command has been enhanced to display STREAMX scheduling information as well as MPE :SHOWJOB information. When appropriate, STREAMX scheduling information is automatically displayed after the status section of the MPE :SHOWJOB command. In addition, VESOFT has created a new %SHOWJOB userset of @A to represent all STREAMX scheduled jobs.
The SCHED-CONDITION/SCHEDULED-INTRO columns display different information depending upon whether or not the job repeats on specific days, is scheduled to submit on a particular day and time or if the job should be launched when a particular condition occurs. Repeating jobs are indicated by a “+” character after the word “SCHED”. For jobs that are scheduled for a particular day and time, that information is displayed much the same as MPE scheduled jobs. For conditional jobs, as much of the condition that can be displayed on one line will be printed, followed by “...” if the conditional expression is longer.
This is essentially the same format as the %SHOWJOB command, and shows the same information as the %SEC SHOWSCHED command. %SEC SHOWSCHED, however, will display the entire condition under which a job will be submitted, as you can see here:
Last -Days-
#A Job Name Submitted By Job
# SMTWRFA-Time-
6 REPORT,MANAGER.SYS
SMG,MANAGER.SYS J1032
WHENEVER (HPDATE=1)
CHECKEVERY DAY
Since the default is to display both jobs and sessions, simply typing %SHOWJOB alone will display MPE jobs and sessions, MPE scheduled jobs, the MPE status block, and STREAMX scheduled jobs in that order. To display only STREAMX scheduling information, type %SHOWJOB JOB=@A. To suppress STREAMX scheduling information, include ;NOSEC as part of the command.
With the ::SETSCHEDULE command, the job stream can specify its own scheduling parameters, e.g.
!JOB DELSPOOL,MANAGER.SYS; OUTCLASS=,1
::SETSCHEDULE AT=02:00
or
::SETSCHEDULE AT=?When would you like to schedule this job for?
What follows the ::SETSCHEDULE must be the :STREAM command scheduling parameters, exactly as they’d be specified after the “;” in the :STREAM command (e.g. “::SETSCHEDULE AT=02:00;DAY=MONDAY”).
Note that if the user explicitly specifies scheduling parameters when he runs STREAMX (e.g. in the STREAMX UDC), those parameters will be used and any ::SETSCHEDULE command in the file will be ignored. This lets a user override the ::SETSCHEDULE settings in the file.
Also note that if you specify several ::SETSCHEDULE commands in one job stream, the FIRST one will take precedence. It’s important to note that the new parameters can be specified at submission or with the ::SETSCHEDULE. So the STREAM command through STREAMX now supports the following syntax:
:STREAM filename
[;REPEAT= [DAILY|WEEKDAYS|day of week[, ...] ] [;WHENEVER=
condition]
[;WHEN= condition]
[;CHECKEVERY= minutes| DAILY ]
[;MPE SCHED PARMS]
It’s the “condition” that is so flexible in this new format. Check out some of these examples:
• ...stream a job at a scheduled time each day:
:STREAM MAINJOB ;REPEAT=DAILY ;AT=01:00
• ...stream a job several times each day (once each hour):
:STREAM XPMAIL.MAILJOB.SYS;&WHENEVER=
(BETWEEN(HPHOUR,6,17) and (HPMINUTE=0))
• ...stream a job once a month:
:STREAM REPORT.JOB.SYS;WHENEVER=(hpdate=1);
CHECKEVERY=DAILY
• ...stream a job if another job fails (aborts):
:STREAM RECOVER.JOB.SYS;
WHEN=JSCOUNT(‘POST,MGR.PAYROLL’)=0
The hard part really is just in making sure that your syntax and parameters are exactly what you want. Some trickier stuff you might try to do would be when you want to stream job A when job C finishes with no errors, but stream job B if it fails for some reason. All of this can be done, it just takes a little think time.
Photo by Brett Sayles from Pexels
The word progressive is on the rise again in our vocabulary. The term rose at first in the turn of the 20th Century, when it signified something that envisioned a better future. In some cases, those progressive tactics were aimed at reforms. You might compare reforms to removing old, buggy versions of compilers to replace them with newer, more capable ones. If you go back far enough, people running HP 3000s were replacing FORTRAN 66 with FORTRAN 77, or replacing MPE written in SPL with MPE/iX in Modcal.
Then there's the progressive tactic of devising something new to meet a need where no solution is in place, old or otherwise. Progressives in the first decade of the 20th created the US Food and Drug Administration. Today, 114 years later, the FDA will be gatekeepers to our survival in the US. All COVID-19 vaccines pass through the FDA.
The HP 3000 equivalent of such a progressive tactic might be MPE/iX source code licenses. Nobody knew why the market would need access to the innermost code for the 3000's OS. Then the HP business changed, dropping 3000 future development. The hit on the market meant more internal designs had to become external tools. Independent support companies, as well as some well-schooled utility vendors, earned the right to read trade-secret code for MPE/iX.
While there's very little need today for that sweeping kind of progressive behavior for an HP 3000 customer, the other kind of forward-looking progressive plans have become too short in supply. Running an HP 3000 in a production environment with mission-critical duties isn't an automatic trigger for support anymore. This isn't true in every production case, but the decline of this progressive investment outlook is costing the community, even while it saves some dollars in operating expenses.
One notable loss is that our most stalwart sponsor, Pivital Solutions, is shifting its resources away from the HP 3000 starting in January. Other support companies have already sidetracked or ended their offerings. Pivital held on longer than nearly all of 3000 expert companies. It remains well-stocked with know-how, not to mention one of those rare MPE/iX source licenses. Source solves problems HP did not anticipate. But the growth of its 3000 customers stopped several years ago, president Steve Suraci reports.
"We will continue to honor our obligations to support our remaining base through 2027," he told me this week, "but we can no longer limit ourselves by our 3000 tethers."
The situation may be different at other companies, but my experience and reports show that eliminating 3000-related budgets is everywhere. "The sites that remain are no longer looking to be progressive," Suraci says. "The vast majority of the remaining customers still use the 3000 for mission-critical functions, but they no longer invest in the platform. They make no pretense when it comes to budgets."
Suraci and his company have been ardent supporters of the 3000's mission ever since the company entered the market almost 30 years ago. At first, there was its work in the GrowthPower ERP market. GrowthPower was an MRP II system with integrated financials that ran exclusively on the HP 3000. There was, at one time, over 1,000 customers for GrowthPower.
About a decade later, Pivital joined the ranks of vendors who sold new HP 3000s as an authorized reseller. This promised to open the doors to sales to even more 3000 use that went beyond MRP. Less than a year after Pivital joined HP's reseller lineup, though, Hewlett-Packard canceled its future development for the 3000.
Pivital was being progressive about its role in the 3000 market. HP didn't reward anyone who stepped out like that, especially so in the case of Pivital. The company was the last one joining the reseller ranks. It didn't rattle Suraci and his team much. They stood their ground on support and remained exclusive to the HP 3000. Many support companies try to maintain a wider range of expertise. Sometimes that means the knowledge base isn't as deep.
It's better for the customer that we specialize, he told me more once. He also reminded the market that its support vendors need to have parts in a depot, rather than shopping for a replacement at the last minute.
"Customers are all too willing to risk their support on a pipe dream that a capable closet technician will show up at a moment's notice, with no service level agreement or parts inventory to support them," Suraci says. There are plenty of parts in the market — but having specifically what a customer needs within a four-hour response time means that the right way to support a site is with a depot.
HP abandoned its 3000 base almost two decades ago, "but we embraced the remnants," he said. "Initially, it was a great match. There was still a progressive base, and we were a willing partner capable of helping them reach their initiatives. "
Over time, he says, things changed. Suraci is unique among support firm presidents. For many years now, he's advised his customers to move onto a computing solution that's supported by a vendor or a marketplace. Something other than an HP 3000 and MPE/iX, to be precise. "For all the right reasons," he says, "the base dwindled as users migrated to more current technologies."
It might have happened more gradually without that vanishing progressive strategy. A site committed to a support budget, with some designs on refreshing architecture where they can, will still be able to rely on the HP 3000 for a good long while. There are seven more full years of MPE/iX use before the 2028 date decision looms. There are even solutions announced or in development to clear that hurdle.
What's not been done, however, is the adoption and practice of supporting every mission-critical 3000. That would include the archival systems holding key data, the kind that regulators demand. Since the progressive tactics have faded, these plans are sending 3000 vendors into new directions. Good vendors like Pivital are curtailing their connections. Supporting your vendor is good for your future.
Earlier this month, a long-time 3000 migration firm pointed to an IEEE article about legacy IT investments. Inside the Hidden World of Legacy IT Systems quotes a study by Statista that reports that three-quarters of all IT spending since 2010 goes toward operating and maintaining existing systems. The numbers throughout the IEEE article tell a story that's familiar to legacy managers like those who maintain HP 3000s. $2.5 trillion, out of a total IT spend of $35 trillion, has gone to trying to replace legacy systems. Nearly a third of that has been spent on failed efforts.
Fresche Solutions' co-founder Jennifer Fisher pointed at the legacy link. The company was once called Speedware, selling development tools and experience with legacy systems. By today, the company's got 22,000 customers, many in what 3000 managers would call the AS/400 space, and it sells X-Analysis, onboarding software that delivers reports on what's inside a legacy installation's many software modules.
Christine McDowell, VP of marketing at Fresche, says that legacy systems got themselves into a jam because they've run so effectively up to now. "The systems ran so well that they didn't change a lot," she says. "Time has caught up with them." Older languages, such as RPG in the IBM Series i space that's the modern name for AS/400, are providing a lot of the pain for legacy refreshes.
The company is still managing HP 3000 resources, along with Series i systems, as part of its solutions. There's no more growth in the Series i market than in the HP 3000 space: "We don't see net new IBM i," McDowell says. The growth has been negative in the HP 3000 world. Legacy is holding its own overall, but some platforms are more fixed in place than others.
Many legacy systems, though, share one common element that makes them continued ramparts. "The need for an integrated system is just as great as before," McDowell says. As one of the original group of HP 3000 Migration Partners in 2002, Speedware sold its customers on the advantage of having 100 percent referenceable projects. The Fresche customer base today is many times the size of Speedware's. "It's always been a part of our DNA to strive for 100 percent referenceability," McDowell says. "I never say 100 percent now, because I haven't talked to every customer."
Legacy is surviving in large measure because companies are facing what's called the succession problem. "It's the reality of the people who built and managed these systems," McDowell says. "There was often no succession plan."
To keep the legacy technology relevant, it's got to be modernized. Not everyone needs every aspect of modernization. For the a la carte shoppers, a subscription service can now take the place of capital expenses. IBM's Series i market is distinctive because it still enjoys the support of its creator. More than two thousand business partners and vendors still sell into that market. It's a multi-OS chip ecosystem, supporting a Unix variant, the AS400 environment, as well as mainframe-style systems.
There's proof that the HP 3000 remains in use as a legacy solution, McDowell says. Dun and Bradstreet Asset Reports still show a large number of companies reporting 3000s in service. "Companies still get value from these systems," she says. "They just need to figure out which pieces they will leverage."
This holiday weekend, many of us can give thanks for surviving a year unlike any other. A pandemic is one way to learn how deep your fortitude can go. It was easier to love a business computer that was still being manufactured and sold. Even if the sales were disappointing and irregular, newer systems were still going into the world.
In love, we find out who we want to be. In war, we find out who we are. This has been a year of war for health, and it brings us close to two decades of battle to keep resources at hand for 3000s.
By this weekend, the only systems headed into the world running MPE are the new releases of the Stromasys Charon emulator and some experimental installs of a Classic 3000 emulator. The latter SIMH software runs MPE V and it has devoted hobbyists around it. That emulator is not a production asset. The one from Stromasys is proven.
On a holiday invented to promote thanks as well as outsized eating, Thanksgiving reminds us of what a 3000 user can thank the gods for — and something to envy, too.
Prolific commenter Tim O'Neill has asked, "Can you write about the current futures of other no-longer-supported systems such as HP 1000, Alpha, and old HP 9000s?"
We can write some of that. The HP 1000, a product line that HP turned off just after Y2K, still has third parties who will maintain and support RTE operating system applications. The HP 1000 got a proper emulator from Strobe Data, engineered just in time to capture the business of companies who couldn't part with RTE apps.
A similar story is true of the AlphaServer line from HP. Killed off in the last decade, Alpha is a third-party supported product. No other Alpha computers were built after HP shunted Alpha users to the Integrity line, a migration path of now-dubious future. Alpha has a good emulator in the AXP version of Charon from Stromasys. The presence of Charon also prompts thanks from companies who can't support the concept of 17-year-old HP hardware running MPE/iX.
But while the Alpha and the 3000 live on in the virtualization of Stromasys, both communities can be envious of the deal another retiring environment received from HP. OpenVMS lives on in an exclusive license to VMS Software Inc. The company got a 2013 arrangement to carry OpenVMS forward with new versions using the HP source code for the operating system.
OpenVMS futures have some tantalizing what-if's, both for the OS as well as for the 3000 users who wanted more MPE/iX future from HP back in 2002. OpenMPE campaigned for use of HP's source code for MPE and got an arrangement that was announced 13 years ago this week. That source was limited to a technical support resource, however.
If, as happened with OpenVMS, that source had been promised to a single third party, six years before HP would drop support like it was for OpenVMS, there could be more to be thankful for by now. Extensions of some third-party applications. Support for newer technologies. A replacement OS vendor, blessed by HP, to mention in boardroom meetings about the 3000's future.
Perhaps OpenVMS customers should be thankful for something else, too: lessons HP faced about ending the life of a business operating environment, delivered from the OS that had brought HP to the computing game. Third parties who love and care for a legacy computer were at the ready for the 3000. They fell short of convincing Hewlett-Packard to turn over a marketplace. It seems HP learned that leaving customers with no better choice than replacing a 3000 with Windows was not business that anybody feels thankful for.
Using the analogy of moving out of a house, an MB Foster Webinar shows how application portfolios can tell a company when it's sensible to move apps. Sometimes it's off the 3000 altogether, and then it triggers retirement. Migrations can lead that way. At Boeing, as well as TE Connectivity, retiring a 3000 app led to retiring longtime staff. It's better to have a plan of succession than no plan at all. Everyone's got to prepare for change, even if the preparation is just where to set up the man cave in the house.
It's possible to see a portfolio as the same kind of tool for IT that it is for personal finance. With the stock market roaring at present, more than a few 3000 experts are looking at cashing in to wrap up long careers. Deciding which portfolio elements to convert and migrate to no-risk instruments aids in the changes. MB Foster has made its bones mitigating risk. It's one of the original HP Migration Partner firms.
A classic four-quadrant chart outlines the scoring of applications. One axis shows a business fit, the other a technical fit. Nobody wants an application in the bottom left, low in both aspects. A business decision should drive most of the changes in IT. Score the business fit of applications in a portfolio first, Foster says. If it scores well there, go on to the technical fit.
The portfolio is the tool of governance, he added. Governing often ensures the neediest get resources as required. Application Portfolio Management is only possible if a company knows its applications very well. Very well requires documentation that can be shared over time. The assets in a portfolio can be judged to be worthy of migration based on their risk-benefit-value. What helps a company most, and what could you least afford to let fall into that inevitable lower-left box?
It's usually a low number of apps that can fall off that chart completely, ready for retirement. The largest group is often suited for same-capability migrations when they creep downward. That 70 percent of the apps can get a lift-and-shift of their functionality, usually through replacement.
Working in advance makes it less painful and swifter. "It's like moving out of a house," Foster says. "If you go through your closets regularly, you'll be moving less of what you don't need." In this analogy, the closets are your data, which "has to be made available to the new app. It's not automatic."
"They see a list of 100,000 files and do not want to scrap any of them," he said. "So they move everything to the new system." A tool like Vesoft's MPEX assists by managing those files. That's work that can take place even before a transition is underway. There's no such thing as Data Portfolio Management, but the governance of data is one way to practice for the informed choices of application governance.
Retiring applications is part of a succession plan. The aging of the HP 3000 workforce is upon us. Today when people refer to senior staff, they're also thinking senior citizens. Setting up an application two decades ago, or four, gave companies a durable asset. In time, the moment arrives for change. It can be transformation or elimination. When to set up an application portfolio? When assets degrade through declining business fit, agility, and maintainability.
HP 3000 and MPE/iX manuals might be found anywhere these days. It's a common request to hear from a 3000 pro, "Where can I find that manual?
HP is back in this business with a new interface. These webpages at HPE's website are a high-value address to locate documentation and make it available to a new 3000 administrator. Or a migration team trying to understand how something like TurboStore/iX works.
There's no guarantee of how long HP Enterprise will keep this library open. Get it while you can.
It was easy to complain about OpenMPE's unmet hopes and dreams. HP never gave the small collective of ardent MPE veterans a chance to change things top to bottom. Hemmed in by non-negotaible NDAs, and sequestered to the corral where smaller customers live, OpenMPE didn't do what everybody wanted. Good-hearted and high-minded people came to the board and left, sometimes dismayed.
However, OpenMPE became a harbor for the schooners of 3000 capability. The OpenMPE website recently came under the curation of Keven Miller at 3k Ranger. He's rehosted and returned many of the assets of information OpenMPE created.
For example, there's a great grid showing the relative performance of HP 3000 hardware. Why might anybody need this in 2020? We live in a world where reusing assets is more possible than ever. These MPE systems remain for sale at hardware brokerages. the 3000-L newsgroup doesn't get many new messages these days. One regular post, though, comes from Jesse Dougherty. Systems like A-Class, N-Class, and even 9x9s remain for sale.
Comparing these is a lot easier with a performance chart. So 3k Ranger helps out, forwarding the research collected by OpenMPE. Knocking at the web address of "openmpe.com" doesn't deliver an answer anymore. The work remains at another address, still serving a purpose more than nine years after OpenMPE disbanded.
The aims of OpenMPE were high. At one point in 2009, the group was in line for a source code license. Even 11 years ago, the phrase succession planning was in the lexicon of 3000 owners. Succession was a part of MPE's future, since it's a long-serving asset.
Paper, printed with barcodes or mailed, still plays a role.
Nineteen years ago, Hewlett-Packard rocked the 3000 world with a fateful announcement. "No more new 3000s," the creator of the system said. "December of 2006 marks the end of HP's MPE road. Your ecosystem has been shrinking for some time." And so on.
How bad was that decision, really, in the long view from 2020? It killed companies, cratered careers, made vendors vanish. The world's landfills and scrapyards gathered tons of aging 3000 iron, over the next decade and beyond. What good came of it might be measured in how companies and experts rebuilt their prospects and skill levels.
Not many injured parties fell immediately from a mortal wound. Like COVID, though, the news attacked those whose careers or business models were already vulnerable. I was tempted, in the years that followed, to compare the HP choice as another kind of 9/11. I didn't go there, and I won't try to equate that business decision with a pandemic that's killed close to 1.5 million people worldwide.
The pain of a loss, though, isn't so easily defined. For some people and companies, November 14 was the wildfire that cleared out the old forest floor to make way for new trees. Minisoft was roaring along with its terminal emulator and middleware business. Its founder Doug Greenup summed up the firestorm and the aftermath eloquently.
"At first our business was not really affected," he says. "In fact, our sales actually trended up slightly with upgrades. We were faced with a critical decision to either let our company fade slowly away with the declining MPE business, or reinvent ourselves. I remember that 90 percent of our total business at the time was MPE."
"We decided to take Minisoft in a radical new direction going back to our old word processing days. We originally produced a product called Miniword which competed with HPWord and TDP on the HP 3000. Based on our long lost past, we created a document management suite written in Java that was operating system agnostic. We then marketed this software suite into several new non-HP worlds: QAD, RedPrairie, Manhattan, STW, and Microsoft Dynamics."
"It was very difficult to reinvent, and it took several difficult years," Greenup wrote to us on the 10-year anniversary of the announcement. "HP's decision almost killed our company. But we survived and are stronger as a result."
A few weeks ago, Minisoft dropped a marketing flyer, full color and tri-folded, into my mailbox at the curb. The flyer updated me on eFORMz, its solution for printed forms. It emerged in the years after 2001. Minisoft says, "The world's great brands run on eFORMZ" with a list: Petco, Tiffany, Office Depot, Adidas, Victoria's Secret, Mrs. Fields. The lineup reminded me of the Who's Who list that Ecometry boasted during the year of that 2001 HP announcement. Known brands, the Ecometry sites, all using the HP 3000.
eFORMz doesn't require a 3000. If a company has one, the software integrates effortlessly. The non-HP worlds began to open up as opportunities for Minisoft after Nov. 14. The fact that a printed flyer could promote software in 2020 is a tip of the cap to the continuing power of paper. When the HP news of 2001 arrived at the NewsWire, we were as deeply invested in paper as a little business could be.
Like Minisoft, paper lined my path away from the loss. Books, to be specific, paper that's more durable than periodicals.
I think of books as the HP 3000 of communication. Steady, knowing, rich with data that becomes knowledge and then wisdom. I had to write my way out of the trouble. The Web, as we called it in 2001, became the bridge.
It's been 19 years since HP canceled its future for the 3000 and changed ours. Our lives stopped building on the success of periodical editing and publishing. We still did our 3000 storytelling, of course, and I keep doing it. But every Friday now, for six of them in a row, I write a little newsletter about writing and editing, instead of coding or managing an enterprise system. In the work of becoming a book editor, and the author of a novel and a memoir, I’m not a reporter any longer, not about the book work. I’m an author, as well as an editor and evaluator of other authors.
And Abby? Whoa — a yoga teacher who's produced three DVDs and is now in her 15th year of leading classes. Now people can attend her classes over Zoom. Students come from around the country, where they once had to show up at our address, or live in Austin for private sessions. People who don't think they might do yoga can practice Heavyweight Yoga. Thirteen retreats, too. A Fitness Magazine Fit 50 member, alongside notables like TV anchor Robin Roberts. Obesity Action Coalition's Bias Buster of the Year.
Could I see the way to this day if HP hadn’t ever stopped its 3000 business? Would our tribe instead be like the OpenVMS people who still have vendors and customers, but the latter isn’t spending much anymore, and so the former doesn't have money for ads? That all began in 2013 for VMS, when HP announced the end of its unlimited service to the Digital community. My new cattle drive toward books would’ve started 12 years later than it did. I’d have been 56, just beginning my journey. In that future, we might've had more in our retirement account. Or, we might have looted it for experiences, as we did through the years. What trip, Abby always asks, would you have not gone on?
I can think of a few, but they all promised to be delightful in the cozy run-up to each experience. Were there some lemon meringue pie slices we could have left in the San Antonio Tip Top diner’s cold case? To be sure, there were. How could we know which ones we didn’t need as comfort food for the soul, though?
There are, of course, other ways to measure how things worked out because HP lost its faith. We bet on a business that we didn’t think would last so long. You would've had to ask us on a really honest day in 1996, say, to hear me say this venture had about five good years in it. The unfettered, blue-sky time amounted to six years or so. The next 19 after 2001 have had some seasons better than others. You won't mistake technical publishing for the creative compensations of books and yoga. The satisfactions, though, are a different element to measure.
Many an MPE expert made this kind of transformation. John Burke became a mathematics professor. Some just branched out further, like Birket Foster and his Storm rural internet service company. He's still serving 3000 sites with data migration, too. Fresche Solutions waded into the IBM i Series market and held on to its 3000 work that'd begun while the company was called Speedware.
It’s an alternative history game, this one. However, it’s also a commemoration report. What did we do for Christmas in 2001, versus Christmas of 2000? I always mark what we are spending with the high water mark of the holidays. That was a time that always included the Dec. 31 birthday of my boy, the rock star who was proof I could create something warm and attractive and funny and smart. Amid my obvious failures, Nick is my durable success. And my marriage to a partner both special and true.
We got the Nov. 14 news a few days ahead of the vast majority of our customers. Some of the bigger vendors knew about it days or weeks ahead of us. I've written about hearing about the 3000's end of HP days while holding a payphone receiver with a cord on it. Fitting, considering how classic the 3000 was then and remains today. Wherever Nick and I were headed in Switzerland that night, we kept our appointment. A train station with a payphone on the platform led me to this New Tomorrow. We're all headed there by now because of COVID. Survival is going to be the outcome for so many of us, just as it was after 2001.
Served from a deep cup of irony comes the report that HP, both Enterprise and PC-printer arms, will be paying $1.45 million in a penalty for illegal treatment of its female employees.
The US Department of Labor levied the fine, which will cover back pay for 391 California women who suffered "systematic pay discrimination" while employed at HP.
The irony bubbles up because HP's two longest-serving CEOs this decade were Carly Fiorina and Meg Whitman. The fine includes interest, to be paid to the affected female workers.
Under the settlement, in addition to the settlement payment, the two arms of HP agreed to analyze compensation and take steps to ensure their employment practices follow US law. That accounting will include record-keeping and internal auditing, all to ensure HP's compensation practices are legal.
A Labor Department news release says HP has cooperated. But the arm that sells servers that replaced HP 3000s, Enterprise, says it disagrees with the allegations.
HPE has "settled in the interest of putting this matter behind us.” This enterprise HP, whose HQ address is now San Jose rather than Palo Alto, says it is “committed to unconditional inclusion, including pay equity regardless of gender, race, or sexual orientation.”
The other HP, headquartered in Palo Alto, says "the charges in this case are without merit. We felt it was in the best interests of all involved to resolve this matter as quickly as possible through a voluntary settlement agreement. HP does not tolerate discrimination of any kind.”
The Hewlett-Packard that developed the HP 3000 might not have hired as many women as the newer HP arms. However, the classic HP never was investigated by the US government about hiring misdeeds.
The Labor Department alleges that through routine checks for compliance with employment laws, it found “disparities in compensation between male and female employees working in similar positions.” HP offices in San Diego and Boise, Idaho — the latter where HP board kingpin Dick Hackborn headquartered himself throughout the 2000s — as well as HPE offices in Houston and Fort Collins were the sites where illegal compensation was discovered.
I’m writing to you from a blackout. It’s a willful one, because I’m staying clear of the election vote totals until later today. It’s too soon to tell what the results might mean to people like me, hoping for change, or at least trying to hold back the chaos.
HP 3000 owners were in blackouts back at the start of this century, the last era we had a contested election. It wasn’t all that rare to hear about somebody just learning, quite late, about the November 2001 HP decision on the 3000. A few years later, even into 2005, a vendor would tell me they’d run into another site where time had stopped at the early-2001 marker.
They were so isolated we might have called them willful in their blackouts. They self-maintained, so the greatest source of news, from people like any indie support company on first response, was outside their view. These blackout customers had long ago left HP in all but spirit, buying hardware from the used market. The newer stuff would’ve returned their investment faster, considering parts and repair time they’d spend on their own. They shopped as if it was the Depression and they were strapped for cash.
Their software vendors hadn’t heard from them in a long time. Not because the support from the vendors had lapsed, although it often hadn’t been renewed. When you buy support as if it’s insurance you never use, not much changes in the viewfinder.
While I didn’t expect this blackout to last as long as it did, the lack of death march music helped preserve all of us in the 3000 world longer, so we could grow stronger. I stood on the train platform in Switzerland with a phone in my hand on the 2001 night when Abby told me what HP was about to do. “Don’t worry quite so much,” I said in the dark. “Lots of people are going nowhere soon.”
I then applied the term "homesteader" to those who would choose to push back migration. Eventually HP adopted the term, because their customers started using that. Once in awhile, something from the press sheds a new light on a decision.
There was a virtual blackout, too. Those who knew that HP’s tastes for MPE had run dry didn’t think that would alter their career or their company. HP said most would be migrated in five years. It was more like 10. At the end of that blackout run, lawyers might have become involved. Companies needed valid support contracts from HP, some of them. I guess leaning on lawyers at the end, and then judges, is the endgame for lots of important decisions and turning points.
In a few hours, I’ll wire back in and see what has happened in the election. So far, anyway — it's easy to believe this one will have a long road to settlement. Things will change a lot less than we think, no matter what the courts give us later on. Come to think of it, for quite awhile, 3000 things changed a lot less than Abby thought.
Customers didn't get a vote in that 2001 decision. Democracy promises everyone's voice will be heard. Capitalism and commerce doesn't operate by democracy, though. We'll see if we can manage our government any better than HP handled its 3000 endgame.
NewsWire Classic
We've marked the end of HP's passions for the 3000 many ways and many times over the last 19 years. The month of November is upon us again, and once again filled with changes. From 10 years ago, the story of the 3000's could-have-been fate, reflected in NonStop and its then-current division leader, rubbed some salt into an old wound.
November is a month filled with memory for many a 3000 owner and user. Some of the sting of watching HP stop its futures for the 3000 is sparked by the enthusiasm offered by HP's NonStop general manager, Winston Prather. NonStop enjoyed its first exclusive conference this fall, while Prather is finishing up his fourth year as GM of the server's Enterprise Division.
Prather held the very last post of General Manager for the 3000, a job where he said it was his decision alone to announce the "end of life" (as HP loves to call it) of the server still running more than a few major firms. You can pretty much see the retread from his 3000 talks in his message in the NonStop bimonthly magazine, The Connection, from his intro for this Fall's issue (pictured above; click for details).
With all the changes we've made... we've stayed true to the what NonStop has always done best: delivering the scalability, availability and integrity you rely on to run your business. It's a NonStop, not a Tandem. The difference is real, the fundamentals remain.
Fundamentals remain on duty at many HP 3000 shops which Prather predicted would be long ago migrated. But the struggle continues to eliminate an IT asset as quickly as he eliminated 3000 futures. One customer wrote us -- and didn't want their name used, for fear of risking a severance package -- about a second attempt to replace a custom-built application. "The packages that we’ve been sold, complete with rosy allegations of full asset management functionality, simply don’t have it," he said.
Some kinds of applications are custom-written all over the world, the manager added, and "whole concepts of our line of business are obviously brand new to the programmers."
This manager retired a few weeks after the organization's “conversion staff was only now asking for descriptions of the old database. They’re obviously not converting anything; they’re just going to archive the data and hope they can refer to it later."
In the meantime, the company's management dropped all support for the HP 3000s, even though one lost a disk drive and failed to boot from it. Other than a daily full backup, there's not even a shadow of support for the systems. Without a tool like Adager to rely upon, "the database will overfill (work order lines keep on coming!) in about four weeks." Of such high-level organization's decisions -- running a 3000 until it careens into a ditch -- are a system manager's nightmares conjured.
"I’ll return to the fray seeking work," said this 3000 pro. "But what I’ll do is in the air -- obviously not much 3000 development going on, but I may be just the ticket for maintenance projects, or I can probably be valuable in a conversion. I know I’m employable and there are a few 3000 community residents who know I’m reasonably smart; I’ll be okay."
HP's hubris hovered on the dream that any 3000 app could be moved or replaced. NonStop made it to the other side of the 2002 merger with Compaq, and the 3000 didn't. Along the road, the scalability, availability and integrity relied upon by some businesses fell into in the hands of the migration and conversion companies assigned to muck out the mess.
Perhaps the product name of the NonStop line will keep its customers from looking backward at the last business decision which HP put in Prather's hands alone. That's his story of your November history, even to this day. The buck stops at his GM's desk, right up to when he decides to dismantle the furniture that might still have a future.
Close to 30 years ago, a fresh software vendor included the HP 3000 in its targeted platforms. The hopeful mission was to help level the HP playing field for Unix and MPE/XL business computing. In the years when mainframe stability was the IT standard — and MPE still hadn't locked in its iX suffix — SAP chose the 3000 alongside the HP 9000 servers.
The announcement about the software suite already changing ERP standards came from SAP's world headquarters in Walldorf, Baden-Württemberg. SAP was trying to expand its beachhead in the US. The Internet played a minor role in corporate computing. "The company is going to SAP" wasn't a strategic cliche, because unless that company operated IBM mainframes, there was no widespread target platform for the manufacturing and ERP keystone app.
Twenty-eight years later, SAP has carried its clout to a fresh destination. The target may even dislodge some of the most staunch customers using ERP alternatives like MANMAN. SAP is already the replacement system at TE Connectivity, once the largest HP MANMAN user by system count. The final MANMAN database goes offline this month. SAP will complete its occupation in the TE campaign.
The new platform isn't TE, of course. A company doesn't represent a platform for an application. Even State Farm Insurance, with several hundred HP 3000s during the Nineties, wasn't an MPE platform. The new SAP platform is Suse Linux 15. The Suse Linux world considers SAP adoption a milestone for its customers.
Suse says the majority of SAP customers in the late Nineties "didn’t take much note of SAP’s 1999 announcement that SAP R/3 had just been made available to run on Linux." The 2020 media release from Suse last week reported a historical footnote. "Despite the establishment of an SAP Linux Lab, Linux was a wallflower in the SAP community."
The German vendor was as resolute as any military general about winning a space in the US market, though. Hewlett-Packard was going to be an ally in the assault. The app was so new to datacenters that 1992 coverage included an explanation of what SAP stood for. Systems, Applications, Product was in R/3, "mainframe-class software" headed to HP 9000 and HP 3000 users. The R/3 version had gained client-server abilities to reach beyond mainframes.
In 1992, "the foray into the US market has yielded big fruit in the shape of an agreement with Hewlett-Packard to offer SAP’s R/3 mainframe-class software to its HP 9000 and HP 3000 users." As part of the agreement, SAP and HP opened a joint development center at SAP’s headquarters in Walldorf, staffed by full-time engineers from both companies.
German soil already had a HP 3000 development lab. Down the road in Böblingen, the European HQ for MPE/XL systems was battling the push of Unix. The 25th anniversary of the 3000 was celebrated best up the road in Stuttgart, where a disco party roared with a sax player on a trapeze cable. SAP’s first new products for the North American market were expected in first quarter of 1993.
The software was building its legend of an infinite and sometimes maddening range of customization. That made the concept a good match for the 3000 strategy of robust customization. Business rules for accounting, personnel, manufacturing, materials management, sales and distribution, and plant maintenance — they all were executed in custom modules for most ERP.
Suse said in its 2020 announcement that in the Nineties, "customers already installed other operating systems like IBM AIX, HP-UX, OS/400, and Windows that worked just fine. Back then, SAP even still supported a combination of HP 3000 machines and operating system MPE for R/3."
The lab in Walldorf turned out an HP-UX version of SAP. The MPE/XL edition failed to embed itself in the combat unit of HP's 3000. Böblingen HP engineers were fighting the good fight against migration to Unix.
Linux had such blue skies ahead that it's eventually replaced Unix at many datacenters. Carrying around the proprietary versions of Unix like AIX and HP-UX was extra baggage for a platform: Suse is the second most often used Linux in the world among the branded distros, behind RedHat.
"Suse deployments/transitions for business-critical workloads and applications have been made available for public cloud environments," last week's release says. "Furthermore, major release 15 is the first version to take multi-modal principles into consideration." The names of the distros alone spell the coming change. Vendor specific operating systems were once named as acronymns. VMS, MPE, HP-UX, AIX: these ruled the corporate datacenters.
SAP modified its application to stand on the Linux platform. That represented the strategy beginning in the 1980s. On-premises computing was complemented by time sharing data processing. Everything needed a footprint in corporate offices, even if that footprint was no more than HP 2622 terminals or PCs that emulated them.
Linux won over the acronyms. The Suse report says, "Thanks to valiant efforts by SAP and partners like Suse, customers were able to see the benefits that highly efficient and optimized Linux systems have for mission-critical SAP systems."
There are new acronyms by now, like software-defined infrastructures (SDI), and application-focused architectures. IT is still run on acronyms. The emulation and virtualization of hardware and machines is a modern solution. The Stromasys Charon emulator replaces VMS and MPE servers. What's old, like the Nineties era servers, can become new again.
TE Connectivity is closing down its HP 3000 operations by the end of this year. The company uses MANMAN to manage its manufacturing operations, including IT leadership from Terry Simpkins. This veteran of the community threw his light into my life when he called with a tip on disk drive failures that became an epidemic in 1985. It was a widespread problem HP was keeping quiet. Management at HP had to announce a recall and repair blank check, so companies could get their storage hardware bulletproof again.
About 35 years later, Simpkins and those N-Class servers at TE are retiring. One of the databases in the 3000 cluster at TE had been running since 1978. Now that set of servers is available for sale.
"As we wind down the last remaining MANMAN database here at TE, it’s time to think about the ‘new home’ for our HP 3000s. Therefore, we have 4 N-Class machines, all of them 8-way 750Mhz, that are for sale. Two are available immediately; the other two will be available in early December. Anyone interested, please contact me via email or by phone at 757-532-5685."
Simpkins says he started managing the MANMAN operations at TE in 1993, when the company was Lucas Control Systems. It's been 27 years with the same phone number and mailing address," he says. "My HP 3000 time started at HP in 1981. That's over 39 years on the same platform, not a bad run. I started on MANMAN in 1985 at Spectra-Physics."
The last MANMAN database at TE is scheduled to convert to SAP over the Thanksgiving weekend. "Our legacy begins in the mid 1970's, but I can't quote an exact year — way before my time. That said, the 3000 was turned on before 1978.
Before the corporation became TE, the company names where the 3000s operated were
Shaevitz Engineering
Lucas Control Systems
Lucas-Varity
TRW
Measurement Specialties
TE Connectivity
The 3000 closeout puts two other veterans into the markets, Al Nizzardini and Tracy Johnson. Releasing good talent and assets into the wild is one of the upsides to shutdowns. Experience in the 3000, so rare these days, becomes available once more.
Photo by PxHere
The World Series is on stage this week, seven games of baseball as rich in legend as anything the 3000 represents. In midsummer, the Series appeared to be a longshot to be played. COVID and its threats were reducing the baseball season to a mere 60 games, and even those were in question. Big stars were driving the Players Association, which had to approve the limited schedule.
The stars must have seen a better outcome in playing fewer games for less money, because now we have a Series pitting a mighty payroll against a tiny one. The LA Dodgers have the second-highest payroll in the game. The Tampa Bay Rays sit three slots from the bottom of the payroll rankings. The mighty Yankees lead the list. The Rays spend more than $80 million less per year on players, developing talent and making wise trades and signings.
The no-stars approach is far from old-school baseball. But one classic supporter of the old-school HP 3000 likes what he sees in the Rays and the Series. Steve Suraci says, "Old schoolers do not appreciate what the Rays do on the field. I am not in that class! I find the no-stars approach refreshing. Every player's willingness to put the team ahead of self is unheard of in this day and age."
That fits a professional who runs Pivital Solutions, an HP 3000 support company that was the last distributor to sign on with HP to sell the servers. That was back in the early Nineties, an era when salaries began to explode after the horrific 1994 strike that wiped out that year's Series.
The concept of the 3000 itself has always been everyday goodness. We saw that during the first year after the strike, when we launched the NewsWire. Within a year we were spreading the word about everyday excellence. We used a Willie Mays quote to describe the 3000. "It isn't hard to be good from time to time in sports. What's tough is being good every day."
Steve and I are betting on the Rays to make the team concept a winner in this Series. The Rays are the underdogs, but they ran up the best record in their league during those 60 games, avoiding COVID troubles even though they play in Florida. That kind of resilience echoes what the 3000 has amassed in its many innings of the IT game.
Do you remember the day your first 3000 logon banner rolled across a terminal or a PC? That heady feel of stepping into something new with a promise of permanent promotions? You knew about MPE, a little, or just slid into an office chair and began to plug away at COBOL apps that tapped IMAGE data for the first time.
Starting the NewsWire, 25 years ago today, was not like that. My partner Abby and I arrived at the first issue with 22 years of publishing experience. Between us, we'd managed and launched operations for 18 news publications in the tech industry. Abby was already a publisher at four different magazines.
What was different about the NewsWire startup was its ownership. Just us, along with 10,000 or so owners of HP 3000s. Our audience owned our future. A few told us we were making something that would turn out to make us nothing. A subscription was "Not even worth $10 a year," said one 3000 veteran who'd written features at the HP Chronicle, my previous 3000 outpost. He came on to write for the NewsWire in our October 1995 issue, Volume 1 Number 1, as we say in publications.
That first technical feature, written by someone who doubted we'd sell subscriptions, was "PatchManager/iX: Maintenance Simplified." It toured the new software from HP for patching MPE/iX 5.5. That release was only forthcoming, as they call books that are promised but not yet released. In particular, one staging tool in PatchManager would improve patching. "Welcome to the 21st Century," the feature read. "MPE will go one better than most Unix systems with the StageMan/iX."
The software resolved a crying need. "Backing out a patch in today's MPE/iX environment can rival the agony of abdominal surgery—without the benefit of amnesia," Guy Smith wrote.
HP had been working on PatchManager/iX for more than a year by October of 1995. In publishing the NewsWire 25 years ago, we were picking up the trail of a business server getting a restart from its vendor. PatchManager was "created strictly to address customer issues with the patching process, not as a cost-saving measure," HP said.
Like our readers, we were more cautious about new technology from the commodity sector. One report said "HP 3000 managers press Win95 into service—slowly" while the 3000-ready app Netmail/3000 was releasing DeskLink. The module of Netmail connected HP Deskmanager mail nodes to the outside world. "Until DeskLink came along, HP had been recommending the HP Deskmanager sites set up a Unix system to give their Desk users Internet access." The fall of 1995 was so different that email systems were thriving that didn't use the Internet—we always capitalized the word Internet that year.
We counted on those subscribers for our first revenues, but it was the advertisers and vendors who showed up first. At one point over the last 25 years, we had more than a thousand paid readers. That point arrived years after ads from sponsors—we borrowed the term from TV advertising—carried the NewsWire's fortunes. A publisher, my partner Abby stared down the daunting first months with just a few advertisers. WRQ, the biggest software company serving the 3000 other than HP itself, shook our hands on the Toronto Interex 95 floor for a full-page spread. Those pages 12 and 13, plus HP's ad on the inside front cover and Adager's ad on the back cover, were among our bedrock supporters. Full pages from MB Foster and the Support Group were also part of the starting lineup of our startup. All are serving the 3000 today. Well, not HP.
Creating the graphics files for printing was also Abby's job, tied so closely to the artwork for the ads. I came in during her first issue work to find our Macintosh LC struggling through refreshing pages. We ordered a Power Macintosh 8500 that day, but the chugger of the LC was going to have to get us through our first printing. 1995 was not a great year for Apple. In a few more months, Bill Gates would advise Apple to sell itself to Microsoft.
HP assured our readers they wanted open systems computing. The 3000 was putting on the clothing of an open system, an ill-defined term that usually meant Unix. Open was certainly not the truth about any system vendor's Unix, operating systems usually handcrafted from the standard Berkley Unix to exploit vendor hardware. Unix was open in the sense that software vendors always supported it in general. On the ground, vendor to vendor, the OS had as much support in apps as MPE/iX. If your app was having a problem, you called a vendor support line and logged your problem.
If MPE/iX enjoyed the popularity of Unix in 1995, we might not have taken our shot with the NewsWire. The 3000 world was a forgotten backwater of IT. Our modest venture of two publishing pros in two back bedrooms, tapping experience and a deep list of contacts and experts, never would have had much chance against the likes of publishing giants like IDC, CMP, Ziff Davis, or even Datamation. I'd written freelance for Datamation two years before our NewsWire upstart startup. In the year before we launched the NewsWire we'd both worked on contract for Interex, writing and managing subscription campaigns. One of the hardest talks we faced in that fall was telling Interex executive director Chuck Piercey we were going to sail our own ship into the rest of 1995.
Always the former sports editor at heart, I wrote an editorial for that issue that compared the 3000 to baseball legend Cal Ripken. That year, Ripken broke the record for consecutive games played without a day off. Choosing to use the 3000 represented that same pursuit of reliability.
"All around MPE environments, other systems go down, fail, and struggle to stay online. The HP 3000 takes the field every day. If computers were baseball players, the HP 3000 would be the Cal Ripken of the league. Cal recently broke Lou Gehrigs' Major League record for most consecutive games played." The numbers matched up. Ripken had played in 99 percent of the innings across the 2,131 games in a row. "Cal is steady, productive, and not flashy—but respected by those who watch baseball closely. Those are the traits of the HP 3000."
We started up in October, a time that leads up to the World Series. In the summer of 1994, I'd toured ballparks with my 11-year-old Little Leaguer for a road trip. The journey and its fatherhood roots would become Stealing Home, after 25 years of conception, revision and writing, then publishing. Baseball felt like a natural fit for the NewsWire and our 3000 focus. Willie Mays was a baseball legend and a star. He knew it was an every day, all the time job. "It isn't hard to be good from time to time in sports. What's tough is being good every day," he said. That was the 3000 and its community and its major league of vendors: good every day.
We had our panic and fears during those earliest days. 3000 owners might have experienced some on the day they learned HP wasn't going to continue selling the servers. They could do little to change that. We had to ride out the fallow times in the first year, those months when some vendors wanted to wait to see who'd support the upstart news outlet.
When we traveled to our first Interex show with a full issue, in Anaheim's HP World of 1996, HP was waiting with a warning. Frankly, the state of the 3000 market was not going to earn an HP recommendation of the 3000 to the large corporations. Glenn Osaka had been in charge of the 3000 group and then moved up to managing the business server group. Hearing that HP's heart wasn't in its 3000 work sent a bolt of panic into us. Two people with ad contracts to serve and plenty of ink, paper, and postage to buy—we didn't want to hear how little the upper HP brass thought of the 3000. It was a legacy business, after all. Show some respect.
Little of that first hard summer of 1996 matched the wonder of dreaming up the NewsWire in the spring of the previous year. In March of 1995, we talked about a newsletter that would do the work of a magazine, produced on a tight budget. We'd worked for a publisher together whose purse strings were always drawn tight. We didn't need four-color printing. We'd learned to do good with two colors: black, and a fire engine red. We had to educate many a vendor on how to create artwork that required only two colors.
Then we printed the first issue and got the newsletters delivered two weeks late, produced on too-heavy paper that busted our postage budget. A new printer took us to press the very next month. Abby had to hunt down a graphics company to replace the in-house work the old printer performed.
Like many people in our community, the approach of the Year 2000 lifted our ship. Advertising swelled as software companies added products and customers. The legacy applications and systems were going to need more attention to get them through the narrow part of the calendar, that Dec. 31 when the first two digits of the year were going to turn over for the first time in computing history.
The 3000 business seemed to be soaring by the end of 1999, a period when we posted some of our highest page counts. Interex conferences carried extra ad dollars and gave us chances to sign on new subscribers. The web site was popular enough to carry a paywall tied to subscriptions. For the first three full years, an HP 3000 hosted our web pages. Our webmaster Chris Bartram created a random passcode generator on a 3000 which assigned login passwords for subscribers. After more than three full years, another website, 3kworld.com, paid to license our content. We walked away from further subscription growth to get our stories into a wider world.
More than two years later, HP's managers looked at the prospects for selling these servers in a post-2000 world. Maybe legacy computing became more vulnerable after the classic apps cleared the Y2K hurdle. We'd only been publishing for about six years when the fateful November 2001 news arrived. I developed the Homesteading label for the thousands of customers who'd be going nowhere soon. I was in Europe vacationing with my son when the call from Abby arrived. In a burst of hubris and desperate hope, I rewrote a front page of the Flash Paper that handed the shutdown news from HP to a readership stunned at the prospects of fewer tomorrows.
For some of our readers, HP's intentions of almost 19 years ago mattered little. Their companies were always going to follow their own counsel and were devoted to a full return on their 3000 investment. Many more had careers derailed or sidetracked, saw fortunes dwindle, made plans for different tomorrows.
The NewsWire was never built to become a massive operation with offices, staff, and benefits. Things were lean enough in the Nineties that no one here carried health insurance. Organizing for a small footprint—though not so small that healthcare didn't ever arrive here—gave us a plan for survival long term. Here at the end of 25 years of publishing, 20 of those years have unfurled in the shadow of HP's certain departure from 3000 life.
Those earliest months when we could believe in HP's 3000 faith were still tinged with wry, sometimes dark comedy. Citizen Kane is a favorite film here, and we'd often quote one of its lines at each other when times got tough. Kane is replying to his trust manager when he's asked why he'd want to buy the New York Examiner. "I think it would be fun to run a newspaper," Kane said.
It's been fun. We look forward to more, bolstered by support from companies with a long-term view of 3000 usefulness, like Pivital Solutions. We have enjoyed support from readers and owners and veterans of the 3000 world, too. Here's to a fresh quarter-century, however it looks. The Tampa Bay Rays are looking like a good prospect to get into the World Series, winning on a pittance of a payroll. Little things that are built smart can surprise you with their ability to be good every day.
Gilles Schipper, our Homesteading editor who's shared so much advice and instruction, wanted network help. Along the way to answers, an MPE/iX flaw was uncovered. There's a fix. But first, the problem.
Schipper writes, "All of sudden, two HP 3000s (running MPE/iX 6.5) are unable to accept VT sessions from terminals on same network. Network administrators unable to point to any network configuration or equipment issues that could explain the problem.
"Further investigation shows that one or two IP's associated with PRINTERS (usually 1, but sometimes 2) have appeared in the "GATELIST" command within NETTOOLS.NET.SYS (along with the IP address of the router). It seems that the inability of network terminals to log on to either system is always due to this bizarre situation that I've never seen before."
Currently, the solution is to run a job every five minutes or so that issues a NETCONTROL NET=LAN; UPDATE=ALL,
which results in ONLY the correct router IP address in the GATELIST, and after which everything is okay.
How can I fix the problem permanently without requiring the running of the UPDATE job?
Craig Lalley says he's seen this before.
"I suppose you will probably want to know how I resolved it. I don't remember... but, network redirects come to mind. Are they getting network redirects at the console? Do they have the correct gateway in NMMGR? Have you looked at the buffers?
NETTOOL.NET -> RESOURCE -> DISPLAY?
Of course, what does LINKCONTROL @,A
show? Finally, look at the Name Resolution."
Mark Landin puts the blame on a routing table.
"Sounds like your routing table is getting polluted with bad RIP updates. Doubt it’s coming from the printers themselves. Not sure how you’d track that down. Maybe if you put a PC running Wireshark on the same LAN you could find the source of the bogus updates."
Billy Brewer thinks the router redirects cause the problem.
"What you are seeing most likely is ICMP Redirects (normally coming from a router). I don't think I've ever seen where you would get a printer IP address showing in your gatelist in Nettool as that doesn't make any sense. Basically the culprit is sending out an "alternate" gateway and the HP 3000 unfortunately listens and updates the gateway (Gatelist).
The network guys (at least in my experience) are never wrong or guilty until you prove it to them. Anyway, if this is the case, you can watch your console and if you get the result below, it will tell you the IP address of the equipment sending the ICMP Redirect.
SYS-A:** NETXPORT IP : NETWORK PROBLEM; Gateway redirects severe
Loc: 215; Class: 2; Parm= $A1C37920; PortID: $FFFFF972
If you convert the PARM= value from hex to decimal you get the IP 161.195.121.32, which should be the router that your system is having trouble with.
A1 = 161
C3 = 195
79 = 121
20 = 32
Update: Schipper says the problems came through PCs on the network.
"It turns out that the ICMP redirect requests were being issued by two virus-infected PCs. This was determined by utilizing a packet sniffer. Once those PCs were disconnected from the network, all was good."
Finally, Doug Werth pointed out this is a flaw in MPE/iX which introduced a security hole. That's significant, because 3000s don't often exhibit those. The continued use of these servers on modern networks, pretty remarkable for a server first built in 1972, will expose such stuff.
Werth says, "What you are seeing is in fact caused by ICMP redirects. It has nothing to do with printers or DNS or network resources of any nature. Simply put, a router on the network is inspecting packets and believes it knows a better gateway for the HP3000 to route to use and tells it so via a gateway redirect. The HP 3000 dutifully updates its routing table accordingly.
"If the redirect packets occur at a high enough rate the 'ICMP redirects severe' message is written to the system console. This makes identifying the culprit fairly easily whereby one can ask the network administrator to disable that feature. Yet it only takes one redirect to mess things up which won't reach the threshold of 'severe.' and thus making identification much more difficult. The offending packets can be located by formatting a link trace directly on the HP 3000, or with a packet sniffer like Wireshark externally.
"And how to fix the problem permanently without running the UPDATE job? Beechglen has a patch for all versions of MPE/iX to permanently ignore ICMP redirects. Contact us on how to track down the offending gateway and patches."
"I have long considered this a significant security hole in MPE, as well as all operating systems that accept and act upon ICMP redirects. Turning them off permanently is a must. No server should allow for the possibility of a rogue piece of equipment getting on the network and rerouting its packets. That is a job that should be left solely to the configured default gateway."
It's November of 2000, close to a year past the harrowing Y2K milestone. The HP 3000 is now renamed the HPe3000, adding a letter to remind customers and prospects that the 36-year-old server is ready for the Web.
HP Europe is running a "Let's Go e!" conference. The event is so multilingual that a set of translator booths sits at the back of an Amsterdam hotel conference room. The presentations will convince customers from France, Spain, Italy, Germany, and the UK that tge 3000s in their datacenters can connect data with remote customers.
I'm in the audience and look back to see a UN translator setup worthy of a scene in Judgment at Nuremburg. In real time, the genuine capabilities of a Java-driven app are being demonstrated. It's a proud moment for people like me who invested in the future of the 3000 world.
In a way, the conference is multi-lingual for technology, too. Java made its debut in commercial markets just a few years earlier. In that room we're being told that MPE/iX can speak Java right alongside Unix and Windows NT. It's an important point, that similarity with an open Unix environment, or the omnipresent Windows. The 3000 deserves a seat at the table, HP believes. It's especially important in Europe, where they've had a tough year selling against Unix. HP-UX and Sun Solaris are well dug-in across the continent.
An IT manager from Dornier, which makes custom looms for the fabrics sector, explains how their Enhydra web app server built upon Java/iX runs as fast anything. An outside team built them the app for Windows NT, then moved it to the 3000. At the time, that would've been a 3000 before the ultimate generation.
Not especially fast compared to what would be announced four months later: PCI-based 3000s of the A-Class and N-Class. Still, for Dornier's business clients, fast enough.
Java earned a reputation over the next year or so as being significantly slower on MPE/iX than open system implementations. In almost one year's time, HP decided the ecosystem of the 3000 didn't have a strong future. Despite the translation magic in that Amsterdam meeting room, the place the e3000 was going to go was away from HP's futures.
Emulator day was a Saturday. February 2, 2002 arrived less than 90 days after HP cut short the lifespan of the HP 3000 hardware. On that Saturday, Robert Boers of Software Resources International announced a prototyping project.
We are currently building a prototype HP 3000e emulator, capable of running unmodified MPE and its applications on a Windows platform. Note that this is an A/D project only, we have made no decision yet about making it a product.
Boers was leading the company that would later become Stromasys after a name change. On that Saturday in 2002 he noted, "It is correct that we did not get much response about my note about hardware emulation. Our experience with the VAX and PDP-11 emulators is that the concept is often confused with operating system emulation, and the assumption is that recompiling would be necessary, or that not all applications will run.
"The hardware emulators we build are operating system-independent. The demo we use to show the concept is to unplug a SCSI system disk from a VAX, plug it into a SCSI port of a PC, and boot VMS (or another VAX operating system) from it. We do not need to convert the binary VAX code in any way or form. Performance is not an issue, we have reached VAX 7000 Dhrystone performance on a PC.
"The emulator engine we use is likely flexible enough for the HP3000 hardware (we use the same for PDP-11 and VAX). The core VAX emulator prototype (CPU, memory, disks) took less than 4 months to develop.
"It took us about a year to convince Compaq to support their software on our VAX emulator as they would any other VAX," Boers added. "We did that by passing their VAX hardware diagnostics and architecture tests. They now offer very reasonably-priced VMS transfer licenses."
At the time Compaq was the owner of the DEC lineup. Later that became HP, but the vendor grappled with the concept of transfer licenses without a released emulator in the 3000 marketplace.
In those early days of 2002, we asked HP's Winston Prather about the prospects for speed in setting up a licensing program for an emulator. What's the rush, he wondered. As we pointed out during his interview in that same season, many more people would be available as 3000 emulator customers in 2002 than, say, 2006.
Boers answered a raft of questions in the same timeframe from 3000 customers about the PA-RISC hardware emulator that would become Charon.
1) Would hardware emulation take more processing power than an OS emulator?
Depends on the OS. With a rich feature OS like VMS, the amount of code required to map all functionality accurately would be huge, expensive to write and to debug, and techniques to speed up execution by dynamically translating instruction sequences would not work. With 1-2 Billion instructions per second available the trick is more to keep the code size small. The total size, including the emulation of the major peripherals, of the run-time part of CHARON-VAX is < 500 KB and it fits in PC cache memory.
The big advantage of hardware emulation is the ability of fast and comprehensive testing by running the hardware diagnostics.
2) Does your VAX emulator provide bridges or gateways to the native OS or hardware? Is such even desirable?
Those bridges are available and used e.g to store emulated disks as files (although you can connect physical disks). Serial lines are effectively telnet sessions, and instead of mapping to the host serial ports, you can link them to host applications. But the goal is to leave the OS of the emulated system in control; our design goal is always to be able to run any available OS of the emulated system.
3) For MPE to run directly (ie. loaded directly from HP tapes) wouldn't you have to emulate the entire HP 3000 architecture?
Yes, certainly, that is exactly what we do for the VAX and PDP-11 emulators. For the PDP-11 we emulate over 100 devices (for the VAX less). We generate each device emulator component directly from its hardware description. A CHARON-VAX emulator is booted directly from the standard VAX/VMS installation kit on CD or standalone backup on tape.
4) Could you emulate multiprocessor 3000 hardware config (or, would you need to?)
Yes, but you need a host SMP system to benefit from the multiple emulated CPUs. We run actually clusters of VAX/VMS systems on a single SMP host that way. It only makes sense if performance is an issue, but if the original hardware is capable of it, the emulator should be capable as it is a direct copy.
5) Seems that if you implement a truly portable HP3K hardware implementation, as more modern host hardware becomes available, you could end up with a more powerful MPE box than you could ever have with real 3000 hardware - cheaper too!
Our standard VAX 3600 emulator runs at about five times the speed of a hardware VAX 3600 on an AMD 2000+ system (and probably gets 3 percent faster every year). But the 3600 is a slow system (compared to current technology) to start with. I have not looked into the HP 3000 designs in detail to be able to give an opinion here.
6) How much would we be restricted to peripherals and storage that are compatible with a real HP 3000, and how much could we use non-3000 components: tape drives, DASD, NICs)?
It is a matter of documentation and implementation time, there is no fundamental restriction except for real-time requirements (e.g. connecting with a parallel interface to an instrument), where the host system PCI latency might play a role. But NICs, disks, and tapes map very well. Emulated disks are generally faster than physical ones, because you can use the latest technology.
It remains uncertain when everyone can return to an in-person office. For the HP 3000 manager, this kind of return may not even be necessary. With few exceptions, nearly every hour of maintenance, configuration, and development on MPE/iX can be virtual. And virus-free, unless you consider the kind of viruses transmitted over the Internet.
The HP 3000 often had its vaccinations to resist such viruses up to date. Security breaches continue to be rare, too. Securing passwords is usually enough to prevent uninvited traffic in the 3000's processors. Even configurations on Intel servers — through the Charon HPA emulators — can be secured in a way that gives 3000 managers few intrusions to talk about.
The conversations about security took place over the 3000's mailing list. In our articles we often called it a newsgroup, one that serves a need the face-to-face meetings served. Online does it more efficiently, and at less cost. It’s the kind of thing I wished we would have sponsored earlier. We had to start with print, because ink on paper made it real. Even today in the book world, reviewers demand a printed book at times. Anybody can publish an ebook. Paper makes the author more select.
But by the year 2001, there was room for the newsgroup. 3kworld.com, and a website plus paper for the NewsWire. This year the news exchange on 3000-L has slowed to a trickle. We made our transition to survive by broadening beyond paper for the 3000. There were opportunities. The 3000-L newsgroup begat the NewsWire. For a time, we even licensed our articles, the reporting and content, to a website operated by the biggest North American 3000 distributor. 3kworld didn't last long, but it continued the tradition of getting what you need to know remotely. For decades, August was a big month for in-person training, and September hosted a lot of conferences, too. Web access has filled those opportunities
Long ago, the 3000 experts could work safely from a laptop to administer and repair 3000s. Some of these support pros even had a customer carry around a phone to show the hardware racks and insides of cabinets. Parts that had been shipped to the datacenter, where that phone was running a FaceTime session, were customer-installed. We figure out what we can do that can be helpful to a community whose people are still serving.
The deepest and dimmest part of the 3000's road might have been the earliest days of 2002. All customers knew for certain was that HP had lost its desire to create more MPE/iX customers. Sixty days earlier, the vendor had revealed its plans to end manufacturing the HP 3000 hardware. About another four years was all HP could promise to thousands of customers.
We talked to Winston Prather, head of the 3000 division, during that darkest month of January. OpenMPE was only an ideal from a few loyal customers, including Jon Backus who spurred the organization's creation.
We asked Prather questions about where 3000 people might head next. This was a time before customers leveled serious broadsides at Hewlett-Packard. His replies went beyond the standard "migrate to another HP server platform."
People are talking about a hobbyist’s license for MPE source code. Is this a good first step for an OpenMPE?
I have no problem showing our source code to people from a hobbyist perspective. I’ve always been an advocate for sharing source code.
Would sharing source code hurt HP in any way?
It’s not obvious to me. I tend to think not. I tend to think that HP would not consider that harmful to us. Those customers who would stay beyond 2006 don’t buy anything from us anyway.
Is HP willing to allow MPE to move beyond the HP umbrella?
HP is willing to allow MPE to live on. I don’t know anyone who’s said differently.
People use Microsoft operating systems with HP hardware today. Do you think an OpenMPE, from a third-party entity, could keep people buying HP hardware?
Would people stay on and eventually buy some HP systems? Probably. Is it material, financially? I don’t think so. Would we invest to make that happen? Probably not. I don’t want to stop MPE from living beyond HP, but the return on investment wouldn’t be worth it for us.
How soon do you think have to make a decision about licensing MPE to parties outside HP?
I don’t feel the need to hurry, other than I know in the chat rooms there’s a lot of discussion about it. It comes back to my feeling that, yes, I want to enable an afterlife. But it doesn’t change my recommendation. If I think the majority of my major accounts — and maybe some medium and small accounts — need to do something different than [use HP 3000s], then what’s our hurry? What’s the difference between announcing this type of enablement here in January, versus waiting six months?
For hobbyists who operate emulators, licenses for OpenVMS have a new supplier. VMS Software Inc. is supplying OS licenses for the VAX users who employ the Stromasys Charon emulators. Up until this year, such licenses were only available from HP.
The HP-only license remains the only type that 3000 hobbyists can use. It might seem like a small point, since a hobbyist won't often be concerned with OS licenses. But the 3000 was once on its way to such a license, attached to the need for an emulator.
The OpenVMS free-to-tinker agreements from VSI have an attractive price, one that MPE/iX never achieved: free.
Hobbyist licensing for VAX and other DEC systems was already a tradition by the time HP merged with Compaq in 2002. Compaq had acquired DEC and its business servers in 1998. The plan for a large footprint for OpenVMS might have played a role in getting the first Stromasys emulator into the world.
That was back in the day when Charon was offered by Software Resources International. The company renamed itself Stromasys in 2012, remaining in close connection with HP. Hewlett-Packard said Charon "prolongs the usability of HP OpenVMS VAX and MicroVAX applications by enabling their transfer to new hardware platforms without any conversion effort."
It was just the sort of thing the 3000 community desired: vendor blessing of an independent emulation tool. More important, such a blessing was going to arrive before HP stopped selling new OS licenses.
"CHARON-VAX emulates a complete MicroVAX system on an OpenVMS Alpha, Linux, Windows NT or Windows 2000 platform," HP told customers in a 2005 web page, "allowing OpenVMS applications to run unmodified."
A $500 license for a production-level system was HP's best offer at the time. Users had to be running an Alpha system to get that deal. Windows and Linux systems would cost a user $1,000. HP called these extension licenses. The hobbyist-grade OS was free.
HP is providing the following extension licenses for the CHARON-VAX environment, allowing the OpenVMS VAX operating system and OpenVMS VAX layered products and licenses to be transferred to the CHARON-VAX environment.
HP bought in fully on integrating Charon with HP's support. The existing HP software service contracts were valid on supported OpenVMS VAX applications running on the emulator. HP fixed software problems if they were also seen in a comparable VAX environment. The offer extended to a layered version of the OS, which included compilers, clustering, and more.
HP 3000 users were teased with a deal that hinged on the release of Charon or any other emulator. In a crucial move, a customer would be able to purchase a license that was not connected in any way to an existing 3000 system.
Late in 2003, HP said it "intends to establish a new distribution plan for MPE/iX which will likely be effective by early 2004. The MPE/iX OS would be licensed independent of the HP e3000 hardware platform. The license terms would grant the licensee the right to use a single copy of MPE/iX on a single HP hardware platform subject to certain terms and conditions."
HP wanted its emulator-based users to host the systems on HP-branded PCs. There was little technology available to verify such a condition, though. MPE would be provided "AS-IS" with no warranty.
HP didn't endorse the use of a 3000 emulator in 2004. The HP stuck fast to the strategy that the best move was a transition from MPE/iX to another HP platform. "At the same time, HP realizes that some customers are interested in running MPE/iX applications in an emulated environment."
The expected price for an MPE/iX license was $500, with a right to use that was non-transferable. HP was going to include subsystems software such as compilers, but it didn't get specific about products.
The DEC VAX license was generous in its bundle of software:
ACMS, ALL-IN-1, HP Ada, HP BASIC, HP C, CMS, COBOL, DCE, DCPS, DECmigrate, DECram, DECwrite, DFS, DQS, DTM, DTR, DECnet-Plus, DECnet Phase IV, DECwindows Motif, FMS, Forms, Fortran, GKS, LSE, MACRO-64, MAILbus, MMS, Notes, Pascal, PCA, PHIGS, RMS Journaling, RTR, SLS, SQL, TCP/IP Services for OpenVMS, VAXcluster, OpenVMS Clusters, Volume Shadowing for OpenVMS, X.25, X.500.
For MPE/iX, the emulator license to create new 3000s based only on PC-Intel hardware never showed up in time. HP inserted a clause that said such a license could only be purchased when an emulator was being sold. Then the vendor closed out the offer by saying it would sell no MPE/iX licenses of any kind after 2010.
The deal stands in sharp contrast with the OpenVMS lifespan engineered by HP Enterprise. An independent company, VSI, holds the rights to the OS. Now it's going to be able to distribute an OpenVMS for hobbyists.
For any manager outside the HP 3000 ecosystem, it's hard to fathom: a business server last sold during the 1990s hosts a scheduling app today. Yes, it's a 9x7 Series HP 3000, the servers that launched the second generation of PA-RISC computing at HP. First, there was the Series 930 in 1987, followed quickly by the Series 950 and the 925. In a blink of an eye, HP built the 9x7s, known as Nova servers at the time.
MPE/iX 6.0 is as current as it gets for a Series 957, the system that Jim Maher is trying to keep in play at his company. That's an HP 3000 first shipped 29 years ago. These are usually the RX models that sold for about $63,000 new. That configuration gets you 64 concurrent users. Back in those days, a 3000 was sold with a fixed number of users.
"Has anyone experienced issues, or had to make configuration changes, to their HP 3000 when upgrading Cisco switch IOS to version 16.09.05?" Maher asked on the lightly-used HP3000-L list.
He explained that "it's a 957 running 6.0 that runs an old scheduling app developed years ago. We have been trying to get off it for years. We connect through a transceiver on the multi-function board. Pretty simple, I'm told. The last time they updated the Cisco switch they had some problems. Any help would be much appreciated."
For the most part, development on the 9x7 Series ended in 1997. That's when HP rolled out the Series 997 along with the recently updated Java/iX. The version 4 of Java turned out the be the last one included with MPE/iX.
Maher didn't get a reply on the 3000-L to his query, so if a reader here has Cisco-plus-MPE/iX 6.0 experience, please pass it along to him. Meanwhile, marvel at a 29-year-old design managing to keep up with 21st Century switches — with a little help from the 3000's friends.
HP 3000s can surprise us with their tenacity. A consultant to a financial services company is managing mail exchange from an HP 3000. The work relies on the Telemon MAIL software, created in the 1990s by the well-regarded data transfer company.
Telemon gave the world the Typeahead Engine during the 1990s. The hardware device improved HP 3000 connectivity speeds. When the Internet rose up in the next decade, MAIL made its way into some 3000 shops.
In the years that followed, MAIL found a place in many other IT shops because it had been released into the wild. Stein said MAIL, installed on a 3000 today, shows as being from 1998. "They would like to send email out via a service, such as SendGrid, instead of a local exchange server."
The HP 3000 in the equation is timeless enough that it doesn't have a formal database. It uses Keyed Sequential Access Method files. "They are big on KSAM," Stein says. "KSAM is definitely a different animal."
Emailing data from a 3000 is a different animal, too. The Telemon software is at the heart of MAIL.MAIL.ESP from Beechglen. "Addressees can be configured with SETVARs," says Tracy Johnson from TE Connectivity. "It sends via our company exchange server and is routed from there."
"Beechglen's software uses Telamon's email program. MAIL was shareware. If SendGrid uses SMTP relay, I believe you can configure it to use SendGrid." Johnson offers to cut a DDS tape of MAIL and snail mail it to Stein.
Mark Ranft of Pro3K says, "I’ve used the Telamon mail.exe program for years. The mail hosting server must be configured to allow mail forwarding from the IP address of the HP 3000. Keep in mind, your mail/security teams may not permit this.
"I am not familiar with SendGrid, but it may allow mail forwarding. I see it has an option for Address Whitelist setting, which allows a specified email address or domain for which mail should never be suppressed."
MAIL and the Beechglen software were created by utility software firms. Meanwhile, Netmail/3000 was built by an Internet pro who focused on well, email: Chris Bartram at 3kassociates.com. Netmail was as full-featured and standards-based as an email package ever got on the 3000.
“They are big on KSAM” is a phrase I never thought I’d hear again. Of course, people think there’s no more MPE enterprise computing, either.
Photo by Mikaela Wiedenhoff on Unsplash
One decade ago this week, the Stromasys PA-RISC emulator made its debut in the market and on our webpages. The founders of the project were Dr. Robert Boers and the company's CEO in 2010, John Pritchart. Their interview with us remains useful. The talk, published a couple of years in advance of the release of what Stromasys called Zelus at first, shows the path for replacing HP 3000 hardware remains sound.
Newswire Classic
A long-awaited 3000 hardware emulator appears to be on its way to market, as Stromasys this summer announced a development, test and shipping timeline for Zelus. The product is described as a “cross-platform virtualization system” by the company that was founded as a spin-off from the Digital Computer European Migration Center in 1998. Stromasys, which called itself Software Research International until last year, has thrived on an emulator for DEC customers, those who need to keep using Vax, Alpha and PDP-11 hardware to support legacy applications. HP put the 3000 effort at Stromasys on ice for more than a year while it cleared the transfer of MPE boot technology for the emulator.
The software has more to offer than making companies able to use 3000s indefinitely. Stromasys says Zelus will buy time for the sites which are migrating and need more connectivity and power for their interim 3000s during a migration.
Robert Boers headed up the company during 2009, but this year brought on John Pritchard as CEO so Boers could focus on the tasks of being the firm’s CTO. In the wake of the company’s announcement about Zelus at the recent HP Technology Forum, we interviewed the pair via Skype, bridging the gap between Texas and their Swiss headquarters -- even as the company works out details to bridge what will be an 8-year gap in 3000 manufacture when Zelus goes on the market next year.
Your press statement on Zelus says the product “ensures continuity after the phase-out program of the HP 3000 hardware.” Do you believe that’s how your customers will view the situation: phasing out the 3000?
Pritchard: For people who have mission-critical legacy systems, they believe all of their hardware are on life support. What we’re offering is to shift their focus away from worrying about hardware maintenance to giving them a software platform life that is independent of a hardware platform.
When it ships next year, will this product bridge the gap between 3000 hardware last built in 2003 and the newer technologies such as iSCSI?
Boers: Things like iSCSI will work out of the box. We do that for our VAX and Alpha emulation routinely, because iSCSI is elegant and useful. You tell Windows to create a virtual disk which is an iSCSI disk. You can tell the emulator that this virtual device is your SCSI drive. You can map to new hardware, so if you have serial ports, for example, you can map them to an Ethernet-based remote serial multiplexer. Most of this stuff is mapped standards.
So does that mean that the controlling environment for the emulator will be Windows?
Boers: It can be anything. For the time being, we typically develop under Windows 64 bits. But we provide these products under Linux as well. The customer only sees MPE. Basically, these things behave as virtual clients. From a usage point of view, you don’t have to know where they run. In Linux, we remove what we want, so you have something that runs on the footprint of VMWare. But for all of these choices, we need to know more about what the customer is looking for.
Pritchard: One of the purposes of this announcement to start to invite a dialog with the community. We want to select a few sponsor companies who’ll say, “Here’s my application, I want to be one of the first to migrate. Here’s my configuration, and here’s what I need.” We want to focus our development team on just a few specific customer applications.
We’ve gotten far enough in our prototyping to know that it really works, and what we need is a lot more market feedback and a couple of sponsor customers to work with, to get a few successes under our belts.
What is being a sponsor customer going to look like?
Pritchard: We’ll select a couple of companies that will give us complete access to their environment for their 3000 application. The customers we’re looking for in early adopters should be lower-risk environments.
Boers: Let me give you a couple of examples. In dealing with Hewlett-Packard, the issue they had the most difficulty with was the whole physical licensing process, their hardware-enforced licensing mechanism. They have given us two device ID strings which we can use in out emulators, a low- and a high-end machine.
The other issue is something that HP is washing it’s hands of: Unlike physical hardware, you can run this emulator on a number of different platforms with different performances. A lot of the third party licensing is based on performance. If we don’t do anything, then there’s no performance information there. I want to know from the third party software providers if that’s okay, or what we can do technically with ease, provide information about relative system performance [of the emulator.]
We can emulate a system ID string as a standard. Every time you install an emulator you buy another license key. Whether to some extent software vendors want to link to that.
We addressed this a couple years ago, when we did our first attempt. I didn’t really get information in that area — except for comments that it should really be HP, as part of their software transfer licenses [of MPE/iX] who should take care of that. But obviously, HP is pretty much out of the game by now.
Hewlett-Packard manufactured countless hardware devices over the 31 years that it built HP 3000 gear. The earliest systems could heat rooms while running and buckle pickup truck beds when moved. In time, the 3000s could be carted in a luggage carrier (remember those at airports?) and even held under an arm.
People hang on to these creations for several reasons, not the least of which is the boxes get forgotten. This treatment was common even where the servers were at work, since the systems themselves rarely needed tending and disappeared into closets and under staircases.
The gear continues to surface, long after the last manufacturing line shut down at HP in early 2004. Peripheral devices like tape drives and disks were built for several HP lines including the 3000. A few of these bits of 3000 iron floated across the horizon recently.
Free to a good home: This A-Class A400 server recently used by Michael R. Kan, retired MPE/iX support engineer now enjoying a post-HP life. The A400 had a dual boot capability and include a C1099 console terminals and cables. This was especially worthy of genuine care and affection. "I was on the MPE/iX support team before transitioning to XP/P9500 support," Kan said.
HP didn't want the A400 back when Kan left on a retirement buyout. "Since I was a ‘remote’ who was working, no one ever followed up on the equipment and I couldn’t find anyone to take it. MPE/iX had wound down and no one or group with HP wanted the extra 3000 stuff."
Kan's A400 made its way into a Bay Area workshop. As a penultimate model of the newer PCI-based 3000s, the server's worth is still something that can be tracked by hardware resellers. Only the A500 is newer.
On the other end of the value scale sits the HP 7978B tape drive. A working model surfaced on the 3000-L newsgroup last month. This was a $22,000 device in its heyday that backed up onto a 33.75 MB 9-track reel. One of these behemoths appeared in the 3000 community not long ago. The owner was reporting about taking it to its natural finish line: the scrapper. We'd call them recyclers in a more current term.
Tracy Johnson has owned this backup device since 1998. Just sitting in his garage, he said, when the day of community junking came around. He managed to fit the device in the back of his minivan for the 7978's last ride.
A $22,000 tape drive, sitting in a minivan (for now). Think about the resale life of those two devices. How much could you get for a 36-year-old minivan? No, it’s just parts on wheels there. Maybe some useful ones.
The van only has to navigate through gravity and traffic markers, while it avoids taking up the same space as other vehicles and pedestrians and structures.
The tape drive has a lot more to do. It’s almost like a clown car compared to the minivans of today. It has file formats, tape locations, and network-serial connections to navigate. There’s calibration to consider, plus the age of the media. All more complex than staying on the correct side of yellow lines on asphalt, or following the routing from one address to another.
The drive needs an operating system. The minivan’s operating system includes a driver, plus a set of maps or memories about how to get where the driver intends to appear. To be fair, it will be the rare minivan of 1984 that could still run. I don’t think the first minivan arrived in the world until a few more years after that.
Between those two points lies the XP line of storage devices. An XP12 started this run, and XP9500 wrapped it up. One of those surfaced in the community, too. Worthless? Not as much as the 7978. More of an antique, honestly. Without monetary value, unlike the A400, but able to store a thing or two. Headed for its last ride in a minivan, maybe.
Apple soared through a $500 per share mark yesterday. The market confidence comes from assessing the outlook for Apple's business model. The computers and devices Apple sells are powered by proprietary chips, either today, for phones and tablets, or next year for the rest of the company's line.
The operating systems for these devices are also Apple's specialized OS's. Software created for iOS or for MacOS will not operate on other devices. Soon, the Apple-branded chips will demand rewrites of applications.
Does this sound familiar? It should for customers who recall the state of HP's Year 2000 business plans. Proprietary operating systems all around for MPE, VMS, HP's Unix, and NonStop. HP-only chips powering all of those servers. Software rewrites needed as newer HP-proprietary chips entered to replace PA-RISC.
In a tale of two companies, HP's valuation at $70 a share in 2000 could be compared to Apple's $3.68 per share. Then there was a 3:1 split for Apple, and now there's a 4:1 split coming next week.
Making its own hardware and OS has been a good business play for Apple. HP turned away from this model to embrace commodity computing. Today only NonStop and HP-UX operating systems are sold by HP.
OpenVMS has been licensed by VMS Software Inc. MPE/iX licensing ended in 2010. Hewlett-Packard has a split over those two decades, indeed; the company is now halved into Enterprise and Inc. The size of its wide-ranging mission was too inefficient to maintain as a single entity. Commodity couldn't carry HP into a higher orbit.
Legacy strategy has often been powered by vendor-specific technology. Many factors apply to this year's soaring valuations. Apple became the first company ever valued at $2 trillion this month.
There's still value in legacy enterprise. The HP-UX and NonStop environments can be purchased from HP Enterprise today. Tru64, the Unix built by Compaq before HP bought the firm, is sold through indie outlets like Island Computing.
The last two decades seem to have proven there's no harm in engineering proprietary hardware and software environments. The crucial element is innovation and market reach. The invention within OpenVMS and MPE/iX keeps working for corporations that invested in legacy designs. Apple is releasing its 16th version of MacOS this year. Version number 14 of iOS rolled out this summer.
HP was able to create about 14 major releases of MPE/iX over the 20 years it sold the OS. It just hasn't been able to sustain growth using its own designs. That's a mission its legacy customers have accomplished.