제2장 명령어

본 장에서는 Tmax에서 사용할 수 있는 명령어를 설명한다.

2.1. cfl

텍스트 형태의 Tmax 환경 파일을 컴파일하여 tmconfig(이진 Tmax 환경 파일)을 생성하는 명령어이다. 프로그램을 동작시키기 위해서는 프로그램에 맞는 환경 파일 정의가 필요하고 환경 파일의 정의가 완료된 후엔 환경 파일이 올바르게 생성되었는지 검증이 이루어져야 한다. cfl은 텍스트 형태로 작성된 Tmax 환경 파일을 이진 파일로 컴파일하는 명령어이다.

컴파일하는 중에 에러가 발견되면 이진 환경 파일을 만들지 않고 컴파일을 중단된다. 에러가 발견되지 않으면 이진 파일로 변환된 Tmax 환경 파일이 생성된다. 컴파일이 완료된 이진 Tmax 환경 파일은 gst, tmboot, tmdown 등에서 사용한다. 멀티 노드 환경에서 특정 노드의 환경 파일을 컴파일하고 싶은 경우에 [ -n node_name ] 옵션을 사용한다.

다음은 멀티 노드 감시 환경을 설명한다.

[그림 2.1] 멀티 노드 감시 환경

멀티 노드 감시 환경

참고

gst, tmboot, tmdown 명령어에 대한 자세한 내용은 각가 “2.3. gst”, “2.31. tmboot”, “2.33. tmdown”을 참고한다.

2.2. fdlc

필드 키 테이블을 컴파일하는 명령어이다. 필드 키 방식은 서버와 클라이언트 사이의 데이터 통신에서 구조체를 전송하는 방법처럼 전체 구조체의 항목을 전달하지 않고 필요한 항목만 전달한다. 항목을 전달하기 위해서는 각각의 항목을 구별할 수 있는 유일한 키가 있어야 한다. fdlc는 텍스트 형태로 정의된 필드키 테이블을 컴파일하여 필드 키를 생성하는 명령어이다.

필드 키

서버 / 클라이언트 데이터 통신에서 필드 키 버퍼를 사용하여 데이터를 보내는 경우 FDL 방식을 사용한다. FDL(Field Definition Language)은 필드 키 버퍼에 2개의 쌍으로 되어 있는 식별자와 식별자에 대응하는 데이터 값을 저장하여 서로 다른 프로세스 간에 데이터를 교환하는 방식이다. 필드 키 버퍼에서 각각의 식별자는 데이터 타입과 중복되지 않는 식별 번호의 조합으로 만들어지는데 이 식별자가 필드 키이다.

애플리케이션에서는 필드 키 대신에 프로그램에 대한 판독성을 높이기 위한 필드명을 사용한다. 각각의 필드명은 실행 중에 필드 키 이진 파일을 참조하여 필드 키로 전환되어 버퍼에 저장된다.

FDL 방식은 해당 필드를 사용하는 프로그램의 변경없이도 필드의 타입(type)과 길이를 변경할 수 있고 각 필드의 길이를 가변적으로 사용할 수 있다. 데이터 타입은 일반 C 언어에서 제공되는 Char, Short, Integer, Long, Float, Double, String, Carray 등의 타입을 지원하며 필드명은 16자까지 사용 가능하다.

fdlc 컴파일러는 텍스트 형태로 정의된 필드 키 정의 파일을 컴파일하여 사용자 프로그램에서 참조되는 필드 키를 이진 파일을 생성한다. 사용되는 필드 키 정의 파일은 텍스트 파일이며 테이블 파일명은 <.f> 형식의 파일이어야 한다. 기본 결과물은 <tmax.fdl>과 <필드 키 정의 파일명_fdl.h>이다. 서버 프로그램은 생성된 헤더 파일을 참조하여 컴파일되어 필드의 데이터를 저장하거나 읽어올 수 있다. 클라이언트는 fdlc 명령어로 생성된 파일을 FDLFILE이라는 환경변수에 반드시 등록해야 한다.

필드 키 버퍼의 장점은 데이터의 독립성이다. 구조체 버퍼의 경우에는 사용되지 않는 필드가 존재하더라도 구조체 전체를 전송할 수 밖에 없지만 필드 키 버퍼의 경우에는 필요한 필드만을 선택하여 전송할 수 있다. 또한 개발의 생산성 향상을 위해 다양한 필드 키 조작 함수를 제공하고 있다.

주의 사항 : fdl number값이 16777216 이상일 경우에는 허용하지 않는다.

참고

필드 키 조작 함수의 자세한 내용은 “Tmax FDL Reference Guide”를 참고한다.

2.3. gst

이진 Tmax 환경 파일을 참조하여 서비스 테이블을 생성하는 데 사용되는 명령어이다. gst는 cfl 명령어에 의해서 생성된 이진 Tmax 환경 파일의 SERVER 절과 SERVICE 절을 참조하여 각 서버별로 서비스 테이블을 생성한다. 이 테이블은 서버 프로세스에서 제공하는 서비스 목록으로, 서버 프로그램과 함께 작성하여 프로그램이 컴파일될 때 함께 컴파일된다. 서버 프로세스가 동작할 때 서비스 위치를 찾는 데 사용된다.

gst 명령의 결과 파일은 지정된 TMAXDIR 디렉터리 하위에 svct 디렉터리에 <서버명_svctab.c>로 생성된다. TMAXDIR은 source config 파일의 NODE 절을 참고한다. 서버명은 SERVER 절에 등록된 서버명이며, 각 파일의 내용은 SERVICE 절에 등록된 해당 서버가 제공하는 서비스명이다.

Tmax 환경 파일에 등록된 서비스는 반드시 해당 서버의 서비스 테이블에도 등록되어야 한다. Tmax 환경 파일의 SERVER 절이나 SERVICE 절에 서버명, 서비스명, 서비스의 SVRNAME 등이 변경된 경우는 gst 명령을 사용해서 서비스 테이블과 서버 프로그램을 컴파일해야 한다.

참고

cfl, tmboot, tmdown 명령어에 대한 자세한 내용은 “2.1. cfl”, “2.31. tmboot”, “2.33. tmdown”을 참고한다.

2.4. hkcfl

hkcfl은 텍스트 형태의 Host-link 환경설정 파일을 컴파일하여 이진 Host-link 환경설정 파일(hlinkcfg)을 만드는 명령어이다. 컴파일하는 중 에러가 발생하면 컴파일을 중단하고 정상적으로 컴파일이 완료되면 이진 환경설정 파일이 생성된다.

2.5. idlc

Entera의 conversion할 때 정의 파일을 실제 프로그래밍 가능한 소스(stub)로 변환해 주는 유틸리티이다.

idlc에서 사용 가능한 옵션과 그에 대한 설명은 다음과 같다.

2.6. mkcli

Tmax 클라이언트 모듈을 생성하는 명령어이다. 파라미터는 최대 1024자까지 사용할 수 있으며 이 명령어가 실행되면 cc 컴파일러에 의해 클라이언트 모듈이 생성된다.

2.7. mkacl

ACL(access control list)을 생성하는 명령어이다. 서비스 접근 권한 제어 (제 3단계 보안)는 사용자 그룹별로 이루어진다. 서비스는 접근 권한이 허용된 그룹에 해당되는 user만 접근이 가능하다. 해당 기능을 사용하기 위해서는 group 파일을 생성해야 하며, 해당 그룹에 속하는 user 파일이 있어야 한다. 그리고 서비스별 접근 가능한 사용자 그룹을 지정하는 acl 파일이 있어야 한다.

acl 파일을 생성하기 위해서는 mkacl 명령어를 사용해야 한다.

참고

멀티 노드에서 사용하는 경우에는 “2.1. cfl”의 [-A] 옵션 설명을 참고한다.

2.8. mkgrp

사용자 그룹을 생성하는 명령어이다. 서비스 접근 권한 제어(제 3단계 보안)는 사용자 그룹별로 이루어진다. 하나의 서비스는 서비스에 대해 접근 권한이 허용된 그룹에 해당되는 사용자만 접근이 가능하다. 따라서 이 기능을 사용하기 위해서는 group 파일을 생성해야 하며, 해당 그룹에 속하는 사용자 파일이 있어야 한다. 그리고 서비스별 접근 가능한 사용자 그룹을 지정하는 acl 파일이 있어야 한다. group 파일을 생성하려면 mkgrp 명령어를 사용해야 한다.

2.9. mkpw

암호 관리 명령어로 Tmax 사용자가 선택할 수 있는 보안 확인 메커니즘은 4가지가 있다.

  1. 보안 사용 안함

  2. 도메인 보안 확인

  3. 사용자 보안 확인

  4. 서비스 접근 제어

보안 확인 메커니즘을 사용하려면 사용자명과 암호를 $(TMAXDIR)/config 디렉터리의 passwd 파일에 등록해야 한다. mkpw는 passwd 파일을 관리하는 데 사용된다.

2.10. mksvr

Tmax 서버 모듈을 생성하는 명령어이다. mksvr를 사용하여 서버 모듈을 생성하는 경우 Tmax의 환경 파일에 서비스를 등록하지 않아도 동적으로 서비스를 등록할 수 있다. 파라미터는 최대 1024자까지 사용할 수 있으며 이 명령어가 실행되면 cc 컴파일러에 의해 서버 모듈이 생성되며 옵션들은 다음과 같다.

2.11. racd

멀티 노드로 분산된 환경에서 각 노드를 중앙 관리하기 위한 명령어이다. racd는 여러 노드를 하나의 도메인으로 Tmax 시스템을 구축한 경우 한 노드에서 Tmax 시스템을 집중 관리하기 위해 각각의 노드에서 미리 기동되는 데몬 프로세스이다. Tmax 시스템을 관리하는 노드에서는 racd를 실행하지 않아도 된다.

racd는 도메인 내의 한 노드에서 tmadmin을 통하여 전체 노드를 관리하거나 또는 cfl로 환경 파일을 도메인 내의 모든 노드에 동일한 내용으로 적용 가능하도록 처리한다.

아래는 racd의 특징들에 대한 추가 설명이다.

IP 버전이 IPv6이거나 InfiniBand의 SDP(Socket Direct Protocol)일 경우에는 환경 파일에 다음을 반드시 지정해야 한다.

SYSTEM_PROTOCOL="IPV6"
SYSTEM_PROTOCOL="SDP"

만약 racd를 -k 옵션과 함께 사용한다면 환경변수에 다음을 지정해야 한다.

TMAX_RAC_IPV6="IPV6"
TMAX_RAC_IPV6="SDP"

다음은 racd 명령어 사용법에 대한 설명이다.

2.12. racdr

멀티 노드, 멀티 도메인으로 분산된 환경에서 각 노드에 명령 수행, 파일 전송을 수행하기 위한 명령어이다. 관리를 원하는 노드에는 racd 데몬이 기동이 되어 있어야 한다. 환경 설정 파일을 일정한 형식에 맞춰서 미리 작성을 해야 한다.

다음은 racdr 명령어 사용법에 대한 설명이다.

2.13. rcakill

RCA를 종료하고자 하는 경우 RCA가 사용하는 자원을 제거하기 위하여 사용한다.

2.14. rcastat

RCA는 Tmax 시스템 입장에서는 클라이언트 프로세스로 관리되기 때문에 Tmax 시스템 관리 툴인 tmadmin으로 모니터링이 가능하다. Tmax에서는 RCA를 모니터링하기 위한 rcastat이라는 별도의 툴을 제공한다. 툴을 사용해서 관리자는 현재 RCA의 설정 내용을 확인할 수 있으며 현재 RCA에 접속한 클라이언트의 수 등을 모니터링 할 수 있다.

2.15. sdlc

서버 및 클라이언트 사이의 데이터 통신에 사용하는 방식은 여러 가지가 있지만 그 중에서 구조체(Struct)를 사용할 경우에는 해당 구조체를 Tmax 시스템에서 인식할 수 있어야 한다. sdlc는 이런 구조체를 정의한 파일을 컴파일하는 명령어이다.

SDL(Structure Data Language)은 Tmax에서 정한 표준 구조체 데이터 형식이다. 이기종 노드 간 통신할 때 Integer, Float, Double 등의 데이터 타입과 관련해서 다음의 문제를 갖는다.

SDL은 이러한 문제를 해결하기 위해서 하나의 표준형을 정한 것으로 Integer, Float, Double의 통신을 지원하여 자유로운 통신 타입을 지원한다.

클라이언트 프로그램과 서버 프로그램에서 사용되는 구조체는 동일해야 한다. 구조체가 변경되었을 경우 클라이언트와 서버별로 구조체가 sdlc에 의하여 재컴파일되어야 하며, 새롭게 생성된 <구조체 파일명_sdl.c>는 서버 프로그램과 함께 반드시 재컴파일해야 한다. 사용되는 구조체 파일명은 <.s> 형식의 파일이고 결과물은 <구조체 파일명_sdl.c> 형식이다. 구조체 파일에는 서버 및 클라이언트 사이의 통신에 사용되는 버퍼 타입 구조체가 정의되고 이 구조체 이름은 통신 버퍼로 tpalloc(), tpcall(), tpacall() 등에 사용된다.

sdlc 명령어로 생성된 파일은 클라이언트에 SDLFILE이라는 환경변수에 반드시 등록해야 한다.

2.16. svcrpt

Tmax 시스템을 운용할 때 서비스 수행에 관련된 로그 기록을 분석하여 출력하는 명령어이다. 출력 내용은 수행된 서버 및 서비스의 이름과 횟수, 평균 서비스 수행시간이며 원하는 시간 범위 내에서 1시간 단위로 출력이 가능하다. 서비스 로그는 서버별로 CLOPT 절에 [-l] 옵션을 설정하면 5분 간격으로 $ULOGDIR에 <svclog.mmddyyyy>라는 이름의 파일이 저장된다.

2.17. tdlclean

run 디렉터리의 구버전 라이브러리 파일이나 불필요한 파일을 정리하는 명령어이다. 특히, [-m] 옵션 또는 [-M] 옵션을 사용하면 공유 메모리에서 지정한 동적 모듈이 완전히 삭제된다.

2.18. tdlinit

TDL 공유 메모리 및 동적 모듈을 초기화하는 명령어이다. tdlinit은 설치될 때 단 한 번만 수행하며 Tmax를 부팅하기 전에 수행해야 한다. 멀티 노드 환경인 경우 마스터 노드에서만 수행 가능하다.

2.19. tdlnm

VERSION=2 이상에서 지정한 라이브러리에 대한 자동 export될 함수 목록을 조회하는 명령어이다.

2.20. tdlrm

TDL을 더 이상 사용하지 않을 경우에 공유 메모리를 완전히 제거하기 위한 명령어이다. tdlrm을 할 경우 tdlcall()을 사용할 수 없다.

2.21. tdlseqno

특정 모듈과 함수의 시퀀스 번호를 조회한다.

2.22. tdlshm

TDL 공유 메모리 정보를 조회하거나, 통계 모니터링 활성화 여부 및 모듈 활성화 여부를 설정하는 명령어이다.

2.23. tdlsync

TDL 공유 메모리와 백업 파일 동기화를 수행하는 명령어로 자동 백업을 사용하지 않을 경우 필요한 관리 툴이다.

2.24. tdltrace

TDL 환경 설정 정보와 통계 정보를 조회한다.

2.25. tdlupdate

지정한 동적 모듈을 업데이트하는 명령어이다. [-m] 옵션으로 라이브러리명을 반드시 지정해야 한다. 지정한 라이브러리가 이미 등록되어 있을 경우는 지정한 라이브러리를 업데이트하며 아직 등록되어 있지 않을 경우 새로 추가한다. 멀티 노드 환경인 경우 마스터,슬레이브 노드에서 모두 수행 가능하다.

2.26. tencrypt

SVRGROUP 절의 OPENINFO에 들어가 문장에 대해서 암호화하는 유틸리티로 OPENINFO에는 DB에 접속 아이디 비밀번호가 조회된다.

DB 관리자와 TP 관리자가 분리되어 보안이 되어야 하는 상황에서는 cfl을 실행하면 DB 관리자가 있어야 하는 일이 발생하기 때문에 불편한 사항이 발생할 수 있다. tencrypt를 사용하면 DB 관리지가 OPENINFO에 들어가는 값을 암호화해서 TP 관리자에게 문장을 넘겨주면 DB 정보 노출없이 자연스럽게 TP관리자와 DB관리자가 보안에 문제 없이 운영될 수 있다.

tencrypt는 cfl에서 해석 가능한 암호화한 문장을 출력하는 기능으로 사용법은 아래에서 설명한다.

참고

cfl 명령어에 대한 자세한 내용은 각가 “2.1. cfl”을 참고한다.

2.27. tmadmin

Tmax 시스템 관리 명령어이다. Tmax 시스템의 동적인 관리를 위해 Command 인터프리터 형태로 제공되는 모니터 프로그램이다. Tmax 시스템이 사용하는 공유 메모리의 정보를 읽어서 동작 중인 시스템의 환경설정 내용이나 서버 프로세스의 동작 상태, 또는 서비스 상태 등을 파악할 수 있다.

참고

cfl, tmboot, tmdown 명령어에 대한 자세한 내용은 각각 “2.1. cfl”, “2.31. tmboot”, “2.33. tmdown”을 참고한다.

tmadmin 툴에서 사용할 수 있는 명령어

다음은 tmadmin을 실행한 후 사용할 수 있는 명령어이다.

참고

각 명령어의 사용방법 및 처리 결과에 대한 자세한 내용은 Tmax Administration Guide”의 “5.2. tmadmin”을 참고한다.

2.28. tmapm

Tmax 시스템에서 서비스 타임아웃은 시그널 알람을 사용하여 동작한다. tmapm은 서비스에서 시그알람을 재정의하거나 시그널 알람을 사용하지 못하는 서비스에 대해서 서비스 타입 아웃을 제공하는 서버이다.

tmapm은 USC 서버로 환경설정 파일의 SERVER 절에 다음과 같이 설정한다.

2.29. tmaxlibver

Tmax 라이브러리의 버전 정보를 조회하는 명령어이다. Tmax 6 버전부터 컴파일하지 않고도 라이브러리의 버전 정보를 볼 수 있도록 tmaxlibver의 기능이 변경되었다.

CFLAGS 환경변수를 설정한 후 tmaxlibver를 실행하면 CFLAGS에 지정된 컴파일 옵션을 사용한다.

주의

DB stub 등 일부 라이브러리에서는 버전 정보 조회 기능을 사용할 수 없다.

2.30. tmaxtrace

Tmax 애플리케이션 관리자나 개발자가 각 애플리케이션에 대하여 Runtime Tracing을 할 수 있도록 하는 명령어이다. Runtime Tracing은 애플리케이션이 실행하는 동안의 수행에 대하여 기록을 남기는 Trace point 개념에 근거하고 있다. Trace point는 tpcall()과 같은 atmi 함수의 시작이나 끝, 트랜잭션의 시작 등을 예로 들 수 있다.

Trace point가 발생했을 때 나타나는 현상은 다음과 같다.

  1. Trace point가 유효한 것인지를 확인하기 위해 필터가 적용된다. 유효하다면 Trace record가 receiver 파일에 기록되고 마지막으로 Action이 일어난다. Action은 프로세스를 종료(abort)시키거나, 시스템 call을 호출하는 등 여러 가지가 있을 수 있으며 이는 선택 옵션이다.

  2. Filter, Receiver, Trigger 항목은 아래에서 설명하는 스펙에 따라 정의된다. 이 항목은 TMAX_TRACE의 환경변수를 선언하면 정의할 수 있으며 클라이언트와 서버 모두 설정할 수 있다.

    실행 중인 프로세스의 spec을 변경하기 위해서는 tmadmin 툴의 chtrc 명령어로 변경할 수 있다.

  3. TMAX_TRACE 스펙 중 Trigger 옵션을 'dye'로 설정하였을 경우에는 해당 프로세스의 요청을 받는 서버의 프로세스들도 Runtime Tracing이 수행된다. 클라이언트에서 dye를 설정하였다면 해당 서비스를 수행하는 프로세스가 atmi category가 되며, Runtime Tracing이 수행된다.

  4. 클라이언트에서 TMAX_TRACE를 사용할 경우 클라이언트 환경설정 파일(tmax.env)이나 환경변수에 ULOGPFX를 반드시 지정한다. 아래와 같이 지정할 경우 해당 디렉터리에 <clilog.날짜> 파일이 생성되며, 이 파일에 해당 로그가 쌓인다.

    ULOGPFX=/data1/tmax50/client/clilog

다음은 TMAX_TRACE의 사용법에 대한 설명이다.

2.31. tmboot

Tmax 시스템의 전체나 또는 일부분을 실행시키는 명령어로 Tmax 환경 파일을 바탕으로 시스템을 실행한다. 옵션 없이 실행되거나 [-f] 옵션만이 사용되면, 모든 Tmax 관리 프로세스들과 Tmax 환경 파일의 SERVER 절에 등록된 모든 서버 프로세스들을 실행시킨다.

NODE 절에 등록된 모든 노드에서 Tmax 관리 프로세스인 TMM, CLL, CLH 프로세스가 순서대로 실행된다. SVRGROUP 절에 OPENINFO 항목이 등록된 서버 그룹이 존재한다면, 각 서버 그룹별로 TMSNANEMINTMS 항목을 참조하여 TMS 프로세스들이 실행된다. Tmax 관리 프로세스들은 노드별로 정의된 TMAXDIR 디렉터리 하위의 bin 디렉터리에서 실행된다.

Tmax 관리 프로세스들이 생성된 후에는 SERVER 절의 모든 응용 서버 프로세스들이 실행된다. 응용 서버 프로세스들은 SERVER 절에 등록된 순서대로 실행된다.

tmboot는 실행된 서버 프로세스의 초기화를 실행한 후에 다음 서버 프로세스를 실행시킨다. 프로세스 초기화는 tpsvrinit()를 이용해서 진행한다. 모든 서버 프로세스들이 초기화를 모두 완료할 때까지 다음 프로세스가 실행되지 않는다. tmboot는 각 응용 서버 프로세스들을 그들의 MIN 항목에 정의된 개수만큼 실행시킨다. MIN 항목이 정의되지 않은 경우 기본값은 1개이다.

tmboot는 SERVER 절의 서버들에 대하여 CLOPT, MIN, MAX 항목의 값을 사용한다. 서버 프로세스가 실행될 때 tmboot에 의해 사용되는 서버의 boot 파라미터이며, 서버의 나머지 항목들은 서버가 실행된 후 시스템에 의해 실행되는 runtime 파라미터이다. 설정 정보는 소스 설정 파일의 SERVER 절을 참고한다.

모든 응용 서버 프로세스들은 동작하는 노드에 정의된 APPDIR 디렉터리에서 실행된다.

참고

cfl, tmdown 명령어에 대한 자세한 내용은 각각 cfl, “2.33. tmdown”을 참고한다.

tmboot를 실행할 때의 tmconfig 경로 참조

tmboot 명령어로 Tmax를 기동할 경우 이진 바이너리 환경 파일 ${TMAXDIR}/config/tmconfig를 ${TMAXDIR}/path/tmconfig에 복사한 후 ${TMAXDIR}/path 디렉터리에 있는 환경 파일을 사용한다.

하지만 이미 Tmax 엔진이 기동되어 있는 상황에서 tmboot –S 또는 –s 를 이용하여 특정 서버만을 기동할 경우에도 ${TMAXDIR}/config/tmconfig를 참조한다면 아래와 같은 환경에서 문제가 될 수 있다.

다음과 같이 운영 중 변경된 환경 파일을 CFL로 재컴파일한다.

$ cfl –i node1.m

새로 추가된 서버를 기동한다.

$ tmboot –S svr3

운영 중인 환경에서 환경 파일을 변경한 후 tmboot –S를 시도하려면 다음과 같은 에러가 발생할 수 있다.

(E) BOOT3007 maxsvr (1) is over for svr(svr3:svr2): nodeno = 0, svri = 5, cur = 1, ksvr = 1 [BOOT0015]

운영 환경에서 CFL을 수행하였을 경우 ${TMAXDIR}/config/tmconfig는 변경된 내용이 적용되지만 실제 공유 메모리에는 변경되기 이전인 ${TMAXDIR}/path/tmconfig와 동일하게 구성되어 있기 때문에 tmboot –S로 새로 추가한 서버 프로세스가 기동될 때 실제로는 기존에 이미 실행 중인 서버 프로세스를 추가로 기동하는 결과가 발생한다.

Tmax 엔진이 기동되어 있는 상황에서의 CFL은 허용되지 않지만 이 실수로 인한 에러가 발생하면 해당 에러는 디버깅하기가 쉽지 않다. 따라서 Tmax 엔진 동작 중 tmboot [–S], [-s], [–g], [-q], [-t], [-A] 등의 옵션으로 각 서버를 기동시킬 때 참조하는 tmconfig의 경로는 ${TMAXDIR}/config/tmconfig가 아닌 ${TMAXDIR}/path/tmconfig이다. 단, 엔진을 기동할 경우 ${TMAXDIR}/path/tmconfig를 참조한다.

$ cfl –i new_config.m –o tmchg
$ tmadmin : cfgadd –I tmchg
$ tmboot –S new_svr –f tmchg
주의

tmboot를 수행할 때 [-f] 옵션을 사용하여 특정 이진 바이너리 환경 파일을 지정하면 ${TMAXDIR}/config/tmconfig를 참조하여 서버를 기동한다. 동적 서버를 추가할 때에는 반드시 [–f] 옵션으로 특정 환경 파일을 지정하여 ${TMAXDIR}/config/의 변경된 이진 바이너리 환경 파일을 참조하도록 한다.

2.32. tmd

서버 프로그램을 테스트하기 위해 클라이언트를 시뮬레이션하는 명령어이다. 프로그래머는 직접 클라이언트 프로그램을 작성하지 않아도 쉽게 서버 프로그램의 동작 상태를 확인할 수 있다.

참고

tmb 명령어는 Windows NT와 Windows 2000 환경에서는 작동하지 않는다.

tmd에서 지원하는 버퍼 유형은 STRING, CARRAY, FIELD, 구조체 버퍼이다. CARRAY 버퍼의 경우에는 print 가능한 데이터에 대해서 지원한다. STRING이나 CARRAY 데이터는 공백으로 데이터의 끝을 간주하기 때문에 계속되는 데이터를 표시하기 위해서는 큰따옴표(" ")로 데이터를 처리해야 한다. 구조체 버퍼의 경우 단일 구조체에 대해서 지원하고 있으며 송수신 구조체 타입이 일치해야 한다. 수신한 버퍼 유형과 같은 버퍼를 tpreturn() 함수 내의 파라미터로 사용해야 한다.

그렇지 않으면 다음과 같은 에러 메시지를 출력한다.

(E) 3004 not supported output type

2.33. tmdown

Tmax 시스템 전체나 또는 일부분을 종료시키는 명령어이다. tmdown은 Tmax 환경 파일을 바탕으로 하여 Tmax 시스템을 종료시키기 때문에 기본적으로 [-f] 옵션을 사용하여 참조할 이진 Tmax 환경 파일(소스 설정 파일)을 cfl로 컴파일한 결과물을 경로와 함께 지정해야 한다.

[-f] 옵션이 생략될 경우 기본값으로 TMAXDIR 디렉터리 하위의 config 디렉터리에 있는 tmconfig 파일을 참조한다. [-f] 이외의 옵션이 사용되지 않는다면 tmdown은 Tmax의 모든 관리 프로세스와 Tmax 환경 파일의 SERVER 절에 등록된 모든 서버 프로세스를 종료시키고 Tmax 시스템과 관련된 IPC 자원들을 제거한다. 종료 순서는 다음과 같다.

  1. SERVER 절에 등록된 응용 서버 프로세스들이 종료된다.

  2. 서버 그룹별로 TMS 프로세스가 동작 중이라면 TMS 프로세스가 종료된다.

  3. Tmax 시스템 관리 프로세스들이 종료된다. 프로세스 종료는 CLH, CLL, TMM 순서로 진행된다. 이 순서가 일반적인 시스템 관리 프로세스 종료 순서나 CLH의 MIN 값이 1이 아닌 경우에는 CLL이 CLH보다 먼저 종료될 수도 있다.

백업으로 기동된 서버에 동적으로 등록된 서비스가 있는데 이 서버가 모두 다운되어 동적으로 등록된 서비스가 공유 메모리에서 사라질 경우를 가정해본다. 이 경우 장애 복구 후(백업 서버들이 모두 종료되고 정상 노드의 서버들이 재기동되어 있는 상태), 백업 노드로 접속한 클라이언트에 대해서 naming 서비스를 제공할 수 없게 된다. 따라서 백업 서버의 동적 서비스는 해당 서버가 모두 종료된 후에도 공유 메모리에서 삭제되지 않도록 처리한다.

Rolling Down 기능

클라이언트의 요청을 처리하고 있던 Tmax 시스템이 비정상적으로 종료될 경우 기존 버전에서는 현재 처리 중인 요청에 대해서만 응답을 처리하여 전달한 후 큐에 쌓여 있는 요청에 대하여 TPECLOSE 에러를 전달하였다. 하지만 Tmax 5에서는 Tmax 엔진을 다운시키기 이전에 요청된 모든 클라이언트에 대하여 정상적으로 응답을 주는 Rolling Down 기능을 제공한다.

2.34. tmmbfgen

텍스트의 서비스 정보 파일을 서비스 정보 바이너리 파일로 만드는 명령어이다. 사용자가 작성한 서비스 정보 파일은 그대로 웹 서비스 게이트웨이와 xwsdlgen에서 사용할 수 없기 때문에 tmmbfgen으로 새로운 파일을 생성해야 한다. tmmbfgen에 의해서 생성된 파일을 서비스 정보 바이너리 파일이라고 한다. tmmbfgen을 하면 문법을 체크하고 파라미터의 타입 체크를 통해서 웹 서비스 게이트웨이에서 참조하기 전에 미리 유효성 검사를 할 수 있으며 텍스트 문서를 여러 개로 분할하여 관리가 가능하다.

참고

untmmbfen 명령어에 대한 자세한 내용은 “2.39. untmmbfgen”을 참고한다.

2.35. tmsnmpd

표준 SNMP 프로토콜에 의해서 Tmax 구성 및 성능 정보 조회하는 명령어로 조회가 가능하도록 SNMP Agent인 tmsnmpd가 추가되었다. CNMP 프로토콜은 기본적으로 UDP 161번을 사용하므로 이 포트를 사용하려면 root 권한이 있어야 하며, 1024 이후의 포트를 사용할 경우 일반 사용자 계정으로도 사용 가능하다. Tmax SNMP Agent는 tmboot와 무관하게 tmsnmpd를 실행해야 한다. racd와 동일하게 tmboot / tmdown과 무관하게 동작한다. tmsnmpd를 실행하기 전에 환경변수로 TMAXDIR이 지정되어 있어야 한다.

참고

tmmbfgen 명령어에 대한 자세한 내용은 “2.34. tmmbfgen”을 참고한다.

Tmax SNMP MIB

사용자는 Tmax 서버의 속성 및 통계 정보에 접근할 수 있으며, 이것들은 Tmax MIB에 정의되어 있다. MIB는 표준 SNMP의 한 부분이다. MIB에 대한 내용은 www.ietf.org 사이트를 참고한다.

다음은 Tmax MIB의 OID 트리를 나타낸다. TmaxSoft의 Enterprise OID는 1.3.6.1.4.1.14586이다. 모든 Tmax의 속성값의 접두어는1.3.6.1.4.1.14586.200이 된다.

[그림 2.2] Tmax SNMP의 OID

Tmax SNMP의 OID

현재 버전에서는 SNMP v1, v2c만을 지원한다. 구성 및 성능에 대한 조회만 가능하다(READ-ONLY 기능만 지원). SNMP 유틸리티(snmpget, snmpwalk 등)는 해당 OS 벤더에서 지원받거나 NET-SNMP(http://net-snmp.sourceforge.net/) 등을 사용할 수도 있다.

NET-SNMP의 간단한 사용 예는 아래와 같다.

$ nmpwalk –v 2c –c tmax 192.168.1.100:9999 1.3.6.1.4.1.14586.200

환경설정

2.36. tperr

tperr은 Tmax 에러 번호와 에러 타입을 이용하여 에러에 관한 자세한 정보를 조회할 수 있도록 하는 명령어로 Tmax 시스템 운용 중에 발생하는 에러에 대해서 쉽게 원인을 찾아 해결할 수 있도록 해준다.

참고

에러 메시지의 자세한 내용은 "Tmax Error Message Reference"를 참고한다.

2.37. twagent

Tmax 웹 Agent와 연결하는 데몬 프로세스 기동을 위한 명령어이다.

2.38. uncfl

텍스트 형태의 Tmax 환경 파일을 컴파일하여 생성된 tmconfig(이진 Tmax 환경 파일)을 다시 역으로 분석하여 텍스트 형태의 환경 파일로 변환하는 명령어이다. 환경 파일을 컴파일하고 기동시킨 후 실수로 텍스트 환경 파일을 삭제한 경우에 유용하게 사용할 수 있다.

또한 여러 개의 텍스트 환경 파일을 작성 후 시스템 운용 중에 현재 어떤 환경으로 동작하고 있는지 확인할 경우에도 유용하게 사용할 수 있으며 tmadmin의 cfgadd 명령어를 이용하여 서비스를 동적으로 추가할 때에도 유용하게 사용될 수 있다. cfgadd 명령어에 대한 자세한 설명은 Tmax Administration Guide”의 “5.5.3. cfgadd(ca)”를 참고한다.

참고

cfl 명령어의 자세한 내용은 “2.1. cfl”을 참고한다.

2.39. untmmbfgen

untmmbfgen은 서비스 정보 바이너리 파일을 서비스 정보 파일(텍스트)로 변환하는 명령어이다. tmmbfgen 명령어의 자세한 내용은 “2.34. tmmbfgen”를 참고한다.

2.40. xwsdlgen

웹 서비스 스펙 중 명세서 역할을 하는 WSDL 문서를 생성하는 명령어이다. 현재 WSDL 문서는 1.1, 2.0이 존재한다. xwsdlgen은 웹 서비스 게이트웨이 환경설정 파일과 서비스 정보 바이너리 파일을 입력받아서 WSDL 문서를 생성한다.