OSC 운영
본 장에서는 OSC 시스템을 기동 및 종료하는 방법 및 운영 중인 OSC 시스템에 대한 정보를 조회하거나 변경하기 위해 제공되는 기능을 설명한다.
1. OSC 기동 및 종료
OSC 시스템의 기동과 종료는 oscboot/oscdown 툴을 사용한다. oscboot/oscdown은 OSC 시스템 전체를 기동 또는 종료할 수도 있고, 특정 OSC Region을 기동 또는 종료할 수도 있다.
|
1.1. OSC 기동
다음은 OSC를 기동하는 단계에 대한 설명이다.
-
OpenFrame 시스템 서버 기동
oscboot 툴은 ${OPENFRAME_HOME}/config 디렉터리에 ofsys.seq 파일이 존재할 경우 설정된 서버를 순차적으로 기동한다. 이 기능은 어떤 서버가 부팅 과정에서 다른 서버에서 제공하는 서비스를 호출할 경우에 서비스를 제공해야 하는 서버가 부팅되지 않았을 때 서비스를 호출하는 서버는 에러를 발생한다. ofsys.seq에 설정된 서버를 순차적으로 기동하는 기능은 이러한 에러의 발생을 방지하기 위한 기능이다. ofsys.seq 파일은 OSC를 설치할 때 기본적으로 설정되어 있다.
oscboot 툴은 내부적으로 oscboot.pre에 기술한 작업을 선행한 뒤 OpenFrame 시스템 서버들을 기동한다. 그 후, 모든 기동 과정이 종료된 다음 oscboot.post에 기술한 작업을 수행한다. oscboot.pre/oscboot.post 파일 모두 ${OPENFRAME_HOME}/bin 디렉터리에 위치한다.
-
OSC 시스템 서버 기동
oscboot 툴은 엔진 내부적으로 지정된 OSC 시스템 서버를 기동한다.
-
OSC 사용자 서버 기동
oscboot 툴은 ofosc.seq에 기술된 OSC 사용자 서버를 기동한다.
-
OSC Region 기동
osc.region.list에 기술된 OSC Region을 하나씩 기동한다. 각 Region을 위한 리소스들을 준비한 후 OSC Region에 속하는 서버들을 기동한다.
다음은 각 OSC Region에 필요한 리소스들을 준비하는 과정이다.
-
공유 메모리에 OSC Region에서 사용할 시스템 메모리 영역을 생성한다.
-
공유 메모리에 OSC Region에서 사용할 사용자 메모리 영역을 생성한다.
-
공유 메모리에 OSC Region에서 사용할 TSQ를 위한 영역을 생성한다.
-
태스크 컨트롤(Task Control) 기능을 위한 디렉터리를 생성한다.
-
Intra-partition TDQ 데이터셋을 초기화한다.
-
RTSD와 시스템 테이블들을 생성한다.
리소스 준비가 완료되면, OSC Region에 속한 애플리케이션 서버와 보조 서버를 기동한다. 각 OSC Region이 부팅될 경우 PLTPI에 설정된 프로그램들은 DFHPLT 매크로의 PROGRAM=DFHDELIM 항목의 구분과 관계없이 순서대로 실행된다. PLTPI 프로그램에서 EXEC CICS START 명령어를 통하여 요청된 트랜잭션은 모든 PLTPI 프로그램들의 실행이 끝난 후 시작되며, 모든 PLTPI 프로그램들이 실행이 끝나면 OSC Region 기동이 완료된다.
-
|
1.2. OSC 종료
다음은 OSC를 종료하는 단계에 대한 설명이다.
-
OSC Region 종료
oscdown 툴은 ${OPENFRAME_HOME}/config 디렉터리에 있는 osc.region.list 파일을 참조하여 OSC Region을 순차적으로 종료한다. 각 OSC Region을 종료할 때 우선적으로 PLTSD에 설정된 종료 선처리 프로그램들을 실행한다. OpenFrame 환경설정에 osc.{servername} 서브젝트, GENERAL 섹션의 PSTSD 키의 VALUE 항목을 참조하여 PLT를 로딩하고 PLT에 지정한 프로그램들을 실행시킨다.
PLTSD는 2단계로 나뉘어진다.
-
DFHPLT 매크로의 PROGRAM=DFHDELIM 항목이 나오기 이전에 지정된 프로그램이 순서대로 실행된다. 이 단계에서 OSC 애플리케이션 서버는 TRANSACTION 리소스 정의에 SHUTDOWN(ENABLED) 항목으로 지정된 트랜잭션이 요청되거나 또는 OpenFrame 환경설정에 osc.{servername} 서브젝트, GENERAL 섹션의 XLT 키의 VALUE 항목에 지정된 DFHXLT 매크로에 설정된 트랜잭션이 터미널에서 요청되는 경우만 받아들여 처리한다.
-
모든 사용자 트랜잭션이 종료된 다음, DFHPLT 매크로의 PROGRAM=DFHDELIM 항목 이후의 프로그램들이 실행되며, OSC 애플리케이션 서버는 새로운 사용자 트랜잭션 요청을 받지 않는다.
-
DFHXLT 매크로는 oscxltc 툴을 사용하여 컴파일 및 배포한다. oscxltc에 대한 자세한 사항은 OpenFrame OSC "툴 참조 안내서"를 참고한다.
-
DFHPLT 매크로 및 DFHXLT 매크로에 대한 자세한 사항은 OpenFrame OSC "리소스 정의 안내서"를 참고한다.
-
위의 과정이 끝나면 해당 OSC Region에 속한 애플리케이션 서버와 애플리케이션 보조 서버를 종료한다. OSC Region이 사용한 리소스들을 삭제한다.
-
공유 메모리에 OSC Region을 위해 할당된 TSQ를 위한 영역을 삭제한다.
-
공유 메모리에 OSC Region을 위해 할당된 사용자 메모리 영역을 삭제한다.
-
공유 메모리에 OSC Region을 위해 할당된 시스템 메모리 영역을 삭제한다.
-
태스크 컨트롤(Task Control)을 위해 생성된 디렉터리를 삭제한다.
-
RTSD와 시스템 테이블들을 삭제한다.
-
-
OSC 사용자 서버 종료
oscdown 툴은 ${OPENFRAME_HOME}/config 디렉터리의 ofosc.seq에 기술된 모든 서버들을 기동할 때의 역순으로 종료시킨다.
-
OSC 시스템 서버 종료
oscdown 툴은 엔진 내부적으로 지정된 OSC 시스템 서버들을 oscboot 툴로 기동할 때의 역순으로 종료시킨다.
-
OpenFrame 시스템 서버 종료
oscdown 툴은 ${OPENFRAME_HOME}/config 디렉터리에 ofsys.seq 파일이 존재할 경우 모든 서버들을 기동할 때의 역순으로 종료시킨다. 이 기능은 어떤 서버가 종료 과정에서 다른 서버에서 제공하는 서비스를 호출할 경우에, 서비스를 제공해야 하는 서버가 먼저 종료되어 서비스를 호출하는 서버가 종료되지 않는 현상을 막기 위해 제공되고 있다.
위 과정이 모두 완료된 다음, oscdown 툴은 oscdown.pre에 기술한 작업을 선행한 뒤 시스템 서버들을 종료한다. 그리고 시스템 서버들을 종료한 후에는 oscdown.post에 기술한 작업을 수행하는 동작을 한다. oscdown.pre, oscdown.post 파일 모두 ${OPENFRAME_HOME}/bin 디렉터리에 위치한다.
oscdown 툴의 [-i] 옵션을 사용하여 시스템을 종료하는 경우 OSC Region 리소스 정리가 되지 않으니 필요한 경우에만 제한적으로 사용하고 다시 OSC Region을 기동할 때는 oscboot 툴의 [-m] 옵션을 사용해야 한다.
2. OSC 운영
OSC 운영 항목은 크게 전체 시스템 레벨과 Region 레벨에서 관리되는 항목으로 나누어 진다.
OSC 시스템 레벨에서 관리되는 항목은 시스템 로그 조회 및 시스템 리소스 조회 및 관리 기능이 제공된다. Region 레벨에서 관리되는 항목은 Region의 현황, OSC SD 테이블 관리, RTSD 관리 등 Region 일반 항목과 트랜잭션, 터미널, Map 등과 같은 상세한 Region 리소스 항목으로 나누어 진다.
운영자는 시스템 전반적으로 영향을 미치는 항목과 Region에 영향을 미치는 항목을 구별하여 운영을 하도록 한다.
2.1. 시스템 운영
OSC는 시스템 서버 및 Region의 운영을 위해서 OSC 시스템과 관련된 정보 조회, 로그 조회, 리소스 조회의 기능을 제공한다. OSC에서 제공하는 시스템 운영 항목은 다음과 같다.
-
RESP, RESP2 코드 조회
-
시스템 서버 및 애플리케이션 서버 로그 조회
-
시스템 리소스 조회 및 관리 : Named Counter, Scheduled Transaction, Terminal
위 시스템 레벨의 운영은 OpenFrame Manager의 [OSC] 메뉴를 통해서 할 수 있다.
RESP 코드 조회는 oscresp 툴로도 가능하며, 터미널 연결 정보 조회 및 관리는 oscadmin 툴을 통해서도 제공된다.
OpenFrame Manager 시스템 운영에 대한 자세한 내용은 OpenFrame Manager ”사용자 안내서”를 참고한다. |
2.2. Region 운영
OSC는 Region의 현황 조회, OSC SD 및 RTSD 관리, EDF 기능 등의 기능을 제공한다. 또한 Region에서 사용하는 각 리소스들에 대해서 상세한 관리를 할 수 있도록 기능을 제공한다.
Region 운영 항목은 다음과 같다.
-
Region 일반 정보 조회
Region과 관련된 일반적인 정보를 조회하는 기능을 제공한다. Region의 기본 정보(APPLID, JOBID, SYSID 등) 및 시스템 메모리 사용 현황, SPOOL 사용 현황, 서버 로그 등을 조회할 수 있다.
OpenFrame Manager의 [OSC] > [Regions] 메뉴를 통해서 이 기능을 사용할 수 있다.
-
Region 현황 조회
기동 중인 Region의 프로세스에 대한 정보를 조회할 수 있다. 운영자는 실시간으로 실제 서버 프로세스의 PID, Tmax에서 관리하는 SPRI, 트랜잭션 관련 정보, 사용자 애플리케이션이 EDF 기능을 통해서 디버깅 중인지 여부를 알 수 있다. 또한 특정 서버 프로세스가 사용자 애플리케이션이나 시스템의 오류로 인하여, 또는 그 밖의 어떤 문제로 작업을 진행하지 못하고 있는 상태라면 해당 프로세스를 종료시켜서 수행하던 작업을 중단시키고, 새로운 프로세스를 기동하도록 할 수 있다. 단, 프로세스를 중단시키는 기능은 사용하던 리소스의 정합성을 손상시킬 수 있으므로 각별한 주의를 필요로 한다.
OpenFrame Manager의 [OSC] > [Regions] 메뉴를 통해서 이 기능을 사용할 수 있다.
-
OSC SD 테이블 관리
OSC SD 테이블을 보다 편리하게 관리할 수 있도록 리소스 정의를 조회/등록/수정/삭제할 수 있는 기능을 제공한다. oscsdgen 툴을 사용하여 OSC SD 테이블에 리소스 정의를 등록 할 수 있고, 정의 되어있는 리소스를 수정 및 삭제 할 수도 있다. 또한 oscsddump 툴을 사용하여 정의 되어있는 리소스들을 조회 할 수 있다.
OpenFrame Manager의 [OSC] > [Regions] > [System Definitions] 메뉴를 통해서 조회/등록/수정/삭제의 기능을 GUI 환경의 인터페이스를 통해 제공한다.
-
OSC RTSD 테이블 관리
OSC RTSD 테이블 관리는 3가지 방법을 통해서 실시간으로 운영 중인 OSC 시스템을 관리할 수 있다.
-
방법1)
OpenFrame Manager의 [OSC] > [Regions] > [Runtime Resources] 메뉴에서 DB 테이블에 로드된 리소스 정의를 조회 및 수정할 수 있다. 단, 리소스를 삭제하면 운영 중인 애플리케이션 서버에서는 더 이상 해당 리소스를 사용할 수 없다.
-
방법2)
OSC에서 제공하는 RTSD 툴을 이용하여 DB 테이블에 로드된 리소스 정의를 조회/ 등록/수정할 있다. 단, 리소스 정의를 삭제하는 기능은 제공하지 않는다. RTSD 툴은 현재 운영 중인 애플리케이션 서버의 RTSD 정보를 업데이트하는 oscrtsdupdate 툴과 RTSD 정보를 매크로 형태의 텍스트 파일로 생성하는 oscrtsddump 툴이 있다.
-
방법3)
시스템 프로그래밍 인터페이스(System Programming Interface)를 사용하여 관리용 OSC 애플리케이션을 작성한다.
Runtime Resource의 경우 수정이 가능한 리소스가 제한적이므로 목록을 확인한 후에 변경한다.
-
Region에서 사용하는 리소스들에 대해 상세 관리를 할 수 있는 운영 항목은 다음과 같다.
항목 | 설명 |
---|---|
트랜잭션 |
트랜잭션이 수행되는 Region, 트랜잭션을 요청한 터미널, 트랜잭션에 대응하는 프로그램 이름, 트랜잭션 수행 시작시간 등 트랜잭션과 관련하여 상세 정보를 조회할 수 있는 기능을 제공한다. 트랜잭션 리소스 상세 조회는 OpenFrame Manager의 [OSC] > [Regions] > [Transaction Status] 메뉴에서 할 수 있다. |
스토리지 |
사용자가 GETMAIN 명령어를 통해서 사용하는 스토리지 영역을 상세 조회하는 기능을 제공한다. 운영자는 할당받은 스토리지 영역에 대한 정보 및 실제 GETMAIN을 사용하는 프로세스 정보를 확인할 수 있다. 스토리지 영역에 관한 조회는 OpenFrame Manager의 [OSC] > [Regions] > [Storage] 메뉴에서 할 수 있다. |
터미널 |
애플리케이션에 접속한 터미널의 목록 및 NETNAME의 조회 및 게이트웨이 번호 등을 조회할 수 있는 기능을 제공한다. 운영자는 실시간으로 애플리케이션에 접속한 터미널에 대한 정보를 관리할 수 있다. 터미널에 대한 상세 조회는 OpenFrame Manager의 [OSC] > [Terminals] 메뉴에서 할 수 있다. |
TDQ 및 TSQ |
애플리케이션 서버에서 사용 중인 TDQ 및 TSQ에 대해 목록 조회 및 TSQ 내용 확인할 수 있는 기능을 제공한다. 또한 TDQ의 내용을 TSQ로 이동하는 기능과 TSQ의 내용을 TDQ로 복사하는 기능을 제공한다. 운영자는 TDQ 및 TSQ와 관련된 다양한 기능을 보다 편리하게 관리할 수 있다. TDQ 및 TSQ의 운영은 OpenFrame Manager의 [OSC] > [Regions] > [Queues] 메뉴에서 할 수 있다. |
OpenFrame Manager의 [OSC] 메뉴에 대한 자세한 사용법은 OpenFrame Manager "사용자 안내서"를 참고한다. |
2.3. 로그 레벨 관리
OSC 시스템의 로그 레벨은 OSC 시스템 및 사용자 서버 로그 레벨과 각 Region 로그 레벨을 따로 분리하여 관리한다.
OSC 시스템 및 사용자 서버 로그 레벨은 OpenFrame 환경설정 중 osc 서브젝트, GENERAL 섹션의 SYSTEM_LOGLVL 키의 VALUE 항목으로 관리되며, 각 서버는 기동할 때 해당 설정값을 읽어서 적용한다. OSC 시스템은 사용자가 각 Region의 로그 레벨을 oscadmin 툴을 통해서 조회 및 변경이 가능하고, 이렇게 변경된 값은 OSC 시스템 서버 로그 레벨과는 다르게 실시간으로 해당 Region에 반영된다.
로그 레벨에는 3가지가 있다. 다음은 각 로그 레벨에 대한 설명이다.
레벨 | 설명 |
---|---|
E(Error) 레벨 |
실제 모든 로그에 오류가 발생했을 경우에 대한 로그 정보만 기록된다. |
I(Information) 레벨 |
E 레벨보다 좀 더 상세한 로그 정보가 기록된다. 문제가 발생했을 때 E 레벨보다는 더 많은 정보를 얻을 수 있지만, 로그 파일의 크기는 더 커질 수 있다. (OSC 시스템의 기본값) |
D(Debug) 레벨 |
문제가 발생했을 때 엔진이 어떤 작업을 수행 중이었는지, 엔진의 어느 부분에서 문제가 발생했는지 알 수 있는 자세한 로그 정보가 남는다. 로그 파일의 크기가 커진다. |
|
OSC00001 Region에 대하여 로그 레벨을 조회하는 예는 다음과 같다.
oscadmin -l OSC00001
OSC00001 Region에 대하여 로그 레벨을 디버그로 설정하는 예는 다음과 같다.
oscadmin -l OSC00001:D
3. 보안 관리
OSC 시스템의 보안 관리는 TACF(Tmax Access Control Facility)를 기반으로 한다. TACF는 OpenFrame 시스템에 접근하려는 사용자에 대한 인증 과정을 통해 허가되지 않은 사용자로부터 시스템을 보호하고, 권한이 없는 사용자로부터 시스템의 리소스에 대한 부적절한 접근을 차단하는 기능을 제공한다.
TACF는 Region 서버마다 보안 관리를 다르게 설정할 수 있으며, 이는 OpenFrame 환경설정에 osc.{servername} 서브젝트의 SAF 섹션을 통하여 설정이 가능하다. 운영자는 보안 범위를 리소스 전체로 할지 또는 개별 리소스로 할지를 설정할 수 있다.
Region 서버의 보안 설정에 대한 자세한 설명은 OpenFrame OSC "환경설정 안내서"를 참고한다. |
3.1. 사용자 보안
OSC Region은 TACF에 사용자 등록을 통해서 허가되지 않은 사용자로부터의 접근을 보호하는 기능을 제공한다. 운영자는 사용자를 등록하는 과정을 통해서 시스템을 보호하고, 사용자는 Sign-on 과정을 통해서 인증된 트랜잭션 및 리소스에 대해서 접근을 한다.
다음은 TACF를 통해 OSC 애플리케이션의 기본 사용자인 CICSUSER를 CICSGRP 그룹에 등록하는 예이다.
ADDGROUP CICSGRP ADDUSER CICSUSER DFLTGRP(CICSGRP) NOPASSWORD
사용자는 터미널에 접속하여 CESN을 통해 Sign-on 과정을 거치면 트랜잭션 및 리소스에 접근할 수 있는 권한을 가진다. 그리고 OSC 시스템의 사용을 마친 후에는 CESF을 통해 안전하게 Sign-off 과정을 거쳐 허가되지 않은 접근을 막는다. 사용자는 CESN 및 CESF를 통하여 인증 절차를 거치지 않고 애플리케이션 프로그램에서 SIGNON 및 SIGNOFF와 같은 명령어를 통하여 직접 인증 절차를 거칠 수도 있다. 애플리케이션 서버는 별도의 인증 절차를 거치지 않으면 기본 사용자에 대한 권한을 가지고 동작한다.
다음은 OSC 시스템에서 사용자가 Sign-on을 할 수 있도록 제공하는 기본 트랜잭션 CESN의 화면이다.
|
3.2. 리소스 보안
OSC Region은 사용자의 리소스 요청에 대한 보안 기능을 제공한다. 개별 리소스에 대해서 요청을 하면 사용자가 리소스를 접근할 권한이 있는지를 파악하여 접근 여부를 결정한다.
OSC 시스템에서 보안 서비스를 제공하는 개별 리소스는 다음과 같다.
-
트랜잭션
-
TDQ
-
FILE
-
START된 트랜잭션
-
프로그램
-
TSQ
다음은 개별 리소스 보안을 위해 TACF에서 사용하는 디폴트 리소스 클래스 이름이다. 리소스 단위로 보안을 적용하려면 디폴트 멤버 리소스 클래스를 사용하고, 리소스 그룹 단위로 보안을 적용하려면 디폴트 그룹 리소스 클래스를 사용하도록 한다.
디폴트 클래스 | 대상 | 구분 |
---|---|---|
TCICSTRN |
트랜잭션 |
멤버 |
GCICSTRN |
트랜잭션 그룹 |
그룹 |
DCICSDCT |
TDQ |
멤버 |
ECICSDCT |
TDQ 그룹 |
그룹 |
FCICSFCT |
File |
멤버 |
HCICSFCT |
File 그룹 |
그룹 |
ACICSPCT |
START된 트랜잭션 |
멤버 |
BCICSPCT |
START된 트랜잭션 그룹 |
그룹 |
MCICSPPT |
프로그램 |
멤버 |
NCICSPCT |
프로그램 그룹 |
그룹 |
SCICSTST |
TSQ |
멤버 |
UCICSTST |
TSQ 그룹 |
그룹 |
개별 리소스에 대한 보안 기능을 이용하려면 다음의 절차를 거쳐야 한다.
-
보안 규칙을 적용할 리소스를 TACF의 디폴트 멤버 리소스 클래스에 등록한다. 또는 그 리소스가 멤버로 등록된 리소스 그룹 프로파일을 디폴트 그룹 클래스에 등록한다.
-
리소스의 접근 리스트에 접근할 사용자 및 사용자의 권한을 등록한다.
-
OpenFrame 환경설정에 osc.{servername} 서브젝트, SAF 섹션의 SEC 키와 개별 리소스 보안 키의 VALUE 항목을 YES로 설정한다.
다음은 OIVP 트랜잭션을 TCICSTRN과 GCICSTRN에 등록하고, CICSUSER에 대하여 READ 권한을 부여하는 예이다. 트랜잭션 단위로 보안 서비스를 적용하려면 TCICSTRN을 이용하고, 트랜잭션 그룹 단위로 보안 서비스를 적용하려면 GCICSTRN을 이용한다.
RDEFINE TCICSTRN OIVP UACC(NONE) PERMIT OIVP CLASS(TCICSTRN) ID(CICSUSER) ACCESS(READ) RDEFINE GCICSTRN OIVPGRP UACC(NONE) ADDMEM(OIVP, OIBR, …) PERMIT OIVPGRP CLASS(GCICSTRN) ID(CICSUSER) ACCESS(READ)
다음은 OIVPFILE을 FCICSFCT와 HCICSFCT에 등록하고, CICSUSER에 대하여 UPDATE 권한을 부여하는 예이다. 리소스 단위로 보안 서비스를 적용하려면 FCICSFCT을 이용하고, 리소스 그룹 단위로 보안 서비스를 적용하려면 HCICSFCT을 이용한다.
RDEFINE FCICSFCT OIVPFILE UACC(NONE) PERMIT OIVPFILE CLASS(FCICSFCT) ID(CICSUSER) ACCESS(UPDATE) RDEFINE HCICSFCT OIVPGRP UACC(NONE) ADDMEM(OIVPFILE) PERMIT OIVPGRP CLASS(HCICSFCT) ID(CICSUSER) ACCESS(UPDATE)
OSC 시스템은 TDQ, TSQ, 프로그램, START된 트랜잭션에 대해서도 동일한 과정을 통해서 보안 서비스를 제공한다.
|
4. 로그 정보
로그는 Tmax 내부 프로세스들이 생성하는 로그, OSC 애플리케이션 서버 또는 시스템 서버들이 생성하는 로그, 그리고 OSC 애플리케이션 서버에서 수행된 서비스 정보를 담는 로그, OSC 시스템 명령어 조작 로그 등으로 나뉘어진다.
4.1. Tmax 로그
Tmax 로그는 Tmax 설정 파일에 기술된 노드 절의 SLOGDIR, TLOGDIR 항목에 설정된 디렉터리에 생성된다. SLOGDIR에는 Tmax 시스템 메시지들이 저장되는 파일이 생성되고, TLOGDIR의 파일에는 XA를 이용한 트랜잭션이 발생할 때 트랜잭션과 관련된 메시지들이 기록된다.
4.2. 서버 로그
OSC 애플리케이션 서버와 시스템 서버들이 생성하는 로그는 OUT 로그와 ERR 로그가 있다. 두 로그 모두 Tmax 설정 파일에 기술된 서버의 노드 절에 있는 ULOGDIR에 저장된다. ULOGDIR은 사용자가 자유롭게 설정할 수 있으나 ${OPENFRAME_HOME}/log 아래의 디렉터리로 설정할 것을 권장한다.
OUT 로그
CLOPT 절에 [-o] 옵션과 함께 파일명을 지정해주면, OSC 애플리케이션 및 시스템 서버에서 stdout으로 쓰는 모든 출력물들은 그 파일에 출력된다. OSC 시스템 서버는 OpenFrame 환경설정 중 osc 서브젝트, GENERAL 섹션의 SYSTEM_LOGLVL 키에 VALUE 항목에 설정한다.
OSC 애플리케이션 서버 및 보조 서버들은 해당 OSC Region의 로그레벨에 따라 로그가 기록된다.
-
포맷
다음은 OUT 로그의 포맷이다.
시간 로그레벨 메시지코드 [10:모듈명:SPRI:PID] 로그메시지
항목 설명 시간
날짜를 제외한 HHMMSS 타입의 timestamp이다.
로그레벨
E, I, D, T 중 하나가 지정된다.
-
E(Error) : 시스템에서 오류가 발생한 경우 출력되는 메시지로, 사용자가 잘못된 정보를 주었거나, 시스템 내부적으로 오류가 있는 경우 출력된다.
-
I(Information) : 시스템이 사용자에게 정보를 알려주는 메시지를 뜻한다. 서버의 각종 정보들이 이 로그 레벨로 출력된다.
-
D(Debug) : 시스템 디버깅 용도로 출력되는 메시지이다.
-
T(Test) : 입력 또는 출력되는 데이터가 있는 경우 자세한 디버깅 로그가 출력된다.
메시지코드
로그 메시지에 해당하는 고유한 코드번호이다.
[10:모듈명:SPRI:PID]
-
10 : OSC의 제품번호이다.
-
모듈명 : 메시지를 출력하는 OSC 시스템의 모듈명이다.
-
SPRI : 애플리케이션 서버의 Tmax SPRI 값이다.
-
PID : 애플리케이션 서버의 Process ID이다.
로그메시지
로그 메시지가 출력된다.
-
-
예제
다음은 OSC00001 애플리케이션 서버의 OUT 로그 예제이다.
172703 I OSC0011I [10:CICSRES:59:19582] OSC00001 server boots - resource manager initialization completed 172703 I OSC1705I [10:DFHSIPLT:57:19584] PLTPI : PLT suffix(I1) 173905 E OSC2010E [10:CICS:57:21240] : cics command error - EIBRESP = 0x0000001b(PGMIDERR), EIBRESP2 = 0x00000001, EIBFN = 0x0e0e(HANDLE ABEND), VALFLAG = 0x18000001, FLAG = 0x20000000
osc 서브젝트 설정방법에 대한 자세한 내용은 OpenFrame OSC "환경설정 안내서"를 참고한다. |
ERR 로그
CLOPT 절에 [-e] 옵션과 함께 ERR 로그에 대한 파일을 지정할 수 있다. OSC 애플리케이션 혹은 함께 연결된 다른 OpenFrame 혹은 제품 모듈이 STDERR으로 쓰는 모든 로그들은 그 파일에 생성된다.
4.3. 서비스 로그
트랜잭션 서버에서 트랜잭션을 종료할 때 로그 테이블(OFM_OSC_OLOG)에 직접 로그를 저장한다. 사용자는 osclogrpt 툴을 이용하거나 OpenFrame Manager를 통해서 트랜잭션에 대한 통계 정보를 조회할 수 있다.
로그 테이블에서 관리하는 항목은 다음과 같다.
항목 | 설명 |
---|---|
리전 이름 |
서비스를 처리하는 서버의 이름이다. |
트랜잭션 일자 |
트랜잭션이 발생한 일자이다. |
트랜잭션 시각 |
트랜잭션이 발생한 시각이다. |
노드 이름 |
트랜잭션을 수행한 노드 이름이다. |
SYSID |
OSC 시스템의 SYSID이다. |
트랜클래스명 |
트랜잭션을 수행한 트랜클래스 이름이다. |
SPRI |
트랜잭션을 수행한 Server의 Tmax SPRI이다. |
PID |
트랜잭션을 수행한 PID이다. |
트랜잭션 ID |
트랜잭션 이름이다. |
트랜잭션 수행시간 |
트랜잭션을 수행하는데 소요된 시간이다. |
트랜잭션 CPU 사용시간 |
트랜잭션을 수행하는데 소요된 CPU 시간이다. |
사용자 ID |
트랜잭션을 요청한 터미널에 로그인한 사용자의 ID이다. |
터미널 IP |
트랜잭션을 요청한 터미널의 IP 주소이다. |
터미널 NETNAME |
터미널의 NETNAME이다. |
시스템 에러 코드 |
시스템의 기반 엔진인 Tmax에서 반환한 처리 결과값이다. |
사용자 반환 코드 |
트랜잭션을 처리한 사용자 프로그램이 반환한 처리 결과값이다. |
4.4. 조작 로그
조작 로그는 ${OPENFRAME_HOME}/log/cmd 디렉터리에 osc_cmd_{YYYYMMDD}.log 라는 파일에 저장되며, 부팅/다운 및 TDL 메모리 변경 등 OSC 시스템 명령어의 수행 결과를 기록한다.
-
포맷
다음은 조작 로그의 포맷이다. 로그레벨은 OSC 시스템 명령어가 성공하였을 경우 S(Success)를 실패하였을 경우 E(Error)를 의미한다. 로그레벨을 제외한 항목은 서버 로그의 OUT 로그와 동일하다.
시간 로그레벨 모듈명 로그메시지
항목 설명 로그레벨
S, E 중 하나가 지정된다.
-
S(Success) : OSC 시스템 명령어의 처리가 성공한 경우이다.
-
E(Error) : OSC 시스템 명령어의 처리가 실패한 경우이다.
-
-
예제
다음은 조작 로그의 예제이다.
135017 S OSCBOOT OSC system servers boot start 135017 S OSCBOOT OSC system servers boot successfully 135017 S OSCBOOT OSC region(OSC00001) boot start 135029 S OSCBOOT OSC region(OSC00001) PLTPI ok 135029 S OSCBOOT OSC region(OSC00001) boot ok 135035 S OSCTDLUPDATE OSC region(OSC00001) module(PGM00001) tdlupdate ok 135041 S OSCDOWN OSC region(OSC00001) shutdown start 135101 S OSCDOWN OSC region(OSC00001) PLTSD(suffix:) ok 135102 S OSCDOWN OSC region(OSC00001) shutdown ok 135102 S OSCDOWN OSC system servers shutdown start 135102 S OSCDOWN OSC system servers shutdown successfully
4.5. 모니터링 로그
모니터링 로그는 OSC 모니터링 서버가 작동되는 계정의 SMF 데이터셋에 자동 생성된다. 사용자 트랜잭션이 실행되었을 경우 트랜잭션과 관련된 OSC 시스템 정보 및 리소스 정보를 로그로 남기게 된다. 단, 모니터링 로그를 남기기 위해서는 SMF 기능을 사용하기 위한 환경 설정 및 데이터셋 생성을 사전에 준비해야 한다. SMF 기능 설정이 되어 있지 않을 경우 모니터링 로그가 생성되지 않고 오작동할 수 있다.
SMF 데이터셋에 저장되는 로그의 포맷은 OSC 모니터링 서버의 환경 설정에 따라 달라진다.
SMF에 대한 구체적으로 기록되는 정보들에 대해서는 IBM 안내서 중 "CICS Customization Guide"의 CICS Monitoring과 관련된 항목을 참고한다. |
5. 서버 복구
OSC 시스템 서버 프로세스 및 애플리케이션 서버 프로세스들은 내부적인 에러 또는 사용자 프로그램의 문제로 운영 체제에 의해 강제로 종료될 수 있다. 또한, 하드웨어의 문제로 인하여 OSC 시스템을 기동하고 있는 노드 전체가 예상치 못한 상황에서 종료될 수 있다. 또 다른 문제로 애플리케이션 서버 프로세스가 내부적으로 연결고리를 가지고 있는 다른 제품 혹은 다른 OSC 서버와의 연결이 끊기는 경우가 발생할 수 있다.
5.1. OSC 시스템 서버 복구
OSC 시스템 서버는 서버 프로세스에 문제가 발생하면 Tmax 설정의 RESTART 옵션에 의해 새로운 서버 프로세스가 부팅된다. 내부에서 사용하는 서버 정보 구조체에 문제가 생기지 않는 한 새로운 프로세스는 이전 상태를 복구하여 OSC 애플리케이션 서버에 서비스를 지속적으로 제공한다. 단, OSCDFSVR는 RESTART되는 경우 기존 연결 정보들이 모두 초기화된다.
멀티노드 환경에서는 OSCNCSVR, OSCSCSVR, OSCDFSVR 시스템 서버가 동작하던 특정 노드에서 장애가 발생하면 새로운 서버 프로세스가 다른 노드에서 재시작되도록 설정한다.
아래 서버들은 장애가 발생하는 경우 다음과 같은 추가적인 특징을 가진다.
서버 | 특징 |
---|---|
OSCNCSVR |
다른 노드에서 재시작(RESTART)되더라도, OpenFrame 환경설정에 osc 서브젝트, GENERAL 섹션에 설정된 NCS_FILE이 공유 디스크의 동일한 파일을 지정하고 있다면 지속적인 서비스 제공이 가능하다. |
OSCSCSVR |
백업 설정을 한 경우 이전에 남아있던 요청들을 처리하고, 그렇지 않는 경우 새로운 요청들만 처리하는 서비스만 제공한다. |
OSCDFSVR |
기존 동작하고 있던 EDF 기능을 모두 에러 처리되고, 다시 EDF 기능을 시작해야 한다. |
osc 서브젝트 설정방법에 대한 자세한 내용은 OpenFrame OSC "환경설정 안내서"를 참고한다. |
5.2. OSC 애플리케이션 서버 및 보조 서버 복구
서버 프로세스가 예상치 않은 에러로 종료되는 경우 OSC 애플리케이션 서버에서 애플리케이션 레벨의 복구 관리를 맡는다. 문제가 발생한 경우 해당 트랜잭션은 비정상으로 종료되고, 복구 가능한 리소스들은 rollback된다. 이후 Tmax 서버 설정의 RESTART 옵션에 의하여 자동 또는 수동으로 새로운 서버 프로세스들이 기동되면 정상적인 상태로 다음 트랜잭션을 처리한다. 노드가 종료되는 경우 Tmax 엔진에 의하여 복구 관리된다.
OSC 애플리케이션 서버 프로세스들은 TSAM 데이터셋을 사용하기 위해 부팅을 할 때 Tibero 서버 또는 다른 데이터베이스 제품과 연결한다. 이 경우 네트워크 에러 등의 예상치 못한 문제로 인하여 이 연결이 끊기는 경우가 발생할 수 있다.
파일, Auxiliary TSQ, Intra-partition TDQ 등 TSAM에 접근하려는 트랜잭션 내부의 요청은 애플리케이션에 에러 답변을 돌려주고, 해당 트랜잭션의 복구 가능한 TSAM 데이터셋 접근 요청은 rollback된다. 이후 같은 서버 프로세스에서 요청을 받은 트랜잭션들은 새로운 연결이 될 때까지 대기 상태에 놓인다. 연결 타임 아웃 기간 안에 다시 연결되지 않으면, 트랜잭션은 한번 더 TSAM 연결이 필요한 부분에서 에러를 발생하고 종료된다.
TACF 제품을 사용하기 위해서도 데이터베이스 제품에 연결이 필요하다. 이 경우도 TSAM 연결과 마찬가지로 네트워크 에러 등의 예상치 못한 문제로 연결이 끊길 수 있다. 해당 TACF로의 요청은 에러를 발생하여 사용자 애플리케이션으로 관련 에러를 반환하고, 다음 TACF 요청에서 다시 접속을 시도하여 연결을 복구한다.
OSC 애플리케이션 서버는 보조 서버인 OSC TDQ Log 서버와 TCP/IP 소켓 통신을 이용하여 데이터를 주고 받는데, 이 또한 네트워크 에러 등의 문제에 노출되어 있다. 문제가 발생하면 해당 로그 TDQ로의 접근은 에러로 인하여 실패하게 되고, 사용자 애플리케이션의 다음 접근 요청에서 재접속을 시도하여 복구한다.
리소스 사용에 대한 내용은 OpenFrame OSC "개발자 안내서”를 참고한다. |
6. 시간 변경
OSC 시스템 서버는 기본적으로 CICS ASKTIME 명령어로 현재 구동중인 시스템 서버의 날짜와 시간을 받아와서 OSC 시스템의 날짜로 설정한다. 그러나 사용자는 필요에 따라 특정 시간에 OSC 시스템 전체나 특정 사용자 프로그램들을 테스트 해야만 하는 상황이 발생 할 수 있다. 이를 위해 OSC에서는 TX_TIME이라는 기능을 통해 사용자가 원하는 날짜와 시간으로 OSC 시스템 전체 혹은 특정 리전, 특정 사용자 프로그램의 날짜와 시간을 설정할 수 있다.
TX_TIME 설정에 대한 자세한 내용은 OpenFrame Manager "사용자 안내서"의 "OSC"를 참고한다. |
6.1. 시간 설정 준비
다음은 TX_TIME 기능을 사용하기 위한 준비 단계에 대한 설명이다.
-
DB 테이블 확인
시스템 테이블 OFM_OSC_TX_TIME을 확인한다. (OSC 제품 설치 시 oscinit 툴을 통해 생성됨)
-
OSC 설정
OpenFrame 환경설정에 osc 서브젝트, GENERAL 섹션의 ENABLE_TX_TIME 키의 VALUE 항목을 YES로 설정한다.
osc 서브젝트 설정방법에 대한 자세한 내용은 OpenFrame OSC "환경설정 안내서"를 참고한다.
-
TCache 설정
pfmtcache.cfg 파일에 다음 내용을 설정한다. (OSC 제품 설치 시 기본으로 포함되어 있음)
# cache for OFM_OSC_TX_TIME CACHE_NAME=OFM_OSC_TX_TIME SIZE_MEM=32 # the total cache memory size in kilo-bytes SIZE_HASH=32 # the number of hash key (MAX=65536) SIZE_KEY=14 # the number of digits of the index column SIZE_REC=38 # the size of a single record in bytes INV_TIMEOUT=10 # invalidation timeout in sec
6.2. 시각 설정
TX_TIME은 DB 테이블에 저장된 데이터를 사용하여 OSC 시스템의 시간을 설정한다.
다음은 TX_TIME DB 테이블의 구조와 그에 대한 설명이다.
항목 | 설명 |
---|---|
CONTROL_TYPE |
사용자의 날짜와 시간을 설정하는 KEY_ID의 타입이다.
각 타입의 우선순위는 Transaction > Terminal > User > Region이다. |
KEY_ID |
사용자의 날짜와 시간을 설정하는 곳의 ID이다. ID 범위 지정을 지원하는 '*'가 최대 1개까지 포함될 수 있다. |
USER_DATE |
사용자가 설정하려는 날짜이다. 'YYYYMMDD’의 형태로 저장한다. |
TIME_TYPE |
사용자가 설정하려는 시간의 타입이다.
|
USER_TIME |
사용자가 설정하려는 시간이다. 'hhmmss' 의 형태로 저장한다. |
LAST_REG_USER |
마지막으로 데이터를 저장한 사용자의 이름이다. |
LAST_REG_TIME |
마지막으로 데이터를 저장한 사용자의 시간이다. 'YYYYMMDD hhmmss’의 형태로 저장한다. |
LAST_UPDT_USER |
마지막으로 데이터를 수정한 사용자의 이름이다. |
LAST_UPDT_TIME |
마지막으로 데이터를 수정한 사용자의 시간이다. 'YYYYMMDD hhmmss’의 형태로 저장한다. |
6.3. 시간 변경
기존에 TX_TIME 테이블에 존재하던 데이터의 날짜와 시간을 변경하는 방법에 대한 설명이다.
-
TCache 초기화
기존에 TCache에 적재되어있던 데이터들을 초기화하여 새로운 날짜/시간을 적재할 준비를 한다. 데이터 초기화는 TCache의 관리자 툴인 pfmtcacheadmin을 이용하거나, OpenFrame Manager를 통해 시간을 변경하여 해당 시간의 정보를 TCache에서 삭제한다.
다음은 pfmtcacheadmin을 이용하여 TCache에 적재된 TX_TIME 관련 데이터들을 초기화하는 예이다.
pfmtcacheadmin -i OFM_OSC_TX_TIME
-
날짜/시간 업데이트
TX_TIME 테이블에 존재하는 데이터의 날짜 / 시간을 OpenFrame Manager의 TX_TIME 기능으로 수정한다.
32bit 환경에서는 2038년 문제 때문에 2038년 1월 19일을 넘어가면 1970년 1월 1일로 넘어가기 때문에 2038년 이후 시간은 사용하지 않도록 한다.
7. 리소스 자동 설치
OSC 시스템 서버를 운용하기 위해서는 서버 운용에 필요한 리소스를 System Definition에 정의해야 한다. 그러나 일부 리소스의 경우 System Definition에 직접 정의하지 않더라도 OSC 시스템에서 사용자가 필요로 하는 리소스를 자동으로 설치하여 운용 중에 사용이 가능하다. 사용자가 사전에 System Definition에 자동 설치할 리소스 모델을 정의하면, 리소스 자동 설치(AutoInstall) 기능에 의해 System Definition에 정의되지 않은 리소스 사용 요청이 왔을 경우, 미리 정의된 모델을 기준으로 리소스를 생성한다.
7.1. 프로그램 자동 설치
다음은 프로그램 자동 설치를 위한 준비 과정이다.
-
환경설정
OpenFrame 환경설정에 osc.{servername} 서브젝트, AUTINST 섹션에 PGAIEXIT 키의 VALUE 항목에 자동 설치 컨트롤 프로그램명을 설정한다.
osc.{servername} 서브젝트 설정 방법에 대한 자세한 내용은 OpenFrame OSC "환경설정 안내서"를 참고한다.
-
컨트롤 프로그램 작성
OSC 환경 설정에 정의된 컨트롤 프로그램은 사용자가 System Definition에 정의되지 않은 프로그램을 실행할 때 OSC 시스템 내부에서 호출된다.
컨트롤 프로그램은 설치하고자 하는 프로그램명을 입력으로 받아 사용자가 작성한 로직에 따라 프로그램 리소스 모델명을 반환한다. 결과적으로 OSC에서 리소스 모델과 동일한 속성을 가진 프로그램 리소스를 새로 생성하여 실행시킨다.
다음은 프로그램명('TARGETPGM')을 입력으로 받아 프로그램 리소스 모델명('MODELPGM')을 반환하는 컨트롤 프로그램의 작성 예이다.
IDENTIFICATION DIVISION. PROGRAM-ID. OSCPGACC. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. * Commarea constants 01 PGAC-CONSTANTS. * Module type 03 PGAC-TYPE-PROGRAM PIC X VALUE '1'. 03 PGAC-TYPE-MAPSET PIC X VALUE '2'. 03 PGAC-TYPE-PARTITIONSET PIC X VALUE '3'. * Language 03 PGAC-ASSEMBLER PIC X VALUE '1'. 03 PGAC-COBOL PIC X VALUE '2'. 03 PGAC-PLI PIC X VALUE '3'. 03 PGAC-C370 PIC X VALUE '4'. 03 PGAC-LE370 PIC X VALUE '5'. * CEDF status 03 PGAC-CEDF-YES PIC X VALUE '1'. 03 PGAC-CEDF-NO PIC X VALUE '2'. * Data location 03 PGAC-LOCATION-BELOW PIC X VALUE '1'. 03 PGAC-LOCATION-ANY PIC X VALUE '2'. * Execution key 03 PGAC-CICS-KEY PIC X VALUE '1'. 03 PGAC-USER-KEY PIC X VALUE '2'. * Load attribute 03 PGAC-RELOAD PIC X VALUE '1'. 03 PGAC-RESIDENT PIC X VALUE '2'. 03 PGAC-TRANSIENT PIC X VALUE '3'. 03 PGAC-REUSABLE PIC X VALUE '4'. * Share status 03 PGAC-LPA-YES PIC X VALUE '1'. 03 PGAC-LPA-NO PIC X VALUE '2'. * Execution set 03 PGAC-DPLSUBSET PIC X VALUE '1'. 03 PGAC-FULLAPI PIC X VALUE '2'. * Dynamic status 03 PGAC-DYNAMIC-YES PIC X VALUE '1'. 03 PGAC-DYNAMIC-NO PIC X VALUE '2'. * Concurrency 03 PGAC-QUASIRENT PIC X VALUE '1'. 03 PGAC-THREADSAFE PIC X VALUE '2'. 03 PGAC-REQUIRED PIC X VALUE '3'. * Api 03 PGAC-CICSAPI PIC X VALUE '1'. 03 PGAC-OPENAPI PIC X VALUE '2'. * JVM 03 PGAC-JVM-YES PIC X VALUE '1'. 03 PGAC-JVM-NO PIC X VALUE '2'. * Return code 03 PGAC-RETURN-OK PIC X VALUE '1'. 03 PGAC-RETURN-DONT-DEFINE-PROG PIC X VALUE '2'. LINKAGE SECTION. * Include Program Autoinstall commarea 01 DFHCOMMAREA. COPY DFHPGACO. PROCEDURE DIVISION. IF PGAC-MODULE-TYPE = PGAC-TYPE-PROGRAM IF PGAC-PROGRAM = 'TARGETPGM' MOVE 'MODELPGM' TO PGAC-MODEL-NAME END-IF END-IF. MOVE PGAC-RETURN-OK TO PGAC-RETURN-CODE. EXEC CICS RETURN END-EXEC.
-
프로그램 모델 정의
System Definition에 자동 설치 프로그램 모델을 정의한다. 일반적인 프로그램 리소스 정의와 동일하며, 프로그램이 자동 설치되는 경우, 이 단계에서 정의된 모델의 속성을 가져오게 된다.