In todays complex computing world, current trends are calling for handling a reduced product set in order to ensure more productive environments in development and management. Thus transfer to Cobol (and DB2) is an obvious option provided it can be done at reasonable cost and effort.
Main issues.
Automatic conversion.
Every effort has been put into the product for no or minimum manual intervention for the conversion process. Simply feed in listings of Mantis objects and get BMS maps and Cobol code and supporting information. For Supra conversion you must also supply DB2 tables (declares).
Customizable algorithms.
As MCT System will generate program code and Job streams some installation defaults must be set like date and time standards, DSNs for Mantis files and compilation decks.
Another customizable item refers to program names because Mantis names may be longer than allowed by MVS host. You select which portions of source name to be used. You can add also fixed data. Once selected, this algorithm will be conversion wide used at program generation of own and called programs, thus almost eliminating manual intervention (the exception is when the called program is a variable not known at conversion time, a warning is recorded at log file).
For Supra conversion, parameters are available to specify current and new table names.
Cobol follow on uptades.
Enabled follow on Cobol maintenance is another plus you will get. When doing so may be you also you will find advantageous replacing some areas by a more efficient "native" Cobol code.
Execution pathlength savings.
Cobol execution of programs will be a simulation of converted program, but as long as complex "interpretation" is no longer needed, there will be important reductions in pathlength and storage requirements.