December 19, 2014

Making a New Case Against Old Hardware

Try to Order PartsIt won't make the resellers of HP's 3000 hardware happy, but Stromasys has started to make a strong argument against preserving the life of Hewlett-Packard's MPE hardware. In a link inside a video that was attached to a 2015 happy holidays message, we've spotted a 96-second summary that shakes the bones of the assurance there's plenty of parts in the world to support aging 3000 systems.

Maintaining the original MPE-based systems from Hewlett-Packard is risky and difficult, the commercial that's hosted on the Vimeo website says. The software is worth preserving, it continues, and it notes more than 5,000 companies have used the Stromasys Charon technology to enable hardware emulation. The majority of these Stromasys clients have emulated Digital's server hardware to preserve VMS applications.

Lower than full migrationOf course, there's a mention of emulation's savings versus a full migation. For the customers who are leaving the HP 3000 because the hardware's old, this point might have some traction. The level of support from the original hardware vendor, as well as the end of HP's 3000 manufacturing, drove a significant number of migrations in the past. The Stromasys argument states that with new hardware, an application suite can be preserved. Customers who remain on their homesteaded systems often say they'd be happier if their futures didn't include the expenses and risks of migrating.

There's a short reference to cloud-based Charon installations amid the message, too. In that level of solution, investment in the powerful Intel-based hardware is exchanged for a typical cloud-rental fee. In some cases, the investment in the hardware required to emulate HP-branded 3000 servers can be substantial.

Most interesting, Stromasys now has offered MPE support among the services it sells. It's right there alongside VMS and Solaris software support. The company hasn't issued a press release and there aren't details immediately available on the levels of operating system support, or the staff which will be supplying it.

Read "Making a New Case Against Old Hardware" in full

Posted by Ron Seybold at 07:14 AM in Homesteading | Permalink | Comments (0)

Pivital Solutions: Your complete
HP e3000 resource

December 17, 2014

MB Foster extends Ability Commerce's retail

Screen Shot 2014-12-17 at 6.19.47 PMAbility Commerce, a direct commerce software and provider of JDA Direct Commerce Professional Services, has announced their partnership with MB Foster. The two companies offer services to enterprises that use the JDA products including Escalate Retail, the latest generation of the Ecometry ecommerce software suite.

Ability, in calling MB Foster "a software programming and consulting firm specializing in highly scalable data access and delivery solutions for the  JDA Direct Commerce (Ecometry) software platform," plans to use its new partner to transform and migrate the surround code popular in Escalate installations.

“MB Foster’s addition to our strong partnership solutions dedicated to the JDA Direct Commerce software platform will allow us to provide an even higher level of service to that user base, "said Shawn Ellen, Director of Sales and Marketing for Ability Commerce. "MB Foster is committed to the Ecometry user base and will be joining us as a sponsor at our Ability Commerce User Summit this coming March 11-13 in Delray Beach, Florida."

Posted by Ron Seybold at 06:20 PM in Migration | Permalink | Comments (0)

December 16, 2014

How OpenCOBOL Helped Porting COBOL II

Editor's note: A little while ago the 3000 newsgroup was discussing the merits of OpenCOBOL compared to the heartland compiler of MPE, COBOL II. Roy Brown offered his story of how he made the open source COBOL step in to do the work that COBOL did during a 3000 migration. A port, if you will.

By Roy Brown

I used OpenCOBOL to port two HP 3000 COBOL programs — only two, but one of them was the big and critical engine at the heart of a system otherwise written completely in PowerHouse.

Key_to_replacementI first used the portability checker on COBOL II to make a few amendments to bring the program in line with the standards — and was able to roll that version back into the production HP3000 code at the time.

The thing that remained non-standard, but which OpenCOBOL supported, IIRC, was entry points. I could have got round the limitation of not having them, but I was pleased not to have to.

The one remaining issue after that was not having IMAGE on the new platform, but having to use Oracle instead. So I rewrote the IMAGE calls as Oracle PRO*COBOL calls. And I was quite surprised that this made the program shorter, or would have if I hadn't left the IMAGE calls in, but commented out, so I could refer back to them if there were issues.

So, armed with a readable program, I slotted it through the PRO*COBOL precompiler, which spits out unreadable COBOL, put that through the OpenCOBOL compiler, which spits out C (or did then, at any rate — does it still?) and then compiled that with the GNU C compiler.

Read "How OpenCOBOL Helped Porting COBOL II" in full

Posted by Ron Seybold at 05:53 PM in Migration | Permalink | Comments (0)

December 15, 2014

2015 migrations creep on, in virtual mode

HocusPocusIn the concept of virtualization, a server is replaced by another which pretends to be just like the original. There's no new HP 3000 in emulation, for example. Just the idea of one. The essence of the HP 3000, its PA-RISC architecture, is replaced using the Charon product: software that mimics the HP hardware. Virtualization engines use software to eliminate hardware.

Some MPE migrations which have been underway for years look like they may be using up virtual man-months, so the IT group won't have to adopt a new application. The plan and lengthy project time eliminates the need to go live with changes.

In a virtual migration, the organization knows its intention. Get onto another environment with mission-critical apps. But the work never gets completed, something like a "forthcoming" novel that's expected but unfinished. Virtualized migrating can very well be the reason any 3000 project still has a 2017 target date.

"These days with the tools that are available," said Alan Yeo of ScreenJet, "no migration should take more than 12 months." He added that he believes that engaging a migration services company of any reasonable size would get most of of an organization's code running in test-mode in about six weeks.

Read "2015 migrations creep on, in virtual mode" in full

Posted by Ron Seybold at 07:44 PM in Migration | Permalink | Comments (0)

December 12, 2014

Essential Skills: Using Password Vaults

Editor's note: HP 3000 managers do many jobs, work that often extends outside the MPE realm. In Essential Skills, we cover the non-3000 skillset for these multi-talented MPE experts.

By Steve Hardwick, CISSP

Passwords are always a challenge for security professionals. Why is creating a secure password so difficult? More importantly, how can a user tell if their password has been stolen? Typically, when all the damage has been done and the password has been used by someone else. At this point in time it is too late. One way to resolve this is to have a password vault such as KeepPass or 1Password.

VaultA vault is a good investment of your time. A security breach that might result from having no vault might be difficult to even detect. It might be that the time the breach is discovered may not be the first time the hacked credentials were used. This might be how many times a stolen credit card is used before the owner gets the bill. Second, the hacker could have hacked the password and is just keeping it for later use or sale. One of the preventative measures for this is to require users to periodically change passwords. 

This changing strategy can stem the use of stolen passwords and also prevent the future use of any that have not yet been exploited. From a user's perspective, though, generating multiple passwords every 60-90 days just compounds the passwords nightmare.

As a security professional I have seen several solutions that users concoct to try and get around this issue. One common one is to write them all down and hide the resulting list. It turns out there are not that many good hiding places. Under keyboards, behind pictures, inside speakers, taped to the underside of a drawer or chair, back of a bookcase do not qualify as good locations. Also, many users forget to update the sheet with new passwords. Another approach is to create a text file, e.g. shopping_list.txt, and put everything in there. A quick search of the most frequently used files normally finds those. Plus if the hard drive crashes, and the file is not backed up, new ones have to be set up all over again. 

A variation of the last theme is to use a password vault. This is a method where the password information is stored on a file, but the file is encrypted. In this case only one password is needed, to decrypt the vault, and access is granted to all of the other passwords. The most ubiquitous form of encryption is AES - Advance Encryption Standard. AES256 encryption is adequate for most users.

However, one word of caution. If the password used to encrypt the vault is easy to guess, then the contents are at risk. 

Read "Essential Skills: Using Password Vaults " in full

Posted by Ron Seybold at 02:34 PM in Homesteading, Newsmakers | Permalink | Comments (0)

December 11, 2014

Big, unreported computing in MPE's realm

When members gather from the 3000 community, they don't often surprise each other these days with news. The charm and challenge of the computer's status is its steady, static nature. We've written before about how no news is the usual news for a 40-year-old system.

Pegged gaugesBut at a recent outing with 3000 friends I heard two pieces of information that qualify as news. The source of this story would rather not have his name used, but he told me, "This year we actually sold new software to 3000 sites." Any sort of sale would be notable. This one was in excess of $10,000. "They just told us they needed it," my source reported, "and we didn't need to know anything else." A support contract came along with the sale, of course.

The other news item seemed to prove we don't know everything about the potential of MPE and the attraction of the 3000 system. A company was reaching out for an estimate on making a transition to the Charon emulator. They decided not to go forward when they figured it would require $1 million in Intel-based hardware to match the performance of their HP 3000.

"How's that even possible?" I asked. This is Intel-caliber gear being speficied, and even a pricey 3000 configuration shouldn't cost more than a quarter-million dollars to replace. It didn't add up.

"Well, you know they need multiple cores to replace a 3000 CPU," my source explained. Sure, we know that. "And they had a 16-way HP 3000 they were trying to move out."

Somewhere out there in the world there's an HP 3000, installed by Hewlett-Packard, that supports 16 CPUs. Still running an application suite. The value is attractive enough that it's performing at a level twice as powerful as anything HP would admit to, even privately. 

A 4-way N-Class was as big as HP would ever quote. Four 500-MHz or 750-MHz PA-8700 CPUs, with 2.25 MB on-chip cache per CPU, topped the official lineup.

Unix got higher horsepower out of the same HP servers. An 8-way version of the same N-Class box was supported on HP-UX; HP would admit such a thing was possible in the labs, and not supported in the field. But a 16-way? HP won't admit it exists today, and the customer wouldn't want to talk about it either. Sometimes things go unreported because they're too big to admit. It made me wonder how much business HP might've sustained if they'd allowed MPE to run as fast and as far as HP-UX ran, when both of those environments were hosted on the same iron.

Posted by Ron Seybold at 09:14 PM in Homesteading, Newsmakers, User Reports | Permalink | Comments (0)

December 10, 2014

Getting Macro Help With COBOL II

GnuCOBOL An experienced 3000 developer and manager asked his cohorts about the COBOL II macro preprocessor. There's an alternative to this very-MPE feature: "COPY...REPLACING and REPLACE statements. Which would you choose and why?"

Scott Gates: COPY...REPLACING because I understand it better.  But the Macro preprocessor has its supporters. Personally, I prefer the older "cut and paste" method using a decent programmer's editor to replace the text I need. Makes things more readable.

Donna Hofmeister: I'm not sure I'm qualified to comment on this any longer, but it seems to me that macros were very efficient (and as I recall) very flexible (depending on how they were written, of course). It also seems to me that the "power of macros" made porting challenging. So if your hidden agenda involves porting, then I think you'd want to do the copy thing.

There was even porting advice from a developer who no longer works with a 3000, post-migration.

Read "Getting Macro Help With COBOL II" in full

Posted by Ron Seybold at 06:10 PM in Hidden Value, Homesteading, User Reports | Permalink | Comments (0)

December 08, 2014

IMAGE data schemas get visualized

Is there any program that will show the network of a TurboIMAGE database? I want to output the relationships among sets and items.

CFAWireframeIn 2011, Connie Sellitto researched the above question, while aiding new programmers who were charged with moving a pet organization's operations to a non-MPE system. Understanding the design of the database was important to this team. Sellitto mentioned a popular tool for PCs, but one not as essential as an IT pro's explanations.

You might try Microsoft's Visio, and you may need to have an ODBC connection to your IMAGE database as well. This produces a graphical view with search paths shown, and so on. However, there is still nothing like a detailed verbal description provided by someone who actually knows the interaction between datasets.

To sum up, we can refer to ScreenJet founder's Alan Yeo's testing of that Visio-IMAGE interplay

Taking a reasonably well-formed database into Visio and reverse engineering, you do get the tables and items. It will show you what the indexes in the tables are, but as far as I can see it doesn't show that a detail is linked to a particular master. Automasters are missing anyway, as they are really only for IMAGE.

My conclusion: if you have done all the work to load the databases in the SQL/DBE and done all the data type mappings, then importing in Visio might be a reasonable start to documenting the databases, as all you would have to do is add the linkages between the sets.

If you don't have everything in the SQL/DBE, then I would say we are back where we started.

Read "IMAGE data schemas get visualized" in full

Posted by Ron Seybold at 10:31 PM in Hidden Value, Homesteading | Permalink | Comments (0)

December 05, 2014

A Forced Migration, One That's Unfortunate

ImagesThis month in the US includes more than the usual ration of Christmas carols and holiday office parties. This is the first month when we US citizens are renewing our healthcare, all of us at once. It's Open Enrollment! According to my insurance agent, everybody's got to be insured by the end of the month. I'm one of the people who's having an experience like 3000 users got in 2001. Blue Cross is migrating me away from a product that it no longer wants to sell.

The parallels, so far, are pretty close. There was nothing that stopped working with my health plan. Like HP, Blue Cross simply stopped selling it because it wasn't making the vendor enough profit. The plan was not removed because of the Affordable Care Act (commonly known as Obamacare). But then, the HP 3000 was not removed because of the HP merger with Compaq. These were simply business decisions, by HP and by Blue Cross of Texas.

Business decisions are taken as a result of events that create situations. Insurers must protect profits, in the same way that HP had to protect its ability to grow after it absorbed $25 billion of Compaq. Customers don't get consulted about discontinuing products.

Much like the experience of the 3000 community with the 2001 migration march, my journey to a new plan will trigger more expense, and let Blue Cross earn more by doing less. I'll see about a 20 percent increase in recurring costs -- which might look cheap compared to how much the 3000 migration has cost the companies being forced to move.

There's a difference that's important, though. The active event that's changed the sale of insurance in America comes with federal rules. It now costs at least $395 a year to homestead, as it were, with no insurance at all. That's a fine that can rise as high as 2 percent of your gross income. A similar bill for a company making $5 million yearly in profit would be $100,000. That would be money spent just to stay on a system which the vendor stopped making or supporting.

Thankfully, there's no such fine for homesteading. There's a bill if a site simply stops support of all kind, however. Every computer system breaks down sooner or later, because nothing is built to never break. A company's insurance on its computer operations is support. The 3000 community got an advantage over those of us who've seen their products discontinued. System support got less costly.

Read "A Forced Migration, One That's Unfortunate" in full

Posted by Ron Seybold at 04:56 PM in Homesteading, Migration | Permalink | Comments (0)

Search