Migrating jobs from COBOL Mainframe system to UNIX system


Login or Register for Dates, Times and to Reply

 
Thread Tools Search this Thread
Top Forums UNIX for Beginners Questions & Answers Migrating jobs from COBOL Mainframe system to UNIX system
# 1  
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
# 2  
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.
These 3 Users Gave Thanks to jim mcnamara For This Post:
# 3  
Migrating jobs from COBOL Mainframe system to UNIX system

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.
# 4  
The following is an excerpt from my Microfocus Cobol V4.1 documentation.
Quote:
Chapter 1: IBM/370 Mainframe Compatibility

Conversion Series 1 supports certain extensions which allow you to submit source programs written in IBM SAA AD/Cycle COBOL/370 directly to this COBOL system. This chapter describes how you first configure your system so that it emulates the behavior of IBM/370 COBOL, and also gives hints on how to avoid possible areas of difficulty when you submit your programs.
1.1 Configuring your COBOL System

Before submitting your IBM/370 COBOL programs to this COBOL system, you must configure this system so that it emulates the behavior of IBM/370 COBOL. You can do this in one of two ways:
  • Select the OS/VS COBOL or the appropriate VS COBOL II option from within the Setup utility when you install this COBOL system. When you do this, a COBOL.DIR file is automatically created and contains the system directives for the dialect you specified in SETUP.
  • Create a COBOL.DIR file and set certain system directives according to which dialect you wish to use; that is, for OS/VS COBOL, you set: NOANS85
    NOCOBOL370
    NODG
    NODOSVS
    NOIBM-MS
    NOMF
    NOMS
    NOPC1
    NORM
    NOSAA
    NOVSC2
    NOXOPEN
    NO01SHUFFLE
    NOFLAGSTD
    OSVS
    FLAG
    FLAGAS
    FLAGCD
    for VS COBOL II Release 3, you set:
    NOANS85
    NOCOBOL370
    NODG
    NODOSVS
    NOIBM-MS
    NOMF
    NOMS
    NOOSVS
    NOPC1
    NORM
    NOSAA
    NOXOPEN
    NO01SHUFFLE
    VSC2
    FLAG
    FLAGAS
    FLAGCD
    for VS COBOL II Release 1.1 or Release 2, you set:
    NOANS85
    NOCOBOL370
    NODG
    NODOSVS
    NOIBM-MS
    NOMF
    NOMS
    NOOSVS
    NOPC1
    NORM
    NOSAA
    NOXOPEN
    NO01SHUFFLE
    NOFLAGSTD
    VSC2
    FLAG
    FLAGAS
    FLAGCD
    and for VS COBOL II Release 1, you set:
    NOANS85
    NOCOBOL370
    NODG
    NODOSVS
    NOIBM-MS
    NOMF
    NOMS
    NOOSVS
    NOPC1
    NORM
    NOSAA
    NOXOPEN
    NO01SHUFFLE
    VSC2
    FLAG
    FLAGAS
    FLAGCD.

See your Object COBOL User Guide for further details of the COBOL.DIR file.
You may need to set several other directives to enable this COBOL system to more closely imitate the behavior of mainframe programs. You can select these from the Setup program. They are:
PERFORM-TYPE(OSVS)
IBMCOMP
NOTRUNC
All of the above directives are described in your Object COBOL User Guide.
1.2 Migrating your Applications

When you have configured this COBOL system as described in the section above, you can submit your IBM/370 COBOL programs to it. For the command to do this, see your Release Notes.
1.3 Conversion Issues

Most of the IBM/370 mainframe programs which you submit to this COBOL system will be accepted syntactically and will run successfully. However, errors may occur in a number of areas.
It is probable that you will encounter few or none of these errors, but if you do, following the suggested solutions will greatly reduce any work involved in migrating your application. The known errors are detailed in the following sections together with hints on how to overcome them.
1.3.1 General

1.3.1.1 Error Message Differences

The default actions or assumptions made by this COBOL system after it has issued W or E level error messages may differ from those made by the IBM/370 mainframe Compiler.
Solution

You should either review all E and W level messages carefully, or modify your source to remove the error(s).
1.3.1.2 Files not Supported

IBM/370 BDAM and ISAM files and their corresponding language extensions are not supported under this COBOL system.
Solution

Replace any BDAM files with ANSI relative files, and any ISAM files with ANSI indexed files .
1.3.1.3 The DISK FULL Condition

The file status value for the DISK FULL condition under this COBOL system is not the same as that under IBM/370 mainframe COBOL. This COBOL system returns a hexadecimal value of X3907. An IBM/370 mainframe program returns a character value of 30.
Solution

Change your source program to reflect the changed value.
1.3.1.4 Arithmetic Operations

Under IBM/370 mainframe COBOL, if you perform arithmetic operations on nonnumeric data, it causes a program check (data exception or 0C7).
Solution

Under this COBOL system, you must be sure the F run-time switch is set to the default "+F".
1.3.1.5 Intermediate Result Precision

This COBOL system uses the concept of two numeric registers designed for worst-case calculation. This means you need 18 decimal digits (plus one for overflow) before the decimal point for rounding capability during MULTIPLY and DIVIDE operations. You also need 18 decimal digits (plus one for overflow) for temporary overflow during ADD and SUBTRACT operations. For this reason, intermediate result calculations by this COBOL system are more accurate than in OS/VS COBOL and VS COBOL II.
Solution

To ensure the same accuracy between these two dialects and this COBOL system, replace any COMPUTE statements with a series of operations using user defined intermediate result fields. The size of each result field will vary according to the rules documented in the OS/VS COBOL and VS COBOL II manuals.
1.3.1.6 The COMPUTE Statement

Results of a COMPUTE statement after an OVERFLOW condition are incompatible between the mainframe environment and this COBOL system.
Solution

Use the ON SIZE... clause if there is a possibility of numeric OVERFLOW. You should never depend on the result if this condition occurs.
1.3.1.7 PIC 9 Items

If your source program contains PIC 9(n) DISPLAY usage data items which contain spaces, it may fail at run time.
1.3.1.8 ACCEPT Statements

An IBM/370 mainframe COBOL ACCEPT statement from SYSIN is not supported by this COBOL system.
Solution

For larger amounts of data (that is, a set of parameter cards) you should define a new sequential file. For a single ACCEPT of a small amount of data, enter the input data on the operating system command line when you invoke the application, in the program use the syntax:
ACCEPT data-name FROM COMMAND-LINE 1.3.1.9 DISPLAY Statements

An IBM/370 mainframe COBOL DISPLAY statement to SYSOUT (or any other DDNAME) is not supported by this COBOL system.
Solution

All DISPLAYs are directed to the terminal (console). If you are using the PC-DOS system, this allows you to redirect this output to a file if you request it at the time the application is invoked. See your PC-DOS Reference Manual for further details of redirection.
1.3.1.10 The SIGN SEPARATE Clause

When you download input data from an IBM/370 mainframe which contains signed numeric USAGE DISPLAY data items without the SIGN SEPARATE clause, embedded signs are not interpreted correctly.
Solution

Set the SIGN"EBCDIC" system directive when you submit your programs to this COBOL system. This causes this COBOL system to output code which interprets signed data by using the EBCDIC rather than the ASCII convention. See your Object COBOL User Guide for details of this directive.
1.3.1.11 Comparisons of Alphanumeric Data

Comparisons of alphanumeric data under this COBOL system are not the same as those under IBM/370 mainframe COBOL.
Solution

Set the NATIVE"EBCDIC" system directive when you submit your programs to this COBOL system. This causes this COBOL system to output code which interprets signed data by using the EBCDIC rather than the ASCII convention. See your Object COBOL User Guide for details of this directive.
1.3.1.12 Pointer Variables (VS COBOL II Only)

Under this COBOL system, when you redefine a VS COBOL II POINTER variable as a COMP field, and make an arithmetical calculation on this field to change the value of the POINTER, its behavior will not be the same as under IBM/370 COBOL.
Solution

The problem is because, in this COBOL system, the POINTER has a format defined by the 8086 machine architecture, whereas the VS COBOL II POINTER uses the 370 machine architecture.
This COBOL system provides syntax in the SET statement which enables you to change the value of a POINTER. See your Language Reference for details on how to do this.
1.3.2 File Input and Output

1.3.2.1 File Referencing

IBM/370 mainframe COBOL programs reference data files indirectly via DDNAMEs. This function is not implemented in this COBOL system.
Solution

To emulate this function, use the ASSIGN"EXTERNAL" directive when you submit your program to this COBOL system. Before execution, you can associate the data file-names used in your program with physical files via the operating system SET command.
For example, if your program contains the line:
select in-file assign to ut-s-infile. and your data file is called C:\INFILE.DAT, you enter the command:
set infile=c:\infile.dat which will establish the appropriate connection between the data file-name and your application program.
1.3.2.2 The NOMINAL KEY Clause

The mainframe COBOL NOMINAL KEY IS ... clause for relative and indexed files is not supported by this COBOL system.
Solution

For both types of file, replace the NOMINAL KEY IS ... clause with the ANSI standard RECORD KEY IS ... clause. Also, for indexed files, you should change any Procedure Division references to nominal key in your source programs so that they reference record key.
1.3.2.3 The ACTUAL KEY and TRACK-LIMIT Clauses

The mainframe COBOL ACTUAL KEY IS ... and TRACK-LIMIT IS ... clauses in direct files are not supported by this COBOL system.
Solution

Convert any direct files to relative files as the ACTUAL KEY IS ... clause closely resembles the RECORD KEY clause of relative files. You can then, in most cases, delete the TRACK-LIMIT clause.
1.3.2.4 The TRACK AREA Clause

The TRACK AREA IS ... clause for indexed files is not supported by this COBOL system.
Solution

You should delete this clause from your source program. TRACK AREA was an IBM extension used to improve performance of ISAM during random updates. Indexed files in this COBOL system, like mainframe VSAM files, are reorganized as they are updated.
1.3.2.5 Deleting Records

When you have successfully submitted your programs to this COBOL system, you may find that on execution you cannot delete records in relative files.
Solution

In IBM/370 systems, you can usually delete records in relative files by moving HIGH-VALUES to a delete byte and rewriting the record. The ANSI standard does not require (or use) an explicit delete byte. Therefore, you must change the syntax in your source program so that a DELETE operation is performed on the record.
1.3.2.6 Record Lengths

This COBOL system checks both the minimum and maximum record lengths of a variable length file when it is opened. The file status is automatically set to "39" if the attributes do not match. However, the mainframe environment only checks the maximum length value.
Solution

Review the File Description (FD) record descriptions to ensure that all programs referencing a variable length file use the same minimum and maximum values.
1.3.3 Inter-program Communication

1.3.3.1 Calls to Subprograms

Calls to subprograms using this COBOL system default to dynamic linkage, whereas calls to subprograms on an IBM/370 mainframe default to static linkage.
Solution

Specify the NODYNAM system directive when you submit your source program to this COBOL system; this will cause any CALL operations to be static. See your Object COBOL User Guide for further details of this directive.
Copyright © 1998 Micro Focus Limited. All rights reserv





This User Gave Thanks to jgt For This Post:
# 5  
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?
# 6  
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.
This User Gave Thanks to jgt For This Post:
# 7  
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...
This User Gave Thanks to vbe For This Post:
Login or Register for Dates, Times and to Reply

Previous Thread | Next Thread
Thread Tools Search this Thread
Search this Thread:
Advanced Search

Test Your Knowledge in Computers #874
Difficulty: Medium
A programming language is homoiconic if a program written in it can be manipulated as data using the language, and thus the program's internal representation can be inferred just by reading the program itself.
True or False?

8 More Discussions You Might Find Interesting

1. AIX

Cloning a system via mksysb backup from one system and restore to new system

Hello All, I am trying to clone an entire AIX virtual machine to a new virtual machine including all partitions and OS.Can anyone help me on the procedure to follow? I am not really sure on how it can be done.Thanks in advance. Please use CODE tags for sample input, sample output, and for code... (4 Replies)
Discussion started by: gull05
4 Replies

2. Shell Programming and Scripting

UNIX file system to Linux file system migration

We would be migrating UNIX file system to Linux file system. We do have many directory and sub directories with files. after migrating unix to linux file system , i want to make sure all the files has been copied ? What would be the best approach to validate directory ,sub-directory and file... (1 Reply)
Discussion started by: balajikalai
1 Replies

3. Shell Programming and Scripting

Typeset -i in MVS (Mainframe system)

Hi, I have one job that runs daily and creates daily files. At the end I compare the today's file with previous day's file. And if today's file size is greater or equal to previous day's file, then it is ok, else I need to through error. I have following piece of code: typeset -i... (2 Replies)
Discussion started by: ppatra
2 Replies

4. UNIX for Dummies Questions & Answers

Unix System Programmer Vs. Unix System Administrator

Hi friends, I hope you are all fine and doing well. First of all, let me say that I love Unix with passion. But I have one query in my mind that is bothering me. What should I do, Unix System Administration or Unix System Programmering. Could you please tell me the difference between the two. And... (3 Replies)
Discussion started by: gabam
3 Replies

5. Programming

UNIX system call in COBOL

Hi, The UNIX system call inside the COBOL program is doing the specified command correctly. MOVE W080-UNZIP-FILE-COMMAND TO W080-OUTPUT-COMMAND CALL "SYSTEM" USING W080-OUTPUT-COMMAND RETURNING W080-SYS-CALL-STATUS BUT The problem is, the following keeps on showing on the log file... (2 Replies)
Discussion started by: joyAV
2 Replies

6. Shell Programming and Scripting

FTP files to target Mainframe system

Hi Experts... Greetings for the day..! I just want to FTP the files to mainframe system.. my code is not working..and also i need to put the files in a particular directory in a specific naming format... ftp -i -n ${HOST_NAME} << END_FTP user ${USER_NAME} ${PASSWORD} put ${FILE_NAME}... (3 Replies)
Discussion started by: spkandy
3 Replies

7. UNIX for Dummies Questions & Answers

Converting a Windows system to a UNIX system

Hello I am looking for advise on how to convert a windows based computer system into a UNIX based operating system.. I would like to be able to learn UNIX better than I know it and work didn't allow me to work with UNIX much. Is there a book where I could learn how to accomplish that... (6 Replies)
Discussion started by: baksg1995
6 Replies

8. Shell Programming and Scripting

How to invoke cobol jobs on mainframes

Hi, Does any one of you know how to invoke the cobol jobs on mainframes? Thanks, Waseem (3 Replies)
Discussion started by: ahmedwaseem2000
3 Replies

Featured Tech Videos