What Triggers a Need for New Tools?
March 5, 2013
Editor's note: One of our 2013 projects is exploring the range of development tools that are waiting on the other side of a move off the 3000. I checked in with Alan Yeo, the founder of ScreenJet and a provider of VPlus transition and modernization tools. He's also offering a Transact for non-3000 platforms, TransAction. More than a decade ago, Yeo wired up an interface from the Acubench COBOL suite into his ScreenJet software. The Acubench technology was acquired by Micro Focus five years ago, as part of absorbing the products and customers of Acucorp into the Micro Focus COBOL tool lineup.
By Alan Yeo
If you're developing on the HP 3000, most of the tools that are available do just about everything that is needed. They don't need to be that much better. Remember, if you're cutting code on the 3000 it's either batch code or it's got a UI. If it's got a UI, it's either home-grown or VPlus, and none of the new tools are going to buy you a lot more than existing tools will for that stuff.
Some old tools did integrate with source version control software — but not a lot of people were doing that on the 3000. There are a ton of tools available for the 3000 that people never used, because they could make do with the simple ones. They didn't get into trouble; they were a lot more professional because they could concentrate their knowledge in a smaller area.
I don't think a better development environment would trigger a migration. Who uses dev environments? Techies. The days when the techies in companies decided and led the choice of software solutions ended about 20 years ago. So there has to be a business need to migrate or implement something new. If a company is in a mindset of going somewhere, the protection of application assets by using new tools is an important point. What you've got available to protect that application investment has value.
Unfortunately, the terms migrate/migration have been mangled in their usage over the last decade. To me, a migration is when you take what you have and move it to a different platform (maybe with some changes on the way) or make a change in the base technology as a result of the migration. Buying a different package/applications isn't a migration.
Sure, you may have moved some of the data. But it's rather like buying a new phone and transferring your old phone numbers. You haven't migrated from one phone to the next. You have bought a new one, and binned the old one.
However, having said that, is there a business need to migrate, or a business need to junk what you have and get something new? Then yes, what tools are available in the new environment, what the applications are written in, how easy are they to maintain, how easy to get people with the needed skills — all these things are part of the equation.
As far as better tools for COBOL tools, if you're a COBOL shop, then moving to a better toolset than just a line editor makes a lot of sense. Something with a built-in debugger, for example. Would I use something like the latest COBOL tools to develop something new with a UI? No. Been there done that, and I've been locked into proprietary products that go away. No, COBOL is great for back-end processing, but it isn't a UI product, regardless of how many bells and whistles you hang on it.
And that's from someone who still thinks COBOL is the best app development language, especially for apps that need ongoing maintenance, development and support.