UMS系统数是否可以在OpenJDK下运行？

经过实际测试和检验，UMS系统完全可以在OpenJDK下稳定运行。

注：OpenJDK一般用于Ubuntu、Fedora、Red Hat Enterprise Linux、openSUSE、Debian GNU/Linux和OpenSolaris。

UMS系统数据库模式下的数据处理效率如何？

一般情况下，系统基本仅采用最简单的数据访问机制。在这种基本配置状态下，系统处理速度也能轻松达到每秒50个数据包，能满足小客户的数据处理需求。

对于最新的版本，数据库JDBC访问机制上已经做了很多优化，系统可以支持对数据的并行和分布式处理。系统数据库接口部分的处理速度可以很轻松地实现倍增。适合于大客户的数据处理需求。

UMS系统数据库模式下的如何进行数据重发？

对于需要重发的数据进行重发，有两种方法：
        1)如果需要重发的数据不在发送数据表中，则需要重新插入相关数据。
        2)如果需要重发的数据仍在发送数据表中，则可以将该数据列的result改为-1，并设置cid和status为NULL即可。设置成功后，系统会自动对相关数据启动重发功能。此方法比较方便，但可能会导致该数据先前已存在的状态报告无法匹配。

如果需要对出现发送错误的数据进行重发，一定要弄清楚大致的错误原因。在未弄清楚原因前，反复重发可能会导致重发“死循环”。即发送数据给网关结果出错，发送出错又进行重发，如此反复数据包会在系统内多次循环发送。

UMS系统数据库模式下的状态报告机制如何？

对于相对旧的版本，状态报告机制简要描述如下：
        1)无论发送的信息在设定超时时间内（一般为72小时）是否能获得状态报告，则直接将状态报告插入到上行表（receiver）中，且该条记录的registers为奇数。
        2)上行表（receiver）中的状态报告信息的cid字段对应下行表（transmitter）中的tid字段。

对于最新的版本，状态报告机制简要描述如下：
        1)如果发送的信息在设定超时时间内（一般为10分钟）能获得状态报告，则直接更新下行表的status字段。
        2)如果发送的信息在设定超时时间内（一般为10分钟）未能获得状态报告，则直接更新下行表的status字段为“TRANSMITTED”。以表明发送数据已经传输至网关仅仅是最终状态报告尚未返回。
        3)对于超过设定超时时间后返回的状态报告，则直接将状态报告插入到上行表中，且该条记录的registers为奇数。
        4)上行表（receiver）中的状态报告信息的cid字段对应下行表（transmitter）中的cid字段。
        经过这样的调整后，可以比较容易的确定发送数据的最终状态；避免频繁的跨表匹配查询；简化发送统计和处理方式。

如何使用UMS系统发送WAPPush？

对于相对旧的版本首先要将系统配置到处于“二进制数据库接口模式”下。例如：jssmp网关类型。

然后下载一个WAPPush编码器。利用WAPPush编码器制作一个短信数据。例如：设置标题为“SimpleTeam”以及链接为“wap.simpleteam.com”，可以得到的二进制编码如下：

0605040B8423F005060603AE81EA8DD60……

        WAPPush编码器会提示有关CMPP协议的相关设置。不过在使用UMS系统的JSSMP数据库接口时，需要如下填写：

insert into [下行表] (destinationPeers,coding,content) values ('13901056789',0x00004004,0x0605040B8423F005060603AE81EA8DD60……);

如果要设置多条，则需要修改registers的部分参数，以设置pk_total和pk_number。具体细节请参考《SSMP数据库接口》部分的文档。

对于最新版本，只需要在options参数里面填写otaType和reference两个参数即可。有关的拆分、编码均由系统自动完成，无需人工操作或者干预。