Like the old saying of "some assembly required," the more current demands of application development will require version management, at the least, for 3000-bred apps. They are mission-critical programs, and we've not heard terrific reports about off the shelf replacements for 3000s during a migration. It's possible and has been accomplished, but many more stories are in our files concerning existing code, working on a new platform.
If you're moving code away from a 3000 to another platform, some version management is the minimum you will require. More likely, the solution will integrate a compiler suite with Windows Studio tools. There's something on the market called COBOL Studio from ATX II Tecnologias de Software, S.A. More familiar targets would include the Visual COBOL for Visual Studio, from Micro Focus.
What does it look like when a 3000 is doing more beyond a good programmer's editor? Perhaps like the story that Walter Murray -- who moved from HP's languages lab to a job managing 3000s for the California Corrections System -- shared with us.
For version management, I use HP SRC. I have one master library and one person responsible for keeping it in sync with what's in production. We archive not only the source, but also the compiler listing, object file, and executable, each time a new version is migrated to production. We also archive job streams, UDCs, tables, and so on. We have separate libraries for personal use and projects.
That last part might be just as important as any other Murray mentioned. Good developers have a yen for creating programs, and the ones you'll want to attract will have personal projects. The most broad minded companies set aside time for the code creators to work on these projects.
You never know when some personal coding will yield a breakthrough that can be applied to a mission-critical roadblock. But without management for version changes, the chain of succession for a development team is much weaker.
Murray had other recommendations for the coders who will stay on the 3000 to homestead. (After all, SRC is an MPE/iX tool.) He likes to use Quad, but notes that
the only bothersome limitations with Quad are that it doesn't handle files with variable length records (of which we have very few any more) and the search is case-sensitive (which leads us to avoid lower case in COBOL source code except for comments).
For debugging, I use XDB (HP Symbolic Debugger/iX). It's well worth the time spent learning to use it, even if it's not as good as HP Toolset as a symbolic debugger for COBOL.