« February 2018 | Main

March 12, 2018

Momentum moves towards Museum meeting

CHM displayDave Wiseman continues to pursue a 3000 user reunion for late June, and we've chosen to help invite the friends of the 3000. One of the most common sentiments from 3000 veterans sounds like what we heard from Tom Gerken of an Ohio-based healthcare firm.

"It was really sad seeing the HP 3000s go away," he said, talking about the departure of the system from Promedica. "I really liked MPE as an operating system. It was the BEST!"

The last HP 3000 event 2011 was called a Reunion. A 2018 event might be a Retirement, considering how many of the community's members are moving to semi-retirement.

Wiseman says that he's in retirement status as he defines it. "It's working not because you have to,"he said in a call last week, "but because you want to."

Most of us will be working in some capacity until we're too old to know better. That makes the remaining community members something like the HP 3000 itself—serving until it's worn down to bits. The event this summer will be a social gathering, a chance to see colleagues and friends in person perhaps for the first time in more than a decade.

The weekend of June 23-24 is the target for the 3000 Retirement party. We're inquiring about the Computer History Museum and a spot inside to gather, plus arrangements for refreshments and appetizers. There will be a nominal cover fee, because there's no band. Yet.

If you've got a customer list or a Facebook feed you'd like to spread the word on, get in touch with me. Spread the word. Email your friends.

No matter whether you have a contact list or not, save the date: one afternoon on the fourth weekend of June. Details to come. 

08:13 PM in Homesteading, Migration, Newsmakers | Permalink | Comments (0)

March 09, 2018

Fine-Tune Friday: Account Management 101

Newswire Classic

By Scott Hirsh

Ledger-bookAs we board the train on our trip through HP 3000 System Management Hell, our first stop, Worst Practice #1, must be Unplanned Account Structure. By account structure I am referring to the organization of accounts, groups, files and users. I maintain that the worst of the worst practices is the failure to design an account structure, then put it into practice and stick with it. If instead you wing it, as most system managers seem to do, you ensure more work for yourself now and in the future. In other words, you are trapped in System Management Hell.

What’s the big deal about account structure? The account structure is the foundation of your system, from a management perspective. Account structure touches on a multitude of critical issues: security, capacity planning, performance, and disaster recovery, to name a few. On an HP 3000, with all of two levels to work with (account and group), planning is even more important than in a hierarchical structure where the additional levels allow one to get away with being sloppy (although strictly speaking, not planning your Unix account structure will ultimately catch up with you, too). In other words, since we have less to work with on MPE, making the most of what we have is compelling.

As system managers, when not dozing off in staff meetings, the vast majority of our time is spent on account structure-related activities: ensuring that files are safely stored in their proper locations, accessible only to authorized users; ensuring there is enough space to accommodate existing file growth as well as the addition of new files; and occasionally, even today, file placement or disk fragmentation can become a performance issue, so we must take note of that.

In the unlikely event of a problem, we must know where everything is and be able to find backup copies if necessary. Periodically we are asked (perhaps with no advance notice) to accommodate new accounts, groups, users and applications. We must respond quickly, but not recklessly, as this collection of files under our management is now ominously referred to as a “corporate asset.”

You wouldn’t build a house without a design and plans, you wouldn’t build an application without some kind of specifications, so why do we HP 3000 system managers ignore the need for some kind of consistent logic to the way we organize our systems?

A logical, adaptable, documented account structure is a huge time saver in many respects. As most of us now manage multiple systems, we have no time to waste chasing down lost files, working with convoluted file sets, struggling to keep access under control or reacting to full volume sets.

I once had a conversation with a co-worker who was an avid outdoorsman. He was discussing rock climbing and I asked him about exciting rock climbing experiences. His reply: “In rock climbing, anything exciting is bad.” I would say the same thing about system management. By getting your account structure under control, you build a solid system management foundation that translates into much more pleasant work.

If this were a “best practices” column, we would discuss the best ways to clean up your system’s account structure. But this is worst practices, so let’s look at the no-nos.

No naming standards,
bad naming standards

Oscar Wilde once said, “Consistency is the last resort of the unimaginative.” Do you think he was referring to HP 3000 system management? If so, not much has changed since Oscar’s day.

• In one account the jobs are located in group JCL. In another account, group JOBS. The developers keep “special” jobs in a group you never heard of in the critical application account. And just to make things more interesting, all your so-called “production” jobs are kept in an account called JCL, containing all kinds of groups, including “TEMP.”

By having consistency across accounts I control, I can easily find what I need when I need it. If jobs are always in the same group across accounts, I can LISTF @.JOBS.@, etc. Backups/recoveries are easier, updates are easier, training new operators is easier. Sure, consistency is boring, but we must resist the lure of adrenaline.

• I’m going out on a limb here, but my guess is that your UDCs, the few you have left, are in a different place in every account. Why is that? And your system UDC (singular) is located in the SYS account, right? Because it’s the SYStem UDC, of course! Maybe it’s not such a bad thing to have another, non-SYS account for globally accessible files. What’s the catch? The system UDC file needs to be in the system volume set, for obvious reasons (learned that one the hard way).

• An MPE file name consists of a whopping maximum of eight characters. That should make every character count, right? So why do jobs that live in a group called JCL or an account called JCL all start with the letter J? File that under the department of redundancy department.

• We manage the systems, so we make the rules, right? Wrong. If we want the rules followed, if we want the best rules possible, we must get input and buy-in from all the others who will be expected to honor our rules. Ignoring users when it’s time to develop naming standards and other system policies is a classic Worst Practice, and a good way to ensure continued chaos. And don’t forget that upper management will need to be involved when a little “gentle” persuasion is required.

Scott Hirsh is former chairman of the SIG-SYSMAN Special Interest Group.

06:51 PM in Hidden Value, Homesteading | Permalink | Comments (0)

March 07, 2018

Wayback: When MPE would need no 3000s

3000 license plateIt's been a decade and a half since HP began to examine the needs of the homesteading base of 3000 owners. Fifteen years ago this month, the first HP proposal for licensing MPE/iX outside of the server's ownership was floated into the community. The document in March of 2003 said that a license could be created "Independent of the HP e3000 platform."

HP had renamed the 3000 as the e3000 to tout the server's Internet compatibility. The era around 2003 was full of possibility. Mike Paivinen was a project manager in R&D who spearheaded a lot of planning for 3000 homesteading. Emulators were on the horizon. Somebody would need licensed MPE if they were to use them. Paivinen authored the un-3000 MPE/iX proposal.

The major concern is that without some more details, companies interested in creating a PA-RISC platform emulator would be unable to fully evaluate their business case for moving forward with an emulator project. Below is HP’s current proposal for distributing the MPE/iX operating system independent of the HP e3000 hardware platform.

Onward the plan went, setting out terms that included running any emulator on HP-branded hardware, as well as operating MPE/iX on the emulator with no warranty. At the time the 3000 division was calling itself Virtual CSY, or vCSY.

vCSY intends to establish a new distribution plan for the MPE/iX operating system which will likely be effective by early 2004. The MPE/iX OS would be licensed independent of the HP e3000 hardware platform. The license terms would grant the licensee the right to use a single copy of MPE/iX on a single HP hardware platform subject to certain terms and conditions. Such terms and conditions would require MPE/iX to be run in an emulated environment, hosted on an HP platform, and would include a statement that MPE is provided “AS-IS” with no warranty.

For about $500 a license, HP would offer MPE/iX and some subsystem software like TurboStore "via an HP website. The customer should be able to purchase MPE/iX online, download it, or have it shipped on CD." There was a big catch that would end up kicking in. Item 16 of an HP FAQ was a question that set out a dare.

16. What happens if no one creates a PA-RISC emulator?

A. This new license would not be offered.

In the same time period as this 2003 license plan emerged, HP didn't want to share PA-RISC internal booting procedures with emulation developers. Stromasys, known as SRI at the time, had a better shot than anyone at getting HP's cooperation. The company was founded by ex-HP/Digital executives and already had Digital VMS cooperation in its history.

The license needed an emulator to be available. But if it had been offered before emulator development was complete, it might have had an impact on HP's development cooperation. The chicken and egg dilemma was therefore hatched.

HP was ready to sell an OS for $500 without warranty that used to cost up to hundreds of thousands of dollars. By October of 2003 it would not be selling the hardware anymore which forced that price point. MPE hadn't been sold standalone, separate of a 3000, before then.

The offer of standalone MPE/iX remained on the table for years after the 2004 release target. By the time HP wrapped up all of its 3000 operations including support, new licenses for emulators were still possible. HP set an end of 2010 deadline for those deals. An emulator still wasn't finished, although Stromasys was in active development. Ultimately HP's arrangement created no new MPE/iX licenses. Today booting MPE/iX away from HP's iron demands the transfer of an existing 3000 hardware-based license to today's Charon emulator.

06:09 PM | Permalink | Comments (0)

March 05, 2018

2028 patching begins to emerge

Beechglen Communicator CoverBeechglen Development has announced a new 2028 patching service. The services are aimed at customers using Beechglen for HP 3000 and MPE/iX support. According a PDF document hosted at the Beechglen website, the software modifications to MPE/iX are authorized through the terms of the HP source code license that was granted to seven firms in 2011.

Several 3000 consulting and support providers have an ability to serve the community with revisions to extend 3000 date-handling beyond January 1, 2028. Several of them were on a CAMUS user group call last November. Beechglen is the first company to employ the date repair services through a set of patches. One question is whether the patches can be applied to any system, or must be customized in a per-system process.

The software alterations seem to include changes to MPE/iX, not just to applications and surround code hosted at a 3000 site. Doug Werth, director of technical services at Beechglen, said in a message to the 3000-L mailing list, "While it isn’t quite “MPE Forever” it does extend the HP 3000 lifespan by another 10 years."

The strategy was outlined as part of a document called the Beechglen Communicator, formatted and written to look like the Communicator tech documents HP sent to MPE/iX support customers through 2007. 

The Year >2027 patches have been developed as enhancements under the Beechglen Development Inc. MPE/iX Source Code Agreement with Hewlett-Packard. As provided in this agreement, these patches can only be provided as enhancements to MPE/iX systems covered under a support agreement from Beechglen Development Inc.

The three pages of technical explanation about the patches is followed by a list of third party software companies who have products "certified on Beechglen-patched MPE systems that their software is Y2028 compatible." Adager and Robelle products are listed as certified in the Beechglen document.

Adager is one of seven companies which hold an HP source code license for MPE/iX. Pivital Solutions is another, along with support companies Terix and Allegro, and three other software firms. The companies have a restriction in their use of MPE/iX. As the Beechglen document states, the alterations have to be in service to existing customers. HP released the code to keep 3000s in service, to the extent that the license holders have the technical ability to employ the source.

In 2008, as MPE/iX source licenses were discussed by HP and parties like OpenMPE, Adager's CEO Rene Woc noted a license to source is just the first step in fixing 3000s.

Having access to source though a license doesn't automatically make a license-holder a better provider of products and services, he said.

You cannot assume, even with good readers of source code, that the solutions will pop up. A lot of the problems we see these days are due to interactions between products. So the benefit for the customer would be based more on the troubleshooting skills that an organization can provide.

"Each system applying these patches should be evaluated for customer and third party code that calls the CALENDAR intrinsic directly," the Beechglen document says in an Application Considerations section.

We've reached out to Beechglen to learn what testing these Year >2027 patches have passed through from outside users and sites. HP distributed MPE/iX patches after its software had passed a beta test from more than one testing customer running a 3000. HP testing worked inside the realm of its own support customers, too. No one could beta test an HP patch unless they were already an HP support customer.

OpenMPE hoped to be a test organization for patches in the era after HP closed its labs. The project didn't emerge beyond the discussion phase, in part because there were no dedicated tech resources to do the testing.

07:53 PM in Homesteading | Permalink | Comments (0)

March 02, 2018

Fine-Tune Friday: One 3000 and Two Factors

RSA SecurID fobPeople are sometimes surprised where HP 3000s continue to serve. Even in 2018, mission-critical systems are performing in some Fortune 500 companies. When the death knell sounds for their applications, the axe gets swung sometimes because of security. Two-Factor security authentication is a standard now, serving things like Google accounts, iCloud data, and corporate server access.

Eighteen years ago, one HP 3000 shop was doing two-factor. The work was being coded before smartphones existed. Two-factor was delivered using a security fob in most places. Andreas Schmidt worked for Computer Sciences Corporation, which served the needs of DuPont in Bad Homburg, Germany. CSC worked with RSA Security Dynamics to create an RSA Agent that connected a 3000 to an RSA Server.

Back in that day, authentication was done with fobs like the one above. Now it's a smart device sharing the key. Schmidt summarized the work done for what he calls "the chemical company" which CSC was serving.

Two-Factor Token Authentication is a state-of-the-art process to avoid static passwords. RSA Security Dynamics provides an MPE Agent for this purpose which worked perfectly for us with Security/3000, but also with basic MPE security. The technical approach is not simple, but manageable. The main problems may arise during the rollout because of human behavior in keeping known procedures and avoiding changes, especially for security. But to stay on HP 3000 into the future, the effort is worth it, especially for better security.

The project worked better when it relied on the Security/3000 software installed on the server hosting Order Fulfillment. Two-factor security was just gaining widespread traction when this 3000 utilized it. Schmidt acknowledged that the tech work was not simple, but was manageable. When a 3000 site is faced with the alternative of developing a replacement application away from MPE/iX, or selecting an app off the shelf like SAP, creating two-factor is within the limits of possibility. Plus, it may not be as expensive as scrapping an MPE application.

Schmidt's article covers an Agent Solution created by CSC. Even 18 years ago, remaining on the 3000 was an issue worth exploring. When many outside firms access a 3000, two factor can be key.

DuPont wanted two-factor tested on its NT systems, plus the 3000.

NT and MPE were selected as pilots: NT because of the large number of servers running that environment; and MPE because of the thinking that this platform might be different from all others and more difficult to implement. However, the company also recognized the importance of running its 3000-based Order Fulfillment Process with a lot of different outside partners.

RSA’s first attempt to develop an agent for MPE was very simple: A token had to become configured for a combination of MPE-USER-ID.MPE ACCOUNT. This combination could not be reused on another token. It was not possible to use wildcards or to add SESSION-IDs or MPE-GROUP to have a complete logon string. Because of the MPE characteristic to share logons (on all levels of capabilities) this version of the agent was not what we were looking for. (More drastically: This agent could not function for the MPE platform).

The second attempt was much better: everything was changed to the chemical company’s already-existing Security/3000 setup. Now Security/3000 invokes the RSA Agent to contact the RSA Server. It transmits either the SESSION-ID or the MPE-USER-ID as the name of the token. If the token is known and allowed to access the HP 3000, the agent asks the user for the current tokencode plus PIN.

This agent also functions without Security/3000 by adding some lines to the System’s Logon UDC. This drops some additional functions in combination with Security/3000, like verifying a user profile in any case (SESSION-ID,MPE-USER-ID.MPE-ACCOUNT is defined as allowed logon in Security/3000, all others will be refused before starting anything), but it will work.

The project report details show this could be installed even before two-factor took a wide foothold in IT. Schmidt doesn't share the code in his article because it was custom work for a dedicated customer. But the process is worth a look, even if only to prove that custom code brings a 3000 into security compliance.

"One thing is essential," Schmidt wrote. "The RSA Agent for MPE does not replace the MPE password process like it does for Unix or NT. It is activated first when the HELLO string has been entered and the MPE password hurdle has been passed (Account, User, and/or Group Password) and (as an option) the basic check within Security/3000 for profile existence is passed. Now any other logon UDC functions are invoked, and this activates the RSA Agent.

Having Security/3000 in place is a good idea to replace the session passwords (if any) by supplying the tokencode.

Not having session names in place, the RSA Agent will add an additional password. I do not recommend eliminating the MPE password — it’s still a fence around your system and is needed for batch security (depending on the streaming security you have in place).

Complete details are in the NewsWire website's archived Technical Articles. Go forth and secure, if preserving an application is a better choice than locating an app replacement.

06:52 PM in Hidden Value, Migration | Permalink | Comments (1)