I can’t comment on the COBOL as in all the porting projects I’ve been involved with we’ve only had a handful of small COBOL programs that were called from Natural. We simply re-wrote them in Natural.
Most of the “issues” encountered when porting a Natural/Adabas application are related to the change from EBCDIC to ASCII. As Ralph said, the complexity of the conversion can vary widely depending on how the application was designed e.g. use of hex values, binary fields, alphas redefined as numerics, collating sequences etc. Having said that, you can expect the vast majority of your code to simply compile and run.
Depending on the size and structure of your Adabas database(s) the conversion can be a lengthy and, sometimes, complex process. If the data volumes are small and you have a large enough down-time window for the port, you should be able to use the standard conversion method (unload, decompress, transfer, compress, load). However, if there are any “clever” data structures or you are pressed for time/have large amounts of data, you might want to look at Adamagic from CCA Software (Treehouse).
A large, complicated batch environment will add considerable complexity (and cost) to the port. There is no JCL equivalent on Unix and you will need to convert to shell scripts. There are companies that have tools that can automate some of this work for you. Then there is the issue of scheduling…
I second, Ralph’s suggestion on calling in some experienced help, at least initially. I know SAG has experienced people and tools that can help in the scoping of the project. They can, of course, fly in and do it all for you as well (for a price). Much of the remediation work is sausage machine stuff and, if you have the resources, the more of your own people you can devote to the process the lower the cost; the application knowledge will help as well.
It probably isn’t unreasonable to expect a return on the investment on the porting project to occur in 3-5 years but YMMV.
Take heart from the knowledge that this process has been undertaken successfully by many others before. There are very few Natural/Adabas workloads that I know of that couldn’t run and performas well or better on an Open Systems platform. Adabas is lightning fast and scalable with SMP out-of-the-box; there are sites that average many thousands of Adabas calls per second.
Please take Ralph’s recommendation of investing in a graphically IDE seriously if you value staff retention and productivity. Except for eclipse-based Natural, I’ve worked in all the Natural development environments and I know which one that I prefer and work most productively in.
While the capital and running costs of an Open Systems platform will be lower, don’t forget to factor into your hardware design and costings, the things you take for granted on the mainframe; redundancy, availability, etc. Miss them and the savings could be costly. Have you considered staying on the mainframe and porting to z/Linux…
Good luck with the project.