Chapter 19: Migrating from Mainframe Express 1.1

This chapter describes differences between Mainframe Express 1.1 and Mainframe Express 2.0 that might require you to make alterations in existing applications that you are migrating, or to change familiar methods of working.

19.1 Overview

The overall product shape of Mainframe Express 2.0 is very similar to that of 1.1.

19.2 Details

19.2.1 Assembler Option

Going from 1.1 to 2.0:

390 load modules do not need to be recompiled or relinked. However, if an application runs in AMODE(31), then relinking the 390 modules will mark them as 31-bit, and in Mainframe Express 2.0 they will load above the 16 MB line. This can be good news and bad news: if the code is indeed 31 bit compatible it should work fine and it will reduce 24-bit virtual storage constraint which some large applications are running into on Mainframe Express 1.1; if the code is really 24-bit code, then it will abend, requiring the module to be relinked as a 24-bit module.
The 390 load module now controls the AMODE and RMODE setting at load time allowing mixed modes whereas in MFE 1.1 the AMODE was fixed by project setting.
Although they are no longer required, it is not necessary to remove "//" from link file commands such as INCLUDE or NAME.

Going back from 2.0 to 1.1:

Any link command files created for R2.0 without the leading "//" will require adding them.
Any Assembler 390 modules linked via autolink or via the "Link" tab with AMODE(31) setting will be marked as 31 bit but will revert to loading below the 16 MB line in Mainframe Express 1.1 which could cause applications which run on Mainframe Express 2.0 to run out of virtual 24 bit memory when running on 1.1.

19.2.2 Catalog

All users of a shared catalog must be using the same version of Mainframe Express.

The data structures that underly the Spool View have been expanded and enhanced in Mainframe Express 2.0 to provide more filtering and faster access. To facilitate these changes, the data contained in the spool file has been expanded compared to Mainframe Express 1.1. (The spool file is mvsspool.dat - In 1.1, this dataset was in the directory pointed to by the "Allocation Folder" setting on the Catalog Tab of the Project Settings Dialog.)

Current users of Mainframe Express 1.1 will have a seamless upgrade to the spool used in Mainframe Express 2.0. The first time you use a Mainframe Express project from 1.1, all entries in the 1.1 spool are migrated into the 2.0 spool file. (This spools file is mvsspl01.data - this dataset is now on the same path as the System Catalog. This setting can viewed on the Catalog Tab of the Project Settings dialog box). Once all of the entries from the 1.1 spool have been migrated forward, the mvsspool.dat file will be renamed to mvsspool.1.1.

If you are using a shared catalog and spool for a given project (or projects) you should not try to share the catalog and spool between computers running Mainframe Express 1.1 and computers running Mainframe Express 2.0. This will cause inconsistent viewing of Spool Output on 1.1. Mainframe Express 2.0 will migrate the new entries forward each time the Mainframe Express environment is invoked. This would cause the machines running 1.1 to lose any existing spool output each time 2.0 starts. It would also prevent you from reverting from 2.0 to 1.1.

If you must revert from Mainframe Express 2.0 to Mainframe Express 1.1, you can do so by renaming the mvsspool.1.1dataset to mvsspool.dat. You will lose any entries that were contained in the 2.0 Spool after conversion from 1.1.

19.2.3 IMS Option

The character-based configuration tool has been replaced by a Properties dialog box. To configure IMS, you no longer click IMS on the Tools menu and then click Configuration. Instead, right-click IMS System in the left-hand pane of the IMS View of the Project View, then click Properties on the popup menu.

19.2.4 Project

If you have a project created and built using Mainframe Express 1.1, and you open it in Mainframe Express 2.0, you will see that all COBOL programs have their status shown as "Out of Date". You can in fact run the application without rebuilding, but the debug information files are in the wrong format for Mainframe Express 2.0. Therefore, if you want to debug a project built using Mainframe Express 1.1, you must first rebuild it.

19.2.5 SQL Option

SQL Option for Mainframe Express 2.0 has two major changes:

Full international EBCDIC support that complements the IDE
A new XDB External Compiler Module which is more tightly integrated with the IDE than former XDB COBOL precompilers

19.2.5.1 Migrating a Database Location

Mainframe Express nows provides full compatibility between the IDE and XDB locations, emulating a complete international EBCDIC solution.

In this respect, migrating from the SQL Option in Mainframe Express 1.1 is very similar to migrating from the XDB add-on for Workbench. Please read the first part of the section Migrating a Database Location in the chapter Migrating from XDB, and then return here to read the following sections.

19.2.5.2 ASCII (OEM) / ANSI Locations

Follow the instructions in the section ASCII (OEM) / ANSI Locations in the chapter Migrating from XDB.

19.2.5.3 EBCDIC Locations in Mainframe Express 1.1

XDB Technology supported two types of EBCDIC locations in the Mainframe Express 1.1 environment. We refer to these locations as default EBCDIC and INTL EBCDIC.

Default EBCDIC	Created in Mainframe Express 1.1, using the standard create location sort sequence ebcdic command.
INTL EBCDIC	Also created in Mainframe Express 1.1, but using the new-style *create location sort sequence xxxxx* ebcdic** command.

19.2.5.3.1 Default EBCDIC Location

To access this type of location from Mainframe Express 2.0:

Set the NLS setting in the IDE to the EBCDIC setting you used in Mainframe Express 1.1.

Add the line oemcp=nnnn to the [Client] section of the xdb.ini file, getting nnnn from the following table:

Mainframe Express 1.1 EBCDIC Setting	OEMCP Setting
US (default)	4133
DUTCH ,PORTUGUESE	4133
FRENCH	4393
SPANISH	4380
ITALIAN	4376
UK	4381
DANISH, NORWEGIAN	4373
SWEDISH, FINNISH	4374
GERMAN, AUSTRIAN	4369
INTERNATIONAL	4596

For example, for default (US):

oemcp=4133

If you want to access the location remotely from Mainframe Express 2.0, follow the instructions in the section Using a Remote Location in the chapter Migrating from XDB.
Make sure that Mainframe Express 2.0's XDB Server is down, and Mainframe Express 1.1's XDB server is up.
If you want to place the location in the Mainframe Express 2.0 environment, follow the instructions in the section Making a Remote Location Local in the chapter Migrating from XDB.
When you insert the SYSLOCALS and SYSLOCATIONS records, use the corresponding MAINTAIN record as your guide for field values - MAINTAIN is an example of the record contents for a default EBCDIC location.

Eventually, you will want to change this old-style location to the Mainframe Express 2.0 format. To convert:

Make a backup copy of your location.
Log into SQL Wizard with a super-user authority userid.

Issue the command:

alter location zzzzz to codepage yyyy with sort sequence xxxxx ebcdic

where zzzzz is the name of the location, xxxxx is one of:

DUTCH	FRENCH
SPANISH	ITALIAN
UK	DANISH
SWEDISH	GERMAN
PORTUGUESE	US
TURKISH

and yyyy is one of:

Mainframe Express EBCDIC Setting	`yyyy` (if OEM=850)	`yyyy` (if OEM=437)
DUTCH, US, PORTUGUESE	8229	4133
FRENCH	8489	4393
SPANISH	8476	4380
ITALIAN	8472	4376
UK	8477	4381
DANISH, NORWEGIAN	8469	4373
SWEDISH, FINNISH	8470	4374
GERMAN, AUSTRIAN	8465	4369
INTERNATIONAL	8692	4596

For example, for a location called personnel in a US environment (with OEM codepage 437), issue the command:

alter location personnel to codepage 4133 with sort sequence us ebcdic

Your location will then become fully compatible with Mainframe Express 2.0, and will use a standard EBCDIC collating sequence. It can then be accessed by Mainframe Express 1.1 INTL and Mainframe Express 2.0. We strongly recommend that Mainframe Express 1.1 applications do not use this location after it is altered, unless you have installed the international FixPack.

19.2.5.3.2 INTL EBCDIC Location

To access this type of location from Mainframe Express 2.0:

Set the NLS setting in the IDE to the EBCDIC setting you used in Mainframe Express 1.1.
If you want to access the location remotely from Mainframe Express, follow the instructions in the section Using a Remote Location in the chapter Migrating from XDB.
Make sure that Mainframe Express 2.0's XDB Server is down, and the Mainframe Express 1.1's XDB server is up.
If you want to place the location in the Mainframe Express 2.0 environment, follow the instructions in the section Making a Remote Location Local in the chapter Migrating from XDB.
If you have an old-style XDB EBCDIC location, then when you insert the SYSLOCALS and SYSLOCATIONS records, use the corresponding MAINTAIN record as your guide for field values - MAINTAIN is an example of the record contents for a default EBCDIC location.

If you have a new-style XDB EBCDIC location, you should just use the records that exist in the Mainframe Express 1.1 system location as your guide for field values.

If you have a new-style XDB EBCDIC location, you do not need to convert your location. These locations are already compatible with the Mainframe Express 2.0 format.

If you have a old-style XDB EBCDIC location, you will want to change it to the Mainframe Express 2.0 format. To convert:

Make a backup copy of your location.
Log into SQL Wizard with a super-user authority userid.

Issue the commands:

set location zzzzz to codepage yyyy alter location zzzzz to sort sequence xxxxx ebcdic

where zzzzz is the name of the location, yyyy is your OEM codepage (usually codepage 850), and xxxxx is one of:

DUTCH	FRENCH
SPANISH	ITALIAN
UK	DANISH
SWEDISH	GERMAN
PORTUGUESE	US
TURKISH

Your location will then be fully compatible with Mainframe Express 2.0, and will use a standard EBCDIC collating sequence. It can then be accessed by Mainframe Express 1.1 INTL and Mainframe Express 2.0.

19.2.5.4 Migrating Environments to Mainframe Express 2.0

If you are upgrading your Mainframe Express installation to Mainframe Express 2.0, you can skip this section. If you are installing Mainframe Express 2.0 alongside Mainframe Express 1.1 and you want to move your existing configuration to Mainframe Express 2.0, follow the instructions in the section Migrating Environments to Mainframe Express in the chapter Migrating from XDB.

19.2.5.5 XDB ECM Differences

Some directives are now ignored since they don't do anything in the XDB External Compiler Module (ECM) that SQL Option now uses. However, the ECM will continue even if it doesn't recognize an obsolete directive. It just displays a message indicating the directive is ignored.