In Your History: Strobe emulator project rolls up sleeves

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.”


Using Shell Scripts on MPE/iX

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 [email protected]
2      //
/keep ss
/e
:

You have created a command file called SS — when you type SS you will execute showjob [email protected]

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 [email protected] 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.


For your older 3000: JBOD, RAID enclosures

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 was never a PC

Time warp tunnel
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.


How to schedule on MPE/iX using MPEX

Onscreen report
Newswire Classic

By Shawn M. Gordon

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]
                    [;[email protected]]
                    [;NOSEC]

Examples: %SHOWJOB [email protected]
           %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 [email protected] 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


3000 sites miss progressive tactics, then vendors

Puzzle pieces with hands
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.


Legacy systems remain ramparts of IT

Notre dame architecture
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." 

 


Giving gratitude for 3000s and survival

Thanksgiving-1680142_1920
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.


Application portfolio work helps with moving

Moving van

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? Quadrant
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."

When deciding whether to re-host (lifting code to another computer) or replace, the full range of software assets is inventoried. The real answer about what needs to be moved, and in what priority, comes from asking about the whole portfolio. While that study's going on, there are those closets to be cleaned. Few people do such cleaning, VEsoft's Vladimir Volokh says.

"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.

Photo by HiveBoxx on Unsplash


HP Enterprise reclaims 3000 manual library

HPE Documentation interface for support

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.