是说各位是不是觉得上一篇有点短 qwq
当然我个人是..... 并没有这样觉得 XD
不过还是多发一篇(那前面是在大声什么
这篇故事有点微妙 qwq
废话! 看标题就知道应该很微妙了齁 XDDDDDD
不知道中文这样翻是否到位
但其实看到原文标题
电算机 梦见るままに 待ち至り
应该就会发现这个故事其实跟某个著名的(ry
总之这个故事的Marvel点很低 (可以说几乎没有，我很担心被警告还是删文 ><)
而且目前也找不到原文的文字网页
故事出自于2012年夏天，由136Hz主办的10人接力百物语朗读活动
这一篇是排序第10的136Hz本人朗读的最后一篇故事
故事由读者投稿，所以大概只有投稿者跟136Hz自己有文字档了 qwq
附上原故事朗读连结：
http://www.youtube.com/watch?v=6pOyMoZC5EE
====================正文开始的分隔线====================
这是距离现在超过一轮生肖以前的故事了。
当时，我在某间承接外包业务的公司里，
担任企业用大型电脑的夜间操作员。
(P.S 作者是派遣公司员工，所以是承接外包IT业务的公司雇用的外包人员)
我当时负责的主机是某日本制造商──N公司的产品。
工作的内容就是把系统在每天傍晚以前收集到的所有资料依照排程执行处理，
并且确认处理结果。
如果没有问题，就输出帐册之类的文件。
工作内容相当简单，
没错，就是几乎不怎么需要技术基础的轻松工作。
也是有极小的机率会发生处理结果错误的状况，
那时候就会需要有所应变。
但依照那间公司的政策，
数据复原跟重新执行程式工作(Job)的动作只有正职员工可以做，
所以对我来说，这个工作就只是重复一些非常没意义的单纯例行公事。
在这样的日子里，千禧年问题以及相关因应对策的话题甚嚣尘上，
现在想想，那整件事情真是雷声大雨点小，令人感到有些无言以对，
但对于当时的我来说，还算是个很大的问题。
之所以会如此，是因为我当时负责的大型电脑因为规格上的问题，
在公元2000年以后就无法再使用，所以与客户之间的契约因此而结束了。
而另外一台我负责的主机，
则是客户想要把整个系统转成他们公司自己维护，
所以我这个人就变成了冗员，下一次续约很有可能会有危险。
我因此而感受到后脑勺传来一阵阵寒意，
就在我想着自己必须转移技术专业，
从大型电脑跳去个人电脑或服务器的时候，
那间公司的正职员工跟我接洽了另外一件业务。
那是在I公司制造的大型电脑上运作的，某间成衣公司的系统。
我当时根本就没有摸过I公司的产品系统，
所以我没有给他很正面的回应，
但是因为我所属的派遣公司的影响，
事情发展成我要接受该位正职员工的相关教学。
大型电脑大致上可以分成两大类，
也就是日本N公司的产品，还有I公司的产品。
如果要简单地说明，大概就像是PC-9801跟IBM PC的分别了吧。
总而言之，两种产品的操作概念完全不同。
讲真的，我是很想乖乖等契约到期，然后去找一些别的工作，
但因为一些现实层面的因素，所以我非得承接这个系统的业务不可。
另外，还有一个很重要的因素让我不想跟这件事情扯上关系。
那就是──那个系统常常出问题，就是常常当机啦。
一般来说，商务用大型电脑的系统通常都是用COBOL语言开发的，
只要系统一旦正式开始运作，通常就可以运作得相当稳定，这是我当时的认知。
实际上，以我原先负责的系统来说，跑Job跑到当机的状况，
一年里可能也不过就那么几次，或根本就不会发生。
但是，那个系统状况好的时候，是一天就可以当一次，
状况不好的时候还会当两、三次，
简直就是当机当到理所当然，是一套跟笑话没两样的系统，
老实说我心里的想法是：“拜托你们饶了我好吗”。
所以，公司内部也出现了一些声音，
认为即使是从系统营运端的角度来看，
也实在没办法再让系统在这种状态之下继续跑下去。
公司似乎也已经为了这件事情而跟客户讨论了好几次，
但因为对方相当一毛不拔，所以相关的交涉也就因此而难产了。
不过，每当Job执行到当机的时候，
客户就一定会在半夜里被通知的电话吵醒，
而这一点倒是打中了罩门，让对方终于做出了要修改系统的决定。
所以，除了操作电脑系统以外，我又得负责解析原始码的工作。
详细的状况这里就不多说了，总之程式的内容真的写得十分粗糙。
而我则是跟正职员工合作，
持续进行确认程式说明书跟原始码内容的工作。
“你看看，就连高职生的回家作业都比这东西好一点吧？”
工作过程中，我不小心说溜嘴，把心里的抱怨讲了出来。
于是正职员工对我说：
“据说这间公司在专案谈成以后，又对开发程式的公司杀价杀得很凶，
开发公司好像在系统完成之后就拒绝了所有的技术支援需求的样子，
所以有些程式码是他们公司自己想办法挤出来的，
每次一出问题就东挖西补，才会变成这样的啦。”
我仔细看了一下，在那种只能读取数值作为引数的处理程序里，
竟然把资料来源种类指定成ANK文字(半角英数文字+半角片假名)，
另外也有发生完全相反的状况。
这种程度的问题，根本可以在输入数据的程式里预先做好防范了不是吗？
像这样的问题我们发现了非常多。
另外，因为系统改写的次数也非常之多，
与客户讨论以后，结果最后决定要全面性地更换这个系统。
虽然我当时也很高兴可以从这种苦行之中获得解放，
但事实上是从这时候才要正式开始对旧版系统进行全面性的解析作业，
提出系统需求、设计程式、进行各式各样的相关测试等等等等，
新系统要正式运作起来根本就是很久很久以后的事情。
然后呢，进行解析作业的某天夜里，
在检查负责产生帐册文件的某几个子程序(Subroutine)的时候，
竟然发现了一些连说明书里也没有记载的Subroutine。
那些Subroutine跟某个每月/每周处理程序连结在一起，
只要那个处理程序有动作，系统就会执行其中一个Subroutine。
那个Subroutine的功能是从数据库里提取某些特定的资讯，
等到这个Subroutine跑完以后，就会启动下一个Subroutine，
把所提取的资料制作成帐册文件。
接下来，下一个Subroutine会修改这个文件的档名，
然后它会被储存到一直被设定成唯读资料夹的帐册文件资料夹里面。
它的程式架构就是这样。
我对正职员工报告了以上这些奇妙的Subroutine的运作模式。
“我看看，它想要加载的数据，
是第一行的第12字符开始，1个字符，
这边是从第六行的第13字符开始，3个字符…”
像这样比对File Layout，调查程式码的过程里，我发现了一件奇妙的事情。
“这间公司的File Layout里还有包含Record Name耶。”
“真的耶，就是因为连这种鬼东西都要写进去，
才会让程式出错的啊，真是的。”
就在一连串的抱怨的过程之中，我发现了那个Subroutine所要呼叫的数据，
并不是储存在Record File里面的资料，
而是从Record Name之类的，内容不会变动的字段里，
提取出文字列的一部份。
“这个程式是怎么回事啊，搞不懂它要做什么耶。”
我看着那些程式所要撷取的文字列抱怨了起来。
正职员工看着我撷取出来的文字列，露出了一副为难的表情。
“这…是不是可以读成ia ia cthulhu啊？”
“洛克莱夫特是吗？克苏鲁的呼唤那个？”
“那就把这个部分的Job撷取出来执行看看吧？”
正职员工的表情突然间奇妙地变得有点兴味盎然的感觉。
“我知道了，那么，我就改写一部份程式码，
让程式可以把Spool File打印出来好了。”
所以我就花了大概两个小时，制作可以执行的JCL，
尝试执行这一系列的Job，
看看最后从打印机里输出的文件内容会不会是…
结果还真的是那些诅咒的文句。
“in his house at r'lyeh dead cthulhu waits dreaming.”
(在拉叶城的宅邸里，死去的克苏鲁在睡梦中等待。)
“ph'nglui mglw'nafh cthulhu r'lyeh wgah'nagl fhtagn”
“这不就是…拉叶书(R'lyeh Text)？”
正职员工看着那些文件喃喃自语…
“呜哇，这东西要超过100页了啦！”
打印机不断地吐出印上了那些内容的纸张。
这时我在机房里闻到一股跟打印机所散发的臭氧味不一样的，
某种似乎有点腥臭的味道，会是我的错觉吗？
“呜哇，页数都超过200页了耶。”
“这样太浪费纸了，快删掉那个Spool档。”
于是那个夜晚就这样结束了。
后日谈：
所以我们发现，那个系统每次实施每月/每周处理的时候，
都会启动那一串Subroutine，由电脑咏唱那些咒文。
而且那间公司每个月都会有几天笼罩着一股有如海风一般腥臭的味道，
虽然我猜想那有可能只是印制帐册文件的时候，
从打印机里发出的臭氧味就是了。
那间公司大楼的楼上就是员工宿舍，
因为一些原因，所以某次上夜班的时候有机会听人分享怪谈，大概就是一些：
“据说在公司旁边的河里，有人看见过河童。”
“有人在公司大楼里看见外面有半鱼人。”
之类的怪谈故事。
这到底是不是因为牠们回应了电脑的呼唤了呢？
曾经参与过软件系统开发工作的人应该可以理解，
系统开发这种工作是没有办法单线作业的，
这种程式架构实在不太可能是某一个人自己偷偷写进去的。
据正职员工说，就像前面讲的那样，
开发系统的公司跟客户之间在金钱方面似乎有过相当大的争执，
所以我想，这应该不是单一员工的个人行为，
很有可能是整个开发小组一起合谋的。
有办法让人做出这种事情的怨念，
让我感受到，人类所造的罪业果然真的很可怕啊。