z/OS 배치 관리자 마이그레이션
배치 관리자를 WebSphere® Application Server for z/OS® 버전 9.0으로 마이그레이션하기 위한 JCL 작업을 생성한 후, 이 작업을 실행하여 실제 마이그레이션을 수행할 수 있습니다. 사용자 정의 마이그레이션 작업을 생성할 때 작업을 생성하는 데 사용된 CNTL 데이터 세트의 BBOMDINS 멤버에서 마이그레이션 작업을 준비하고 실행하는 데 필요한 사용자 정의 지시사항도 작성됩니다. 이 사용자 정의된 지시사항에 따라 배치 관리자를 버전 9.0으로 마이그레이션하는 프로세스를 완료하십시오.
시작하기 전에

이 기사는 프로파일 구성 마이그레이션에 대한 기사입니다. 애플리케이션을 최신 버전으로 마이그레이션하려면 WebSphere Application Server 마이그레이션 툴킷을 사용하십시오. 자세한 정보는 WASdev의 마이그레이션 툴킷을 참조하십시오.
sptcfg- 마이그레이션, 공존, 상호 운용성 개요 및 마이그레이션 고려사항의 내용을 읽어보십시오.
- JCL(Job Control Language) 마이그레이션 작업을 생성하지 않은 경우 다음으로 진행할 수 없습니다.
- 배치 관리자 노드를 항상 첫 번째로 마이그레이션하십시오.
- 시스템에 대한 적용 가능한 공존 요구사항을 검토하십시오.
- 이 지시사항에서 참조된 BBOWMG3D 작업은 WebSphere 관리자의
사용자 ID로 제출해야 합니다.
다른 모든 작업은 파일 시스템을 제어하는 사용자 ID로 제출해야 합니다.
- 버전 7.0 이상에서 버전 9.0로 마이그레이션하는 동안 고가용성 유지보수에 관한
참고:
배치 관리자가 다시 시작될 때 배치 관리자를 버전 7.0 이상에서 버전 9.0로 마이그레이션하면 모든 애플리케이션 바이너리가 다시 배치됩니다. 이 조치를 수행하면 배치 관리자가 모든 애플리케이션을 Sysplex에서 다시 사용합니다. 이로 인해, 동기화 설정을 사용할 수 없는 경우 고가용성을 위해 설정한 Sysplex가 사용 불가능 상태가 될 수 있습니다.
마이그레이션 시 고가용성을 유지하려면 배치 관리자를 다시 시작하기 전에 Sysplex의 모든 노드 에이전트에 대한 모든 동기화 옵션을 비활성화하십시오.- 관리 콘솔을 여십시오.
- 시스템 관리 > 노드 에이전트로 이동하십시오.
- Sysplex의 각 노드 에이전트에 대해 node_agent_server_name > 파일 동기화 서비스로 이동하고 모든 동기화 처리를 사용 불가능하게 설정하십시오.
- 팁: WebSphere Application Server 버전 7.0 이상 배치 관리자를 마이그레이션하기 전에 마이그레이션 후 이전 상태로 복원할 수 있도록 하려면 backupConfig 명령 또는 선호하는 백업 유틸리티를 사용하여 기존 구성을 백업하십시오. 자세한 정보는 backupConfig 명령을 참조하십시오. 이 백업 구성의 정확한 이름과 위치를 알고 있어야 합니다.
도움말은 마이그레이션 문제점 해결의 내용을 읽어보십시오.
이 태스크 정보

- WebSphere Extended Deployment Compute Grid 또는 Feature Pack for Modern Batch
- WebSphere Virtual Enterprise 또는 Intelligent Management
프로시저
- 새 버전 9.0 구성 파일 시스템을 작성하고 마운트하십시오.
마이그레이션을 수행하기 전에 버전 9.0에서는 새 구성을 표시할 구성 파일 시스템이 필요합니다. BBOMDHFS 또는 BBOMDZFS를 실행하여 새 구성 파일 시스템을 작성 또는 마운트하거나 수동으로 마운트할 수 있습니다. 어떠한 방법으로든 진행하기 전에 작성하고 마운트되는 버전 9.0 구성에 대한 구성 파일 시스템이 있어야 합니다. 이 구성 파일 시스템은 마이그레이션의 대상이고 버전 7.0 이상 구성 파일 시스템은 소스입니다.
BBOMDHFS 또는 BBOMDZFS는 마운트 지점 디렉토리를 작성하고 구성의 파일 시스템을 할당하며 마이그레이션 작업을 작성할 때 마운트 지점에서 지정한 값으로 파일 시스템을 마운트합니다.
작업을 계속하기 전에 BBOMDHFS 또는 BBOMDZFS를 사용하거나 수동으로 구성 파일 시스템 데이터 세트를 할당, 작성 및 마운트했는지 확인하십시오. 마운트 지점은 WebSphere 관리 ID가 소유하고 최소 755 사용 권한이 있어야 합니다. 새 구성 파일 시스템 구조는 BPXPARM에 포함되어야 다음 IPL에서 마운트됩니다.
- 생성된 JCL 프로시저를 복사하십시오.
마이그레이션 유틸리티 BBOMDCP는 서버를 시작하기 위해 생성된 JCL 프로시저를 지정된 프로시저 라이브러리에 복사합니다. 버전 9.0 구성에는 버전 7.0 이상 구성에 사용되는 것과 다른 JCL 프로시저를 사용해야 합니다. 이 유틸리티는 원래의 버전 7.0 이상 구성에 존재하는 이름 대신에 새 JCL 이름을 대체하여 새 버전 9.0 구성을 업데이트합니다.
주의: 이 유틸리티는 생성된 JCL을 사용자의 프로시저 라이브러리에 복사합니다. 마이그레이션 작업을 생성할 때 버전 7.0 이상 구성에서 사용한 것과 동일한 이름을 지정한 경우, 이 유틸리티는 기존 프로시저를 오버레이합니다. 동일한 이름을 사용 중이면 나중에 롤백할 필요가 있는 경우 이 유틸리티를 실행하기 전에 반드시 기존의 버전 7.0 이상 프로시저를 백업하십시오.BBOMDCP를 제출하고 리턴 코드 0을 확인하십시오.
- 새 프로시저 이름을 지정한 경우, 제어기 및 디먼에 대한 RACF® STARTED
프로파일을 업데이트하십시오. 제어기 영역에서 사용하는 STARTED 프로파일은 프로시저 이름 및 JOBNAME을 기반으로 합니다. 시작된 태스크에 올바른 ID가 지정되도록 STARTED 프로파일을 적용해야 합니다. 예를 들어, 버전 7.0 이상 배치 관리자 제어기 JCL 프로시저 이름이 AZDCR이고 버전 9.0에 대해 AZ1DCR을 지정한 경우, 해당 프로시저 이름으로 STARTED 프로파일을 작성해야 합니다.
new controller same identity used in JCL name V7.0 or later configuration | | RDEFINE STARTED AZ1DCR.* STDATA(USER(AZDCRU) GROUP(AZCFG) TRACE(YES))
참고:- 시작하기 위해 다른 사용자 ID를 사용하지 마십시오. 사용자 ID는 다른 사항과도 관련이 있으므로 사용자 ID를 변경하는 경우 다른 사항 또한 변경해야 합니다.
- 예를 들면, 원래 STARTED 프로파일이 일반 STARTED AZ*.* ...인 경우 새 STARTED 프로파일을 작성하지 않아도 됩니다.
- 하위(servant) 영역 STARTED 프로파일은 프로시저 이름이 아닌 JOBNAME을 기반으로 합니다. 따라서 다른 프로시저 이름을 사용하는 경우 하위(servant)와 관련된 문제는 없습니다.
- 디먼과 노드 에이전트는 제어기이므로 다른 프로시저 이름을 사용하는 경우 새 STARTED 프로파일을 의미합니다.
- 다음 중 하나를 수행하십시오.
- BBOWMG3D 작업을 제출하십시오.
배치 관리자 마이그레이션은 독립형 애플리케이션 서버와 연합 노드 마이그레이션이 수행한 것처럼 PRR(Peer Restart and Recovery) 모드로 노드를 가져가거나 가져오지 않아도 됩니다. 배치 관리자 마이그레이션을 위해 제출할 작업은 두 가지가 더 적으므로 이제 실제 마이그레이션을 수행할 수 있습니다.
BBOWMG3D는 마이그레이션 작업을 생성할 때 제공한 정보를 기반으로 버전 7.0 이상 배치 관리자를 버전 9.0로의 실제 마이그레이션을 수행합니다. BBOWMG3D를 제출하십시오. 리턴 코드가 0인지 확인하고 구성 파일 시스템의 마이그레이션 임시 디렉토리에 있는 로그 파일을 검토하십시오. 마이그레이션 임시 디렉토리는 temporary_directory_location/nnnnn입니다. 여기서 temporary_directory_location은 임시 디렉토리 위치에 대해 지정한 디렉토리이며 nnnnn은 마이그레이션 작업을 생성할 때 마이그레이션 ID에 대해 생성된 숫자 값입니다. 기본 임시 디렉토리 위치는 /tmp/migrate입니다.
- 다음 세 가지 작업을 제출하십시오.
- BBOWDPRO 작업을 제출하십시오.
BBOWDPRO는 WebSphere Application Server 홈 및 기본 프로파일을 작성합니다.
- BBOWDPRE 작업을 제출하십시오.
BBOWDPRE는 마이그레이션 사전 업그레이드 프로세스를 실행합니다.
- BBOWDPOS 작업을 제출하십시오.
BBOWDPOS는 마이그레이션 사후 업그레이드 및 종료(파일 권한 변경) 프로세스를 실행합니다.
- BBOWDPRO 작업을 제출하십시오.
- BBOWMG3D 작업을 제출하십시오.
- 마이그레이션 전에 추적 제어 설정을
조사하십시오.
WebSphere Application Server를 마이그레이션하기 위해 수동으로 변경해야 하는 특정 구성 설정이 있습니다. 관리 콘솔을 사용하여 다음과 같이 환경 변수 목록을 조사하십시오.
- 환경 > WebSphere 변수 관리를 클릭하십시오.
- 구성 탭에서 ras_trace_outputlocation 변수를 확인하고
존재하는 경우 해당 설정을 기록하십시오.
ras_trace_outputlocation이 TRCFILE로 설정된 경우, 새 WebSphere Application Server에 대한 시작 프로시저를 수동으로 수정하여 TRCFILE DD문이 포함되도록 해야 합니다.
문제점 방지: 시작 프로시저의 수동 수정은 새 WebSphere Application Server 및 연관 디먼이 시작되기 전에 수행해야 합니다. gotcha
- 이전 애플리케이션 서버와 디먼을 시스템 종료하십시오.
동일한 셀에 있는 배치 관리자 LPAR의 모든 노드가 종료되어야 합니다.
- 필요한 경우, 디먼 JCL 프로시저를 업데이트하십시오.
z/OS용 WebSphere Application Server 버전 9.0는 디먼 프로세스가 동일한 LPAR을 관리하는 서버의 최상위 코드 레벨에 있어야 합니다. 배치 관리자가 시작되면 버전 9.0 레벨에 있습니다.
모든 노드를 버전 9.0로 마이그레이션한 후 및 이전 버전의 라이브러리를 시스템에서 제거하기 전에, 디먼 JCL 프로시저를 업데이트해야 합니다. 이 작업을 수행하지 않으면 디먼이 시작되지 않습니다.
참고:- 버전 7.0 이상에서 버전 9.0로 마이그레이션하는 경우, 디먼은 가장 최신의 버전 SBBOLD2 및 SBBOLPA 데이터 세트를 포함한 STEPLIB가 있어야 합니다.
- 버전 9.0 셀에 버전 9.0 셀과 동일한 시스템에 있는 버전 7.0 이상 셀의 버전 7.0 이상 서버와 통신 중인 버전 9.0 서버가 있는 경우 버전 7.0 SBBOLD2 및 SBBOLPA 데이터 세트를 버전 9.0 디먼의 STEPLIB에도 추가해야 합니다.
- 새 배치 관리자를 시작하십시오.
버전 7.0 이상를 시작하는 데 사용하는 기존 명령을 사용하십시오. 그러나 마이그레이션 작업을 생성할 때 제어기 프로시저 이름으로 배치 관리자 패널에 입력한 값으로 RACF STARTED 프로시저 이름을 대체하십시오. 이 명령은 버전 9.0 배치 관리자를 시작합니다. 서버 초기화가 완료될 때까지 기다린 후 계속하십시오.
다음 메시지는 콘솔 및 작업 로그 BBODMGR에 표시됩니다.BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBODMGR
다음에 수행할 작업
- 소스 구성 파일 시스템의 모든 요소
- 대상 구성의 temporary_directory_location/nnnnn 디렉토리에 있는 모든 요소. 여기서, temporary_directory_location은 임시 디렉토리 위치에 대해 지정한 디렉토리(기본값 /tmp/migrate)이며 nnnnn은 마이그레이션 작업을 작성할 때 마이그레이션 ID에 대해 생성된 숫자 값입니다.
- bbomigrt2.sh 파일


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-zos&topic=tmig_z_adm
파일 이름:tmig_z_adm.html