昨天早上，接到以前同事的电话。
“你还记得你以前写的XX程序吗？”
“啊，怎么啦？”
“XX单位用的时候，又出现时间限制了。”
“我槽！他们还在用啊？！！！”
“是啊，找到我这儿来了。我记得你以前告诉过我修改办法，我还记在笔记本上，但时间太长了，笔记本已经找不到了，只能找你了。”
“…………（程序猿就注定应该是接盘侠吗？）”
于是，让他把我电话号码给对方，让对方晚上给我打电话。
晚上，刚到家，就接到对方的电话。
告诉对方，我得找一下源程序，让他先加我微信，改好后给他发过去。
从NAS中翻出当年的源文件包，很袖珍，才2M多。
一边改，一边回忆……
这套程序是1999年开始写的，因为是上班时间写的，所以算是职务软件，虽然岗位职责中并没有编程这一条。
程序在DOS环境下运行，汉字支持是UCDOS，编程软件是FOXBASE。
程序完成后，解决了基层单位数据录入、计算、清单、发票、报表等全套业务流程，所以马上在各基层单位得到了应用。
而且，由于程序的实用、高效，所以马上又被几家兄弟单位拿去推广了。
其实，当时上级部门考虑到需求，已经组织专业人员开发了一套系统，并组织各单位进行培训，准备推广这套系统。
无奈，开发人员不熟悉业务，也没有认真做业务流程调研，结果写出来的系统根本无法实用。
反倒是自己，因为不知道上级已经在开发系统，所以几乎在同时捣鼓出这套程序。
由于自己就是做业务的，所以有哪些需求，该实现什么样的功能，根本就是信手掂来，而且，最大程度地优化了操作步骤，尽量做到能少按一个键就少按一个键，所以对长时间做重复性操作的使用者来说，是很容易就能体会到其中好处的。
所谓“没有对比，就没有伤害”，听兄弟单位后来反馈过来的消息，他们基层单位的操作员们，都强烈要求使用我的这套程序，而坚决不使用上级部门开发的程序。
这尼玛也太打脸了吧？
但结果是，几家兄弟单位居然就把我的这套程序给推广应用了，而上级部门居然也就默认了。
其后几年里，根据业务需求，自己不断地升级着这套程序，到2004年，已经升级到2.5版了。
也就是在2004年，上级开始推广广域网系统，要求所有数据全部集中，这套单机版的程序也就顺利地完成历史使命了。
然后，再谈谈时间限制的问题。
在这套程序的数据录入模块中，有一个过程是需要输入数据时间的，包括年、月、日。
为避免操作员输入了奇怪的时间，程序中加了一点限制和判断，大约就是这么写的：
如果输入年份小于1999年或大于2005年（这样数据年份只能在1999到2005之间）或不是4位，则提示“年份输入不符规范,请重新输入”。
如果大家的数据都在2004年一并转入上级的广域网系统，就根本不会有后面的故事。
但有个单位的部分数据，由于种种原因，没有资格进入广域网系统，所以还在这套程序中继续做。
所以，2006年1月，这个单位就遭遇了第一次时间限制。
于是他们就去找分管部门，由于我当时已经不在那里了，后面接手的人（也就是上面提到的同事）找到了我，我就告诉他程序的修改方法，他就记在了笔记本上，并去将程序中的时间从2005修改成2010。
因为他不认为这个程序还需要再继续运行5年。
所以，2011年1月，这个单位就遭遇了第二次时间限制。
于是他们又去找分管部门，由于这个同事也调走了，于是又找到了我，我说你们把电脑搬来吧。
搬来后，边开电脑、打开程序，边说明要改什么地方。
“看着，我将这里改成2020，这样你们就可以一直用到2020年了。”
大家都笑了，怎么可能呢，再怎么着这个程序也不可能再用10年吧？
所以，2021年1月，这个单位就遭遇了第三次时间限制。
……
改好程序，很快啊，2020变成2030了。
我再赌这个程序不可能再跑上10年，因为他们那台老电脑没得可能再坚持10年。
但，经历过了2020年无数奇幻的我们，真敢坚信第四次时间限制不会再出现吗？
所以，我认真地写了一个说明文档，告之：哪个程序，第几行，将什么改成什么，然后拷贝到哪个目录下。
并在说明最后，友情提示：
记得经常性地做备份，以这么老的机器，这么老的系统，出问题是随时可能发生的。为避免头疼，切记：备份！备份！备份！
……
将改好的程序和说明文档，一并用微信给对方发了过去，并提醒要拷贝到某某目录，拷贝前记得做备份。
“这个目录怎么进去？”微信上，对方问道。
我迟疑了一下，缓缓敲上几个字：“DOS操作，会吗？”
迟疑的原因是，我突然想起：
对方的声音很年轻。
而这个程序，从1999，到2021，已经，22岁了……
————最终结果的分割线————
最终结果在
230楼。
