我毕业后的第一份工作是在Z行软件中心，在那里，我度过了7年多的时光。这期间我几乎每天都要跟I公司生产的大型机打交道，因为我所在部门负责的软件产品就是基于该大型机平台（行内人一般称为“主机”）进行开发的；也因此，我掌握COBOL开发语言。前两年美国、日本时不时爆出缺少COBOL语言工程师的新闻，我们那些过去的同事碰到时还打趣“将来失业了可以去美国、日本打工”，这当然是闲话。真正在这7年里体会更多的还是大型机的可靠、稳定、超强任务吞吐能力，还有大型机开发运维体系的完善。
诡异的是，到了现在，过了这么些年后，大型机体系当初带给我开发的种种便利都记不起鲜明的印证事例，留在记忆里的反倒都是有关大型机的负面故事，是我踩过的“大”坑，主要有下面几件。
数据丢失案
2010年，Z行正在进行新一代核心系统的推广上线，我其时在Z行数据迁移小组；该小组的工作是从老核心中抽取数据，按照新旧核心数据映射的规则，将老核心数据转换为新核心能够接受的数据，并灌入到新核心中。大概7、8月份的时候，正值一个大的迁移批次，要将Z行好几个省的旧核心数据一次性迁移到新核心中；在进行测试的过程中，我们发现从老核心抽取的数据与灌入到新核心中的数据在条数上一直对不上，灌入到新核心中的数据总是少一些。
一步一步定位后，发现是在用QSAM方式将数据写入Extended-format sequential data sets时（记不真切了）有一个条数上线，超过上线后就写不进去了，并且没有提示和报错，因此丢了数据。当时任务压得很紧，我们通宵调试，某天定位到问题后我就休息了。待早上我在办公区醒来，当时的领导SJX笑着告诉我说，他调试到了精确的文件条数上线，是32768（同样记不真切了）。
这个问题最后反馈给了I公司中国公司，答复是说要提交到美国的实验室分析修复，预计需要6个月。我们项目等不及，换了一种文件访问方式，绕开了这个问题。不知后续这个问题修复了没?
数据误删案
2013年左右，我早已转入Z行核心系统项目组，参与投产后核心系统功能的升级完善。当年4、5月份一个周六的早上5点左右，我睡得正香，做着甜甜的美梦，忽然手机铃声炸响，我迷迷糊糊地接起电话，是数据中心同事TFH。TFH焦急地问:"有个表有2000万条数据，进行历史数据清理后，大概还剩300万条。这正常不？”我像被兜头浇了一盆冷水，立马清醒了，回答到：“肯定不正常。我这就过去。”
挂掉TFH的电话，赶紧通知其时的领导WK，然后打车去数据中心。到了现场后，调出备份数据进行测试分析，问题逐渐定位：在我之前提交的历史数据清理脚本中，一个用来圈定清理数据范围的表达式A&&B||C&&D在I公司最新的10.0版本数据库中是按照（A&&B||C）&&D顺序解释执行的，极大地扩大了数据清理的范围，造成了上述后果。让我气愤不已的是I公司驻场人员置“计算机科学领域表达式中&&符号优先级高于||符号”的常识不顾，一直在引导把锅扣到我头上，Z行领导也是让我拿出更有力证明的态度，大家彼时近乎迷信I公司。我于是在之前开发用的I公司8.0版本数据库中重复提交了该脚本，是按照（A&&B）||（C&&D）逻辑执行的，I公司的驻场人员才闭嘴。
问题原因确认后，紧急提交了新的脚本，通过备份数据恢复了该表。I公司后来也专门修复了10.0版本数据库中的上述问题。
幽灵数据案
也是2013年左右，我们在开发测试时发现，交易回滚后MQ之前已消费或者删除的消息数据又回到了消息队列中，好像是隔一个恢复一个的样子（再次，记不真切了），像幽灵一样。
经过组内沟通后，CY老师反馈之前遇到该问题，他是组内的老资格了，因此很快就找到了问题症结，应该在于选择的MQ访问方式和交易提交回滚时机的配合。于是我们穷举测试了I公司MQ的各种访问方式，记录了不同场景下数据的表现，做成一个开发指引表格，供组内人员在应用中按图索骥，选择适合的访问方式，规避掉潜在的问题。
这件事既没有影响生产，也没有曲折的分析过程，因而没有前两件事情有戏剧性，不过它涉及到的底层技术问题一点也不简单，只是之前有人给蹚过路了。
后记
以上就是我现在印象比较深刻的几件往事。
长时间地基于大型机进行开发设计，我自身的思维习惯都在不知不觉中浸染了很多大型机体系的理念。因此，写出上述故事，不是为了证明大型机体系不好，大型机体系也不是我提到的几件小事能够否定的。写出这些故事，主要是想说明大型机体系不是生而完美的，也是在实践中不断完善的。那7年的时间里，我曾通读过I公司数据库的支持书籍，其中也能看到，数据库的一些重要功能也不是一开始就设计好的，像分区表、utility等，都是后续根据市场客户需要逐步加入的功能。我国很多商业银行当前正在进行信息系统自主可控的努力，有了大型机的示例，我相信，经过我国广大技术人员的奋斗和实践上的不断反馈完善，我们一定可以打造出媲美大型机体系的新的技术体系。
末了，还想说，大型机真是一个好东西，是我国应该薅的一颗“工业皇冠上的明珠”，在将来空间受限却需要可靠高性能实时运算的场景下大有前景，如空间站、潜艇、载人深潜器、宇宙飞船等。
