Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
COBOL, legacy systems brought down to the PC? 8
- Thread starter marydup
- Start date
-
1
- #2
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.
Regards.
Glenn
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.
Regards.
Glenn
-
1
- #3
ShadowFox333
Programmer
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
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
-
1
- #4
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).
Good luck.
etom
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).
Good luck.
etom
Hi,
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.
Regards,
Crox
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.
Regards,
Crox
-
1
- #6
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.
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.
-
3
- #7
Truusvlugindewind
Programmer
"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.
Can you live whitout those?
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.
Can you live whitout those?
Truusvlugindewind
Programmer
Hi Crox. Did you like the star I stuck in your *ss?
Yes, long time no see. Still no assignment? I'm back at the old client.
Yes, long time no see. Still no assignment? I'm back at the old client.
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.
Mazzels
Mazzels
fredericofonseca
IS-IT--Management
Crox,
Very OT
I´m available to give COBOL help to that company if you think I can be of assistance. (Europe if possible).
Regards
Frederico Fonseca
SysSoft Integrated Ltd
Very OT
I´m available to give COBOL help to that company if you think I can be of assistance. (Europe if possible).
Regards
Frederico Fonseca
SysSoft Integrated Ltd
Hi,
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.
Sorry!
Regards,
Crox
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.
Sorry!
Regards,
Crox
fredericofonseca
IS-IT--Management
![[sad]](/data/assets/smilies/sad.gif "[sad] [sad]")
cobollekes
Programmer
Why legacy? Are these systems older than you are?
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. Sun UNIKIS also has serveral sources for information as well.
Charles Townsend
LegacyJ
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. Sun UNIKIS also has serveral sources for information as well.
Charles Townsend
LegacyJ
- Status
Similar threads
- Locked
- Question