Editor's note: In the last two weeks 3000 owners have been asking about DDS tape storage migration and how to find 38-year-old systems. Here in the last working day for the year 2017, it seems like we're running in a time machine. Here's some help on moving old data to new media.

We're taking Monday off to celebrate the new year. Not many people figured the 3000 would have users working in that 15th year since HP stopped making the server. We'll be back Wednesday with a new story. Seems like anything can happen.

I want to restore some files from a DDS tape to a store-to-disc file. It been a while I am not sure if this is something that can be done. I need some help with the syntax.

Alan Yeo says

I think you need to restore the files from the tape and then store them to disc, as the resulting disc file needs to build a header of the files it contains.

So after restore, the store to disc syntax is something like

!SETVAR BACKUP_FILE "nameoffileyouwantocreate"
!FILE BK=!BACKUP_FILE;DEV=DISC
!FILE SYSLIST=!BACKUP_FILE;DEV=LP
!STORE fileselectionstring;*BK;SHOW;PROGRESS=5

Keven Miller adds

There is also TAPECOPY that reads STORE tapes and creates an STD (Store to Disk) on disk -- provided the STORE is all on one tape. I have a copy of the program on my website. Look for TAPECOPY, it's a tar file.

About a month ago, HP 3000 managers, vendors and developers shared techniques on getting their MPE/iX systems a longer lease on life.That upcoming CALENDAR issue hits 3000s at midnight, Dec. 31 2027. The barrier of 2028 and beyond has been cleared. Now it's time to clear up some questions about the fear, uncertainty and doubt surrounding the lifespan of the 3000's OS.

Will my HP 3000 stop working on January 1, 2028?

The hardware itself may be worn out by then, but nothing in the operating system will keep PA-RISC systems — emulated or actual — from booting, running programs, or passing data and IO through networks and peripherals. MPE/iX will do everything it can do today, except report dates correctly to and from software and applications which rely on an older CALENDAR intrinsic.

Is this a problem with the hardware from HP? Will an emulated 3000 prevent this?

The CALENDAR problem is in the OS, not the hardware. The old intrinsic was only built to record accurate dates until then. The resolution will involve work within applications' use of intrinsics, among other software revisions. Replacing CALENDAR with HPCALENDAR is part of the solution. Stromasys Charon sites will have to deal with it too, because they are running faithful virtualizations of the PA-RISC hardware — and use MPE/iX. 

If I don't change anything on my 3000, will the operating system know what day it is on January 1, 2028?

SHOWTIME will report that it's the year 1900. SHOWCLOCK will report the correct year.

Will all file information remain correct?

All file creation and file modification timestamps will be accurate, and files which are created will have correct timestamps, too.

So what kinds of software will be reporting the wrong date starting in 2028?

Software which still relies on CALENDAR for its date-keeping may show incorrect dates. This software can be applications as well as utilities and reporting software. Changes to source code for the programs which use CALENDAR, replacing it with HPCALENDAR, take care of the issues. If software uses internal logic for data calculations, it will continue to work correctly in 2028, so long as it doesn't rely on CALENDAR. The problem actually occurs if FMTCALENDAR is called to format the date. Unless that call is trapped, FMTCALENDAR will always produce a date between 1900 and 2027.

What about the compilers for the OS?

COBOL 85 uses the newer HPCALENDAR intrinsic. The older COBOL 66 uses the older CALENDAR. 

What can I do if I don't have source code for my applications?

Vendors who continue to serve the MPE/iX market can change the call to CALENDAR into a call to HPCALENDAR. A support provider can assist a customer, with the cooperation of the source code holders, in using the newer HPCALENDAR. Alternatively, the call to FMTCALENDAR can be trapped at run time, and the replacement routine can re-map early 1900 years into years starting with 2028.

How about MPE/iX itself? Will that intrinsic ever be repaired? How do I get SHOWTIME running correctly?

Some portions of the OS will continue to rely on the old CALENDAR, which only has 16-bit range to use. Source code license holders—the eight companies licensed by HP to use MPE/iX source—may have an advantage in bringing some OS internals into line with site-specific patches. They are site-specific because HP doesn't permit a revised version of the OS to be recompiled and distributed. SHOWTIME is likely to remain incorrect, since it uses CALENDAR and FMTCALENDAR.

What about date-dependent work like job streaming?

Applications that can be revised to use HPCALENDAR will stream jobs on correct dates. Native job-streaming service in MPE/iX will work if a command uses a request such as "three days from now." In general, the more closely a piece of MPE/iX software relies on CALENDAR, the less likely it will be to deliver accurate dates starting in 2028.

My third-party software might keep track of the date to keep running. What can I do?

Source code revision will be the most direct solution in this case. Some support companies are considering a certification service for Year 2028 operations.

Wayback Wednesday

The replacement hardware arrived in a box that fit inside my mailbox. We bought a jumbo-sized mailbox in 1993, one big enough to let the industry trade journals lie flat on its floor. In those days our community relied on big tabloid publications to keep abreast of the future. Today the pages are digital and needing paper for news is fading fast.

The Minidisc MZ-R50 showed up in great working order, a replacement for the recorder that logged my interviews in the rowdy and roiling days of the 3000's Transition Era. The Minidisc is late '90s tech that can arrive by way of US Mail. A Series 929 wouldn't fit in any cardboard box with padding. That server is 104 pounds of a 2-foot by 18-inch unit that's 22 inches high. UPS could pull it off a truck, though.

My 1997 MZ-R50 has the same age as a Series 997, and like the 3000 server, the hardware has unlocked access to archival information. You buy these things to replace failed hardware, or sometimes for parts. Only the battery had failed on the R50. That's a component likely to be dead on old 3000s, too.

I plucked a Minidisc at random to test my new unit and found an interview about how Interex decided to put distance between itself and Hewlett-Packard. I wrote about the change in the relationship in 2004, but just a fraction of the interview made it into the NewsWire.

The thing about archival data is it can grow more valuable over time. Context is something that evolves as history rolls on. In the late summer of 2004 it wasn't obvious that Interex was overplaying its hand, reaching for a risk to sell the value of a vendor-specific user group. HP told the group's board of directors that user group support was going to be very different in 2005. The reaction to the news sealed the fate of the group. It began with a survey, shifted to a staff recommendation, and ended up as a board decision.

The recorded 2004 interview now puts those views and choices in context. You'll care about this if you ever need a user group, wonder how your enterprise vendor will support customers' desires, or hope to understand how corporate resources influence partnerships.

The key interview quote that made its way into our "HP World stands at brink of changes" report was a line from then-board president Denys Beauchemin. “We’re not competing with HP,” Beauchemin said about HP World 2005. “HP’s going to be there next year. HP will scale back drastically.” The scaling back was a correct assessment. The competition turned out to change everything.

Replacing HP's 3000 hardware is a natural occurrence in a homesteader's life. Components and systems built in the middle 1990s wear out after 20 years of use, whether it's frequent or infrequent. I felt the same way when I checked out the stored recordings here in my offices. I've been at conferences and interviews with a recorder since 1996. I used Sony's Minidisc all the way through the middle 2000s. It was better at indexing than cassettes. Finding anything is the real magic trick once the talk or the interview is done.

A homesteader might feel the same way about their applications and data created for MPE/iX. My Minidisc recorder above that failed was built in 2001 and like an HP 3000 of that era, alas, it runs its recordings no more. I could walk away from the Minidiscs — a couple of dozen at 74 minutes each — and assure myself nothing of value would be there.

Homesteaders don't have that luxury because their applications are so much harder to replace. It's easier for them to replace their aged hardware. My replacement Minidisc unit that's on its way was built even earlier than the one that just failed on me. The new-to-me MZ R-50 scheduled to arrive Saturday was first sold in 1997. The one that eBay's delivering might be a little less aged than that. But it's safe to say my replacement system will be 18 years old. It's advertised as still-working. Lots of its brethren are being sold for parts only.

In 1997 Hewlett-Packard was rolling out the Series 997, a high-end server that delivered the best performance numbers MPE/iX could claim by that fall. The Series 997 sold for $327,930 for a single-processor server, including a 100-user license, 512Mb of memory, a console and a UPS. IMAGE/SQL was part of that package, but the real value there is the compatibility with the applications—the equivalent of those talks and interviews.

That 997 server costs as little as $1,200 for a 5-processor unit today. A homesteader will need to arrange an MPE/iX license to step into that replacement hardware. I don't need a license to run those old Minidiscs, but I don't get the same level of hardware discount, either. The $329 R-50 now sells for $71. It will, if it arrives in working shape, run these recorded bits of 3000 history above.

That's 80 percent off for the 1997 Minidisc, and almost 100 percent off for the Series 997-500. The mere availability of 1997 hardware for business or recording is a testament to good design and the willingness to spurn change.

I have a new HP 3000 A-500 installation that I can't Telnet to. Ping works both ways, but I get nothing with Reflection's Telnet. What do I need to check on the 3000 to get Telnet running?

Robert Schlosser says:

Donna Hofmeister adds:

Hofmeister, one of the community's more experienced hands with the standard Unix and Posix utilities built into MPE/iX and the HP 3000, explains.

The samp files are 

BPTABSMP -- bootptab (most people don’t use)
HOSTSAMP -- hosts
INCNFSMP -- inetd configuration
INSECSMP -- inetd security 
NETSAMP  -- reachable networks
NSSWSAMP -- nsswitch
PROTSAMP -- protocol
RSLVSAMP -- DNS resolving
SERVSAMP -- services

I believe each of the files also has a counterpart in /etc which is a link to the real file in .NET.SYS. If the real files are missing from .NET.SYS then many things (including Telnet and FTP) won’t work.

It was an odd encounter to see the HP 3000 show up on the Forbes website recently. An article about technology and school systems mentioned the server in a sideswipe of a wisecrack. Justin Vincent, a CTO at a school software vendor, wondered aloud how 1970s computing would've handled a 20-student computer lab.

Since the HP 3000 has been a K-12 solution for more than 30 years, Vincent's article took aim at the computer. It was just a glancing blow.

When people first started talking about education technology in the '70s, technology itself was the main blocker. We simply didn’t have the capacity to scale networks. Our devices were huge, input methods were clunky, the cost of each device was prohibitive and there was simply no understanding of how to design easy-to-use K-12 software with individualized and blended features.

Can you imagine if a school district did decide to set up a 20-student computer lab in the '70s? With Hewlett Packard's first “small business” computer (the HP 3000), it would have cost the equivalent of $10 million, and the computers alone would fill up a standard-size classroom!

I was a student in a K-12 classroom in the 1970s. Instead of putting us high school seniors though advanced algebra, we could take a Computer Science course. I was eager to do this and learned that the only lab work we'd do in our parochial high school was filling out an IBM coding form (above) with FORTRAN commands. The actual IBM 029 keystrokes had to happen at the University of Toledo labs. We brought the green-bar output back to the classroom to debug our efforts.

It felt unfair to see those quotes around "small business" computer, though. The 3000 was a genuine small business solution compared to the mainframes. I also wonder how a 20-user 2000 of the late 1970s could have occupied a full classroom. Even in that day, terminals could fit on an average lab desk. The dimensions of tape drive, disk, and CPU still would leave room for students and instructors. Even the small Catholic school classrooms could accommodate a Series III with room to spare.

The writing arrived in the blogosphere by way of Forbes' Community Voice. In the 1970s this was called advertorial, the kind of copy I had to write as a young journalist to meet an advertiser's needs. By 2017 this writing is now being farmed out straight to the advertiser's staff. At least we had to label our advertorials as un-news. What might come as news is the HP 3000 is still running school administration in a few places.

I began writing about migrations only in 2001, after HP decided that moving was the way forward for 3000 folk. I already had 17 years on the 3000 beat by then. Much has happened over these last 16 years, and yet, less than you would think in some places. Companies began in earnest to move away from MPE/iX, sometimes for very good reasons. For example, if your application vendor starts sending you end-of-life warnings for your software, it's a good time to plan for a trip away from an HP 3000.

At other kinds of companies, migration seemed to be the safest way forward. Starting sooner than later was part of the 3000 ethos, too. That ethos might be one reason why some 3000 customers were working in their second decade of departing the 3000. The apps that were not broken didn't have to replaced right away, did they?

Eleven years have gone by since I produced this 8-minute podcast about one of those customers. From the very first year of the Transition Era we knew about the Speedware shop at Virginia International Terminals. VIT was a success story HP shared with its uncertain customers. VIT made the move to HP's Unix and all was well.

However, more than four years later (in 2006) not everything was moved off the 3000. Earlier this year we heard from someone at VIT about replacing their final MPE/iX app. This year. An interesting thing happened on the way to the exit. First they found the job bigger than they could handle themselves. To their credit, their IT management saw a bigger picture. Why just have a functional migrated application? You want it as efficient as it can be.

Back in 2006 VIT thought that way. It tested its migration about 18 months later than expected. Not everything made its way through that assisted migration process. VIT must have found a way to let migration pay its way, permitting a bit of functional MPE/iX to be left alone. Our 2006 podcast talks about the Why of a migration, as well as what happens when that Why changes.

Start to finish from 2002-2017 might be the longest term of any migration. A good 3000 manager doesn't care how long it takes. They care if it's done right—and on the schedule that best suits their organization. The podcast made a point back then which continues to be true. It's your calendar that matters.

It doesn't happen often, but the 3000 world has a request for experts in the employment market. Dwight Demming at National Wine & Spirits posted a notice yesterday, saying he needed two to three "HP 3000 programmers to work on a year-long project."

NWS has been a 3000 user since the 1990s, running an in-house application that tracks shipping of, well, wine and spirits. The customer has always been a forward-looking shop. A few years back the company in Oak Brook Illinois was using Hillary Software's byRequest to move its email and PDF from the 3000 to computers in the rest of the IT environment. byRequest is built to extract and distribute reporting from any HP 3000 application.

Kim Borgman of National Wine & Spirits said at the time, "We [use it to] e-mail all our reports now. Hardly any printing happens on the line printer anymore." byRequest will support secure FTP as well as standard FTP.

The current assignment at the company calls for programmers who are "highly skilled in COBOL, Image/SQL, and VPlus. The work can be done remotely, Demming said in his posting, "with occasional visits to Oak Brook."

The biggest payoff for the employment offer might be in the final line of Demming's post: "Possibly leading to full-time employment." That might be HP 3000 and MPE/iX work, or it might be work on a migrated platform. But a year's worth of HP 3000 work starting around 2018 is a benefit few people could have forseen back when HP turned off its MPE/iX lab lights seven years ago.

Applications for the jobs can be sent to Demming at his email address.

The perspective of tech veterans who left the 3000 community used to sway opinions of those who remained. Vendors sold services like support or software for MPE/iX. Then HP made sales difficult by striking the 3000 off its price lists. So the vendors and IT pros who couldn't make a sale or a living left our world. Some departed and remained wistful and respectful of what HP created for MPE/iX. Others have not done so. They departed and began to disrespect and mock the tech solution that made them a pro.

It makes no sense, they've now said for more than a decade, to put any more resources into MPE/iX or a 3000. Some exiles once lined up a 3000 in a cornfield and shot it up with weapons. The act was an effort at comedy. (A great actor on his deathbed reminded the world that dying was easy, and comedy is hard.) The cornfield gunfire was ruthless because those shooters were targeting a legacy.

The bullets hit the computer, but the shooters were off target. The firing squad treatment included an arsenal worthy of Yosemite Sam. A cannon missed the mark and had to be wheeled closer. The buffoons acted out a fantasy, the finale of what they called “an HP 3000 mainframe computer.” 

Those shots felt the same as those the 3000's devotees have endured in the Migration Era. The era is just about over, but so many of its exits were based on fears of parts inventories gone dry or a lack of vendor attention. Some vendors turned on their community, stoking new business by running down the old success. Those parts are rare, they say, and you can pay us to help you change your mind. HP ran aground with its strategies for computing. Now the CEO is leaving and saying that technology wisdom has a better chance of hitting the value target than business experience.

Even though it was designed in the late 1960s, MPE never had an end of life date. Hewlett-Packard chose to call its end of business deadline for MPE/iX the 3000's end of life. HP was done in December of 2010, but the end of life claim was never true. Now we've learned that not even the expiration of the CALENDAR intrinsic's accuracy, in 10 years from this month, won't make the 3000 die, either.

During the latest CAMUS conference call, a few developers and support providers made the future clear. The year 2028 would not be the moment when a 3000 would fail to boot up and run software including the MPE/iX OS. This was only the year when CALENDAR wouldn't be useful.

"I'm hearing the system won't roll over and die on January 1, 2028," said one 3000 owner during the call. 

"Correct," said Doug Werth at Beechglen. "There are some things that may stick at 2027, depending on how the code was written." Some dating features go back to 1900 for the YYYY elements of the date fields. "There are a lot of places in the operating system that still use the CALENDAR format," Werth added.

Support providers can prepare repairs for the places where MPE uses CALENDAR. The seven companies with source code for the 3000's OS, such as Pivital Solutions, can craft more elegant solutions.

Terry Floyd of the Support Group said MANMAN calls CALENDAR in the subroutine SLJDMPE, "which is used all over the place." Floyd has identified and outlined a repair for MANMAN's source code that permits the MPE/iX application to run until 2049.

Nobody has had much conversation about another alleged end of life date for alternatives to MPE/iX. Unix and its date handling routines stop being accurate in 2038. It's also true for Linux, which drives a lot of the enterprise applications that have tried to replace 3000 apps, as well as much of the cloud-based servers like Amazon's. End of life is not a phrase used in that discussion, one so prevalent that Year 2038 has its own Wikipedia page.

One diagnostic super-program, ODE, holds a wide range of tests for HP's 3000 hardware. These testing programs got more important once HP mothballed its Predictive Support service for the HP 3000 in 2006. Predictive would dial into a 3000, poke around to see what might be ready to fail, then report to HP's support engineers. ODE's diagnostics are a manual way to perform the same task, or fix something that's broken.

However, ODE includes programs that require a password. Stan Sieler has inventoried what was available in MPE/iX and examined each program for whether it's unlocked for customer use. That was back in the days when 3000 owners were still HP support customers. Today the 3000 owners are customers of third party support firms like Pivital Solutions, or Sieler's own Allegro. The locked programs remain in that state, more than six years after HP shuttered its support operations.