无标题无名氏No.59328151 只看PO
2023-08-30(三)13:08:30 ID:kvyVE4n 回应
无授权转载一些我个人喜欢的怪谈( ゚∀。)
第一篇《取子箱》
无标题无名氏No.69010341
2026-07-07(二)01:55:00 ID: kvyVE4n (PO主)
讲真的,我是很想乖乖等契约到期,然后去找一些别的工作,但因为一些现实层面的因素,所以我非得承接这个系统的业务不可。
另外,还有一个很重要的因素让我不想跟这件事情扯上关系。
那就是——那个系统常常出问题,就是常常宕机啦。
无标题无名氏No.69010347
2026-07-07(二)01:55:32 ID: kvyVE4n (PO主)
一般来说,商务用大型计算机的系统通常都是用COBOL语言开发的,只要系统一旦正式开始运作,通常就可以运作得相当稳定,这是我当时的认知。
实际上,以我原先负责的系统来说,跑任务跑到宕机的状况,一年里可能也不过就那么几次,或根本就不会发生。
但是,那个系统状况好的时候,是一天就可以宕一次,状况不好的时候还会宕两、三次,简直就是宕机宕到理所当然,是一套跟笑话没两样的系统,老实说我心里的想法是:「拜托你们饶了我好吗」。
无标题无名氏No.69010349
2026-07-07(二)01:56:01 ID: kvyVE4n (PO主)
所以,公司内部也出现了一些声音,认为即使是从系统营运端的角度来看,也实在没办法再让系统在这种状态之下继续跑下去。
公司似乎也已经为了这件事情而跟客户讨论了好几次,但因为对方相当一毛不拔,所以相关的交涉也就因此而难产了。
不过,每当任务执行到宕机的时候,客户就一定会在半夜里被通知的电话吵醒,而这一点倒是打中了罩门,让对方终于做出了要修改系统的决定。
所以,除了操作计算机系统以外,我又得负责解析源代码的工作。
无标题无名氏No.69010351
2026-07-07(二)01:56:23 ID: kvyVE4n (PO主)
详细的状况这里就不多说了,总之程序的内容真的写得十分粗糙。
而我则是跟正职员工合作,持续进行确认程序说明书跟源代码内容的工作。
「你看看,就连高职生的回家作业都比这东西好一点吧?」
工作过程中,我不小心说溜嘴,把心里的抱怨讲了出来。
无标题无名氏No.69010353
2026-07-07(二)01:56:41 ID: kvyVE4n (PO主)
于是正职员工对我说:
「据说这间公司在项目谈成以后,又对开发程序的公司杀价杀得很凶,开发公司好像在系统完成之后就拒绝了所有的技术支援需求的样子,所以有些代码是他们公司自己想办法挤出来的,每次一出问题就东挖西补,才会变成这样的啦。」
无标题无名氏No.69010357
2026-07-07(二)01:57:08 ID: kvyVE4n (PO主)
我仔细看了一下,在那种只能读取数值作为自变量的处理程序里,竟然把数据来源种类指定成ANK文字③,另外也有发生完全相反的状况。
这种程度的问题,根本可以在输入数据的程序里预先做好防范了不是吗?
像这样的问题我们发现了非常多。
③ANK文字:半角英文+数字+片假名。
无标题无名氏No.69010359
2026-07-07(二)01:57:55 ID: kvyVE4n (PO主)
另外,因为系统改写的次数也非常之多,与客户讨论以后,结果最后决定要全面性地更换这个系统。
虽然我当时也很高兴可以从这种苦行之中获得解放,但事实上是从这时候才要正式开始对旧版系统进行全面性的解析作业,提出系统需求、设计程序、进行各式各样的相关测试等等等等,新系统要正式运作起来根本就是很久很久以后的事情。
无标题无名氏No.69010362
2026-07-07(二)01:58:18 ID: kvyVE4n (PO主)
然后呢,进行解析作业的某天夜里,在检查负责产生账册文件的某几个子程序(Subroutine)的时候,竟然发现了一些连说明书里也没有记载的子程序。
那些子程序跟某个每月/每周处理程序连接在一起,只要那个处理程序有动作,系统就会执行其中一个子程序。
无标题无名氏No.69010365
2026-07-07(二)01:58:38 ID: kvyVE4n (PO主)
那个子程序的功能是从数据库里提取某些特定的信息,等到这个子程序跑完以后,就会启动下一个子程序,把所提取的数据制作成账册文件。
接下来,下一个子程序会修改这个文件的文件名,然后它会被储存到一直被设定成只读的账册文件文件夹里面。
它的程序架构就是这样。