Table of Contents
This chapter describes the process of migrating legacy CICS and batch applications.
Before CICS applications can be used in OpenFrame/OSC, they must be migrated from the mainframe. During migration, program source is converted from EBCDIC characters to ASCII characters. After character conversion, application migration follows the same compilation and deployment steps as a general OSC application program. Applications developed for mainframe CICS can be migrated to OpenFrame OSC system without modification of their logic.
The general process for migrating a CICS application is as follows:
Converting EBCDIC to ASCIIEBCDIC
Application source code is extracted from mainframe and then converted from EBCDIC to ASCII so that it can be used in an open system environment.
Pre-processing
OpenFrame tools are used to optimize application source code to ensure efficient operation in the open system.
Compiling source code
Source code is compiled to generate an executable binary.
Deploying compiled binary
The compiled binary is deployed to OpenFrame.
The following sections describe the information needed to successfully migrate a CICS application to OpenFrame. This includes pre-processing and compiling the source files.
For more information about the process of converting EBCDIC to ASCII and any issues arising during the process, refer to "2.1. Conversion from EBCDIC to ASCII" and "Appendix A. EBCDIC → ASCII Conversion Issues".
After extracting CICS application from mainframe and converting it to ASCII, you must pre-process it. This prepares the application for compilation.
CICS applications are pre-processed using the following four tools:
The ofcbpp tool pre-processes syntaxes only supported in mainframe COBOL.
This tool is used for pre-processing to compile COBOL CICS applications in an OpenFrame environment. It is also used to check COBOL syntax and expand a referenced copybook. In addition, it is used to replace or insert specific clauses. For example, the --add-miss-period option can be used to prevent syntax errors, such as not entering an end period. The --conv-stop-run option can be used to replace STOP RUN that means an end with GOBACK that means RETURN.
The following example pre-processes COBTEST.cob by specifying a copybook path and using --conv-stop-run.
$ ofcbpp -i COBTEST.cob -o ofcbpp_COBTEST.cob -copypath $PWD/COPYBOOK --conv-stop-run
For more information about ofcbpp, refer to OpenFrame COBOL User Guide.
The osccobprep tool pre-processes exceptional COBOL syntaxes supported by CICS. It is used to pre-process syntax of OSC COBOL applications. For example, a program containing a BLL cell structure can trigger an invalid memory access error if it is compiled and executed without pre-processing.
The following example uses osccobprep to delete the BLL cell structure from a file.
$ osccobprep -b OSCTEST.cob
The dliprep tool pre-processes COBOL source codes that include EXEC DLI statements.
The following example uses dliprep to pre-process a COBOL source file that contains EXEC DLI command statements.
$ dliprep DLITEST.cob
The osccblpp tool pre-processes COBOL source codes that contain EXEC CICS command statements.
The following example uses osccblpp to pre-process a COBOL source file that contains EXEC CICS command statements.
$ osccblpp OSCTEST.cob
When migrating CICS applications, all source codes must be pre-processed with osccblpp. You must use the ofcbpp, osccobpp, and dliprep tools only when necessary.
After the application has been pre-processed, it must be compiled into a shared object for use in OpenFrame. Apply options according to the COBOL syntaxes used in the application.
For more information about how to use the compiler and create shared objects, refer to COBOL Compiler related guides.
After the application has been pre-processed and compiled into an executable binary, the binary must be deployed to the OpenFrame system using the osctdlupdate tool. The following describes the deployment process. If you already set the TDL (Tmax Dynamic Library) file, skip the first four steps.
Set the TDLDIR environment variable of the [GENERAL] section in the OSC application server environment configuration file. If the mode and run directories do not exist under the directory specified in the TDLDIR element, they must be created manually. If no directory is specified, the default directory is "${OPENFRAME_HOME}/osc/region/{Region name}/{TDL directory}".
Create the tdl.cfg file in the directory specified in TDLDIR. Use the tdl.cfg sample file that was deployed during the installation of the OpenFrame system.
Run the osctdlinit initialization tool. The initialization process uses the settings specified in tdl.cfg.
Copy the application binary to the mod directory under the TDLDIR directory.
Using osctdlupdate, deploy the compiled binary to the OpenFrame system by specifying the target OSC region name and program name.
The following example uses osctdlupdate to update the OSCTEST program (note that the program file extension is omitted).
$ osctdlupdate OSC00001 OSCTEST
For more information about TDL settings and the tdl.cfg file, refer to Tmax Programming Guide (Dynamic Library).
You can use the osctdlrm tool to delete data from the shared memory, and osctdlinit to re-initialize the shared memory. For more information about these tools, refer to OpenFrame Tool Reference Guide.
You can migrate batch applications developed in mainframe to an OpenFrame system. The process for migrating batch applications includes pre-processing and conversion of the application source code. The method for migrating batch applications is slightly different between COBOL and PL/I. This chapter covers both methods.
The general process of migrating a batch application is as follows:
Converting EBCDIC to ASCII
Application source code is extracted from mainframe and then converted from EBCDIC to ASCII so that it can be used in an open system environment.
Pre-processing
OpenFrame tools are used to optimize application source code to ensure efficient operation in the open system.
Compiling source code
Source code is compiled to generate an executable binary.
Deploying compiled binary
The compiled binary is deployed to OpenFrame.
If the system running OpenFrame is going to use an Oracle database, you also need to convert DB2 SQL statements to Oracle SQL statements.
For more information about the process of converting EBCDIC to ASCII and any issues arising during the process, refer to "2.1. Conversion from EBCDIC to ASCII" and "Appendix A. EBCDIC → ASCII Conversion Issues".
For more information about the process of converting DB2 SQL statements to Oracle SQL statements, refer to "Appendix B. DB2 → Oracle Migration Issues".
This section describes in detail the process of pre-processing, compiling and deploying COBOL batch applications for migration.
Pre-process a COBOL batch application by using ofcbpp before compiling it.
Use ofcbpp to check COBOL syntax and expand a referenced copybook. When compiling ofcob, use ofcbpp for pre-processing if necessary. OpenFrame COBOL uses OpenFrame external file handler by default. However, if you use Fujitsu NetCOBOL, you need to use ofcbppf to use the OpenFrame external file handler.
The following example uses ofcbpp to pre-process TSTCOB.cob by specifying a referenced copybook path.
$ ofcbpp -i TSTCOB.cob -o ofcbpp_TSTCOB.cob -copypath $PWD/COPYBOOK
The following example uses ofcbppf to pre-process TSTCOB.cob in submodule and debug modes.
$ ofcbppf -s -t -i TSTCOB.cob -o ofcbppf_TESTCOB.cob
For more information about ofcbpp and ofcbppf, refer to OpenFrame COBOL User Guide.
Depending on the COBOL compiler in use, the pre-processing process or pre-compiling tasks may vary. The following describes how to compile batch applications depending on the compiler.
OpenFrame COBOL Compiler
When using an OpenFrame COBOL compiler that supports external file handlers, data set I/O can be performed by linking with OpenFrame textfh (Tmax External File Handler) module and specifying the function name to call during compilation. In this case, pre-processing for file I/O is not required.
No option is required to specify an external file handler. During compilation, libtextfh.so must be linked. To call a function with a name specified by OpenFrame COBOL, $OPENFRAME_HOME/lib/libcobsw.so must be linked with libswofcob.so.
The following example uses the OpenFrame COBOL compiler.
ofcob -U –o COBSAMPLE.so COBSAMPLE.cob -L$OPENFRAME_HOME/lib –ltextfh
MF-COBOL Compiler
When using an MF-Cobol compiler that supports external file handlers, data set I/O can be performed by linking with OpenFrame textfh (Tmax External File Handler) module and specifying the function name to call during compilation. In this case, pre-processing of file I/O is not required.
To specify an external file handler, you need to add the -C 'CALLFH "TEXTFH" option and the -C "ASSIGN" EXTERNAL "option at compile time to specify the function, which will be used by the external file handler, and link the libtextfh.so library. To call a function with a name specified by OpenFrame COBOL, $OPENFRAME_HOME/lib/libcobsw.so must be linked with libswmfcob.so.
You can use the tcobfh module instead of the textfh module for MF-COBOL, but if you are using MF-COBOL, it is recommended to use the external file handler as shown in the following example.
The following example uses the MF-COBOL compiler.
cob32 -zvP -U -t –o COBSAMPLE.so COBSAMPLE.cob –C’CALLFH”TEXTFH”’–C’ASSIGN”EXTERNAL”’–L$OPENFRAME_HOME/lib –ltextfh
NET-COBOL Compiler
When using a COBOL compiler that does not support external file handlers, such as .NET COBOL compiler, pre-processing with ofcbppf is required for file I/O and OpenFrame tcobfh (Tmax COBOL File Handler) module must be linked during compilation.
When using the .NET COBOL compiler, link the libaimap.so, libaimacpin.so, and libndbdml.so libraries after pre-processing with ofcbppf.
The following example uses the NET COBOL compiler.
cobol -dy -shared -WC",STD1(JIS1),NOALPHAL,SRF(FIX),NSPCOMP(ASP),DLOAD,RSV(V125),CHECK,MODE(CCVS)" -o COBSAMPLE.so COBSAMPLE.cob -L$OPENFRAME_HOME/lib -laimap -laimacpin -lndbdml
For more information about compilation commands, refer to the respective manual for each compiler.
To dynamically apply a new version of a program or module to an OpenFrame system, use the dlupdate command-line tool. The dlupdate tool first backs up existing module that are being used by running programs and applications so that they can continue to use it. It directs newly executed programs and applications to use the new module.
The following describes the usage of the dlupdate tool.
dlupdate source_path dataset_name
| Parameter | Description |
|---|---|
source_path | Path to the module being applied to the system. |
dataset_name | PDS data set used by the existing module on the system. |
Modules that are backed up with dlupdate can be removed with the dlclean tool. Even if dlclean is not explicitly executed by the user, it will be executed automatically during periods with no system load in order to remove backed up data sets.
For more information about the dlupdate and dlclean tools, refer to OpenFrame Tool Reference Guide.
This section describes compiling and deploying PL/I batch applications for migration.
When using an OpenFrame PL/I compiler that supports external file handlers, data set I/O can be performed by linking with the libtextfh.so library of the OpenFrame textfh (Tmax External File Handler) module and specifying the function name to call during compilation. In this case, pre-processing for file I/O is not required.
The following example uses the OpenFrame PL/I compiler.
$ ofpli -o PLITEST.so PLITEST.pli -L$OPENFRAME_HOME/lib -ltextfh
OpenFrame PL/I does not provide a pre-processing tool, but it supports the --save-temps option to create .mp or .pp interim files depending on source files. PL/I applications include main programs and subprograms. For PL/I applications called by JCL, OPTIONS(MAIN) must be written.
OpenFrame PL/I allows you to specify options for each system type. Use --system-cics for applications that run in OSC, and use --system-ims for applications that run in OSI.
The dlupdate tool is used to dynamically apply new applications, or new versions of an existing application, to the OpenFrame/Batch system. The dlupdate tool is able to update an application that is in use by making a backup of the existing application before applying the update to the system.
The following describes the usage of the dlupdate tool.
dlupdate source_path dataset_name
| Parameter | Description |
|---|---|
source_path | Path to the module being applied to the system. |
dataset_name | PDS data set used by the existing module on the system. |
Applications that are backed up using dlupdate can be removed with the dlclean tool. Even if dlclean is not explicitly executed by the user, it will be executed automatically during system idle periods to remove backed up data sets.
For more information about the dlupdate and dlclean tools, refer to OpenFrame Tool Reference Guide.