Chapter 17: Migrating IMS Applications

This chapter describes the process you should use to migrate your IMS applications from the mainframe to Enterprise Server and lists issues you might encounter while doing so.

Migration Procedure

  1. Download the following application files from the mainframe to your PC:
    1. Source (program + PSB/DBD + MFS)
    2. Stage 1 definition
    3. Unloaded database data
  2. Create a Mainframe Express project containing these downloaded files:
    1. Add the source files to the project.
    2. Build the project.
    3. Load the database data in EBCDIC.
    4. Import the Stage 1 files.
    5. Create segment layout (.slf) files for all segments.

    See your Mainframe Express documentation for information on performing these operations.

  3. Test the project.
  4. Remove any unsupported features and languages, including Assembler exits.

  5. Move the project to Net Express using the Move Project to NetX tool provided with the Migration Development Kit (MDK). See your Enterprise Server Migration Step by Step Guide for more information.
  6. Configure Enterprise Server for IMS support. See the chapter Configuring MTO-enabled Enterprise Servers for IMS for more information.
  7. Configure Enterprise Server for CICS and JCL support as required. See the chapters Configuring MTO-enabled Enterprise Servers for CICS and Configuring MTO-enabled Enterprise Servers for JCL for more information.
  8. Import the Stage 1 files. See the section Importing Transactions in the chapter Configuring MTO-enabled Enterprise Servers for IMS for more information.
  9. Generate the DBDs, PSBs and MFSs. See the chapter Developing IMS Applications in your Mainframe Transaction Option Developer's Guide for more information.
  10. Load or zeroload the databases, converting them from EBCDIC to ANSI if necessary. See the chapter Developing IMS Applications in the your Mainframe Transaction Option Developer's Guide for more information.

Migration Issues

Future versions of Enterprise Server for IMS will support the running of applications compiled using the EBCDIC character set and dependent on the EBCDIC collating sequence. Currently, however, all applications must use the ASCII character set.

When migrating from EBCDIC to ASCII, you may encounter problems where character literals have been used in assignments and comparisons. The binary value represented by a particular character depends on the character set used: an 'A' is equivalent to the hexadecimal value C1 when using EBCDIC, but 41 when using ASCII.

Special Characters in MFS Attributes

Issue

If you have used character literals to specify the values of MFS attributes, the resulting values will be different when you compile using ASCII from those that you obtain when compiling using EBCDIC. For example, the two code fragments below give the same results when compiling with the EBCDIC character set. When using ASCII, however, the first example will give different behavior: '{A' now translates as hexadecimal 7B41 rather than C0C1.

Example 17-1: Attributes specified using character literals

05 ATTRIBUTE-VARIABLES.
   10 CURSOR-ATTR          PIC X(2) VALUE '{A'. 
   10 ERROR-ATTR           PIC X(2) VALUE '{I'.
   10 OK-ATTR              PIC X(2) VALUE ' A'.
   10 PROT-ATTR            PIC X(2) VALUE ' 1'.

Example 17-2: Attributes specified using hexadecimal/binary notation

05 ATTRIBUTE-VARIABLES.
   10 CURSOR-ATTR          PIC X(2) VALUE X'C0C1'.
   10 ERROR-ATTR           PIC X(2) VALUE X'C0C9'.
   10 OK-ATTR              PIC X(2) VALUE X'00C1'.
   10 PROT-ATTR            PIC X(2) VALUE X'00F1'.
Resolution

To facilitate the migration of programs, you can specify at the level of the transaction or the system whether MFS attribute values have been coded using character or binary notation. (The value specified for the transaction definition overrides that for the system.)

How to

Where you specify that the attribute values have been coded as character literals, Enterprise Server will automatically translate the values of MFS attributes to those that would be used if the program were compiled as EBCDIC. For example: the hexadecimal 7B41 value produced by assigning '{A' to an attribute and compiling with ASCII, will be converted to the correct C0C1 value. Where you specify that attribute values have been coded as binary data, Enterprise Server will take no action.

As an alternative solution, edit your programs to use x'nn' notation (as used in the second example above) instead of characters.

Null MFS Fields

Issue

On the mainframe, the MFS null character, which is used to truncate fields, is defined as being x'3F'. However, in the ASCII character set, this represents the question mark (?) character. Therefore, where an ASCII application uses the question mark character in display data (whether held as literals within the program or obtained from an external source) an alternative null character must be chosen.

Resolution

Enterprise Server allows you to specify at the level of the transaction or the system which character is the null character. The default for this is x'1A'.

How to

You must also edit any programs that use x'3F' to use the new null character instead.


Copyright © 2006 Micro Focus (IP) Ltd. All rights reserved.