« January 2018 | Main

February 19, 2018

Relief at Finding One Another is Real

Missed-youIt can be difficult to round up a collective of HP 3000 and MPE users. Even the CAMUS user group society meeting of November was dominated by vendors, consultants and non-customers. I began long ago to classify consultants as customers. They're representing a company that needs expertise but can't put an expert on the payroll. During the call one consultant spoke up saying he was doing just that. A representative from Infor was asking how many of the meeting's attendees had MANMAN installed.

After awhile Terry Lanza, who'd organized the meeting conducted on a widespread conference call, asked "Is there an HP 3000 user group still going, or has that kind of folded?" Doug Werth of Beechglen replied, "The user group doesn't really exist much. It's just the HP3000 Listserv."

Even the 3000-L, where the L stands for Listserv, has many moments of absolute quiet. People are curious, reading what's been up there for more than 25 years. But it can be weeks between messages. The Quiet Day Count stands at seven right now, after an exchange about groups residing on multiple volumesets.

That's why it's encouraging to see people like Lanza and Dave Wiseman bring efforts to bear on finding one another. Wiseman, who's hosted some 3000 gatherings over the very-quiet last five years, still has his eye set on a 2018 3000 meeting. He's looking in specific at two dates for a meeting in June: Saturday the 16th or Friday the 22nd. That could be a meeting in Cupertino, or a gathering out on the California coast in Santa Cruz, he says. I'd be voting for that Friday (flights are cheaper on Thursdays) with time to enjoy California for a couple days afterward.

Get in touch with us via email, or better yet with Wiseman, to show a preference. (davebwiseman@googlemail.com or +44 777 555 7017)

The overwhelming emotion I see and hear during meetings like that CAMUS call or an in-person event is relief. "I thought I was the only one left out here running a 3000," someone said during the CAMUS call. You're not, and gatherings reinforce your good stewardship of an IT resource. They might also provide an update on what to do next. It could be virtualization or a migration. Real world experience flows easier in person. You can also learn what you might have missed.

10:18 PM in Homesteading, Migration, Newsmakers | Permalink | Comments (0)

February 16, 2018

Friday Fine-tune: Deleting Bad System Disks

As HP 3000s age their disks go bad, the fate of any component with moving parts. Even after replacing a faulty drive there are a few software steps to perform. Wyell Grunwald explains his problem after replacing a failed system bootup disk

Our disk was a MEMBER in MPEXL_SYSTEM_VOLUME_SET. I am trying to delete the disk off the system.  Upon startup, the 3000 says LDEV 4 is not available.  When going into SYSGEN, then IO, then DDEV 4, it gives me a warning that it is part of the system volume set — and cannot be deleted. How do I get rid of this disk?

Gilles Schipper of support provider GSA said that INSTALL is something to watch while resetting 3000 system disks.

Sounds like your install did not leave you with only a single MPEXL_SYSTEM_VOLUME_SET disk. Could it be that you have more than one system volume after INSTALL because other, non-LDEV 1 volumes were added with the AVOL command of SYSGEN — instead of the more traditional way of adding system volumes via the VOLUTIL utility?

You can check as follows:

SYSGEN
IO
LVOL

If the resulting output shows more than one volume, that's the answer.

He offers a repair solution as well.

The solution would be as follows:

1. Reboot with:

START NORECOVERY SINGLE-DISC SINGLE-USER

2. With SYSGEN, perform a DVOL for all non-LDEV1 volumes

3. HOLD, then KEEP CONFIG.SYS

4. Create new SLT.

5. Perform INSTALL from newly-created SLT.

6. Add any non-LDEV1 system volumes with VOLUTIL. This will avoid such problems in future.

If you do see only one system volume with the LVOL command, the only thing I can think of is that VOLUTIL was used to add LDEV 4 to the MPEXL_SYSTEM_VOLUME_SET after the install.

07:43 PM in Hidden Value, Homesteading | Permalink | Comments (0)

February 14, 2018

Wayback Wednesday: An Armload of Value

Snow with A-ClassOn a February afternoon in a Silicon Valley of 2001, the HP 3000 realized its highest order of invention. The PA-RISC processors had been powering the server for more than 13 years, and HP was working on the next generation of systems. Y2K was already one year into the rear view mirror and the lineup needed a refresh. HP responded by giving the customers a server they could carry under their arms.

The first A-Class model of what HP called the e3000 came into the meeting room of the Interex Solutions Symposium under Dave Snow's arm. The audience was developers, software company owners, and the most ardent of 3000 customers. The box was the realization of a low-cost dream about the 3000s. The installed base had been hoping for hardware that could keep the 3000 even with the Intel-based hardware powering the Windows business alternatives.

Snow was a little out of breath as he came to the front of the meeting room in the Sunnyvale hotel. He set the 3.5-inch-high server down and caught the eyes of people in the crowd, lusting for the computer. "No," he said, "this one is already spoken for in the labs." Like in the older days of Hewlett-Packard, the company created a tool its own engineers wanted to use. He said the computer was the result of a challenge from a customer the year before: "bring a 3000 into the Chicago HP World show you could carry under your arm. It's a portable computer, although it does weigh a bit."

A-ClassCPUsThe A-Class systems cost thousands less per year to support than the Series 9x8 and 9x7s they replaced. HP told resellers A-Class support would be $415-$621 a month for systems running up to 65 percent faster than the older models. But HP also horsepower-throttled the servers in a move to preserve value for the most costly servers already in the market. The HP-UX version of the A-Class was more than twice as fast.

Snow borrowed one of the few that were testing-ready from HP's MPE/iX labs on that day. In a movie of 5 minutes, Snow leads a tour of the advantages the new design offered over the 9x9 and 99x 3000s. HP pulled the covers and cabinet doors off to show internal hardware design.

HP introduced the speedier N-Class systems just a few months later, and so the market had its ultimate generation of Hewlett-Packard hardware for MPE/iX. The 2001 introduction of the A-Class—a computer that sells today for under $1,500 in some price lists—was part of the reason for the whiplash when HP called off its 3000 futures just 9 months after that February day. When the Chicago HP World closed in that summer, it was the last expo where HP's slides showed a future of more innovations.

These 14-year-old systems have been eclipsed by the Intel hardware, but running a virtualization system. The Stromasys Charon HPA is running MPE/iX production applications on servers even smaller than that A-Class. HP had the idea of making its computers smaller. It was up to the virtualization concept to make them both smaller and faster.

07:16 PM in History, Homesteading | Permalink | Comments (0)

February 12, 2018

MPE/iX keeps propelling relevant history

Professor KanzbergAt a recent meeting of HP 3000 managers running ERP shops, the present conditions and futures surfaced during a discussion. The MANMAN users, running an application on 3000s that hasn't seen an update in more than a decade—like their servers and OS—marveled at the constancy in their community.

Things change slower than expected. A monolithic application like ERP is the slowest of all to change. MPE/iX and its apps are proof: the history of technology is the most relevant history. History makes migration a requirement.

Ed Stein is a board member of the CAMUS user group. At the meeting he said the past three years have not removed many members. The 2028 CALENDAR replacement process caught his eye.

"I chuckled when I read a NewsWire article in 2015 and thought, 'Hey, how many of us are going to be around in 2028?' Well, most of us who were community members in 2015 are still members now," Stein said. "There's a future for those still running on MPE. If you don't like the hardware, then there's Doug Smith [from Stromasys] telling you how to get over that issue. MANMAN could be around in archival use 10 years from now—if not in actual production use."

Stein read that article about the CALENDAR intrinsic's shortcomings and decided he'd plan ahead, just to check off one more crucial challenge to the 3000's useful lifespan. 

"We want there to be a CALENDAR fix sooner than later," Stein said. "Because later, the talent might be retired or gone to fix this thing. We're looking at this as more of an insurance policy. If by chance we're still on this platform 10 years from now, we're going to be okay."

The platform's history is responsible for HP's continued standing in the business computer market, after all. Professor Melvin Kranzberg (above) wrote a set of laws to show how we relate to technology. MPE's relevance is more proven with every subsequent development.

Rule 5 among technology historian Kranzberg's rules: All history is relevant, but the history of technology is the most relevant. The laws read as a cheat sheet for explaining our era that includes Facebook, Google, the iPhone—and yes, cloud-based ERP replacements for MANMAN.

From an article in the Wall Street Journal published just after the MANMAN meeting:

The Cold War led to the buildup of nuclear weapons and the missiles to deliver them anywhere on Earth. That led to the development of a war-proof communication system: the internet. Many related innovations subsequently seeped into every aspect of our lives.

But does that mean we owe the modern world to the existential contest between the U.S. and the former U.S.S.R.? Or was that conflict itself driven by previous technological developments that allowed Hitler to threaten both nations?

Without prior historic events, how could ERP become a system built upon Salesforce and served up from cloud-based computing resources? No MANMAN or HP 3000 success drags back the entry date for the ERP replacements in the cloud.

The 3000 owners preparing for their migrations continue to prove the worth of their investments from the 1990s in MANMAN. 

"You're not alone here in the MANMAN arena," said Doug Werth of Beechglen at the meeting. "MANMAN is still a fairly small subset of companies that are still running HP 3000s. I'm really shocked to say here in this year that there are that many people running HP 3000s. But you're not alone here."

08:56 PM in History, Homesteading | Permalink | Comments (0)

February 09, 2018

Using a PURGEGROUP to clean volumes up

Empty file cabinetIs using PURGEGROUP a way to clean up where groups reside on multiple volume sets? I want to remove groups from Volumesets that aren't considered HOMEVS.

Tracy Johnson says

The syntax for a command on group PUB.CCC might read

PURGEGROUP PUB.CCC;ONVS=USER_SETSW

Denys Beauchemin says

The ALTGROUP, PURGEGROUP and NEWGROUP commands act on the specified volumeset after the ONVS keyword.

The HOMEVS keyword is used to specify in which volumeset the group is supposed to reside and where the files will be found in a LISTF or FOPEN.

If you have the same group.account existing on multiple volumesets and they have files in them, the entries on volumesets—other than what is in HOMEVS for that group—are invisible. If you want to get to them, you need to point the group's HOMEVS to that volumeset and then you can get to the files.

If there are no files in the group.account of other volumesets, it's not a big deal.

Keven Miller says

You could review the volume scripts available that were once on HP's Jazz server. 

Take care in using  the PURGEGROUP command. You can have files existing in the same group name, on separate volumes—which makes mounting that group a problem. So make sure the group on the volume is clean of files you might desire before the PURGEGROUP.

HP's documentation for the PURGEGROUP command has a similar warning.

In the two pages devoted to PURGEGROUP, the manual says,

Do not attempt to purge the PUB group of the SYS account. The public group of the system account, PUB.SYS, cannot be completely purged. If you specify this group in the group name parameter, all non-system and inactive files are purged, which seriously impairs the proper functioning of the entire system.

04:09 PM in Hidden Value, Homesteading | Permalink | Comments (0)

February 07, 2018

Living with what's still working in MPE

Classic-carsSome functionality of MPE/iX will be outliving its accuracy. That's the situation with the CALENDAR intrinsic, which now has less than 10 years of correct capability remaining. Few 3000 support and development companies can reach inside MPE/iX source, and of those, nobody's going to fix the original intrinsic.

"There is no fix inside the CALENDAR routine," says Steve Cooper of Allegro. "There is no pivot point in the CALENDAR routine. It's returning a number from 0 to 127. It's up to the program to decide what to do with that. Or you live with it."

On the latest technical conference call, some companies with access to HP's MPE/iX source were on the line. "If you want to fix the banner when you log in, then you need the source code for MPE," said Doug Werth. "If you want to fix the program that's printing the wrong date on a report, then you need the source code to your program."

To be clear, even having MPE/iX source code won't give CALENDAR more years of accuracy. Werth said that fixing MPE/iX—something the source code companies like Pivital at least have enough license to attempt—isn't an open subject, either. "There's a lot in that HP licensing we're probably not allowed to talk about," he said, speaking of Beechglen.

Chevrolet ApacheLooking the other way and living with what's still working—that's genuinely possible for a 3000 that's not calculating time between transactions. "For this group of people," said CAMUS board member and 3000 manager Terry Simpkins, "if they're still using MANMAN transactionally, they're going to care. If you're in an archive mode where all you're doing is looking up things that happened in the past, not so much."

Many adjustments for declining functionality will come by revising application code. "You can intercept the call to CALENDAR, but the program will be expecting a 16-bit return value in the CALENDAR format," Cooper said. "There's nothing you can do with CALENDAR's value at that point."

The 3000 has been here before. The last time there was a lot of company, as 1999 turned into 2000 for computers from every vendor. CALENDAR won't kill MPE/iX—in that way, it's unlike what the community did for Y2K remediation. 

Allegro was one of the companies that gave 3000 managers date management tools to help get applications beyond Y2K. "I lost a lot of sleep between 1992 and January, 2000," he said. "I'm not losing sleep over this one."

"If you don't have source, and it bothers you, then there are solutions," he added. "The rest of it is cosmetic and you ought to be able to look past that. If you have your application source code, by all means it's simple."

Werth said, "I still have a customer with an application that is not even Y2K compliant. Every year they set their calendar back to the year where the day of the year lines up with the current day of the week. So Wednesday November 16 is still Wednesday, November 16. The year is just wrong."

"There may be some things you just have to live with. You run a report and it says it's 1909 instead of 2037. You live with that. Where it's critical, you figure out a fix for it. Where the applications are having problems, there's plenty of people who will be available to help fix it." 

08:12 PM in Homesteading | Permalink | Comments (0)

February 05, 2018

Migrations Altered to Appear as Emulation

Terms about transition have been fluid and flexible for more than a decade in the 3000 community. People say migration when the solution is actually conversion. Migration has also been called emulation, a status that was the holy grail when HP canceled its 3000 plans. "If only," said the companies dug in on MPE/iX, "there was a way to make something behave like the 3000 value set."

Altered-Carbon-MigrationOpenMPE spent the first four years of its lifespan chasing that ideal. First there was the goal of getting ahold of enough source code that MPE/iX could continue to evolve in labs outside HP. That was shot down right away, and then there was the goal of getting a replacement platform for HP's hardware. The 3000 experience was lashed to PA-RISC and HP wasn't building any more of those servers by 2003.

Enter the first discussions of making a chip that could mimic PA-RISC, a PA-8000 at the least. This emulation was not going to happen in hardware. One plan proposed that HP would continue to make the chips and sell them to a third party vendor. People wanted to believe something.

What people wanted was a way to slip their 3000 computing into a new body, something fresher than HP's old designs. This past weekend Altered Carbon dropped on Netflix. The story shows how the things that make up our true selves — like the programs custom-built to run a company — can be re-sleeved into a new body. The brain is called a Stack on the show, the body is a Sleeve. Sleeves are disposable for the right price. The Stack is backed up and treasured. You only experience Real Death when your Stack is destroyed.

The magic is moving the Stack into a new Sleeve. The magic was putting MPE/iX stacks onto the disposable sleeves of Intel hardware. After emulation's ideal went into hibernation, Stromasys opened the door back up with software, and true emulation was born. It's been more than five years by now, and the project became a product quickly. Emulation means making one host mimic another. It's got a powerful attraction: limited change and no re-training.

Emulation looks like migration, though, when it walks like it and sounds like it. This ducky takes non-3000 software (Linux, Windows, even Unix) and plants it in place of MPE/iX. The programs will slip across to the new host after revisions and rewrites, work that's usually delivered by the line of code. There are substitutions for surrounding tools (like MPEX, or a job scheduler) that demand retraining. It probably looks different to the users, too, so there's that adjustment.

Migration still has real benefits. It walks and sounds a lot different than a software engine that takes 3000 programs and runs them on Intel hardware. Emulation has no other changes except to learn how to replace the oil in the engine and learn how to start it up. Charon, really. Everything else is migration. If you'll be headed to migration, it's a straighter path acknowledge you'll migrate and find an agent to apply that change. The 3000's had years of camouflage offered as emulation. In place of a real emulator, it was the best way forward.

Real migration doesn't pretend to be emulation. Migration of legacy systems assumes there are better tech solutions that have been established since the 2001 designs of MPE/iX and PA-RISC. Genuine migration retains business logic, line by line, with whatever service expertise is needed. You get what you pay for because you need more. It's not the best solution if all you need is non-HP iron.

You get more from real migration than from emulation. More changes, to be sure, so the benefits revolve around extended connectivity (to other software, non-HP) and a broader future (tools not controlled by a system vendor). A bigger ecosystem beckons.

Emulation, by now, needs to be virtualization. The level of complexity in emulating software has been demonstrated over the last 20 years. MPUX was a part of the ViaNova/3000 solution back at the start of this century. It was a sub-system to lets 3000 sites run and maintain MPE/iX applications elsewhere. It was not emulation. MPUX gave system administrators the 3000’s command set, as well as supporting MPE/iX intrinsics, on non-3000 environments. The software didn't isolate applications or users in an emulation environment, but instead provides Unix, Linux or Windows services to the MPE/iX applications.

A migration and an emulation are two different things, a distinction that's important to acknowledge. Emulation gives standard and supportable hardware to MPE/iX with a minimum of change. Migration changes development of surround code, can involve re-training users, strives to modernize apps, and must deliver adaptability to new software.

Migration also gives new, fresher hardware, just like emulation. It's just about the only benefit the two solutions have in common by 2018. Ask for migration by name. And for emulation, do the same.

08:52 PM in Migration | Permalink | Comments (0)

February 02, 2018

Simplifying MPE/iX Patch Management

NewsWire Classic

By John Burke

Patching-machineEven though Patch/iX and Stage/iX were introduced with MPE/iX in 1996, these HP tools are poorly understood and generally under-used. Both are tremendous productivity tools when compared with previous techniques for applying patches to MPE/iX. Prior to the introduction of Patch/iX and Stage/iX, system managers did their patching with AUTOPAT, and you had to allow for at least a half-day of downtime. Plus, in relying on tape, you were relying on a notoriously flaky medium where all sorts of things could go wrong and create “the weekend in Hell.”

Patch/iX moves prep time out of downtime, cutting downtime in half because you create the CSLT (or staging area) during production time. Stage/iX reduces downtime to as little as 15-20 minutes by eliminating tape altogether and, furthermore, makes recovery from a bad patches as simple as a reboot.

This article is based upon the Patch Management sessions I have presented at Solutions Symposia. The complete set of 142 slides (over 100 screen shots) and 20 pages of handouts are downloadable in a file from www.burke-consulting.com. The complete presentation takes you step-by-step through the application of a PowerPatch using Patch/iX with a CSLT and the application of a downloaded reactive patch using Patch/iX and Stage/iX. Included is an example of using Stage/iX to recover from a bad patch.

Why should you care about Patch Management? Studies and surveys suggest that 50-80 percent of all HP 3000s will still be running by 2006-2009 – even HP now agrees. Keeping a system running smoothly includes knowing how to efficiently and successfully apply patches to the system. HP has committed to supplying bug fix patches to MPE/iX and its subsystems through 2006, including two PowerPatches per year. [Ed. note: The process continued through 2008.] There may also be new functionality added, either to support new devices or in response to the System Improvement Ballot (SIB).

Patch/iX is a tool for managing patches. It can be used to apply reactive patches, a PowerPatch, or an add-on SUBSYS tape with a PowerPatch. Patch/iX is actually a bundle including the PATCHIX program and a number of auxiliary files that are OS release dependent. Patch/iX allows you to:

• Qualify all patches in a set of patches;

• Install reactive patches at the same time as a PowerPatch;

• Selectively apply patches from a PowerPatch tape; and,

• Create the CSLT (or staging area for Stage/iX) while users are still on the system; i.e., when it is convenient for you without incurring downtime.

Stage/iX is an OS facility for applying and managing the application of patches. Stage/iX reduces system downtime for applying patches to the length of time required for a reboot and provides an easy and reliable method for backing out patches. Stage/iX includes an interface to Patch/iX that creates the “staging area” and two utilities:

• STAGEMAN, which allows you to manage all aspects of patch staging, including which version of the OS will be used for the next update; and,

• STAGEISL, an ISL utility available from the ISL prompt whenever the system is down. It contains a subset of STAGEMAN functionality that allows you to recover from most problems.

Steps in staging

The set of all operating system files, for example NL.PUB.SYS, etc., are considered the current Base OS. Stage/iX creates and manages staging areas, which are HFS directories that hold versions of files that are different from the Base. More than one staging area can exist at a time. Each staging area contains the difference, or delta, between the Base OS and a patched version of the OS.

When a staging area is activated on the next boot, the files in the staging area are moved into their natural locations while the Base versions of the files are saved in a Stage/iX archive HFS directory. To back out a patch, the reverse takes place and the system is restored to its original state.

Once you are satisfied with the new and patched OS, you can COMMIT the staging area to the Base, deleting the staging area directory and all archived Base files. Note that Stage/iX and Patch/iX allow new patches to be staged and applied in a cumulative fashion. In other words, if you create a new staging area while another staging area is active, the new staging area will contain all the changes between the Base and the active staging area plus all the new changes.

Whether or not you use Patch/iX and Stage/iX, the key to successful OS patching is preparation. Information is the key to preparation. The System Software Maintenance Manual (S2M2) for your particular release of MPE/iX is the bible for all patch management activities. It contains a checklist for each possible update and patch activity along with detailed sections corresponding to checklist items. A hardcopy version and a PDF version on CD usually ship with each major OS release.

A PowerPatch usually comes with some patch-specific documentation – make sure you have it available before you start.

Finally, before you ever sit down at the keyboard, create a Patch Book for the specific patch activity you will be attempting. You can do it with the hardcopy manual and a copy machine, but I prefer to use the PDF version, printing out the two-page checklist and each section that makes up the checklist to create my Patch Book.

How to apply patches

Before proceeding too far, check HPSWINFO.PUB.SYS to ensure the patch has not already been applied. [Note that Patch/iX will tell you if a patch, or even a superceding patch, has already been applied, but it only takes a moment to check HPSWINFO and it could save you some time.] Each patch has an eight character ID. For example, consider TIXMXC3B. The first three characters indicate the subsystem; in this case TIX stands for TurboIMAGE. The next four characters are internal to HP’s patch management mechanism. The final character is the version identifier; in this case “B” indicates the second version of this patch.

First off, identify the proper checklist, in this case Checklist B, and create your Patch Book. Next, review the information about the patches at the ITRC; in particular, look for any patch dependencies.

You need to make sure you have the latest version of Patch/iX installed on your target system. This is critical to your success. All sorts of bad things can happen if you use an old or incomplete version of the Patch/iX bundle. To check the version of Patch/iX, sign on as “MANAGER.SYS,INSTALL” and type in PATCHIX VERSION, The program will respond with something like: Patch/iX Version B.01.09

Once you have the current Patch/iX and your patches, you are ready to run Patch/iX and create your staging area. There are four steps in any run of Patch/iX:

• “Select Activities,” where you define what type of patching activity you want to perform. You have the choice of adding a PowerPatch, adding reactive patches from tape, adding reactive patches from download or adding SUBSYS products.

• “View Patches” (optional): You can actually view information about all the patches that have been applied previously to your system. Note that this can easily number in the hundreds for a system that is kept reasonably up to date.

• “Qualify Patches,” where Patch/iX does a lot of work to determine which patches of the set you supply it with can and/or should be applied.

• Create the stage, the tape, or both that will be used to actually change the OS.

This is all done while normal production continues and places a minimal load on your system. Once you have created your stage with Patch/iX, you run STAGEMAN to activate your staging area with the SET command. The next time you boot your system (and this can be done remotely from your home at 3 AM Sunday morning if you like), your changes will take effect. Total downtime is the time it takes to do a SHUTDOWN followed by a START NORECOVERY.

What if something goes wrong? If you have problems after successfully rebooting your system and you want to back out your patches, simply run STAGEMAN and use the SET command to make the Base the active stage, reboot your system and you are right back where you started. Suppose you cannot even boot the system successfully after setting the stage? Simply boot to the ISL prompt and use STAGEISL (see Fig. 3 below) to set the active stage to BASE, reboot and, again, you are back to where you started.

Figure 3: Using STAGEISL to recover from a SYSTEM ABORT due to a bad patch

Once you are satisfied with your changes after reasonable testing you can again run STAGEMAN and this time use the COMMIT command to make the active stage the Base and free up the disk space occupied by the old Base.

10:41 PM in Hidden Value, Homesteading | Permalink | Comments (0)