ASQCOUNT는 엔진 전체에 걸친 값이 아니라 CLH 하나에 부여되는 값이다. 그래서 각 CLH마다 큐 상태를 보고 ASQCOUNT를 적용하여 부족한 서버를 부트한다.

예를 들면 ASQCOUNT=4로 설정하고, 한 노드에 현재 대기 중인 요청이 5개라면, 현재 큐 크기가 5가 아니고, 각 CLH마다 svr 대기 큐를 가지고 있기 때문에 1번 CLH에 2개, 2번 CLH에 3개가 될 수 있는 상태에서는 ASQCOUNT에 못미치기 때문에 서버를 부트하지 않는다.

다수 CLH에서는 모든 CLH에서 동시에 같은 spr에 스케줄링할 수 있다. 최대한 방지하기 위해 다른 CLH의 상태도 검사하며 스케줄링하지만 요청이 많아지거나 동시에 요청이 있을 경우 발생할 수 있다. 이런 경우에는 늦게 요청된 spr의 소켓에 대기하며 tmadmin의 큐에서는 보여지지 않고 각 CLH의 st -p에 RUN 상태로 보여야 한다. 이런 상태에 있는 요청들은 CLH의 큐에 있는 것이나 마찬가지로 판단하여 svr에 실제 서비스 수행 전에 qtimeout을 체크하여 시간이 이미 지났다면 TPEQPURGE로 응답을 주고 있다.

*SVRGROUP
ServerGroup Name  [COUSIN = cousin-svg-name,cousin-gw-name,]
                  [LOAD = numeric]

*GATEWAY
Gateway Name   [LOAD = numeric]

다음과 같이 설정할 경우 svg1(tmaxh4), svg2(tmaxh2), gw1(tmaxh4), gw2(tmaxh2)가 하나의 COUSIN 으로 묶이게 된다. LOAD의 값이 모두 1이므로 클라이언트에서 TOUPPER 서비스 호출하는 경우 각 svg1, svg2, gw1, gw2가 1:1:1:1로 서비스를 처리한다.

<domain1.m>

*DOMAIN
tmax1       SHMKEY = 78350, MINCLH = 2, MAXCLH = 3,
            TPORTNO = 8350, BLOCKTIME = 10000,
            MAXCPC = 100, MAXGW = 10, RACPORT = 3355

*NODE
tmaxh4      TMAXDIR = "/data1/tmaxqam/tmax",

tmaxh2      TMAXDIR = "/data1/tmaxqam/tmax",

*SVRGROUP
svg1      NODENAME = tmaxh4,
         COUSIN = "svg2, gw1, gw2", LOAD = 1
svg2      NODENAME = tmaxh2, LOAD = 1
                
*SERVER
svr2      SVGNAME = svg1

*SERVICE
TOUPPER      SVRNAME = svr2

*GATEWAY
#Gateway for domain 2
gw1      GWTYPE = TMAXNONTX,
         PORTNO = 7510,
         RGWADDR ="192.168.1.43",
         RGWPORTNO = 8510,
         NODENAME = tmaxh4,
         CPC = 3, LOAD = 1

#Gateway for domain 3
gw2      GWTYPE = TMAXNONTX,
         PORTNO = 7520,
         RGWADDR ="192.168.1.48",
         RGWPORTNO = 8520,
         NODENAME = tmaxh2,
         CPC = 3, LOAD = 1

<domain2.m>

*DOMAIN
tmax1       SHMKEY = 78500, MINCLH=2, MAXCLH=3,
            TPORTNO=8590, BLOCKTIME=10000

*NODE
tmaxh4      TMAXDIR = "/EMC01/starbj81/tmax",

*SVRGROUP
svg1        NODENAME = "tmaxh4"

*SERVER
svr2        SVGNAME = svg1

*SERVICE
TOUPPER     SVRNAME = svr2

*GATEWAY
gw1         GWTYPE = TMAXNONTX,
            PORTNO = 8510,
            RGWADDR="192.168.1.43",
            RGWPORTNO = 7510,
            NODENAME = tmaxh4,
            CPC = 3

<domain3.m>

*DOMAIN
tmax1       SHMKEY = 78500, MINCLH=2, MAXCLH=3,
            TPORTNO=8590

*NODE
tmaxh2      MAXDIR = "/data1/starbj81/tmax",
                
*SVRGROUP
svg2        ODENAME = "tmaxh2"

*SERVER
svr2        SVGNAME = svg2

*SERVICE
TOUPPER    SVRNAME = svr2

*GATEWAY
gw2        GWTYPE = TMAXNONTX,
           PORTNO = 8520,
           RGWADDR="192.168.1.48",
           RGWPORTNO = 7520,
           NODENAME = tmaxh2,
           CPC = 3

Tmax v5.0 SP1까지는 게이트웨이가 속한 노드는 반드시 해당 노드의 일반 서버 그룹(보통 dummy 서버)도 등록되어 COUSIN으로 함께 묶여 있어야 한다. 위 예제 <domain1.m> 에서 gw1 은 tmaxh4 노드에 속해 있으며, gw2는 tmaxh2 노드에 속해 있다. 이 경우 tmaxh4와 tmaxh2의 일반 서버 그룹도 반드시 COUSIN 서버 그룹 내에 포함되어 있어야 한다.

그러나 Tmax v5.0 SP2에서는 위와 같은 불편함을 해결하여 게이트웨이가 속한 노드를 묶지 않고 해당 게이트웨이만 묶어 주어도 된다.

기존 도메인 게이트웨이는 리모트 노드/리모트 도메인의 상태를 체크하지 못하기 때문에 리모트 노드의 특정 서버 (Gateway 포함)에 장애가 난 경우 이에 대하여 감지하지 못하고 그대로 스케줄링되어 클라이언트에게 TPENOREADY 에러를 리턴하였다.

리모트 노드 / 도메인의 상태를 체크하여 리모트 게이트웨이 장애가 발생하였을 경우 남아 있는 다른 서버 그룹이 처리한다. 즉 svg1이 대신 처리한다.

svg1이 dummy 서버 그룹인 경우 혹은 게이트웨이간의 네트워크 장애가 발생했을 경우 리모트 노드인 svg2와 gw2가 각각 1:1로 처리를 하게 된다.

Tmax v5.0 SP1까지는 비트랜잭션 게이트웨이에 한해서만 지능형 라우팅 기능(IRT)을 지원하고 트랜잭션 게이트웨이는 지원되지 않았다. 그러나 Tmax v5.0 SP2에서는 비트랜잭션 게이트웨이, 트랜잭션 게이트웨이, JEUS 게이트웨이에서 지능형 라우팅 기능(IRT)을 지원한다.