리소스 마이그레이션
본 장에서는 CICS 맵, CICS 리소스, JCL을 마이그레이션하는 방법에 대해 기술한다.
1. EBCDIC에서 ASCII로 변환
OpenFrame 마이그레이션 절차는 리소스 종류에 따라 다양하다. 단, EBCDIC 코드가 포함된 리소스를 ASCII 코드가 포함된 리소스로 변환하는 작업은 모든 리소스의 마이그레이션 절차에서 동일하게 적용된다.
코드 변환은 Mainframe의 기본 문자 집합과 개방형 환경의 문자 집합이 다르기 때문에 발생하는 작업으로 리호스팅을 위한 마이그레이션 과정에서는 필수 작업이다.
본 절에서는 사용자가 작성한 COBOL 소스같은 별도의 EBCDIC에서 ASCII로 코드 변환하는 것을 위주로 설명한다.
|
EBCDIC에서 ASCII로의 변환 절차가 모든 리소스 변환 과정에서 필수 절차이기는 하지만, 실제 마이그레이션 과정에서의 변환 작업은 리소스별로 다르다는 점에 주의하도록 한다. |
변환 방법
EBCDIC 데이터를 ASCII 데이터로 변환하는 작업은 리소스에 따라 다른데 Non-VSAM 데이터셋의 경우 EBCDIC 데이터를 ASCII 데이터로 변환하는 별도의 절차가 존재하지 않고 dsmigin이라는 툴을 이용하여 내부적으로 변환이 진행된다.
OpenFrame에서는 EBCDIC 데이터를 ASCII 데이터로 변환만하기 위해서 dsmigin 툴의 --convert-only 옵션을 제공한다. dsmigin은 또한 --source 옵션을 사용하여 여러가지 리소스의 EBCDIC 데이터를 ASCII로 변환할 때 사용할 수 있는데 주로 애플리케이션의 텍스트 형태로 된 원본 파일의 EBCDIC 데이터를 ASCII 데이터로 변환할 때 사용된다.
다음은 원본 파일에 주로 사용할 수 있는 dsmigin 툴의 예제이다. SRCFILE을 80Byte를 하나의 라인으로 인식하여 ASCII로 변환할 때 원본 EBCDIC 문자가 IBM290을 사용하고 있다는 것을 감안하여 변환한다. 변환 후 불필요해진 SOSI 문자 자리에 공백(white space)을 대체하고 변환된 하나의 라인 단위로 CONVFILE을 생성하되 라인의 구분은 줄바꿈 문자(newline)를 사용하여 수행한다.
$ dsmigin SRCFILE CONVFILE -e JP -l 80 -sosi 2 -C -S -n다음은 해당 옵션에 대한 설명이다.
| 옵션 | 설명 |
|---|---|
–e |
변환하려는 원본 데이터셋의 언어를 선택한다. (US, KR, JP 및 JAK 지원) |
–l |
변환하려는 원본 데이터셋이 고정 길이 레코드 포맷일 때 한 라인의 크기를 지정한다. |
–sosi |
변환 후 SOSI 문자 처리의 옵션을 의미한다. |
–C |
EBCDIC 데이터를 ASCII 데이터로 변환만 할 때 사용한다. |
–S |
변환하려는 EBCDIC 파일이 일반 소스일 때 사용한다. (COBOL일 경우 -cob 옵션 사용) |
–n |
변환 후 라인 구분자로 줄바꿈 문자(Newline)를 사용하게 한다. |
|
dsmigin 툴에서 지원하는 다양한 옵션에 대한 자세한 내용은 OpenFrame Base "툴 참조 안내서"를 참고한다. |
다음은 BMS 맵 파일을 변환하는 예이다.
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 >====
변환 전 코드는 다음과 같다.
<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~ø . . .
변환 후 코드는 다음과 같다.
<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
*/** /**/**/**/**/*******'
2. CICS 맵 마이그레이션
CICS의 BMS 기능을 사용하는 CICS 애플리케이션 프로그램을 OSC 시스템으로 마이그레이션할 때에는 CICS 애플리케이션 프로그램에서 사용하는 맵 정보가 함께 마이그레이션되어야 한다.
OSC 시스템에서는 CICS에서 사용하는 맵 실행 파일을 그대로 사용할 수는 없기 때문에 맵 소스 코드를 EBCDIC에서 ASCII로 변환해준 후에 OSC 시스템에서 제공하는 컴파일러로 컴파일해야 한다.
맵 소스 코드의 EBCDIC에서 ASCII로의 코드 변환은 다른 리소스들의 코드 변환과 동일하다. 그러나 EBCDIC 으로 작성된 호스트 맵 파일에 1Byte 문자 외에 한국어나 일본어 등의 2Byte 데이터가 섞여있고 맵의 필드 정의에 programmed symbol 관련 항목(PS=X’F8’ 등)이 설정된 경우 dsmigin 툴을 통한 변환이 정상적으로 진행되지 않을 수 있다. 이는 dsmigin 툴이 BMS 맵 매크로 문법 중 PS 항목을 인식하지 못하여 해당 필드를 적절하게 변환하지 못하기 때문이다.
이를 보정하기 위해서 OSC 시스템에서는 mscadjust라는 툴을 함께 제공하고 있다. 이 툴은 EBCDIC으로 작성된 원본 맵 파일과 ASCII로 변환된 맵 파일을 mscasmc 툴로 전처리한 결과 파일 2개를 입력받아 dsmigin에서 제대로 변환되지 않았을 가능성이 있는 필드들을 찾아서 사용자에게 알려준다. 사용자는 해당 필드를 2Byte 코드로 인식해서 변환하거나 1Byte 코드로 인식해서 변환하도록 선택할 수 있다.
다음은 mscadjust를 사용하여 맵을 변환하는 화면 예제이다.
$ 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))
$mscadjust를 통해서 수정된 맵 코드는 mscmapc 툴을 통해서 컴파일한 후 배포한다.
다음은 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.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
$
|
3. CICS 리소스 마이그레이션
CICS에서 제공하는 시스템 리소스를 사용하는 CICS 애플리케이션이 정상적으로 작동하기 위해 사용자는 필요한 리소스 정의를 CICS 시스템에 설정한다.
마찬가지로 CICS 애플리케이션이 OSC 시스템으로 마이그레이션 된 후에 정상적으로 작동하기 위해 CICS 시스템에서 사용하는 리소스 정의를 OSC 시스템으로 마이그레이션해야 한다.
CICS 시스템에서 사용하는 다양한 리소스 정의 중 OSC 시스템에서 지원 가능한 리소스 정의는 CONNECTION, FILE, JOURNALMODEL, PROGRAM, TDQUEUE, TERMINAL, TRANSACTION, TSMODEL, TYPETERM 등이 있다. 이러한 리소스를 OSC 시스템에서 사용하기 위해서는, CICS 시스템으로부터 위의 타입에 해당하는 리소스의 정의를 얻어온 후, 이 리소스 정의 정보를 oscsdgen 툴을 이용해서 OSC 시스템의 OSC SD 데이터셋에 등록해야 한다.
구 버전의 CICS 시스템에서는 리소스 정의 대신 리소스 컨트롤 테이블을 사용하는 경우가 있다. 리소스 컨트롤 테이블의 경우는 OSC 시스템에서 지원 가능한 리소스 정의로 변환하는 추가적인 과정이 필요하다. OSC 시스템에서는 구 버전의 리소스 컨트롤 테이블 중 DCT(Destination Control Table)와 JCT(Journal Control Table)에 대해서 TDQUEUE와 JOURNALMODEL 리소스 정의로 변환하는 툴을 제공하고 있다.
다음은 DCT를 TDQUEUE 리소스 정의로 마이그레이션하는 oscdct2rd 툴의 예이다.
oscdct2rd –g OSCGROUP DCT.dat TDQUEUE.dat
다음은 JCT를 JOURNALMODEL 리소스 정의로 마이그레이션하는 oscjct2rd 툴의 예이다.
oscjct2rd –g OSCGROUP JCT.dat JOURNALMODEL.dat
각 리소스의 정의 중에는 OSC 시스템에서 지원하지 않거나 사용하지 않는 필드가 포함되어 있을 수 있다. 이러한 필드는 oscsdgen 툴을 사용하여 리소스를 등록하는 과정에서 무시된다.
다음은 resouces.dat 파일에 저장된 리소스 정의를 OSC00001이라는 Region에서 사용 중인 OSC SD 데이터셋에 등록하는 예이다.
$ oscsdgen -r OSC00001 resources.dat
|
4. JCL 마이그레이션
일반적으로 JCL 마이그레이션은 기존의 Mainframe의 JES 환경에서 실행되는 JCL을 다운받아서 Mainframe에서 사용되고 있는 EBCDIC 코드 기반의 JCL 원본 파일을 OpenFrame에서 사용하는 ASCII 코드 기반으로 변환하는 것을 의미한다. 즉 기존의 JCL 소스의 수정없이 OpenFrame의 TJES 환경에서 JCL을 실행할 수 있도록 하는 것이다.
그러나 3rd Party 유틸리티를 사용하는 경우에는 Mainframe과 UNIX 시스템의 차이로 인해 JCL에서 기술되어 있는 SYSIN이나 파라미터를 전달 방식에 차이가 발생할 수 밖에 없다. 따라서 OpenFrame 시스템에서 3rd Party 유틸리티를 사용하는 경우에는 3rd Party 유틸리티에 맞게 해당 JCL을 변환하는 작업이 필요하다. 또한 기존의 Mainframe에서 사용하던 유틸리티가 OpenFrame 환경에서 모두 제공되지 않는 경우가 있다. 따라서 해당 유틸리티를 OpenFrame에서 동일한 기능을 하는 유틸리티로 변환하는 작업이 필요하다.
본 절에서는 고객사에서 사용하는 다양한 유틸리티에 대해 모두 기술할 수는 없기 때문에 고객사마다 공통적으로 필요할 것으로 예상되는 DB2 유틸리티 마이그레이션에 대한 개요만 기술한다.
4.1. DB2
Mainframe의 호스트인 DB2는 UNLOAD(DB2에 저장되어 있는 데이터를 직렬화하여 파일로 다운받는 작업) 수행 후에 컨트롤 파일을 생성한다. 컨트롤 파일이란 UNLOAD 작업을 통해 다운받은 데이터 및 파일을 다시 DB2로 LOAD (추출된 파일을 다시 되돌리는 복구 작업)할 때 사용되는 파일이다.
UNIX 시스템에서 실행되는 DB2 HPU도 동일하게 UNLOAD 작업 이후 LOAD 작업을 수행할 때 필요한 컨트롤 파일을 생성한다. 하지만 Mainframe과 UNIX 사이에 컨트롤 파일의 문법적인 차이가 존재하여 Mainframe에서 생성된 컨트롤 파일을 UNIX 시스템에서 실행되는 DB2 HPU에서는 바로 사용할 수 없다. 따라서 LOAD JCL의 SYSIN에 INSTREAM 방식으로 지정되어 있는 LOAD 컨트롤 구문을 ASC FROMAT METHODL 형태로 변환한 후에 추가로 해당 컨트롤 파일을 UNIX 시스템의 DB2 HPU의 문법에 맞도록 변환해야 한다.
다음은 Mainframe의 DB2 LOAD 컨트롤 구문을 UNIX UDB LOAD 컨트롤 구문으로 변환하는 예이다.
변환 전
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 )
변환 후
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)