AS400银行核心系统开发中的技术总结--多成员表
作者：张广
随着国家的自主安全可控号召，AS400系统在银行IT逐渐退出了。因此很遗憾，重新规划开发的AS400新核心系统就告一段落。不过，在开发过程中，有不少技术值得总结共享，如果有谬误，或有更优方法，也请大家指正。
开发中使用的技术，基本上都是参照IBM信息中心的官方文档，链接在这里
一、背景
银行核心系统通常生命周期在10年左右，现在随着银行系统的数量和复杂度增加，系统的生命期也有逐渐变长的趋势。通常核心系统上线时，很多数据表的记录数并不太多，而当系统运行年限越来越长，巨型数据表就越来越多。
另外，随着城商、农信的省级集中，用以前针对城市级商业银行的系统，来应对省级的数据量，原先规模合理的表，也会变成巨型表。
在实际项目中，已经遇到记录数上亿，和十亿级别的表了，不光严重影响系统性能，在7*24小时不间断运行条件下，数据清理都是个难题。以往的系统，在这方面考虑是比较少的，大概是因为系统设计实现者通常只管上线，不会长期维护，而且原先系统面向银行的规模较小。
因此，要么没考虑大数据量表的拆分，要么常处理方法也只是简单区分下当前表和历史表，在日终时做个当前倒历史的批量（历史表巨大的话，倒历史时间也会变得很长）。
二、数据表分析
分析银行的数据表，容易产生很多记录数的案例，就会发现通常有两种状况比较常见。
一种是明细流水性质的表，产生一笔就会新增一条记录，日积月累就会变得很大。这里面大多数都可以用日期时间为顺序和查询依据的，例如账户明细表，传票表等。
这类表很明显可以按日期进行划分。超过一定的期限以后，历史的数据就可以清理了，通常历史查询功能由ODS之类的数据仓库系统提供。经过清理后，数据量可以保持稳定。
另一种是账户主表，凭证主表，客户信息表等，随着系统多年使用逐渐增长，而且可清理的不多，数据量随业务发展总体呈增长趋势。
三、解决办法介绍
这里我们看看在Firebird系统中巨型表的解决办法。从根本上说，应当将大表分小，并且要适合使用的情景。在开放平台数据库，有分区表的概念，而在400平台，对应的就是*FILE的多MEMBER。
对于可按日期划分的表，我们可以带日期为MEMBER名，每日一个MEMBER，预先创建好，无需倒历史切换，解决了7*24小时和数据清理的问题。
对于主表，可按主键号码或某些字段hash计算分MEMBER。例如，客户表按客户号的hash分区，凭证表按凭证号的hash分区。但账户表要按账户所属机构号分区，这是为了优化结息批处理性能，利于每个按机构并发的结息程序只访问一个MEMBER。
400系统对多MEMBER的限制有哪些呢？
首先，同一个*FILE支持的MEMBER数量，最大为32767个。按每日分区计算，大约可以支持90年。按hash计算，10亿级别的表hash到100个MEMBER，每个MEMBER仅1000万记录数量。
其次，单个MEMBER最多记录数为2^32，大约42亿。但实际上记录数过多，访问操作性能会指数级下降。单个MEMBER内记录数在1000万级别比较合适。
最后，对于LF文件的单个MEMBER，能关联PF的MEMBER数量是有限制的，大概是32个，但实际使用中LF的MEMBER命名与PF相同，完全的一对一建立。如果要搜索多个MEMBER，在应用程序中循环读取实现。
有关多MEMBER的命令有以下这些：
CRTPF或CHGPF时指定MAXMBRS为*NOMAX。
CRTLF或CHGLF时指定MAXMBRS为*NOMAX。
ADDPFM 在PF中新增一个MEMBER。
ADDLFM 在LF中新增一个MEMBER。
RMVM 删除一个指定的MEMBER。
CLRPFM 清空一个MEMBER的所有记录。
下面的CL程序是给PF和LF增加连续日期的MEMBER例子。MEMBER名类似M20150821。
下面的CL程序是给PF和LF增加连续hash的MEMBER例子。MEMBER名类似M01到M99。另外还有3位数M001到M999的程序就不贴了。
建立起多MEMBER文件以后，在应用程序中使用就有注意的地方了。
首要原则，对上层组件尽量透明，把多MEMBER的操作尽可能封装在数据表访问组件内部，对外就像操作的是一个文件一样。这涉及到核心系统整体规划上的“交易--模块公有组件--模块私有组件--数据访问封装”体系，就是另外的话题了。
那么，在RPG程序中，多MEMBER文件的代码怎么写呢？
主要区别在F表定义上。F表定义文件的时候，选项部分需要多写两个，EXTMBR(V_MBRNAME) USROPN。EXTMBR用于根据变量V_MBRNAME的值指示要操作的MEMBER名，USROPN则是在程序执行到OPEN语句时再打开文件。
通过程序中先给V_MBRNAME赋值，再执行OPEN语句，就可以操作指定的MEMBER啦。值得注意的是，前面介绍过激活组会保持文件的打开状态以供下次调用使用，多MEMBER时，不能简单通过%OPEN()内置函数来判断文件是否已打开。
因为%OPEN()函数对不同MEMBER不作区分，比如已打开M003，这次虽然V_MBRNAME赋值了M998，但%OPEN()判断时仍认为文件已打开，必须要通过打开的MEMBER名是否相同来额外区分。
RPG对多MEMBER表的使用例子节选如下。