Table of Contents
This chapter describes the process of migrating legacy system resources such as CICS maps, CICS resources, and JCL.
You cannot use resources that are directly copied from mainframe in OpenFrame without character conversion. The EBCDIC character set used by mainframes is very different from the ASCII character set used by UNIX and OpenFrame. Therefore, the first step in all resource migration procedures must be to convert the source code from EBCDIC to ASCII.
This guide focuses on how to convert user-written source code such as COBOL from EBCDIC to ASCII.
Although EBCDIC-to-ASCII conversion is required for all resource, the actual migration process is resource-specific.
The method for converting EBCDIC data to ASCII data depends on the resource type. For non-VSAM datasets, there is no separate conversion step; conversion is performed internally using a tool called dsmigin.
You can use the --convert-only option to perform EBCDIC-to-ASCII conversion. dsmigin can also be used to convert EBCDIC data from various resources to ASCII using the --source option, which is mainly used to convert application source code (in text format) from EBCDIC to ASCII.
The following example uses dsmigin to convert a resource file. SRCFILE is converted to ASCII using 80 bytes as a single line. Since EBCDIC characters use IBM290, any unnecessary SOSI characters are replaced with blank spaces after the conversion. The results are output to the CONVFILE in line units separated by the newline character.
$ dsmigin SRCFILE CONVFILE -e JP -l 80 -sosi 2 -C -S -n
The following describes options that can be used when processing resource files with dsmigin.
| Option | Description |
|---|---|
–e | Source language. (US, KR, JP, JAK) |
–l | Line length for a source file with fixed-length records. |
–sosi | Method for handling SOSI characters. |
–C | Option to only perform EBCDIC to ASCII conversion. |
–S | Indicates that the EBCDIC file to convert is a general source code (for COBOL, use –cob option). |
–n | Option to use the newline character as line separator after conversion. |
For more information about different options supported by the dsmigin tool, refer to OpenFrame Tool Reference Guide.
The following example converts a BMS map file.
of1atmaxs4:of1a]$ dsmigin MSCMAP01 MSCMAP01.map -e JP -l 80 -sosi 2 -S -n >> M 2019-03-17 17:27:57 [026595:dsmigin_main.c:378] (MIG0001M) =====< DSMIGIN START >===== source file : MSCMAP01 dataset name: MSCMAP01.map member name : unit: volume: schema file : encoding type: JP record length: 80 record format: L dsorg: delimiter: DSMIGIN: (record count = 158) >> M 2019-03-17 17:27:58 [026595:dsmigin_main.c:1255] (MIG0002M) =====< DSMIGIN FINISH >====
Before conversion.
<MSCMAP01>
. . . AÆEOAÆ@×Oa~Mðoko÷]kOAOCaE~ðokAaaUA~AaOE×@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@AÆEOAÆ@×Oa~Mðokoo]kOAOCaE~ðn@@@@@@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@@@@@@@NOððð÷@@@AÆEOAÆ@×Oa~Mðokðo]kOAOCaE~ðokAaaUA~AaOE ×@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@NOðððø@@@AÆEOAÆ@×Oa~Mðokðo]kOAOC aE~ookAaaUA~AaOE×k×a~ø@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AÆEOAÆ@×Oa~ Mðokou]kOAOCaE~ðokAaaUA~MAaOE×kAUa]k@@@@@@@@@@@@@@@c@@@@@@@@@@@@@@@@@@@ @@@@×a~økEOEaEAO~}BO}@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@NOð ððu@@@AÆEOAÆ@×Oa~Mðokoo]kOAOCaE~ðokAaaUA~AaOE×@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@@NOððnð@@@AÆEOAÆ@×Oa~Mðokoo]kOAOCaE~ookAaaUA~AaOE×k×a~ø @@@@@@@@@@@@@@@@@@@@@@@@@@NOððnn@@@AÆEOAÆ@×Oa~Mðokðo]kOAOCaE~ðokAaaUA~ AaOE×@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@NOððno@@@AÆEOAÆ@×Oa~Mðokðo]kOAOCaE ~ookAaaUA~AaOE×k×a~ø@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@AÆEOAÆ@×Oa~ Mðokou]kOAOCaE~ðokAaaUA~MAaOE×kAUa]k@@@@@@@@@@@@@@@c@@@@@@@@@@@@@@@@@@@ @@@@×a~økEOEaEAO~}BO}@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@NOð ðno@@@AÆEOAÆ@×Oa~Mðokoo]kOAOCaE~ðokAaaUA~AaOE×@@@@@@@@@@@@@@@@@@@@@@ @@@@@@@@@NOððno@@@AÆEOAÆ@×Oa~Mðokoo]kOAOCaE~ookAaaUA~AaOE×k×a~ø . . .
After conversion.
<MSCMAP01.map>
BGLOGO DFHMSD TYPE=&SYSPARM, X
LANG=COBOL, X
MODE=INOUT, X
CTRL=FREEKB, X
STORAGE=AUTO, X
TIOAPFX=YES
*
BGLOGO DFHMDI SIZE=(24,80),LINE=1,COLUMN=1
*
DFHMDF POS=(2,2),LENGTH=37,ATTRB=(NORM,PROT), X
HILIGHT=BLINK, X
INITIAL='*** WELCOME TO OPENFRAME ONLINE ***'
DFHMDF POS=(5,3),LENGTH=73,ATTRB=(BRT,PROT), X
COLOR=YELLOW, X
INITIAL=' ***** /****** /*******/** /**/*******/******X
/*** /**/**/**/*******'
DFHMDF POS=(6,3),LENGTH=73,ATTRB=(BRT,PROT), X
COLOR=YELLOW, X
INITIAL='/*******/*******/*******/*** /**/*******/******X
* /***** /********/*******'
DFHMDF POS=(7,3),LENGTH=73,ATTRB=(BRT,PROT), X
COLOR=YELLOW, X
INITIAL='/**///**/**///**/**//////*** /**/**//////**///*X
*/**///**/********/**/////'
DFHMDF POS=(8,3),LENGTH=73,ATTRB=(BRT,PROT), X
COLOR=YELLOW, X
INITIAL='/** /**/** /**/** /****/**/** /** /*X
*/** /**/**/**/**/** '
DFHMDF POS=(9,3),LENGTH=73,ATTRB=(BRT,PROT), X
COLOR=YELLOW, X
INITIAL='/** /**/*******/*******/*******/*******/******X
*/*******/**/**/**/*******'
DFHMDF POS=(10,3),LENGTH=73,ATTRB=(BRT,PROT), X
COLOR=YELLOW, X
INITIAL='/** /**/******//*******/*******/*******/******X
//*******/**/**/**/*******'
DFHMDF POS=(11,3),LENGTH=73,ATTRB=(BRT,PROT), X
COLOR=YELLOW, X
INITIAL='/** /**/**//// /**//////**/****/**//////**///*X
*/**///**/**/**/**/**/////'
DFHMDF POS=(12,3),LENGTH=73,ATTRB=(BRT,PROT), X
COLOR=YELLOW, X
INITIAL='/** /**/** /** /** /***/** /** /*X
*/** /**/**/**/**/** '
DFHMDF POS=(13,3),LENGTH=73,ATTRB=(BRT,PROT), X
COLOR=YELLOW, X
INITIAL='/*******/** /*******/** /***/** /** /*X
*/** /**/**/**/**/*******'
When migrating a CICS application that uses the CICS BMS function, you must also migrate its map information file.
Since OSC cannot use the map file in its original format, you must convert the map source code from EBCDIC to ASCII and then compile it using the OSC compiler.
The conversion of map source code from EBCDIC to ASCII is comparable to other resource code conversions. However, the dsmigin tool may not convert the code correctly if the host map file in EBCDIC includes double byte characters, such as Korean or Japanese, or programming symbols, such as (PS=X'F8'). This is because dsmigin cannot recognize the PS element in the BMS map macro syntax.
The mscadjust tool can solve this problem. This tool receives two files: the source map file (in EBCDIC code) and the ASCII map file preprocessed by the mscasmc tool, and finds any conversion errors generated by dsmigin and notifies the user. The user can select to convert the flagged fields as 2-byte code or keep then as 1-byte code.
The following example uses mscadjust to convert a map source file.
$ mscadjust -o OUTPUT.adj NA810SM NA810SM.map.atm [MSCADJUST] input ascii code map : NA810SM.map.atm [MSCADJUST] input ebcdic code map : NA810SM * before: [.*.* ...|D.. ....X .(...7.....) *.* ] * after: [＊＊ 外注訂正 店指定 （入力画面） ＊＊ ] * do you want to change? (Yes:(Enter/Y/y), No:(N/n))Y --------------------------------------------------- * before: [....] * after: [法人] * do you want to change? (Yes:(Enter/Y/y), No:(N/n)) --------------------------------------------------- * before: [...>] * after: [店№] * do you want to change? (Yes:(Enter/Y/y), No:(N/n)) --------------------------------------------------- * before: [ . ..... .R(..> ] * after: [ 区 発注日 伝票№ ] * do you want to change? (Yes:(Enter/Y/y), No:(N/n)) --------------------------------------------------- * before: [ ..... ......3 ] * after: [ 取引先 取引先名 ] * do you want to change? (Yes:(Enter/Y/y), No:(N/n)) $
After converting the map code with mscadjust, you must compile it by using mscmapc and then deploy it.
The following example compiles a map by using mscmapc.
$ mscmapc OUTPUT.adj >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> * input map : OUTPUT.map * copybook : [/home/oframe/OpenFrame/osc/map/symbolic/NAMS/NA810SM.cpy] create. * binary image : [/home/oframe/OpenFrame/osc/map/physical/NAMS_NA810SM_CS.csym] create. <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< $
For more information about mscasmc or mscadjust, refer to OpenFrame Tool Reference Guide.
For more information about compiling and deploying a map, refer to OpenFrame OSC Mapping Support Guide.
To run CICS applications that use CICS system resources, you must define the resources in the CICS system. When you migrate CICS applications to an OpenFrame/OSC environment, you also need to migrate the resource definitions to the OSC system.
Currently, OSC supports the CONNECTION, FILE, JOURNALMODEL, PROGRAM, TDQUEUE, TERMINAL, TRANSACTION, TSMODEL, and TYPETERM resources. In order to use these resources in OSC, you must first extract the resource definitions from the CICS system and then register them in the OSC SD data set of the OSC system using the oscsdgen tool.
Earlier versions of CICS, which use resource control tables instead of resource definitions, require further processing to convert the resource control tables into resource definitions. OSC provides a tool that can convert destination control tables (DCT) and journal control tables (JCT) into the TDQUEUE and JOURNALMODEL resource definitions.
The following example converts a DCT to a TDQUEUE resource definition by using the oscdct2rd tool.
oscdct2rd –g OSCGROUP DCT.dat TDQUEUE.dat
The following example converts a JCT to a JOURNALMODEL resource definition by using the oscjct2rd tool.
oscjct2rd –g OSCGROUP JCT.dat JOURNALMODEL.dat
Resource definition fields that are not supported or used by OSC are ignored by oscsdgen during the resource registration process.
The following example registers resource definitions (stored in resources.dat) in OSC00001, an OSC SD data set.
$ oscsdgen -r OSC00001 resources.dat
For more information about how to use the oscdct2rd, oscjct2rd and oscsdgen tools, refer to OpenFrame Tool Reference Guide.
For more information about the resource field properties supported by OSC, refer to OpenFrame OSC Resource Definition Guide.
Generally, JCL migration simply involves extracting JCLs from the mainframe JES environment and converting them from EBCDIC to ASCII. Usually, this enables the JCLs to be run in an OpenFrame system without modification.
However, when using a 3rd party utility, there is a difference in the way SYSIN parameter is passed in the JCL between mainframe and Unix. Therefore, the JCL may need to be modified to interface properly with the third-party utility. Some utility functions are not supported by OpenFrame and you must modify some utility-related code to use them in OpenFrame.
This section only provides an overview of migrating the most commonly used utility, DB2.
Within mainframes the host DB2 creates a control file after performing an UNLOAD that serializes and downloads data stored in DB2 to a file. The control file is then used to perform a LOAD that restores the extracted file on DB2 with the data and file downloaded by UNLOAD. In Unix, DB2 HPU creates the control files needed to perform UNLOAD and LOAD.
There are some syntax differences between mainframe and UNIX control files, so a control file created by mainframe cannot be used directly by DB2 HPU on Unix. Therefore, the LOAD control statement specified as INSTREAM in the SYSIN of the LOAD JCL must be converted to ASC FORMAT METHOD L. The control file must also be converted to use the DB2 HPU syntax for the Unix system.
The following example converts a mainframe DB2 LOAD control statement to a Unix UDB LOAD control statement.
Before Conversion
LOAD DATA RESUME YES LOG NO INDON SYSREC00 INTO TABLE LNID2LC0.TLCP0 ( CIJUN_YM POSITION( 1 ) CHAR( 6) , ORG_CD POSITION( 7 ) CHAR( 7) , SNPM_SORT_GB POSITION( 14 ) CHAR( 1) , YUJICHASU POSITION( 15 ) CHAR( 3) , DSBHR_10 POSITION( 18: 25) DECIMAL , YJBHR_10 POSITION( 26: 33) DECIMAL , DSBHR_30 POSITION( 34: 41) DECIMAL , YJBHR_30 POSITION( 42: 49) DECIMAL , DSBHR_60 POSITION( 50: 57) DECIMAL , YJBHR_60 POSITION( 58: 65) DECIMAL , DSBHR_90 POSITION( 66: 73) DECIMAL , YJBHR_90 POSITION( 74: 81) DECIMAL )
After Conversion
LOAD FROM $SYSREC00 OF ASC MODIFIED BY STRIPTBLANKS NULLINDCHAR=? BINARYNUMERICS PACKEDDECIMAL CODEPAGE=970 RECLEN=81 METHOD L ( 1 6, 7 13, 14 14, 15 17, 18 25, 26 33, 34 41, 42 49, 50 57, 58 65, 66 73, 74 81) NULL INDICATORS ( 0,0,0,0,0,0,0,0,0,0,0,0 ) INSERT INTO LNID2LC0.TLCP0 GIJUN_YM, ORG_CD, SNPM_SORT_GB, YUMICHASU, DSBHR_10, YJBHR_10, DSBHR_30, YJBHR_30, DSBHR_60 YJBHR_60 DSBHR_90 YJBHR_90)