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