« February 2017 | Main

March 24, 2017

A Few Stops on the 3000 Maintenance Line

ToolkitAfter inviting our readership to share their HP hardware service providers, we're got some early entries to share. The list of 3000 support teams is not the same as the companies who continue to service hardware. Much of the time these are different companies. While a manager can find some help on MPE/iX administration from a hardware outlet, this account-level support is more thorough and fine-tuned coming from a company like Pivital Solutions, or from The Support Group for MANMAN and ERP-focused engineering.

Even HP recognized this when the company was the primary support vendor for 3000 sites. A Customer Engineer was the equivalent of that hardware guru, working in the days before what Hewlett-Packard called Phone In Consulting Service. Close to 30 years later, onsite hardware maintenance is still the linchpin of keeping HP's aging hardware alive. Customers don't perform much of this while working with a vendor. "There's a liability issue when you have the customer do the component replacements," said one rep who's been working 3000 accounts for several decades.

A Software Engineeer was something very different than an HP CE. Not only did they know IMAGE at a depth that could outpace a CE, they often knew a customer's applications. Not just the HP-branded apps, either. In time, the top-tier utility vendors offered a kind of SE service. Adager was well-known for saving a site from calamity that wasn't yet a customer.

Without further preface, here's a few notes on some hardware resources who've volunteered information or been verified by their customers.

Saratoga Computers: "We are a group of ex-HP CE's," says Jim Maher. "All of us are experts servicing HP3000, 9000 and yes even 1000's. our average experience working on HP equipment is over 30 years." Hardware support providers usually branch out to other systems, such as Dell and HP's ProLiant systems. even Cisco switches, workstations and printers. Maher says that's the case at Saratoga.

Blueline Services: Bill Towe founded this provider that backs up the internal needs at The Support Group, among many other 3000 customers. In some cases the best way to bring up a downed 3000 is to ship a replacement system; that's what happened once, according to the Support Group's Terry Floyd. Component-level service is available as well.

In Europe, ScreenJet's Alan Yeo recommends Newcorp. Yeo's software tool and consultancy practice also has worked with Nike Computing and Prestige Datacentre Solutions.

Allegro's Steve Cooper said he's got a select group of companies for his MPE/iX customers using HP's 3000 hardware.

Our top-tier partners, that I can recommend without reservations are:

Ideal Computer Services (serving Northern California, Southern California, Maryland); Black River Computers (working in Ohio) and Abtech (based in San Diego)

We also do work with a number of other hardware maintenance companies, and even act as an escalation center for some hardware/software maintenance companies. But for one reason or another, those companies have not made it to the above list. Most of our customers still come through a third-party hardware company, but many contract with us directly.  Some of those are self-maintainers, some rely on their applications vendor for hardware support, and some are just rolling the dice. We try to be flexible, meeting our customers' needs. As a result, we see a bit of everything.

Pivital's practices utilize third party hardware-centric companies. But CEO Steve Suraci says his company uses its own technicians, too. The company's in an elite position, since it's got a license for the MPE/iX source code, one of just a handful of firms with such technical access.

We continue to support both MPE and the underlying HP 3000 hardware as one of the select few remaining support companies with access to HP's original source code. We maintain 7x24x365 phone support for those requiring that SLA. In New England, we support our own hardware agreements with our own local technicians. Outside of New England, we support our customers through a network of contracted technicians that have agreed in writing with us to support our customers SLA. In many cases, we will maintain parts on site to help facilitate quicker times to recovery.

One other way to resolve hardware issues can bypass the HP components completely. That's the strategy that works for the MPE/iX sites using the Stromasys Charon HPA virtualized 3000s. No HP hardware is required to keep MPE/iX apps and services available, because the entire configuration is powered by Intel-based servers (ProLiants are popular, but Dells reign, too) and non-HP peripherals.

06:28 PM in Homesteading | Permalink | Comments (0)

March 22, 2017

Webinar explores data migration roadblocks

MB Foster is broadcasting a webinar on Thursday at 11 AM Pacific Daylight Time, a briefing that covers tools and strategies to move data. The program promises to cover components of data migration projects. As is often the case, the webinar also will highlight the potential roadblocks to migrating data. Explanation of methods, project planning, and data governance are also a part of the one-hour show. Registration for access is at the MB Foster website.

PotpourriIt can take months to move data from one platform to another. Just ask Bradley Rish, who as part of the Potpourri Group managed a two-step process to migrate away from Ecometry software on an N-Class HP 3000. Potpourri first went to Ecometry on HP-UX, then a few years later moved away from HP's proprietary environment to Windows. Same application, with each move aimed at a more commodity platform.

But there was nothing commodity about the company's data. Data migration required eight months, more than the IT pros at the company estimated. Rish said that two full-time staffers, working the equivalent of one year each, were need to complete the ultimate migration to Windows.

Migrations of data don't automatically mean there's an exit from the HP 3000. At Potpourri, after a couple of years of research by IT, the exit from the 3000 was based on HP's plans for the computer, not any inability to serve more than 200-plus in-house users, plus process Web transactions. It's a holding company that serves 11 other web and catalog brands. More than half its transactions occur in the final 90 days of each year. Holiday gift season is the freeze-out time for retailer IT changes.

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

March 20, 2017

Data migration practices support cloud IT

Crm-data-migration-steps-cloudCompanies moving from HP 3000s to cloud-based IT are reaching deeper into data migration. In some cases, the records that have never left a datacenter are becoming an asset managed in cloud computing. The process prompts lessons on tools and practices that can be new to IT administrators and ERP developers in 3000 shops.

Work at The Support Group is helping to lead manufacturer Disston Tools onto the Force.com cloud services, leaving the classic MANMAN ERP application behind. Disston is adopting the Kenandy cloud ERP solution as a MANMAN replacement.The tools to migrate Disston's data cover a wide scope of functionality, from the Minisoft IMAGE-savvy ODBC utility to the commonplace Microsoft SQL Server Information Services (SSIS).

The latter tool can be priced more effectively for a smaller enterprise if it can be licensed as a developer version for a one-time data move, said the Support Group's David Floyd. "I'm not running a production database with SSIS," Floyd said. He added that it took four days of training to become fluent in using SSIS. At the Force.com cloud service, a proprietary database takes the place of IMAGE to store company information that has sometimes never left the world of MPE/iX and the 3000.

Migrating a key enterprise asset like ERP can trigger expansion of data capabilities. The Support Group's Terry Floyd said that adding a data warehouse has been part of migration engagements like the Disston project. SQL Server-based warehouses have become a reliable facet of upgraded ERP. Data warehousing was a potential tool in the 3000-based ERP architectures. The services were often provided using non-3000 database repositories.

The pricing for these data mart and data warehouse concoctions were well outside the reach of small- to medium-sized enterprises, though. One offering from the late 1990s, SalesMAN, was a solution that ranged from $95,000 to $160,00, sold as a bundle. The mart database was priced separately.

On the other end of the software cost scale, that one-time SSIS license for a developer was under $100 for a year, Floyd said.

Migrations can also spark consolidations and normalizations of data. For example, the Support Group experts say a company with several product lines created by separate entities will hope to merge part number sequences. An 8-digit number and a 12-digit number for two lines becomes a single numbering scheme.


11:20 PM in Migration | Permalink | Comments (0)

March 17, 2017

Friday Fine-Tune: Moving all disks at once

I want to take all my disks, system volume set, and the user volumes, and move them to another machine that has no disks. How can I best do this?

Lars Appel replies

You might use SYSGEN to create two different config groups in the SYS account, one for the old system (e.g. CONFOLD), and one for the new system (e.g. CONFNEW). To create the new config you might start with one of the existing config templates, e.g. CONF9x8.SYS for 3000/9x8 systems. Use BASEGROUP to open it, adjust IO to your needs and KEEP it as CONFNEW.

7935Just make sure that every disk gets an LDEV in the new config. Paths and LDEVs (except for LDEV 1) do not need to be the same on the new system. MPE/iX will notice (and "collect") all available volumes during bootup (as long as they are "visible" by a configured LDEV number).

Shutdown the system, plug disks into the new box, power it on, boot from the primary path (or enter the appropriate path for LDEV 1) and at the ISL prompt do a START NORECOVERY [NOSYSSTART] GROUP=CONFNEW.

You might also need to adjust NMCONFIG with NMMGR as a different system will probably have the LAN cards at a different physical path. In case you make a copy of NMCONFIG, make sure it stays on LDEV 1 (FILE;DEV=1).

We replaced LDEV1 on our HP 3000, did an INSTALL. Then we did
The MPE-filespace was restored normally, but the HFS filespace was not. RESTORE told me to use CREATE=PATH which I then did. The DIRECTORY is on my STORE tape - so what went wrong?

Wolfgang Kinscher, and Gilles Schipper reply:

If you are planning an install keep this in mind: Do not specify the option "DIRECTORY" with a partial (DATE>=) backup. STORE will not put the HFS directory structure on tape. Do the following instead: STORE ;*T;DIRECTORY stores all of your MPE/HFS directories on tape. Then do your partial backup without DIRECTORY option

After the install, first restore your DIRECTORY with RESTORE *T;;DIRECTORY and then restore your partial and your latest full backup respectively.

09:13 PM in Hidden Value | Permalink | Comments (0)

March 15, 2017

3000 job fills at mainframe's speed

Ursinus_College_sealPublic listings of HP 3000 positions can be tricky to track. A Web search I run with Google tagged an opening in Pennsylvania last week. Google will track a search term and email results to you. Although "HP3000" returns a lot of pages about 3000-horsepower motors, it sometimes unearths news.

The position looked like a classic one and didn't seem to be related to migration work, although it's hard to verify the latter. The immediate opportunity, posted by David Mortham of staffing firm The Fountain Group was for an "HP 3000 Mainframe Engineer."

We are seeking a HP 3000 Mainframe Engineer for a prominent client of ours. This position is located in Collegeville, PA. Details for the position are as follows:

  • Good knowledge in HP3K Mainframe.
  • Good Experience with COBOL, Suprtool, Cognos Quiz, QTP and MPEX.
  • Able to work on enhancements as per the business requirements.
  • Able to troubleshoot issues within HP Mainframe Environment.
  • Able to handle the technical production support issues
  • Prepare technical documentation for various processes flow applications.
  • Able to manage business requirements, writing business requirement documents / technical design documents.
  • Excellent design and technical query writing skills.

It's all there: Powerhouse 4GL, aided by top tools MPEX and Suprtool, with the applications in COBOL. It wasn't available less than a week after the March 6 posting. 3000s can not only be as fast as any mainframe, the remaining openings in 2017 move off the market at similar speeds.

There's not much of a clue about where this 3000 job, a full time one at that, was open. But the listing floated up on the Higher Education job board. Ursinus College, an institution nearly 150 years old, is in Collegeville. Universities earn higher regard when they're older. Some business computer systems do as well.

11:22 AM in Homesteading, Newsmakers | Permalink | Comments (0)

March 13, 2017

3000 friends: Meet in the Valley, or seaside?

Dream InnAn HP 3000 user group meeting has become so rare by 2017 as to be legend. After Interex closed up shop suddenly in 2005, Alan Yeo organized a late-binding gathering in 2005, then another in 2007 and another in 2009, all in Silicon Valley. By 2011, Yeo was working along with me and Marxmeier Software's Michael Marxmeier to put on the HP3000 Reunion at the Computer History Museum. The Reunion provided the debut spot for the only HP 3000 emulator, the Charon HPA from Stromasys.

Then the meetings began to evolve to reconnect us without needing a formal program. The most enjoyable part of the formal meets, after all, was the SIG-BAR gatherings in the hotel lounges. Gossip and speculation were always a key part of SIG-BAR. Lately the meetings have moved exclusively to this Special Interest Group. Last year there was a lunch meeting at the Duke of Edinburgh pub, set up by Birket Foster.

There's something about these leaders that can rouse people to return. The Bay Area in summertime has drawn a rich collective of 3000 veterans and experts. In 2008 the Computer History Museum hosted a seminar on 3000 software history. Another fellow with user group meeting experience is leading this year's charge to the Valley.

Dave Wiseman notified us about a 2017 gathering he's setting up for the Bay Area.

So we used to all be good friends in the community and its about time we met up again for a beer or three. We had a couple of very pleasant meetings in the UK and I am in California early June so I thought that I might organize one in the valley around June 5/6/7th. I am happy to organize a meeting while I'm in San Francisco. Could you tell me if you would be interested in coming? We’d love to see all of our old friends again

Dates: Any preference for Monday June 5th, or Tuesday June 6th?
Location: San Francisco/ SFO airport hotel/ Cupertino, or Santa Cruz (I’d see if we could book the Dream Inn for a Santa Cruz location)
Time: Lunch, afternoon or evening

Please email me, davebwiseman@googlemail.com, so we can see if there are enough people interested to make it worth everyone's while.

I'd put a vote up for the Dream Inn (above, seaside) since it was a stop on my cross-California 20th wedding anniversary trip with Abby. They're even got a Dream Floor at the top.

Stan Sieler has already said he's available for the meeting, even before it's got a firm date and time and location. Stan has to make room for a magic class he teaches on Monday nights. With enough interest, users could make a meeting appear this summer.

Unlike the full-on group meetings of old, today's gatherings feature no Powerpoint slides and plenty of memories—plus updates on what everyone is doing these days that's different.

08:18 PM in History, Homesteading, Newsmakers | Permalink | Comments (1)

March 10, 2017

Friday Fine-Tune: Going Beyond JBOD

By Gilles Schipper

Mod 20sOne of the most cost-effective ways of advancing the reliability of your legacy system may be to replace your existing “JBOD” disk system with a much more reliable disk system. MOD20 units, still a better deal than individual disks, can provide a good starting point to implement RAID. JBOD is an acronym meaning “just a bunch of disks” — which would characterize the majority of HP 3000 systems as they were initially sold. JBOD disk systems comprise a set of independent — typically SCSI-connected — disks, which are each seen by the HP 3000 as a single logical device number or LDEV. Each disk LDEV is associated with a “volume set” and the failure of a single disk renders the “volume set” to which it belongs inoperable and un-accessible.

Traditionally, most 3000 systems have comprised a single volume set (specifically, the required SYSTEM volume set, with the brevity-challenged label “MPEXL_SYSTEM_VOLUME_SET”).

Systems comprising a large number of “JBOD” LDEVs increased the likelihood of system downtime, since the failure of a single, old disk effectively resulted in a “down” system — requiring a time-consuming disk replacement and system reload before the system could properly function once again.

To mitigate such delicate exposure to a single disk failure, many installations implemented the “User Volume Set” feature built in to MPE/iX, then constructed multiple volume sets so that the failure of a single disk affected only the volume set to which it belonged.

For practical purposes, the only real benefit to this approach was to reduce the amount of time required to replace the disk and reload only the data residing on the affected volume set. (In reality, it was usually quite unusual for a system to continue normal, or even minimal operation with even a single unavailable volume set).

To further improve system reliability and minimize downtime an optional, additional-cost software  product was available in the form of software mirroring — aka “MPE/iX mirroring.”

This enabled the system administrator to configure non-system volume set disk drives to be associated with  identical corresponding “mirror” disks. The software was responsible for dynamically duplicating the contents of  both disk drive “mirrors” such the failure of one of the two mirror drives could be tolerated without affecting the continuous operation of the system. The damaged disk could then be replaced and the dynamic disk duplication would resume.

Only if both mirror pairs failed would there be a corresponding system outage and data loss. However, software mirroring was still far from ideal. Since it was unavailable for the MPEXL_SYSTEM_VOLUME_SET, the failure of a system disk, unprotected by mirroring software, would result in certain system down time.

Further, software mirroring exacted a price in terms of CPU and I/O overhead that could otherwise be utilized for actual “useful” processing. 

And, as a wise person once said, given a choice, a feature is almost always better implemented in hardware than software. This certainly applies to disk mirroring and nicely aligns with the the Nike MOD20 RAID disk system, which is (one of the) HP 3000’s solutions to the compromises associated with software mirroring.

The MOD20 features dual controllers, duplicated (even triplicated) power supplies, and up to 20 disk drives housed in a single frame/enclosure that provides significant improvements over the MPE/iX software mirroring functionality.

Each MOD20 provides for a maximum of 8 logical units (LUN’s) to be configured — each of which appears as a single logical device no. (LDEV no.) to the HP 3000. A maximally and optimally configured MOD20 will include 20 disk drives and be configured as follows:

14 disks to be defined as type RAID1, using up 7 LUNS—since each LUN comprises two separate mirrored disks. RAID level 1 is equivalent to simple mirroring whereby one disk is dynamically maintained as a duplicated mirror image on its mirrored twin disk, which must of identical size and model.

If one disk of the mirrored pair fails, the other disk can take over the responsibility of presenting the requisite data IO to and from the host system with no perceived performance degradation. The remaining 6 disks can be configured as a single LUN comprising 4 RAID 1/0 disks and 2 hot spares.

A RAID 1/0 configuration takes an even number of disks and duplicates the contents of half of them (as a group) onto the other half.

The hot spares would act as dynamic replacements for any disk in the MOD20 that fails, such that even the  failure of one or two disks would not prevent the entire disk subsystem from maintaining its fail-safe mirroring capability. Without the hot-spare feature, failure of a single disk would allow normal system activity to continue but without further fail-safe capability for the failing LUN only.

Chances of both disks in the same LUN failing are extremely remote. That is why I advise you to forgo the hot spare capability. Utilize a 6-disk RAID 1/0 LUN instead of a 4-disk RAID 1/0 LUN, giving you additional usable disk space overall.

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

March 08, 2017

ERP ecosystems now being fed by analysis

EcosystemThere's a rule that Sue Kiezel of the Support Group follows for her ERP clientele. Try not to let the IT department establish architecture for a replacement system. Consultants who have experience with business rules and structure are the best choice to arrange the parts and plan the new flow.

"IT is for infrastructure, and for development," she said while leading me on a tour of the new denizens inside the Kenandy ERP ecosystem. "Put your business experts on the team. You'll find someone to code it inside IT."

The issue to face while relying on the current generation of IT pros is that they no longer have broad views of how companies organize business processes. In the era when the 3000 was growing, the most dynamic beasts of the ecosystem were programmer analysts. The PAs were usually people who knew the business first and learned to program as a way to solve business problems. These days the development skills seem to wag the dog.

The IT department is essential to the success of any ERP ecosystem because that's the source of support. An ecosystem was the aspect of 3000 ownership in the biggest trouble. However, that diagnosis came from the days when outside vendors who sold apps and databases were considered the ecosystem. In some ways, the new ERP that the Support Group implements delivers a new generation of ecosystem: Kenandy's tools and modules, built with the Salesforce software that underpins it all. One surprise is that even the database has become a built-in, specialized choice. Dare we say it, proprietary, even.

The database is "Beyond Relational" according to the Kenandy field guide of software creatures. Instead of Structured Query Language, the Salesforce ecosystem uses Salesforce Object Query Language. SQL becomes SOQL, and the database itself is called the Force database. The architecture is evocative of the world of IMAGE inside of MPE, where a database was built to service the file system and the known programming universe, instead of being something that was built to serve a much wider world—but not nearly as easily or efficiently. Here's how Salesforce describes what you get right in the box to deploy data into apps.

The Force database provides not only a mechanism for creating persistent objects, but also a way of automatically generating a user interface around these objects. Reporting, tagging and much additional related functionality can also be added to applications, all out-of-the-box Force.com platform features.

You can create, configure and deploy persistent objects using the web-based Force.com Setup menu environment. However, database services are also tightly integrated with the Apex programming language, which has a dedicated syntax for invoking searches and iterating over results.

Kenandy's ecosystem is driven by the choices made by Salesforce, design that's been proven in cloud computing over a decade of field use. Programming for Salesforce has become the way to build out the ecosystem that drives Kenandy. Since the platform has become application software tied to services, it's Platform as a Service. TSG's Terry Floyd said that entering the new ecosystem can feel, at times, like relearning MANMAN, MPE, IMAGE and sometimes Fortran. Making that much change to a mission critical app like ERP calls for expertise to make the migration. This is trusted advice that comes more easily to the Support Group; a decade ago they were leading 3000 MANMAN sites to the IFS software platform. ERP based upon Kenandy is an ecosystem even more diverse .

06:39 PM in Migration | Permalink | Comments (0)

March 06, 2017

Add-on applications pour down from clouds

Acrylic-finish-paint-250x250Forecasting software has been a $2 million addition to enterprise resource planning systems. The P in ERP signifies a mission to search for a view of the future. Add-ons like McConnell Chase's FD7, purchased for an additional $2-$4 million on top of software investments in monolithic apps like MANMAN, generate a strong business for vendors. In-house systems are a good match for that kind of app. Today's IT options can bring this kind of forecasting power onto the pallettes of many more companies.

The analyst and software experts at The Support Group have been implementing the Kenandy ERP solution at an HP 3000 MANMAN site. Kenandy runs on the internal architecture of Salesforce, the cloud IT supplier to millions of sites. In a cloud IT solution a company buys a subscription to an application. Kenandy, for example, is an application choice in the world of Salesforce. Rather than hoping for a third party to create a tool that can access Kenandy, the new cloud model delivers forecasting as an option on the bill of fare.

Forecasting was never a built-in MANMAN module, Terry Floyd of TSG reminded us last week. David Floyd of the company recently returned from data integration work at Disston Tools in Chicopee, Massachusetts. Together the two men explained how cloud ERP can bring essentials like forecasting within reach. They're in the the second generation of software expertise at TSG. Terry Floyd wrote archiving software for MANMAN during the 1980s, for example, a product that was sold and added to MANMAN sites. This sort of software can be added to a cloud ERP solution like Kenandy's. Today, however, it's a subscription option, as quick to integrate as adding a tier of TV channels to a cable subscription.

Changes that spring from the migrations forced by HP have been costly. Not every new look triggered by HP's drop of the 3000 is negative, though. Adding planning power has been a multi-million dollar bet in the old 3000-era strategy. There are, however, a few aspects of cloud computing which the old-era model continues to beat.

For example, the Floyds say archival storage can be tricky to cost out in the cloud. Storage can cost more in a cloud solution;  5 to 10 years of company transactions based in the cloud might be a questionable choice. Cloud-based history can be costly. Local storage of history—that familiar disk array sitting beside an in-house host—still is at least as inexpensive as cloud, and often cheaper.

In another example, the data extraction ability of Minisoft's ODBC has been helping David Floyd at the Disston project. Other tools on the non-3000 side of the migration do transformation and loading. The same software being used in 3000s all over is cost-effective and powerful enough to move Disston data into and out of 3000s. The error-handling facilities of the ODBC standard are up against a Salesforce tool in Kenandy, though. Data Loader is a graphical tool that helps get data into Salesforce objects.

Integrated, subscription-based modules for software aren't exactly a new concept to the 3000-era manager. The 3000 shipped with tools like QUERY, for example. It was a crude tool that could be used for sophisticated tasks, so long as a manager had the skills to deploy it with subtle strokes. A little like painting a portrait with a spoon and acrylics. Today's software, included from the cloud, is something like a smart paintbrush that knows exactly how those strokes should appear, and where the best colors are, too.

TSG looks to be on the vanguard of a real replacement for MANMAN. The learning curve can be worth the return—for companies who are able to let go of their MANMAN and 3000s. Change is a rising tide that can lift all ships for the sailors who are watching the horizon. It's a good idea to make sure you have a navigator for this journey.

10:28 AM in Migration | Permalink | Comments (0)

March 03, 2017

When and how to back up 3000 directories

Editor's Note: Homesteading Editor Gilles Schipper weighs in on  using the 3000's store directory option, rather than invoking the buldacct program, to make clean backups.

By Gilles Schipper
Homesteading Editor 

CityDirectoriesIt's common to see confusion surrounding the use of the ;directory store option versus the buldacct directory creation program. In order to benefit from the store ;directory option, one has to utilize the option almost perfectly in both the store and the restore following a system INSTALL. Consequently, it becomes much easier to fall back on the buldjob options to re-create the directory -- although that option is inferior.

In order to be able to effectively utilize the directory option, the first thing that must be done properly is to ensure that the appropriate ;onvs= option is also used in the case where user volumesets are utilized. Otherwise, the non-system volumeset directories do not get restored after the INSTALL since they are not on the tape.

But even if the store part is done correctly, the other opportunity to go wrong presents itself during the reload process.

The proper procedure during reload is as follows:

1. perform INSTALL
2. restore ;directory from tape
3. re-create disk and volumeset environment via VOLUTIL

Then -- and this where many go wrong,

4. Again restore ;directory from tape (this re-creates the volumset directory environment on the master volumes for all user volumesets for those utilizing it)
and then
5. restore files
6. reboot with start norecovery (to enable network functionality)

Of course, for those that do not utilize user volumesets, the directory option becomes much less error-prone. And, for those that utilize third-party backup utilities, the ;directory option -- as utilized in the MPE store command -- is generally replaced with a similar option in the various backup utilities.

The bottom line: for those that utilize the MPE store command to perform their backups, the properly-used ;DIRECTORY (and, if appropriate) corresponding ;ONVS= options) -- together with correct restore procedures as indicated above -- will get the desired result 100 percent of the time. Notwithstanding, of course, any tape issues occurring, which would be problematic no matter which directory re-creation option is used.

The bottom line is that the proper way to perform a full backup if you're using the MPE backup facility:

:file t;dev=tape
:store /;*t;partdb;directory;onvs=mpexl_system_volume_set,big;

Of course, upon further reflection, and better than the store command: use sysgen to create a backup tape that not only contains all files, but also the SLT -- so that this one tape alone can be used to INSTALL and RELOAD your system. The use of sysgen for such purpose will require use of an indirect file.

09:12 PM in Hidden Value, Homesteading | Permalink | Comments (1)

March 01, 2017

Wayback Wed: Customers' Proposition 3000

Computerworld April 22

During the month of March 21 years ago, the 3000 community tried to raise a ruckus. The object of Proposition 3000 was to prod HP into making the 3000 a full citizen of the future of business computing. After only a couple of years of introduction, the new processor HP was developing with Intel looked like it would pass by the world of MPE/iX. HP and Intel dubbed the IA-64 technology the future of computing. HP had backed away from plans to make the 3000's OS run on the new chip it was calling "Tahoe."

"The company appears to be making a fundamental but flawed assumption that MPE migrations will be channeled directly into HP-UX or NT-on-HP hardware." This was enough of a crisis that application vendors were standing up at an Interex Programmer's Forum to report HP asked them to rewrite their apps for HP-UX. We launched the NewsWire with a fanfare of it promoting the HP 3000 Renaissance. Not so fast, HP's top management was saying. We set down the challenge to HP and its customers in our FlashPaper (which you can read here to recall the outrage of the moment.) In this era, NT was the name of what would become Windows Server.

Customers want these systems, and vendors believe in their superiority. But those kinds of business blessings apparently clash with HP's profit motives; that's the only reason we can fathom for threatening to force an entire installed base to migrate to HP-UX or NT. You can decide for yourself how that kind of a productivity hit will impact your company's profits.

FlashPaper headline Mar 1996This was the canary in the mine shaft, the HP debate about whether to include MPE/iX in the future of business computing systems. In 1996 the IT world was allowing HP and Intel to call Tahoe the future, because the joint project was only a couple of years old. Tahoe had not yet become Merced, and then Itanium, all the while slipping release dates and getting lapped Intel's own by x86 generation enhancements. In 1996 the future looked to be slipping away. The most alarming development was HP asking vendors to rewrite for Unix. Soon enough, a few of them did, most notably the software company that put the 3000 into the world of the Web: Ecometry.

At the meeting we learned the problem wasn't really profit at HP. At the time of the Proposition, HP was earning $600 million a year in profit on sales of $1.2 billion. The 3000 division needed more engineering hands to move MPE/iX forward, resources the company would not provide.

The protest was staged at a Bay Area Interex meeting, a setting similar to the ruckus 3000 users raised in Boston at an Interex show six years earlier. But IPROF was not the annual show attended by thousands. The Proposition 3000 name and the movement were so-named because it was the new era of California's state propositions. HP's Tony Engberg replied that he would work to get the 3000 advocates an audience with top HP officials. The hearing felt desperately needed after Ecometry's Alan Gardner laid out the future HP presented him.

“I’ve got two visions of the HP 3000,” Gardner said. “One’s a nightmare, and the other is a fantasy. The nightmare is that the 3000 is going away, while the fantasy is that HP will begin to promote the HP 3000 as the operating system choice of the world."

The March movement arose in the face of HP's slow pace of advancing the 3000. At the time the servers were on an older release of the PA-RISC designs HP first rolled out in the late 1980s. The HP 9000 was farther ahead. 3000 General Manager Harry Sterling, still new to his job, explained that rolling forward MPE/iX was taking longer than expected.

“We do not have a firm commitment yet that we can talk about in terms of an implementation on the new [Tahoe] architecture,” Sterling said. “Last year I was hoping we would, but our roll-forward has become even more complex than it was at that time. We have the current focus of getting to the PA-8000. The next thing after that is what we might do to take advantage of 64-bit architecture on that chip. Beyond that would be the use of the new Intel architecture.”

The next year HP assured 3000 customers that the architecture, being called IA-64, was on the 3000's distant horizon. Computer Systems chief Dick Watts, computer chief Rick Belluzzo and CEO Lew Platt moved out of HP's computer orbit within a few years. The items within the Proposition became a list of desires HP would not fulfill.

  • 64-bit chip commitment for the HP 3000. We heard last night they would look into it,” Kell said. “Last year we heard that they would do it.”
  • Available platforms for MPE. “One new precedent that was somewhat disturbing was when the D-class servers were introduced, they said MPE wouldn’t available for it. This is the first time a PA-RISC platform has not been available across both systems.”
  • Lead time on critical products for MPE/iX. “We’re still waiting on 32-bit ODBC drivers, and we’ve waited a long time for telnet server. DCE is still in an intermediate stage, but largely it’s still lagging behind.”
  • MPE and HP-UX cooperation. “It’s what we’re really missing. They co-exist; that was the buzzword a couple of years ago. Dogs and cats can co-exist given enough management supervision, but they won’t necessarily co-operate.”
  • Common hardware across both HP 3000s and HP 9000s, from an Open Systems Division, with MPE/iX or HP-UX as an option, both servers with robust APIs to make ISV porting of applications to MPE/iX “as trivial as any other Unix platform.”
  •  Stressing the strengths of MPE/iX, “and not its weaknesses. We don’t have to be told anymore what the 3000 can’t do, because a lot of the things we were told it can’t do it now can.

HP plans of 1997 had to be reset by a Hewlett-Packard that was acquiring Digital during 2001. Product overlap meant the larger of the two systems — VMS instead of MPE/iX — would get its road cleared to Itanium. Things had changed enough in HP's management to make the displeasure of vendors and programmers a lesser concern than product consolidation needs. Computerworld's Jai Vijayan called the Proposition "rumbling in the ranks of the old faithful." The majority of the customers didn't want to look at a proposition of no 3000s in HP's future.


02:15 PM in History, Homesteading | Permalink | Comments (0)