December 28, 2018

Fine Tune: Optimized Disaster Recovery

By Gilles Schipper

While working with a customer on the design and implementation of disaster recovery (DR) plan for a large HP 3000 system, it became apparent the implementation had room for improvement.

In this specific example, the customer had a production N-Class HP 3000 and a backup HP 3000 Series 969 system in a location several hundred miles from the primary.

The process of implementing the DR was completed entirely from a remote location — thanks to VPNs and an HP Secure Web Console on the 969. One of the most labor-intensive aspects of the DR exercise was to rebuild the IO configuration of the DR machine (the 969) from the full backup tape of the production N-Class machine, which included an integrated system load tape (SLT) as part of the backup.

The ability to integrate the SLT on the same tape as the full backup is very convenient. It results in a simplified recovery procedure as well as the assurance that the SLT to be used will be as current as possible.

When rebuilding a system from scratch from a SLT/Backup tape, if the target system differs in architecture from the source system, it is usually necessary to modify all the device paths and device configuration specifications with SYSGEN and then rebooting the system in order to even be able to utilize the tape drive of the target system to restore any files at all.

(This would be apart from the files restored during the INSTALL process — which does not require proper configuration of any IO component at all).

Some would argue that this system re-configuration needs to be completed only once, since any future system rebuilds would require only a “data refresh” rather than a complete system re-INSTALL.

I say that this would be true only in very stable system environments where IO configurations — including network printer configurations — are static and where TurboIMAGE transaction logging is not utilized. Otherwise there could be unpleasant results and complications from using stale configurations in a real disaster recovery situation. In any case, there really is no reason to take any chances,

The labor-intensive step of creating a proper DR target system configuration environment is achievable minus the labor-intensive part – or at least without repetition of the manual chore of re-configuring the target system each time the DR is exercised.

Unless both the production system and the DR system are architecturally similar (i.e. they belong to same HP 3000 family) the configuration of the target system (the DR machine) cloned from the source system (the production machine) will be non-trivial.

At a minimum, before data restore can begin on the DR machine, the path hierarchy of the tape drive associated with the backup tape must be re-created. Further, if the subsequent restore requires more than just the system disk, all the path components for all the disk drives must also be created.

In a real DR situation, this task can be daunting at best – particularly since it may be difficult to access the appropriate documentation that describes the pertinent SYSGEN configuration. How much preferable would it be to be able to complete this configuration well in advance of the hope-to-never-happen event.

In fact, it is entirely possible to create an appropriate DR configuration environment that is (almost) completely integrated into one’s production environment.

SYSGEN IO requirements

In order to provision a potential DR HP 3000 system’s IO configuration requirements into an existing production HP 3000 SLT, it is only necessary to configure all of the DR path components into the existing production system’s IO configuration.

The fact that these paths do not exist on the production (source) system is immaterial — as long as you can withstand the menacing, although perfectly innocuous console error messages that accompany a reboot of a system so configured.

There is also the matter of actual device numbers — and that is why I included the “almost” when mentioning “completely integrated” earlier.

Clearly, it is not possible to have duplicate device numbers when configuring both production and DR devices into the production SYSGEN IO configuration. So, in order to distinguish between the two systems (one the real production, the other virtual DR), I simply add 100 (you can choose any number) to the device numbers associated with the virtual machine. Then when actually testing or invoking the DR process, it is a simple matter to change the device numbers in a batch job designed for that purpose.

Another batch job could be pre-built that would add the appropriate disk drives and volume sets to the system’s disk pool, using VOLUTIL. These batch jobs would be included in the full backup tape and could be restored almost immediately following the INSTALL by referencing :file tape;dev=107 (to use my example of adding 100 to the corresponding virtual device).

The command :restore *tape;{fileset}; directory;olddate; keep;create;show (where {fileset} corresponds to the fileset that would include the appropriate device number change and volutil batch jobs. One could take this technique one step further in the case where the DR target machine is unknown.

In such a situation, you could create a SYSGEN IO configuration that includes path constructs for any possible virtual machine that you could think of and include them in the host configuration – adding 100 for devices associated with virtual machine 1, 200 for virtual machine 2, and so on.

Posted by Ron Seybold at 08:03 PM in Hidden Value, Homesteading, Newswire Classics | Permalink | Comments (0)

December 24, 2018

Gifts given, 11 years after a Christmas

Eleven years ago we wished for nine things that would help 3000 users in the years to come. At the close of 2007 there was no virtual HP 3000 product like Charon. We didn't even allow ourselves to wish for such a thing.

But here on the last office day before Christmas, it's fun to review our holiday wish list. Let's see what we got and what HP withheld until it was too late for the vendor to supply what the community requested.

We've heard these desires from HP 3000 customers, consultants and vendors. Some of the wishes might be like the Red Ryder BB-Gun that's at the center of the holiday epic A Christmas Story. As in, "You don't want that, you'll put your eye out." If you're unfamiliar with the movie, the line means "I don't want you to have that, because I worry what you will hurt once you get it."

1. Unleashing the full horsepower of A-Class and N-Class 3000 hardware
2. Just unleashing the power of the A-Class 3000s (since every one of the models operates at a quarter of its possible speed)
3. Well, then at least unleash the N-Class systems' full clock speeds
4. HP's requirements to license a company for MPE/iX source code use
5. A way to use more than 16GB of memory on a 3000
6. A 3000 network link just one-tenth as fast as the new 10Gbit Ethernet
7. A water-cooled HP 3000 cluster, just like IBM used to make
8. A guaranteed ending date of HP's 3000 support for MPE/iX
9. Freedom to re-license your own copy of MPE/iX during a sale of an 3000

HP finally supplied Numbers 4 and 8. The first created the Source Code Seven, vendors who hold licenses that let them create workarounds and custom patches for MPE/iX issues. Number 8 arrived during the following year. It can be argued HP didn't end all of its MPE/iX support for several years beyond that official Dec. 31, 2010 date.

Some of the more inventive indie support companies have devised ways to use 32 GB of memory for 3000s, too. Ask yours about Number 5.

The last two items seem like real BB-Guns. But they have a chance of helping the community see the 3000 future more clearly, instead of putting its eye out.

A guaranteed ending date for HP's 3000 support is something both homesteaders and migration experts desire. By moving the finish line twice already, HP has kept customers from finishing migrations, or even starting them, according to migration partners.

What's more, the "we're not sure when support is really done" message keeps the 3000's service and support aftermarket in limbo. Customers tell us that they will be using their HP 3000 systems until their business demands they migrate away. HP plans to change its business practices someday for the HP 3000. But nobody knows for certain what day that will be.

That brings us to No. 9, the freedom to re-license your own MPE/iX. HP development on this software ends in one year. That's the end of changes to the operating environment, a genuine Freeze Line for MPE/iX. HP should be able to compete on a level field with the rest of the community. HP Services seems to need those special 3000 licenses.

Number 10? A wish for a long life and continued interest in MPE/iX from the HP 3000 gurus of the community. Someone can bring some these gifts after there's no one inside HP to cares about the 3000 community.

Posted by Ron Seybold at 07:40 AM in History, Homesteading, Newswire Classics | Permalink | Comments (0)

December 14, 2018

Routers and switches and hubs, oh my!

Editor's Note: Initial HP 3000 hardware networking can be like a trip down a Yellow Brick Road. Here's a primer for the administrator who's wondering if that HP 3000 can link to a network

By Curtis Larsen

Auntie MAU! Auntie MAU! A Twisted Pair! A Twisted Pair!

Once upon a time networks were as flat as the Kansas prairie, and computers on them were a lot like early prairie farmsteads: few and far between, pretty much speaking to each other only when they had to. (“Business looks good again this year.” “Yep.”) Most systems still used dumb terminals, and when speaking to anything outside the LAN, system-to-system modem connections were the way to do it.

A tornado named the Internet suddenly appeared in this landscape. It uprooted established standards and practices, swept aside protocols and speed limitations, and took us into a Technicolor networking landscape very different than what was there before.

Toto, I get the feeling our packets aren’t in Kansas anymore

Smaller companies were tossed before the tornado to eventually land and quickly begin growing again in the new environment. Large companies like IBM, HP, Digital, and Microsoft, who were rooted and established in their own proprietary standards (it sounds like an oxymoron, but it’s true) survived by generally ignoring the howling winds. Eventually, munchkin-like, they all came out to see what the general fuss was about, and found that a house-sized chunk of change (pun intended) had landed.

Networking, and the TCP/IP protocol had truly arrived in style, bringing strange new applications and markets. Serial connections and proprietary networking (“What do you mean we don’t need SNA to connect to the Wichita office anymore?”) gave way to a new kid on the block. And her little dog, too.

Follow the Yellow-Colored-Cable-and-Labeled-at-Both-Ends Road!

So then the HP 3000 managers found themselves sitting in a strange new networking land of strange new networking things. And for some of us, trying to understand the whole of it all — especially in relation to “legacy” system like the HP e3000 — was a little daunting. What are all these networking black boxes we plug the system into, and what do they all do? How can they make life better? (How can they make life worse?) If you’re not sure (or just plain curious) read on.

We’re off to see the wizard — this wonderful wizard of ours!

The networking wizard of your HP 3000 system is a program named “NMMGR.” It allows you to define networking hardware and tells you how to create connections with them. But what things can you define? Before we talk about connecting to things, we should probably take a crash-course in the things you’re connecting to.

Which path do I take? Well, you could take this one, that one, or both...

The basic networking boxes you’ll connect to are hubs, routers, switches, bridges, and gateways. Oh My. Let’s take them one at a time.

Since life is like an analogy, I’ll stretch one for the hub to go like this: If your network traffic is like water through a hose, then a hub is like a splitter, allowing multiple exits. Generally speaking, a hub simply splits the traffic from the “incoming” line into each connected port “out.” This is cheap and simple to set up if you don’t have a lot of connections, but like too many divisions on any hose, too many hubs will make the end connections anemic. The fewer connections the better, so most hubs have no more than 24 ports total.

Obviously, to make things better for all connections in larger networks, more “water pressure” was needed — and the switch was born.

Pay no attention to that man behind the curtain!

No, I’m not talking about the System Administrator. A switch looks very similar to a hub, but the appearance ends there. Again, if your network is like a stream of water in a hose, then your garden-variety switch is like a water tank, adding pressure to the line. Huge water tanks are placed at the heart of a city’s water system, while small tanks are placed on buildings. At the heart of most networks — tended by a cooing Network Administrator — is a core switch (the main tank).

Additional “work group” switches (building-sized tanks) can be used in wiring closets for special-need areas of the network. So, although a hub and a switch both offer multiple connections, the resulting “streams” have vastly different origin and force. Now that we’re one big speedy networking family, no one minds if it all fails, right? No? Well love can build a bridge, and so can electronics.

My Network’s crashing… What a world! What a world…

Having all your network connections on one physical segment isn’t too grand — especially when it fails. By segregating physical networks and then “bridging” them together, you ensure that in the face of adversity, some people can still laugh at the ones who can’t work. Aquariously speaking, a simple bridge is like a valved pipe between two water systems, passing water in both directions, and shutting one side’s valve if that system “loses pressure” (goes down). You say you want to route water based on content? Well then.

This here’s the ‘Packet of a Different Header’ you’ve heard about

Simply put, a basic router is an intelligent (logically) one-way bridge, examining network data information and very quickly sending data packets down one line or another. In our epic analogy, a router could be a thermal valve, forcing only cold water to flow this way, and hot water that way, preserving us from the heartbreak of tepidity. Since the router has to work quickly, it usually works at a lower level than other equipment does, caring less about content and more about destination. You say you’d like to exchange hot water with someone else? You’d like the gate to swing both ways?

There’s no place like the home network! No place like the home network…

A router is excellent at sending packets from Here to There (and not necessarily Back Again), but nothing beats the gateway for two-way communication. A gateway takes data from one network and sends it to another, even re-creating the data packet on the other side, if need be.

To stretch our analogy to its limits, we could say that two different water systems exist, having the same characteristics, including temperature. One system is chlorinated, while the other is not, and so simply allowing the water to pass unmolested would be an issue — one system would become diluted, and the other exposed. What we need is a filtration pump that allows the water to be pumped in either direction, adding chlorine one way, and taking it out in the other direction.

Connecting to the Internet requires a gateway, since your home network doesn’t “know” how to reach something out there. What it does know is how to hand off a data packet destined for “Not Here” to a gateway for processing. The gateway in turns checks the packet’s address and sends it to the best possible network closer to the packet’s Ultimate Destination, re-labeling the packet as it does so, and putting its own address in the packet’s “return address.” If the packet’s Ultimate Destination isn’t on the new network either, then the gateway there does the same thing until the packet finally hits the Emerald City.

On its way back home, because of all the “return addresses” it picked up, the packet passes back through each gateway that it came from until, clicking its little ruby slippers, the packet realizes it is in no place but home.

Because of its intensive examination work, a gateway is almost always dedicated to its task, especially on larger networks. It was the gateway’s filtering abilities that led to using them as a firewall to protect networks by purposefully filtering and/or denying different types of connections and data. But the firewall is a topic all its own — just make sure you use one!

And you were there, and you, and you.
Oh Auntie Carly, there’s no place like MPE!

So there you have it — Networking Devices 101. Now that you know what you can connect your e3000 to, you can come up with some ideas on how to use them, and answer questions about what to connect to. Should an 3000 be connected to a hub, or to a switch? (Switch!) Does a printer need to be connected to a hub or a switch? (A hub will usually be fine.) Should I use my 3000 as a gateway? (I think not.) Should the physical part of my network the e3000 is on be bridged? (Yes.) Can I configure a gateway and connect my e3000 to the Internet? (Certainly. But make sure you have a firewall first!)

Curtis Larsen has been working with HP 3000s for over 25 years, and believes that, given enough time, any application can be written using the CI.

Posted by Ron Seybold at 07:02 PM in Hidden Value, Newswire Classics | Permalink | Comments (0)