CA-IDMS… one of the top mainframe software development and database systems from years gone by. ADS/O for the screens, IDMS calls for database operations. Good stuff, if you know how to use it. Compare to Model 204 (also known as M204), Software AG Natural and ADABAS, CA-Datacom (IDEAL and Datacom/DB), and MAPPER on the Unisys mainframes.More productive than straight COBOL, but not as powerful for some applications as the true 4GL environments like Focus and RAMIS.
One thing that drives customers to modernize is the license cost. For example, the State of Iowa reports that they saved $296,413 in FY 2005 by negotiating a common license agreement with CA to support 3 agencies. That’s great, that these savings could be had — but it’s sobering to realize that if the savings were that large, the ongoing expense surely isn’t $1,000 per year. It’s still a 6-fingure number. And that doesn’t take into account the fact that all of the mainframe software vendors are raising their fees every year.
Then there is the problem of impending retirement of the IDMS knowledgeable programmers. it’s like the Year 2000 (Y2K) problem – just not with the hard deadline. At some point in time, the systems can’t be maintained.
So what do you do? The mainframe is secure, it works well, as long as changes are not required and as long as there is money to pay the fees. But the first “rush” change that’s needed in response to new laws or the offerings of a competitor, or the first time 4 or 5 programmers retire at the same time… life gets interesting.
If you want escape the clutches of the software vendor, you can do a COBOL-to-COBOL migration that eliminates the license fees to CA altogether and is minimally disruptive. We have a fully automated solution for that, and it’s a great fit for those who have no intention of moving off the mainframe.
On the other hand, if you want to get off the mainframe altogether, we have tools and processes for redeveloping your existing IDMS and ADS/O application to the Java platform or to Microsoft .NET. You get full source code, and it’s maintainable source code. The third choice, and one that some organizations select when they want a rock bottom price and don’t care if they ever maintain the code, is to do a line by line translation of the whole body of code.
An interesting aspect of ADS/O is that the runtime environment “does a lot for you” that cannot be duplicated on another platform without writing a lot of code. If your modernization vendor doesn’t understand ADS/O, you can wind up with a solution that doesn’t deliver the full functionality or doesn’t perform well. Since CA does not publish the internals of ADS/O, much detective work is required to get it right.
The database migration is pretty straightforward. There are emulation solutions, but you don’t need one of those — just migrate the data over to DB2 or ORACLE or Microsoft SQL Server as the case may be. Running an emulation layer just exposes you to more license fees and more vendor lock-in.
Some customers want the mainframe look and feel; others want a web system look and feel. We can do either one, without changing the underlying programming. And in fact, we can migrate your IDMS system to either .NET or Java, mostly by changing options and tools.
If you’re happy with your IDMS system and can stand the fees, maybe the time isn’t right to consider a modernization. But, you don’t want to modernize “under the gun” either. Check those retirement dates on the key staff, and think about how soon several hundred thousand — or millions — of dollars per year add up. When you’re ready, we’re here.