« December 2019 | Main | February 2020 »

January 30, 2020

Calendar date issues are already surfacing

Hurdles
The 2028 date hurdle for MPE/iX has been well documented and thoroughly discussed. Although the January 1, 2028 deadline — when MPE/iX CALENDAR processes will start to report dates as January 1, 1970, and so on — seems like it's years away, it's much closer. Calendar issues emerge as programs call for dates.

Programs that call for dates in the future are already facing the hurdle. Systems that use Unix, Linux, or other operating systems this month have triggered these involuntary date rollbacks already.

In one recent case, a top 100 pension fund had a nightly batch job that computed the required contributions, made from projections 20 years into the future. It crashed on January 19, 2018 — 20 years before Y2038.

HP 3000s have been key tools in many financial and resource planning operations. While dates are usually used to track transactions as a matter of history, some ERP users look forward to forecast their resource needs.

MPE/iX has a Y2028. Unix and Linux have a Y2038. This is important to know for a legacy system manager's planning and tactics. There's no good reason to tear down a legacy system if its only show-stopping flaw is date handling. A solution for the 3000 community is already at hand in several spots. 

Stromasys reports it has been working with an independent developer for a 2028 fix, something available to its Charon emulator sites. That update was shared with us in July of last year. It's not public yet, but that indie developer confirms the work is in progress. Beechglen has a 2028 solution it is selling as a service.

There are additional developers and consultants who say they're ready to repair 2028 issues with MPE/iX systems. It's important to know that the HP 3000, as one of the older legacy systems still working in businesses, is in no worse shape than systems driven by Linux or Unix. It's only a matter of when, not if, a date handling process will need to be addressed.

The legacy of an operating system is a condition defined very broadly. Legacy systems have been successful for a long time, and the vendor's focus has usually slipped away from these legacies. It can remind us of that term "proprietary" that was hurled at the 3000 for a decade before HP quit on its futures. Nearly all technology has a proprietary aspect, even if it only amounts to a support clause that makes one knowledge resource crucial to the OS health. 

Photo by Interactive Sports on Unsplash

01:23 PM in Homesteading, Migration | Permalink | Comments (0)

January 28, 2020

What good are Nike arrays?

HP NIke Array
By John Burke

3000 users still can employ used HP Nike Model 20 disk arrays. There was once a glut of these devices on the market — meaning they were inexpensive — and they work with older models of HP 3000s. Here's a note from one company using these Nike arrays.

"We’re upgrading from a Model 10 to a Model 20 Nike array. I’m in the middle of deciding whether to keep it in hardware RAID configuration or to switch to MPE/iX mirroring, since I can now do it on the system volume set. It wasn’t in place when the system was first bought, so we stayed with the Nike hardware RAID. We’re considering the performance issue of keeping it Nike hardware RAID versus the safety of MPE Mirroring. You can use the 2nd Fast-Wide card on the array when using MPE mirroring, but you can’t when using Model 20 hardware RAID.

So, with hardware RAID, you have to consider the single point of failure of the controller card. If we ‘split the bus’ on the array mechanism into two separate groups of drives, and then connect a separate controller to the other half of the bus, you can’t have the hardware mirrored drive on the other controller. It must be on the same path as the ‘master’ drive because MPE sees them as a single device.

Using software mirroring you can do this because both drives are independently configured in MPE. Software mirroring adds overhead to the CPU, but it’s a tradeoff you have to decide to make. We are evaluating the options, looking for the best (in our situation) combination of efficiency, performance, fault tolerance and cost.

Note: Mirrored Disk/iX does not support mirroring of the System Volume Set – never did and never will. Secondly, you most certainly can use a second FWSCSI card with a Model 20 attached to an HP 3000

All of the drives are accessible from either controller but of course via different addresses. Your installer should set the DEFAULT ownership of drives to each controller. To improve throughput, each controller should share the load. Only one controller is necessary to address all of the drives, but where MPE falls short is not having a mechanism for auto-failover of a failing controller.

In other words, SYSGEN reconfiguration would be necessary to run on a single controller after SP failure in a dual SP configuration. You could have alternate configurations stored on your system to cover both cases of a single failing controller but the best solution is to get it fixed when it breaks. The best news is that SP failures are not very common.

There is a mechanism in MPE for ‘failover’ called HAFO - High Availability FailOver. It is only supported with XP and VA arrays, and not on Nike’s or AutoRAIDs (because it does not work with those).

Andrew Popay provided some personal experience.

"We have seven Nike SP20 arrays, totaling 140 discs spread across all the arrays, using a combination of RAID 1 (for performance) and RAID 5 (for capacity). We use both SP’s on all arrays, with six arrays used over three systems (two per system). One of our systems has two arrays daisy-chained. The only failures we have suffered on any of the arrays have been due to a disc mechanism failing.

"We never find any issues with the hardware raiding; in fact, as a lot of people have mentioned, hardware raiding is much more preferred to software raiding. Software raiding has several issues, system volume, performance, ease of use, etc. Hardware raiding is far more resilient.'

As for anyone concerned about single points of failure, I would not worry too much about the Nike arrays, I would say they are almost bulletproof. For those who require a 24x7 system and can’t afford any downtime whatsoever, maybe they should consider upgrading to an N-Class, with a VA or XP. Bottom line: SP20’s are sound arrays on the HP 3000s, easy to configure, set up and maintain.

01:58 PM in Hidden Value, Homesteading | Permalink | Comments (0)

January 23, 2020

When the HP Way Led the 3000 Astray

Winding road forest

Editor's Note: Being a legacy system expert has its frustrating days. If experts of today ever wonder why they got into the lifespan of Hewlett Packard and MPE, they can look back to the start and the promise of the 3000. Bill Foster was a part of the HP team that created the system, before he went on to found Status Computing. the story below shows the an HP which had to remake MPE.

All the Foster you want, in an HP history worthy of being a book, is at his website.

By Bill Foster

If there ever was a company that always seemed to do the right thing, it was HP back in the 70’s. We had a term called The HP Way. There was no written definition — it was something you felt. When something good happened it was part of The HP Way. When you had the inclination to do something bad — cut corners on a project, treat a customer badly, turn in an inflated expense account, fire a really bad employee — these things didn’t happen. They were not The HP Way. It’s like we walked around with little halos over our heads.

Of course, if this was the only place you worked, you assumed all companies were like HP. You had to leave Hewlett Packard to become a part of the real world. So, we shipped HP 3000 serial #1 to the Lawrence Hall of Science in nearby Berkeley. A couple of weeks later they shipped it back. That 3000 could support at most two or three users on a good day -- nowhere near 16 or 32 or whatever they promised.  And MPE was crashing three or four times a day.

A few months and a couple of machines later HP punted and withdrew the 3000 from the marketplace. They gave free 2116 computers to the customers in hopes of appeasement — The HP Way. Bill and Dave were fuming -- this had been by far the most expensive project in the company’s history, and Hewlett Packard was being inundated with bad press — something that had never happened in the entire history of the company.

In fairly quick succession Paul Ely came down to save things and a few months later my boss Steve Vallender left. I don’t think Steve was fired — HP never fired anyone back then, they just promoted them into oblivion. But Steve was somewhat un-promotable — he lacked a college degree and HP was pretty snobbish about that.

Dick Hackborn asked me if I wanted Steve's old job. Are you kidding? Sure! Hurt me! I was looking to move up the ladder — this was a fantastic break. My guess was they chose me over my hardware counterpart because management finally figured it was better to put a software guy in charge of computer projects. No matter -- here I was, not even 30 years old, running all the hardware and software development for HP's computer business.

My first and most important job was to come up with a plan for the hockey pucks.  A year earlier, Dick Hackborn had hired a couple of smooth-talking marketing bozos out of IBM. Hackborn created a group called Product Marketing within his Engineering group to compete with the real Marketing group at the other end of the building.

This was very out of character for HP — to hire senior people from the outside. One of their first actions was to give mementos of a project to the engineers who had developed it — something tangible to remember their efforts. Apparently this was done all the time at IBM. The IBM marketing bozos came up with the idea of a brass paperweight about the size of a hockey puck, but about half the thickness. Stamped on each one were three overlapping circles signifying batch, realtime, and timesharing — things that the 3000 was supposed to do.  And each individual’s name was engraved on the back.

These were supposed to be handed out months earlier, but with all the problems, Vallender had hidden them away in a file cabinet. My first command move was to sneak in one weekend, lug them out to my car, and take them home to my garage.  The last thing I wanted was for anyone to get wind of them. The next step was to try to get some kind of usefulness out of the 3000 machine, and that meant fixing MPE.

Image by David Mark from Pixabay

05:36 PM in History, News Outta HP | Permalink | Comments (0)

January 21, 2020

Using RAID5 on an HP 3000

Hard-Drive
By Gilles Schipper
Homesteading Editor

RAID storage, including a low-cost MOD20 array, can improve a 3000's performance. Here are a few things to consider if you will be acquiring a MOD20.

Although possible, I would not recommend utilizing RAID5 LUNs in an HP 3000 environment — unless your greatest priority is to maximize disk space availability at the expense of performance.

RAID5 offers fail-safe functionality over a group of disks (minimum of three) by means of one disk of the RAID5 disk being allocated as a parity disc. The benefit of RAID5 over RAID1 is that it results in a greater amount of overall usable disk space than RAID1. However, it performs poorly in an HP 3000 environment, and cannot be booted from if specified as the system disk (LDEV 1).

Although the supported maximum memory configuration of each Storage Processor (SP) unit is 64MB, 128MB works best (although not all of it can be used).

Each SP has 4 memory slots. You can maximize the performance of the MOD20 by populating each SP with four 32MB memory SIMMs, 72-pin, FPM with parity, 60ns.

The NIKE MOD20 is a very capable and useful solution to the fragile environment afforded by a JBOD environment — particularly because most 3000 JBOD disk systems tend to be very mature and consequently relatively unreliable and prone to failure.

And, although the MOD20 disk system itself is also quite long in the tooth, it’s got built-in fail-safe mechanisms. Also, the MOD20 would appeal to those with very limited budgets, since the devices are quite inexpensive in the used-equipment market.

There are other, more advanced RAID systems that also support the HP 3000 environment. These include the HP Autoraid12H system, various VA7400 systems, some of the HP XP-family members, as well as EMC systems. This list is in order of increasing cost, for the most part.

The bottom line: if you are not already utilizing RAID technology for your 3000, now would be a good time to consider it seriously.

01:53 PM in Hidden Value, Homesteading, Newswire Classics | Permalink | Comments (0)

January 16, 2020

MPE/iX Command File Scripts Explained

Code on screenBy Ken Robertson

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.

More Information

Tim Ericson’s collection of UDCs and Command files has recently been resurrected and re-published in the public domain at www.3kassociates.com/index_cmd.html

Image by fancycrave1 from Pixabay

08:42 AM in Hidden Value, Homesteading, Newswire Classics | Permalink | Comments (0)

January 14, 2020

Listserv still serving advice after 26 years

Bank vault safety deposit boxes
The 3000-L Listserv repository is the HP 3000 resource that's been in the longest continuous use for the MPE/iX ecosystem. HP had a Jazz website for about 13 years, content that was carried over to Fresche Legacy's servers once HP's labs closed. 3000-L was online for about a year or so before the NewsWire entered the Web.

The content on the 3000-L was a big reason I believed we could do a monthly HP 3000 newsletter. We curated and learned, education and advice we shared with readers. Even after 26 years, 3000-L can be searched for answers that go back to the era of MPE/iX 4.0.

That repository is full of history about the people who have created the MPE ecosystem, too. with enough patience, most answers will be hiding in the hundreds of thousands of email messages. All are logged by subject line. 3000-L can be searched within date ranges, too.

3000-L was once so robust that we could publish a column about its gems once a month as part of the first 10 years of the NewsWire. 

The columns are archived in our 1996-2005 pages. We called them NetDigest, and for awhile they were written by John Burke, who helped us found the NewsWire with his knowing voice and deep technical experience.

For the source material for those columns, refer to the 3000-L search panel.

For the columns, refer to the Tech Page of the '96 - '05 issues. Once you arrive at the Tech Page, just do a search within the page for the phrase net.digest. We've got 106 columns there.

Photo by Jason Pofahl on Unsplash 

03:29 PM in Hidden Value, Homesteading, Web Resources | Permalink | Comments (0)

January 09, 2020

How to Encrypt 3000 Log-on Passwords

Padlock
NewsWire Classic

Is there a way to encrypt MPE logon passwords to keep auditors satisfied that the HP 3000 is secure? We need to show that they cannot be easily read with the ;pass parameter (i.e. listuser xxx.yyy;pass)

The replies generated one of the longest threads of the month on the 3000-L.

Tracy Johnson offered an opinion that “the answer to your auditors is not in encrypting passwords. The answer lies in restricting AM and SM capability to only those key personnel who can use the the “;pass” parameter within established policy. AM and SM capability also presumes the same capability to change another user’s password, and therefore also the ability to look it up.”

Chris Boggs reported in a virtual testimonial that “Our auditors were not satisfied by even limiting SM and AM capabilities to only two individuals (both in our department). Since we had Vesoft's Security/3000 already, I changed our regular logon ID’s to use the Vesoft password which is encrypted.

"There are other features in Vesoft security which are handy when dealing with auditors such as password obsolescence, password “history,” minimum password standards, inactivity logouts, day/time restrictions, automatic deactivation of logonID’s after a certain number of failed logon attempts, and probably a few others.”

Bradmark’s Jerry Fochtman said some Interex Contributed Software Library routines can help. “I developed a routine to return the passwords for user/group/account (based upon caller’s capabilities) during this time. It also signaled if the password was encrypted, simply returning blanks in this case. There was another routine which given a password, would encrypt it based upon HP’s approach and tell the caller if the entered password matched the one in the system directory.”

Fochtman also took note of the Vesoft abilities and added his humble opinion on the security solution from Monterrey Software, “SAFE/3000. It also utilizes one-way encryption for its passwords. And in terms of strictly security, it is a better tool in several areas, such as network security.”

Michael Gueterman, whose company Easy Does It Technologies does pre-audits for 3000 sites, added notes on using only session-level passwords.

“That’s fine for some things, but I still recommend keeping at least MPE Account passwords in place for all but the most “open” areas. For accounts with SM or PM, I also recommend MPE User passwords as well. Also, when at all possible, explicitly define what people are ALLOWED to access, instead of using generic wildcards. Wildcards make auditors unhappy, and an unhappy auditor is dangerous!”

Image by meineresterampe from Pixabay

03:41 PM in Hidden Value, Newswire Classics | Permalink | Comments (0)

January 07, 2020

So many owners = so much value

Office building colored floors
Editor's Note: While the MPE/iX MANMAN customers mull over their 2020 options, it's useful to look at the history of an application being orphaned by its creator. Cortlandt Wilson, a consultant on ERP systems, wrote this early-years history of how MANMAN's ecosystem evolved. The bottom line is proof that value in an application like MANMAN is baked-in — or it wouldn't have survived so much change.

Over the years MANMAN has experienced highs and lows. At one time the software's creator, ASK Computing, was a media darling — a successful high-tech company founded and run by a woman, Sandy Kurtzig. The MANMAN product has a good reputation in the mid-sized manufacturing systems market. The company, however, unsuccessfully tried to follow up its success with a next generation solution based on a new technology infrastructure.

When I was with ASK in the late 1980s, on several occasions I heard the president and co founder of ASK say that “we are an applications company, not a software tool company.” Unfortunately, the companies on top of the ERP market all developed their own technology infrastructure. The search for a new technology infrastructure led ASK to purchase Ingres for its relational DBMS and tools.

ASK finally purchased a infrastructure and the basic application software for a ERP system from a then little-known Dutch company named Baan. As part of the sales agreement ASK modified significant amounts of the functionality and called the application MANMAN/X. Strained by development costs and weak sales, the company floundered.

By 1994, ASK was facing a severe cash crisis. Looking for a financial angel or a buyer, the board of directors finally recommended a buyout offer from Computer Associates. Many ASK employees, however, responded to the takeover by resigning.

Industry analysts’ concerns about CA’s “ferocious reputation” and the loss of experienced staff highlighted the takeover of ASK. Many MANMAN customers expressed skepticism about CA’s ability to maintain the product, and the quality of support noticeably dropped. 

By 1996, CA concluded that application software and services shouldn’t be managed like software tools and utilities. CA spun off its manufacturing products into an independent business unit to be named the MK Group (MK for Manufacturing Knowledge). MANMAN/X was renamed MK to reflect its marketing role as the flagship product.

Note: Wilson reported from a user group meeting of CAMUS in the late 1990s that the MK Group began to prove stable and was responding better to customer needs. There's inherent value in MANMAN that the repeated transfers of ownership have scarcely erased. By this summer, sites using the ERP package will have right of use for a product that has endured three changes of ownership. The software went from ASK Computer Systems to Computer Associates to SSA Global to Infor. The final owner of MANMAN, Infor, kept up support for nearly 14 years.

Photo by Takafumi Yamashita on Unsplash

04:28 PM in History, Homesteading | Permalink | Comments (0)

January 02, 2020

Even in apps retirement, 3000 data survives

Aging hands on keyboard
A notable manufacturing datacenter in the 3000 community is making changes to its application lineup over the coming year. Although the profile of the apps and their status is changing, there's no talk of removing MPE from the datacenter yet.

Al Nizzardi is part of the IT command at TE Connectivity, the company that has more MANMAN instances running than any other in that ERP ecosystem. There's been a devotion to the 3000 that's extraordinary. Terry Simpkins has been the face of using 3000s in manufacturing since the 1990s. The IT director at TE even appeared once in a magazine ad promoting the 3000.

At TE, plans for the future of ERP applications have been aimed at SAP for several years. It's a migration, but one with echoes. SAP shares a customization practice with MANMAN: both apps are better choices when they're tuned to individual business practices.

After a few decades of use, the data repository for a MANMAN site becomes an asset that deserves its own curation. Data from a 3000 goes back to the late 1970s. The final cutover to SAP is likely to take place in late 2020 or sometime in 2021, by Nizzardini's reckoning.

"Databases are slowly migrating to SAP," he said. "I believe the final cut over will be 12 to 24 months out from today. That does not mean the end of the HP 3000. Historical data will reside on a HP 3000 of some sort."

TE runs a production N-Class, a test N-Class, an N-Class disaster box, and an A-Class. The datacenter does some Netbase shadowing, Nizzardini added. "We are still formulating a plan on our options, whether it's using an emulator or the N-Class we have" for archival MPE computing. "Either one of those options will be moved to a co-lo."
 
Experts on managing MPE/iX computing never stray too far from a place of helping. "We will be ready for when the Phoenix arises," Nizzardini quipped. "I've often said they will have to yank that HP 3000 out of my cold dead hands."
 
Image by Steve Buissinne from Pixabay

12:41 PM in Homesteading, Migration | Permalink | Comments (0)