TUXEDO 应用系统的配置 3.1 TUXEDO 应用系统的常见配置 配置文件 UBBCONFIG 介绍 一 个 TUXEDO 应 用 系 统 的 所 有 资 源 都 在 一 个 文 本 文 件 中 进 行 定 义 ， 该 文 件 称 为 UBBCONFIG，在配置完成后，UBBCONFIG 被编译成一个二进制的文件 TUXCONFIG.在 TUXEDO 系统启动时,从该文件中读取系统的配置信息。UBBCONFIG 文件类似 WINDOWS 下的*.INI 文件。 它包括以下 9 大部分, 我们称之为节,RESOURCES， MACHIENS， GROUPS 这三个节必须的，其他的节是可选的。 RESOURCES(必需): 与整个系统有关的配置信息 MACHINES(必需): 一个 TUXEDO 应用系统可以跨越多台服务器,在该节中配置与每台服务 器有关的信息 GROUPS(必需): TUXEDO 中的服务可被分为多个组,在该节中配置与组有关的信息 SERVERS(可选): 与 SERVER 有关的信息在该节配置 SERVICES(可选): 与 SERVICES 有关的信息在该节配置 NETWORK(可选):与网络有关的信息在该节配置 ROUTING(可选) :路由规则在该节配置 NETGROUPS(可选):与网络分组有关的信息在该节配置名称解释： 名称解释：TUXEDO 应用系统 一个 TUXEDO 应用系统包括服务端，客户端，服务端安装在服务器上，客户端一般安装在 PC 机上，从开发角度看，一个 TUXEDO 应用系统包括服务端程序，客户端程序，一个配 置文件。此外，一个 TUXEDO 应用系统可以部署在一台服务器上，也可以部署在多台服务 器上。 SERVER： ： 服务端程序用 C 或 COBAL 编写，每一个程序文件编译成一个相应可执行文件，该可执行 文件在运行时称为 SERVER，它实际上就是一个进程。每个 SERVER 都有一个名字，也就 是该进程的名字。为与 TUXEDO 应用系统的服务端区分，我们在本书中，我们用 SERVER 表示该进程，用服务端表示 TUXEDO 应用系统的服务端。 SERVICE： ： 在每个服务端程序中，主要是一个个的函数，在 TUXEDO 中称这些函数为 SERVICE，一般 也称之为服务。在该 SERVICE 中实现业务逻辑，在客户端中调用这些 SERVICE 来实现各 种操作，如在前面的例子 simpapp 中， 服务端程序为 simpserv.c，它编译成可执行文件 simperv, simpserv 就是一个 SERVER，该 SERVER 包括 SERVICE：TOUPPER。

下面我们给出一个配置文件的例子： 下面我们给出一个配置文件的例子 *RESOURCES IPCKEY 123456 MASTER simple 

"TOUPPER" LOAD=50 PRIO=50 BUFTYPE="ALL" TRANTIME=30 AUTOTRAN=N *ROUTING 各节之间的包含关系： 各节之间的包含关系： 从上到下，是一对多的关系，即：一个 TUXEDO 系统可以跨越多台服务器，一台服务器上 可以有多个 GROUP，但一个 GROUP 只能在一台服务器上，一个 GROUP 中可以有多个 SERVER，一个 SERVER 中可以有多个 SERVICE。

下面我们分别对每个节种具体的常见配置进行说明，NETWORK,NETGROUP,ROUTING 三 节及其他比较高级的配置我们在后面的内容中说明 RESOURCES(必需 必需): 必需 该节是必须的，在这里配置与整个 TUXEDO 应用系统有关的信息，主要包括： IPCKEY: TUXEDO 使用它标识公告板及其他的 IPC 资源。它不能与该服务器上其他的 IPC 资源的 ID 号冲突范围：32,769-262,142 MASTER: 指定该 TUXEDO 应用系统的 MASTER 服务器,在该服务器上对整个 TUXEDO 系 统进行管理配置,可以为该 MASTER 服务器指定一台备份服务器,当该 MASTER 服务器当机时,可从 BACKUP 服务器上进行管理。在进行系统迁移时,也要指定 BACKUP 服务器。 DOMAINID：该 TUXEDO 应用系统的唯一标识 UID, GID, PERM:这三个参数控制对系统 IPC 资源的存取权限 UID: 可对该 TUXEDO 应用系统进行管理的 TUXEDO 系统管理员的用户 ID,在 UNIX 下 就是 UNIX 系统的用户 ID,默认为执行 TMLOADCF 的用户的 ID。在 NT 下该设置 没有用,要设为 0。 GID: 在 UNIX 下为 UID 中所指定的用户所在的组 ID,在 NT 下该设置没有用,要设为 0 PERM: 指定对 TUXEDO 系统 IPC 资源的存取权限。默认值为 0666,即任何人都可以对该 IPC 资源进行存取。 MAXACCESSERS,MAXSERVERS,MAXSERVICES:这三个参数控制该 TUXEDO 应用系统 对 IPC 资源的使用情况。 MAXACCESSERS: 在本系统的一个节点(一台服务器)上,同时可以有多少个进程可以访问 该 TUXEDO 系统的公告板,默认值为 50,它包括本地客户端进 程,SERVER 进程,但不包括管理进程如:BBL,DBBL 等 MAXSERVERS: 在本系统中,总共可以有多少个 SERVER 存在,包括进行管理的 SERVER, 如:BBL,TMS 等。默认值为 50。 MAXSERVICES: 在本系统中,总共可以有多少个 SEVICE 存在, 默认值为 100。

TUXEDO 应用系统的部署方式： 一个 TUXEDO 应用系统可能部署在一台服务器上或多台服务器上,也可能是部署在共用一 块全局共享内存的几台服务器上,可在 MODEL,OPTIONAS 中配置该 TUXEDO 应用系统的 部署模式。 MODEL SHM: 单机或多台服务器但共用一个全局共享内存 MP: 多台服务器但没有共用一个全局共享内存 OPTION: LAN: 是多机（MP）部署模式 MIGRATE: 可对该系统进行迁移

TUXEDO 的管理进程 BBL 定时对它所在的服务器上的 TUXEDO 系统进行检查,检查超时的 事务,超时的客户端连接等。 SCANUNIT: 5 指定检查的最小时间单位,它单位为秒,必须是 5 的倍数。 默认值为 10,即 10 秒。 SANTIYSCAN:10 每隔多少个 SCANUNIT 检查一次, SANITYSCAN*SCANUNIT 不能大于 300 秒。默认值为 12,即 120 秒 BLOCKTIME: 20 指定一个消息可以阻塞多长时间,如果过了 BLOCKTIME *SCANUNIT 秒 该 消息还没有发送出去,将超时出错。 BLOCKTIME *SCANUNIT 不能大于 32767 秒。默认值为 6,即 60 秒。 同步调用的超时说明 对同步调用 TPCALL,指从 TPCALL()开始调用,到 SERVER 端的返回结果到到该客户端并写 到输入缓冲区这一段时间。包括: 客户端开始调用 TPCALL() 把数据通过网络发送到 SERVER 端 SERVER 端的处理时间 SERVER 端把处理结果通过网络返回给客户端 客户端 TPCALL()调用返回 异步调用和会话方式的超时说明 对异步调用和会话方式,当一个进程调用 TPACALL(),TPCONNECT(),TPSEND()时,超时时间 只包括如果接收队列满时,这些调用的等待时间,如在 TPACALL()中,所调用的 SERVICE 的接 收队列如果满了,那么 TPACALL()可阻塞在那里,直到该队列不满,可以接收该 TPACALL()发 送的请求。从 TPACALL()开始阻塞到 TPACALL()返回这段时间为它的超时时间。 对 TPGETRPLY(),TPRECV()的超时时间是指如果要接收的队列为空时,它们应该阻塞在那里 等待有消息到来的时间。 如:超时时间为 60 秒, 一点整调用 TPGETRPLY()从接收的队列取消息,这时接收队列为空,如 果到了一点零一分该接受队列还为空,那么 TPGETRPLY()将超时出错。

要不要进行负载均衡,Y:要,N:不要,默认值为不要

MAXCONV: 在一台服务器上最多可以有多少个会话同时存在。范围:0-32768,默认值为 10 NOTIFY : 设置消息的通知方式,有以下 3 种:默认为 DIPIN IGNORE: 该 TUXEDO 系统中的 CLIENT 不接收任何消息 SIGNAL: 用 SIGUSR1,SIGUSR2 信号通知 CLIENT 有消息到来， 如果在非 UNIX 平台上设 置采用该方式，那么会被自动转化为 DIPIN 方式。 DIPIN: 当 CLIENT 调用 ATMI 函数时,顺便检查看是否有消息,如果有就发送给该 CLIENT 默认值为 DIPIN

*MACHINES(必需 必需): 必需 该 TUXEDO 应用系统所包含的每台服务器都要在该节中进行配置 LMID: 在 TUXEDO，要为该应用系统中的每台服务器指定一个逻辑服务器名。如在上面 的例子中，TUXEDO 应用服务器 MYSYS 对应的逻辑服务器名为：simple， TUXEDO 应用服务器名的查看方法： 1. 在 UNIX 下用 uname -n 查看 SERVER 的名字, 2. 在 NT,WIN2000 下用 ECHO %COMPUTERNAME$查看 SERVER 的名字 注意： 如果 SERVER 的名字太长(>8)或含有“.”等可以" "引起来,如: "DEMOSERVER.COM" TUXCONFIG: 配置文件 TUXCONFIG 所在的路径 TUXDIR: TUXEDO 的安装目录 APPDIR: TUXEDO 应用系统所在的目录 注意：TUXCONFIG，TUXDIR，APPDIR 的值要与它们在环境变量中的设置的值一样 ENVFILE: 该服务器上与 TUXEDO 有关的环境变量(如 FIELDTBLS 等)可以放到一个文件中, 在 ENVFILE 中指定该文件名。 TYPE: 指定该服务器的类型,当两台服务器的 TYPE 不一样时,在它们之间传送数据时要进行 编码/解码工作 ULOGPFX: 指定 ULOG 文件所在的目录及前缀。默认目录为$APPDIR,前缀为 ULOG。 UID,GID,PERM,MAXACCESSERS,MAXCONV 这 些 在 RESOURCES 中 的 配 置 , 在 MACHINES 中可以被重新配置,并且这些新的配置值会覆盖在 RESOURCES 中的配置值。

*GROUPS(必需 必需): 必需 在 TUXEDO 中,要对 SERVER 进行分组,配置 GROUP 主要有三个目的, 1． 因为 GROUP 与数据库之间是一对一的关系,在一 TUXEDO 应用系统中,如果有多个数据 库,就要配置多个 GROUP,在该 GROUP 中配置 TUXEDO 与数据库的连接参数等。 2． 数据依赖路由是以 GROUP 为单位的。 3． 进行系统迁移时也时以 GROUP 为单位的一个 GROUP 有一个名字,还有一个 GROUP ID,GROUP 的名字和 GROUP ID 在一个 TUXEDO 系统中必须唯一。 每个 GROUP 要指定该 GROUP 所在的服务器， 及它的 ID 号， 如果该 GROUP 中的 SERVER

要与数据库或其他的资源管理器相连，那么要在 OPENINFO 中设置连接的参数。具体的配 置我们在讲数据库编程时再说明。 *SERVERS: 该系统所包含的所有的 SERVER 都在该节进行配置。 在 DEFAULT 中的设置对所有的 SERVER 起作用。 SRVGRP: 该 SERVER 所在的 GROUP SRVID: 该 SERVER 所对应的 ID,在一个 GROUP 中必须唯一 MIN: 该 SERVER 最少启动的进程数 MAX: 该 SERVER 最多可启动的进程数 RESTART,RCMD,MAXGEN,GRACE: 在 TUXEDO 系统了,当一个 SERVER 进程因某中原因 死掉时,可设置它可以自动重起,这 4 个参数指定 TUXEDO 的重起信息。 RESTART 该进程死掉时是否可以自动重起,默认为 N(不可以) GRACE，MAXGEN：在 GRACE 秒内，该进程最多可以重启 MAXGEN 次。 RCMD： 指定该 SERVER 重启时,要执行的一个可执行文件名 注意： 1． 为了使一个 SERVER 可以自动重起,光设置了 RESTART=Y 还不够,还要设置 GRACE,MAXGEN 才能在该 SERVER 死掉时,自动重起, 2． 该 SERVER 能够被自动重起的一个前提条件时它还没有被从 BULLITION BOARD 中清 除。 例子: test SRVGRP=GROUP1 SRVID=1 RESTART=Y GRACE=100000 MAXGEN=255 该设置指定在 100000 秒的时间内,SERVER 进程:test 可以启动 255 次。 在缺省情况下，TUXEDEO 的每一个 SERVER 对应一个请求队列，该 SERVER 从该请求队 列中取客户端发来的请求，并把处理的结果通过该请求队列返回给客户端，TUXEDO 的 SERVER 可以配置成多个 SERVER 对应一个请求队列， MSSQ 方式， 即 以提高响应的速度。 与 MSSQ 有关的参数是： RQADDR：该请求队列的名字，一般设成与该 SERVER 的名字一样 RAPERM：该请求队列的存取权限，默认为 0666 REPLYQ：该 SERVER 中的某个 SERVICE 调用其他的 SERVICE，并有返回结果，则应设置 REPLYQ=Y，即把其他 SERVICE 的应答放到该队列中 CONV: 该 SERVER 是否采用会话(CONVERSATION)通讯方式,注意采用会话通讯方式的 SERVICE 要单独在一个 SERVER 中,不能与采用其他通讯方式的 SERVICE 在同一个 SERVER 中,并且该 SERVER 要设置 CONV=Y CLOPT: 指定该 SERVER 的启动参数。默认为-A,即再该 SERVER 启动时，发布该 SERVER 包含的所有的 SERVICE。通用的有: -e: 指定错误输出文件,默认为$APPDIR 下的 stderr -o: 指定标准输出文件,默认为$APPDIR 下的 stdout -r: 记录该 SERVER 中 SERVICE 每次调用的处理时间,并记录在错误输出文件中,然后可采用 TUXEDO 的性能分析工具 txrpt 对该 SERVER 进行性能分析。 -A: 发布该 SERVER 包含的所有的 SERVICE

*SERVICES: 在 SERVICES 中可针对每个 SERVICE 进行配置，主要有： AUTOTRAN: 调用该 SERVICE 时是否自动启一个全局事务。默认为 N LOAD:如果采用负载均衡,指定该 SERVICE 的负载因子，默认为 50 PRIO: 指定该 SERVICE 的优先级，默认为 50 DDR: 指定数据依赖路由规则 与远程客户端有关的配置： 与远程客户端有关的配置： 1． 在 MACHINES 中要配置 MAXWSCLIENTS，即最多可以有多少个远程客户端同时连接 到该服务器上，在上面的例子中为 5 个 2． 在 SERVERS 中要配置 SERVER：WSL WSL SRVGRP="GROUP1" SRVID=1116 CLOPT="-A -- -n //192.168.120.113:8888 -m 2 -M 5 -x 6" 说明： -n //192.168.120.113:8888: 远程客户端通过该端口与服务器建立连接 -m 2 :最少启动多少个 WSH 进程 -M 5：:最多启动多少个 WSH 进程，默认值为 MAXWSCLIENTS/m -x 6：每个 WSH 进程可同时处理多少个远程客户端 3． 程客户端所在的服务器上要配置 WSNADDR 环境变量，它的值为-n 参数的值，如在上 面的配置中为： SET WSNADDR= //192.168.120.113:8888 的编译: 配置文件 UBBCONFIG 的编译 用下面的命令进行编译: tmloadcf –y UBBCONFIG 文件名 如:下面的命令编译名为 ubbsimple 的 TUXEDO 配置文件,生成二进制的配置文件 TUXCONFIG tmloadcf –y ubbsimple 有时候在改变了 TUXCONFIG 的目录后，执行 tmloadcf，会出现类似下面的错误，可把原 来的 TUXCONFIG 文件删除，然后再编译。 D:\simpdb>tmloadcf -y ubb CMDTUX_CAT:1601: ERROR: TUXCONFIG,TUXOFFSET d:\simpdb\tuxconfig 0 doesn't match first device entry on configuration d:\tuxdemo\simpdb\tuxconfig 0 D:\simpdb>del tuxconfig D:\simpdb>tmloadcf -y ubb D:\simpdb> 用 tmunloadcf 命令可对二进制的配置文件 TUXCONFIG 的进行反编译 如下面的命令反编译 TUXCONFIG,并把结果输出到文件 myubb 中。 通过反编译 TUXCONFIG 可查看该 TUXEDO 应用系统的一些属性默认值。 Tmunloadcf >myubb

3.2 多机（MP）模式的配置 多机（ ） 一个 TUXEDO 应用系统可以部署在多台服务器上，这些服务器通过网络连接，这种部署方 式称为 MP 方式， 在这些服务器中要选择一台服务器做 MASTER 服务器,在该服务器上有一 个 DBBL 进程,负责整个 TUXEDO 应用系统的管理工作。在每台服务器上都有一个 BBL 进 程，它与 DBBL 进程进行通信，管理各自服务器上的配置。每台服务器上还有一个名为 BRIDGE 的进程和一个名为 TLISTEN 的进程，他们负责服务器之间的通讯。MP 模式的结 构如图：

如果配置了 MP 方式，那么在这些服务器之间可以做负载均衡和容错，客户端可以和其中的 任何一台服务器建立连接，如果该服务器上没有该客户端所要调用的服务（SERVICE） ， TUXEDO 可以自动把请求发送到别的有该服务的机器取处理，并把结果返回个客户端，如 图， SITE1 上的客户端调用了 TRANSFER， 当在 SITE1 上没有该 SERVICE， SITE3 上有， 在 那么 SITE1 通过 BRIDGE 把请求发送到 SITE3 上，SITE3 把处理结果也通过 BRIDGE 发送 到 SITE1 上，通过 SITE1 把结果返回给该客户端。这些对客户端时透明的。 如果 SITE1，STIE2，SITE3 上都有 TRANSFER，并且设置了负载均衡（LDBAL =Y） ，那么 TUXEDO 将根据他们的负载情况把请求发送到负载较小的服务器上。 如果 SITE1，SITE2，SITE3 中的某一台或两台服务器出故障了，那么正常的机器仍然能够 继续运行，如果时他们之间的网络连接断了，BRIDGE 进程会自动进行重试，并且在这些服 务器之间可以配置多个网络连接通路， 当其中的一个出现故障时， 会自动采用别的连接通路。 所以 MP 方式提供了一个高可靠性的分布式应用系统。

方式的步骤： 配置成 MP 方式的步骤： 1. 这些服务器之间可以通过网络互相访问 2. 在每台服务器上都正确安装了 TUXEDO SERVER 3. 应用已发布到这些服务器上 4. 选择一台服务器做 MASTER 机, 6. 在 RESOURCES,MACHINES,NETWORK,NETGROUPS 中做相应的配置 RESOURCE: MODEL 要设为 MP OPTIONS 中要有 LAN MASTER 服务器上的 DBBL 负责与其他服务器上的服务器 BBL 进行通讯, BBLQUERY: 每台服务器上的 BBL 每隔 SCANUNIT*BBLQUERY 秒,向 MASTER 机上的 DBBL 发送一次状态信息。默认为 300 秒 DBBLWAIT: 如果 MASTER 机没有收到某台服务器发送的状态信息,它将等待 SCANUNIT*DBBLWAIT 秒,如果还没有收到该服务器发送的状态信息,这台服务 器将被分离出去(PARTITIONED)，默认为 20 秒 MACHIENS： ： 在 MACHINES 中要配置该 TUXEDO 应用系统包括的每台服务器，如果该服务器时 UNIX 服务器， 那么要配置 UID， GID， UID， GID 为 TUXEDO 用户所对应的 UID， GID， UNIX 在 下可以用 ID 命令查看。

NETWORK: 在该节中配置服务器之间通讯的 IP 地址及 BRIDGE 进程, 在一个 MP 方式的 TUXEDO 应用系统中，不同的服务器之间通过 BRIDGE 进程进行通讯， 该 BRIDGE 的侦听 IP 地址及端口 在 NADDR 中指定。如果是在 UNIX 下要指定该 BRIDGE 所用的网络设备，如果是在 NT 下则不要。 在 TUXEDO 系统启动前，不同服务器之间的通讯是通过 tlisten 进程来进行的，因为这时还 没有 BRIDGE 进程。 NLSADDR 为 tlisten 进程侦听的 IP 地址及端口。 方式的配置例子。 一个 MP 方式的配置例子。 环境： 环境：WIN2000 服务器一台，安装 TUXEDO6.5, 服务器名 WIN,IP 地址:10.13.1.124 SUN5.8 服务器一台，安装 TUXEDO6.5, 服务器名 SUN,IP 地址:12.22.32.35 MASTER 机为 WIN2000 服务器,BACKUP 机为 SUN。 在 WIN2000 服务器上的 UBBCONFIG 的内容如下,在 SUN 服务器上不用编写 UBBCONFIG 文件。当启动时 DBBL 会自动

把 WIN2000 服务器上的 TUXCONFIG 文件发送到 SUN 服务器上。 *RESOURCES IPCKEY 87656 MASTER site1,site2 MAXACCESSERS 40 MAXSERVERS 40 MAXSERVICES 40 MODEL MP OPTIONS LAN *MACHINES WIN LMID=site1 APPDIR="d:\tuxdemo\mp" TUXCONFIG="d:\tuxdemo\mp\tuxconfig" TYPE="win2000" TUXDIR="d:\tuxedo65" SUN LMID=site2 UID=1006 GID=30 APPDIR="/export/home/simpapp" TUXCONFIG="/export/home/simpapp/tuxconfig" TYPE="sun" TUXDIR="/export/home/tuxedo"

1. 在 WIN2000 服务器上把该 UBBCONFIG 编译成 TUXCONFIG tmloadcf -y ubbmp 2. 在 WIN2000 服务器上启动 tlisten 进程 tlisten -l //10.13.1.124:6001 3. 在 SUN 服务器上启动 tlisten 进程 tlisten -d /dev/tcp -l /12.22.32.35:6001 4. 在 WIN2000 服务器上启动该 TUXEDO 应用系统 tmboot -y TUXEDO 会先启动 WIN2000 服务器上的进程,然后再启动 SUN 服务器上的进程。 5. 在 WIN2000 服务器上执行 simpcl mp test 因为 WIN2000 服务器上没有 TOUPPER 服务,TUXEDO 会自动调用 SUN 服务器上的 TOUPPER 服务,并把结果返回给客户端,这一切对客户端来说是透明的。