« What If: Fault lay not in the 3000, but in HP? | Main | Foster looks into IT crystal ball Wednesday »

January 14, 2013

Could migrations be sparked by fresher development environments?

In a recent poll I conducted about the tools of the 3000 developer, I found a lot of classics. Finding classics at work is common among the 3000 community. And just because technology is steeped in legacy doesn't make it a fool's tool. Micro Focus likes to tell customers who are using its COBOL and development environment software, "Just because it's old doesn't mean it's not gold."

FreshSolutionsHowever, nearly all of the three dozen veteran coders -- architects, designers, maintainers and more -- use something first released in 1980s. And only one who replied to our December poll mentioned any change management or version control software as part of coding and creating for MPE. Perhaps everybody works with code they created, on a small team --perhaps as slim as just themselves.

So when these experts said their software toolset runs to Qedit, QUAD, EDITOR/3000, MPEX, Suprtool -- or in one gruesome report, the bare-bones vi -- we assume they're using what they grew up getting adept with. Success breeds habits, and then practices. It's a good strategy for decades if nothing much changes. But when a corporation acquires other companies and IT environments, it eventually gets a datacenter architecture too big for a few favorite tools and nothing else. These kinds of companies and corporations are on the path to migrations away from the 3000. What they'll use to create systems on the new boxes will be designed to embrace change while it feeds multiple-platform developer teams.

The question is, can these advanced and high-productivity tools ever push a maybe-migrator across to engaged status? Put another way, can the likes of Visual Studio, Eclipse, or InDesign sell a company on Windows PCs, Linux enterprise servers or networks of iMacs? Can a toolset lead a company to modernize its enterprise environment? Perhaps it can, when you consider what IDEs yield: application software, the element that's supposed to trigger all enteprise platform decisions.

There's a nifty IDE primer online at the Mashable website, but it's more of a way of understanding what types of IDEs are out there. It admits it's only a sampler of everything available for enterprise developers.

One long-time 3000 vendor, now in heavy engagement with migrators, calls this strategy "offering a great set of tires to try to sell a car." Better development tools are more than just very good tires, though. A better analogy might be smartphones. Apple wants your iPhone purchase, and they lure you with App Store gems. Google wants to sell Android phones, and their hook is the superior contact, syncing and mapping tools built into that phone OS.

Many 3000 companies who are left using the server rely on bulletproof solutions, running at a cost they can justify. Something more than the loss of HP-branded support, or worries about parts supply chains, will have to be at work to get them to migrate. Newer tools might not be enough by themselves. But there's always the skills of newer developers, the kind a company must hire eventually when veterans retire or depart. Younger development teams will expect collaboration and coordination. The 3000 experts are so good at this they don't seem to need an integrated development environment.  

In the 3000 world, among those who are not yet migrated, there's no apology about using the battle-tested favorites. "I designed on paper and pencil -- still do, but have added Visio for the diagrams," said the community's security expert Art Bahrs. "Then I used editors on my PC and uploaded the code, compiled/ran/said proper incantations, and debugged on the PC. I repeated the cycle until done."

Chuck Trites, an independent consultant and developer, said "I still use EDITOR, and have used Quad and others too. I also use Ultra Edit, which is nice for large files and large rec sizes. Still doing FORTRAN and COBOL. I use MPEX and Suprtool and a few other gadgets."

Other 3000 sites have a simpler answer about what to use to develop. "Contractors," said Tracy Johnson, a former OpenMPE director who works on the IT staff of Measurement Specialties. Perhaps that means that the tools that a contractor brings along are the spark for any changes and modernizations.

At one point, Acucorp offered a COBOL development environment that hooked up with ScreenJet and Eloquence, all in the service of speeding up modernizations. Acucorp developed a 3000-aware COBOL, just about the time HP was announcing its end-game in the 3000 business. Then Acucorp got acquired by -- wait for it -- Micro Focus. It sells Visual COBOL for Visual Studio 2010. Mike Howard, whose Unicon Conversion Technologies is one of the companies who have made 3000 migrations across to .NET, testifies about Visual COBOL. He calls it the fountain of youth for legacy COBOL shops.

A supplier of COBOL solutions tries to make its developers more powerful and aware as they stick to an olden, golden language. Micro Focus is nearly the only game in the COBOL community by now, aside from Fujitsu. If the language remains constant but expanding across vendors, then the differences might lie in IDE feature sets.

07:03 PM in Migration, User Reports | Permalink

Bookmark and Share

Use our search engine to find 20 years
of HP 3000 news and articles



The comments to this entry are closed.