天上掉大饼之土人俗事: 消息中间件（Message-Oriented Middleware, MOM）

Java与C作消息集成需要注意的几个问题(2)——符号问题

Fri, 25 Nov 2005 08:29:30 GMT

Java与C作消息集成需要注意的几个问题(2)——符号问题

Java里没有无符号数。这个非常讨厌。在C里面我们经常会用到下面这样的结构来定义消息：

#program pack(1)

typedef struct tagMYSTURCT {
unsigned char dataCount;
char dataContent[];
} MYSTRUCT, PMYSTRUCT;

在这个结构里面无符号数dataCount保存着数组dataContent的尺寸，在绝大多数硬件平台下，unsigned char的范围是0-255。而由于Java里面没有无符号数，其byte类型的范围是-127-128，这样，如果在C里面将dataCount设成200，那么java用byte直接读入的话就是-56，显然会造成问题。因此，在C和Java通讯时，还必须要注意符号的问题。

对于这问题，我的解决方法是把Java这端的整形量全部用8位长整型long定义，这样在处理4位以下的整形数时就不用考虑符号问题了。反正由于字节顺序问题，不能直接用jdk提供的库函数来从字节流里解析整形量，正好在自己写的函数里把这个问题一并处理了。

Java与C作消息集成需要注意的几个问题(1)——字节顺序问题

Thu, 24 Nov 2005 12:56:35 GMT

C/C++在通信时，一般都是直接将内存中的数据拷贝到输出中，这样，在输出的字节流中一个整形量的各个字节就是按照其在内存中顺序输出的。而目前常用的x86平台上，整形量是按照小字节优先的顺序保存的，即数据的低8位保存在开头的第一个字节中，数据的高8位保存在最后一个字节中，比如32位（4字节）整形量0x00123456，其在内存中的实际存储就是0x56 0x34 0x12 0x00。这样，其在通信的输出里也是0x56 0x34 0x12 0x00。

在一般情况下，网络通信的两端往往都是C/C++，所使用的机器平台也都是x86平台，字节顺序并不会产生什么问题。

但是当一端是C，另一端是java时，就有问题了。因为Java为了保证平台无关性，其整形量在I/O时会自动转换为大字节优先顺序输出，比如32位整形量0x00123456的实际输出是0x00 0x12 0x34 0x56，恰好和x86平台上的C程序是反过来的！

因此，当C和Java程序进行通信时，必须有一端首先对其输入或输出的信息进行字节顺序的转换，使两端数据的字节顺序一致，才能保证数据的正确性。

btw: 今天一上午都在写java的转码程序了，其实按理应该是在C那一端按照其所使用的硬件平台类型来转码比较好，但是因为我这个系统要和别人对接，数据格式已经被人家先定好了，所以没办法只能改我这一边的东西了:(

压缩BCD码与该死的18M WebsphereMQ Integrator 2.1

Wed, 23 Nov 2005 14:13:31 GMT

先来解释一下压缩BCD码。现在在搞的一个和别人合作的项目中，对方要求的通讯数据里有几个字段是用压缩BCD格式来编码的，于是恶补了一下压缩BCD码的基础知识。下面先卖弄一下，然后再来骂骂18M。

学计算机的人都知道，一般十进制数字在计算机中都是转换成二进制来表示的。二进制表示法来表示数字有一个问题，就是小数部分无法保证精度。因为数字的小数部分在二进制下只能表示成n1*(1/2)+n2*(1/4)+n3*(1/8)+...+nn*(1/(2^n))的形式（其中n1,n2,...,n3为0或者1），这样很多能用十进制精确表示的数字，如0.2，用二进制就只能近似表示成0*(1/2)+0*(1/4)+1*(1/8)+1*(1/16)+...，即（0.00110011...)2。这在很多情况下会产生舍入误差。爱国者导弹的控制软件中就曾经有过一个因为这个问题造成的bug，海湾战争中有次伊拉克发射飞毛腿导弹袭击，美国人要发射爱国者拦截，可是由于这个bug导致控制系统当机，于是眼看着飞毛腿击中了一个兵营……

于是，为了保证十进制数字存储的精度，某些人发明了BCD码（Binary Coded Decimal)，并在18M的机器里得到了广泛的应用。是一种通过二进制编码来直接表示十进制数字的方法。在这种方式下，每位10进制数字用一个字节，0-9分别是：
0 0x0
1 0x1
2 0x2
3 0x3
4 0x4
5 0x5
6 0x6
7 0x7
8 0x8
0 0x9

显然这样是很浪费的，于是出现了压缩的BCD码。这个编码用半个字节（4bit）来表示一位数字，这样每个字节就可以表示两位数字。比如，十进制97用压缩BCD码来表示就是0x97，12567就是0x12567。

这个很简单，而且IBM似乎也很general，在WebsphereMQ Integrator里也提供了对压缩BCD码的支持，可是，当我写好Integrator里的数据结构，并把编码好的数据发送到MQ里之后，Integrator报解析错误：packed BCD error, no sign found。啥意思哩？google上查了一堆文档之后才知道，Integrator里面的那个压缩BCD码支持的是COBOL的COMP-3数据类型。这个类型基本上和一般的压缩BCD码是一样的，只有一点区别，就是它的最末4bit不是0-9的数字，而是16进制的C、D、F，用来表示符号位，即这个数字是正数还是负数，C表示正数，D表示复数，F则表示这个数是无符号数。比如0x123F是十进制的123，0x123D则是十进制的-123。可这就是问题了，我用的数据结构中那几个BCD数都在中间，到哪儿去给它找位置塞这半个字节的符号呢？……于是只能自己写数据parse程序……该死的18M!!!

使IBM WebsphereMQ JMS Client不产生RFH2消息头的方法

Wed, 23 Nov 2005 09:30:02 GMT

IBM WebsphereMQ JMS Client在将JMS消息转换成MQ消息时，缺省行为是在消息前添加RFH2头。
这要求接收处理该消息的程序在获取消息时必须能够正确处理或省略RFH2头以得到后面的数据。
显然这增加了程序的复杂性，最好能够让JMS Client不自动生成这个RFH2消息头。

下面就是在google上查到的两种关闭JMS RFH2消息头生成功能的方法：
方法1：这个方法最简单，就是在生成JMS Queue指定Queue名称的时候加上targetClient参数
比如Queue名称为"Queue1",则相应的生成JMS Queue的语句为:

Queue queue=session.createQueue("queue:///Queue1?targetClient=1");

方法2:设置MQ JMS Queue对象的targetClient属性

Queue queue=session.createQueue("Queue1");
com.ibm.mq.jms.MQQueue q = (com.ibm.mq.jms.MQQueue) queue ;
q.setTargetClient(com.ibm.mq.jms.JMSC.MQJMS_CLIENT_NONJMS_MQ); //JMSC.MQJMS_CLIENT_NONJMS_MQ 为预定义整型数,值为1

这个方法的好处是灵活,如果之后需要打开JMS生成RFH2头的功能,只需重新设置targetClient属性即可:
com.ibm.mq.jms.MQQueue q = (com.ibm.mq.jms.MQQueue) queue ;
q.setTargetClient(com.ibm.mq.jms.JMSC.MQJMS_CLIENT_JMSCOMPLIANT); //MQJMS_CLIENT_JMSCOMPLIANT值为0

使用JMS连接WebsphereMQ 5.3的问题

Wed, 23 Nov 2005 07:40:03 GMT

环境：
server: windows 2k 简体中文版
IBM websphere MQ 5.3.0.2 多语言版

client: windows xp sp2 简体中文版
IBM websphere MQ 5.3.0.2 Client 多语言版
Sun JDK 5.0

我按照MQ 5.3 using Java手册上的例子通过JMS连接MQ：
String HOSTNAME = "machine1";
String QMGRNAME = "machine1.QM1";
String CHANNEL = "SYSTEM.DEF.SVRCONN";

QueueConnectionFactory factory=new MQQueueConnectionFactory();
factory.setTransportType(JMSC.MQJMS_TP_CLIENT_MQ_TCPIP);
factory.setQueueManager(QMGRNAME);
factory.setHostName(HOSTNAME);
factory.setChannel(CHANNEL);

QueueConnection conn=factory.createQueueConnection();

运行到最后一行时会抛出异常：
MQJMS2005: 未能为 'machine1:machine1.QM1' 创建 MQQueueManager

而服务器上的事件察看器里也有相应的Websphere MQ错误事件记录：
"无法启动 TCP/IP 响应程序。

试图启动响应程序的一个实例，但该程序被拒绝。

该故障产生的原因可能是子系统没有启动（在此情况下你应该启动子系统），或者是等待的程序太多（在此情况下你应该稍后再尝试启动该响应程序）。原因码是 0 。 "

而我用C写的MPI程序连接完全正常。

google之，发现很多人有同样的问题，但是没有找到方法来解决。

再看MQ的手册，发现MQ提供了几个验证JMS安装是否成功的程序，其中一个IVTRUN是用来
验证P2P连接的，于是运行之，也出现了同样的错误，不过这次给出的提示更详细了：
“正在创建 Connection
捕捉到异常: javax.jms.JMSException: MQJMS2005: 未能为 'machine1:machine1.QM1'
创建 MQQueueManager
链接的异常: com.ibm.mq.MQException: MQJE001：发生 MQException：完成码 2，原因码
2195
MQJE020：队列管理器不支持 CCSID
IVT 已完成”

看来这个问题和CCSID有关，赶紧查手册和配置，果然，Websphere Client Java所用的CCSID缺省为816，而我在中文windows 2k上建立的Websphere MQ队列管理器的CCSID(可通过队列管理器的属性->常规->编码字符集标识察看）是1381，两者不兼容，故无法建立连接。

那就设置一下factory的CCSID试试：

String HOSTNAME = "machine1";
String QMGRNAME = "machine1.QM1";
String CHANNEL = "SYSTEM.DEF.SVRCONN";

QueueConnection conn=factory.createQueueConnection();

这下就OK了。

总结：
使用JMS连接MQ时必须设置正确的CCSID参数，否则连接会失败。

btw：
鄙视一下IBM的Document，例子非常少，看起来就跟天书没什么差别，难怪IBM的support那么值钱呢。