I have mainframe legacy systems that need to be brought down to the PC. Will MicroFocus COBOL do the conversion for me or will I have to rewrite the COBOL programs?
The various vendors of PC-based COBOL compilers have generally done an excellent job of making their products compile mainframe code cleanly. Microfocus seems to have done one of the better jobs of allowing you to run mainframe code unchanged on the PC.
That said, there are a myriad of other issues that can make moving a mainframe COBOL system to a new platform "interesting". If your mainframe uses CICS, you'll need PC-based CICS. If your system has a batch component, there are likely issues around JCL. EBCDIC/ASCII issues can be a problem as can data formats (e.g. big vs little endian).
The closer your COBOL system is to fully standard (i.e. uses few, if any, vendor extensions) and self-contained (only calls other COBOL modules), the easier the conversion is likely to be.
What is your mainframe. I just completed a conversion
from Vax Cobol to Rm-Cobol. The differences were minimal.
Mostly things like select statements, file status usage,
some syntax and of course the whole display accept monster.
We converted all the files to flat sequential files and just reindexed them using the indexing from the programs that use them. There were about 250 programs and the system ran from the clients using telnet. They now run terminal server and the clients can't tell the difference except the
programs run a lot faster. I just wrote a cobol program to read the Vax cobol programs as flat files and convert the vax code to Rm-cobol code. Took three or four days to write the conversion and a few months to do the testing and get the systems running. If you need any thoughts let me know.
Enjoy Bob
I echo all that was previously said and wanted to raise a very special point. If you are comming from an EBCDIC mainframe and your files contain Binary or packed (comp-3) data, you will have problems with the translation from EBCDIC to ASCII as mentioned by 3gm above. The best way I have found to get around this problem was to write a program or use a utility to convert the file completely into Display format prior to transmission to the PC. You can then write programs on the PC side to return your file into it's original format. I have seen some transmission utilities that can be configured to handle the transmission without translating the binary characters however, they also have problems of their own.
I moved a batch only application from Mainframe to PC a with only minor changes to the Cobol code (mainly Select statements). At that time I was using CA-Realia (which I do not believe is offered anymore).
Screen-io can be difficult but perhaps you can use a mainframe-look-alike subsystem?
Compile all the sources and look what the errors are.
Combine them and think about a cure. (Use a powertool for this like SPF/SE. It can be done in minutes.)
Make a strategy for things you don't have look-alike systems for on the pc.
There are companies whom can do all the work for you.
In Micro Focus COBOL, files need not be converted; just specify that they are in EBCDIC. Convert for efficiency only. To convert, write a program to read the EBCDIC and write ascii (NATIVE). COMP and COMP-3 fields are no problem. Micro Focus COBOL knows that they are to be unmodified.
The syntax for QSAM and VSAM files is identical. ISAM and BDAM files must be converted to Indexed or Relative files, unless you code your own access method. %-)
Note that the default file name is the external name (DDNAME). There are numerous ways to modify this.
If you want to outsource the conversion, I can do it, as I have extensive experience in both IBM Mainframe COBOL and Micro Focus COBOL.
"Down to the PC". We all assume to MS-Windows. Is that right?
The COBOL won't be a problem, but like my honorable friend Crox already mentioned: you must pay attention to the online interface. Micro Focus can supply you with marvellous screen-io gadgets, but what is your current application based upon? CICS, IMS TSO/ISPF?
Also other mainframe components: JCL, utilities/goodies like sort,GDG datasets and job schedulers.
I love it. Lucky you! Still no work but there is something in the air for a company that does conversions all the time like 'downsizing' (better rightsizing) from mainframes to micro's or any other conversion from any language to any other (language or version of the) language. They can use some help with COBOL and PL/I.
I'll do this big job on my own and of course with the conversion software of Cornerstone. The only reason they need me is to write some conversion rules for specific company situations. General conversion things are no problem at all for them. It is amazing what they can analyze. For example it is no problem at all for them to analyze the different use of some fields in a program and depending on some characteristics to decide for some part of the conversion to use a certain conversion rule. It is even possible to let those things depend on things on (sub-)system level. So in fact they need me only to create some master-conversion rules in the way the customer likes it.
Mainframe S/390 COBOL applications can be "Batch", CICS, IMS, IDMS, etc. The batch COBOL can be handled by almost any COBOL compiler as long as you handle the data element QSAM, VSAM, IMS/DB, SQL.
One of the big issues will be how the capabiles of JES2 (Job Scheduling, Print Spooling, etc.) are handled. If you are running on Windows BAT files can be assembled to string multiple jobs together. The print spooling will be a exercise in writing sequential files and then printing the file.
CICS COBOL applications can be another big issue. The major items involve the screen interface (BMS Maps) and they are not necessarily replaced by SCREEN SECTIONS or DISPLAY/ACCEPTS which are more traditional in the PC COBOLs. EXEC CICS is not supported by traditional COBOL compilers. If you wish to convert these COBOL applications to run outside of a CICS environment, you should be prepared to loose capabilities in your COBOL applcation if using traditional PC COBOL compilers.
There are solutions and/or roadmaps for convertion CICS COBOL to run on a PC. If your goal is to redeploy CICS to an Application Server (Java Enterprise) then the LegacyJ solution PERCobol and Transaction Platform is excellent (screens are converted and all CICS services are supported). If you would like to run on Solaris (Unix) environment the Sun UNIKIS solution has batch, print spooling and other CICS cababilities. Frankly, I like the LegacyJ solution (no code changes).
There are several places you can go for assistance. There is a white paper that might offer some assistance.
I don't know what capabilities one would lose converting from CICS to pc COBOL screens. True, CICS does a lot for you, but you have much more control over the user interface with pc COBOL screens.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.