Migrating jobs from COBOL Mainframe system to UNIX system

In a nutshell requirement is to migrate the system from mainframe environment to UNIX environment (MF cobol would be used I guess). I have not much of idea in this field. I need to do some investigation on following points -

  • Ease of conversion
  • Known Data compatibility issue
  • Issue in performance handling large volume of data
  • Any other key feature that is important

I also need to know the various database options available for this task with micro focus Cobol in Unix. Above are some criteria. we can choose others as applicable. some e.g are DB 2 U DB, SYBASE , ORACLE.
Any input in this regard will be quiet helpful. Thanks in Advance

MicroFocus COBOL is your very best ORACLE option. It specializes in supporting ORACLE db's. It also is highly compatible with mainframe COBOL.
This will be the relatively easy part, moving code onto UNIX.

UNIX is ASCII, IBM mainframe is EBCDIC. UNIX has a tool, dd, meant for this kind of conversion. EBCDIC->ASCII - it runs on UNIX. We ran conversions in about 2005 and things have not changed markedly since then. You will have problems with abstract datatypes (structs in UNIX speak), like packing.

Getting JCL, job control, job routing, output routing, and scheduling on task can be really painful. Get somebody who has done migrations before. Otherwise as a neophyte you will simply make lots of mistakes.

The user interface migration is another 'get outside help' topic. Assuming you have (or want) a desktop user interface kind of environment.

  1. Learn to code shell - bash, ksh whatever the UNIX systems has, bash is pretty close to ubiquitous. The C shell should not be used. It has quirks.
  2. Get contractors who have done this kind of thing before - assuming this program is central your company's operation and you like having a job.
  3. Learning to code in either perl or C will be a lifesaver for quick data fixes.
  4. Do not try to fix or upgrade or tune anything, ever, until you have it working completely correctly. Even if it runs 10 times longer. Do not listen to programmers on this topic. Just migrate and make it work correctly - as defined by what you get in parallel runs between the main frame and the ported code environment. Tune later, most of the performance issues will relate to SQL and ORACLE , not necessarily hardware.
3 Likes

Thanks a lot Jim. You have said a lot in your details below. I was already thinking about Micro focus Visual Cobol Development Hub because it supports Unix and Linux including Windows. You also mentioned UNIX has a tool, dd, meant for this kind of conversion.
Is there any documentation/link or relevant posts that gives much details about how you did your conversion in 2005 for EBCDIC->ASCII - it runs on UNIX.

The following is an excerpt from my Microfocus Cobol V4.1 documentation.

1 Like

Hi Jgt,
This documentation looks like system migration. I am more interested in job migration from Cobol to Unix. Am not sure if this helps?

Job migration compared to system migration, implies that there is, or will be, a common data set?
We really do not have enough information about the current system and the target system to be of more help.

1 Like

As jgt already mentionned, we dont have much info on what /what extent you are moving what from mainframe to unix, COBOL is just the language used to program.... when I had to do the migration from OS/3 (Unisys) to unix, it was not the Cobol the pain ( I am not saying it was easy...) but I because of time limit had a port 1 to 1 ( make a unix box work and look like a mainframe...) I realized that I had no idea how transaction monitors worked, having just a little experience with Tuxedo...
my last port I did was stopped at 80% for political reasons, I opted for a version of open-cobol... Worked well many tools for conversion of data structure etc... but like the previous getting a transation monitor working means being able to emulate the screen the application uses/used on mainframe can be quite a challenging task... In other words you need a team to work on that in parallel...

1 Like

The current system is a Mainframe IBM with Z/Os operating system with data/Jobs in cobol while the target system is an IBM system with Unix operating system on it and data/jobs in Oracle.
@vbe, was your port 1 to 1 through an FTP? How convenient can it be converting data from cobol to Oracle?
@jgt, making a common dataset for jobs in cobol to Oracle is the piece. Is it all about massaging data to the target system?

The most difficult is not the conversion, once you know what is going on you can figure out how long it will take, its more if you are talking of production, negociating the downtime, the time to transfer the last state of all the data then converting and validating the lot, you can leave the system in readonly and lock the system for update but having people accessing will impact transfer time etc...
cobol / Oracle under unix means you are not using a transaction monitor, lots of chances you lets that to Oracle... So its more what/how good is the design of the new database, are you DBA sure of their table structures... I would say an indexed file = table ( easy...) but do you have I dont know the term in English, in french it was "fichier relatif", that could give you some headaches...

Oh, for the system, ask how many concurrent users you had accessing the apps on the mainframe, be sure to have enough pseudottys, on the Unix, then remember the users once connected may well be always the same user under Unix under Oracle, so look at the params like nfile nproc per user limits and ajust them as needed my machine crashed the second day of production because i didnt know how many users... ( run out of TTYs ) good job I knew how to calculate in hexa and use mknod....