1980年代初期，我在PABX系统公司担任硬件工程师，当时，软件在PABX系统设计中已经占据主导地位了，因此，来自浮动闸输入的程式码漂移线(errant line)也可能轻易地导致错误。在不断听到硬件和软件设计师激烈的交相指责后，我发誓，在我的除错过程中绝不要再重蹈这些覆辙。正是抱持着这种想法，才有了以下这段真实故事。
故事开始于一通来自我们公司英国办事处的电话，主要内容是抱怨一些最新发布的硬件，或是由PABX的产品所引发，在随机通话中出现的单向通话(one-way audio)情况。此外，尽管并非经常出现，但在分机之间的通话可能会在PABX系统运作中接收到来自其他通话的音讯，这个问题很令人担心，因为它可能潜藏着法律责任。
一通来自伦敦的电话
CEO很关注这个问题，而我们则拼命地试图在总部实验室复制问题，但并没有成功。很快，最后的决定是我和软件设计师必须立即飞到英国以设法解决问题。CEO随后设法让我的护照在仅仅几天内更新，因此，软件设计师和我在那个周末都准备好飞到英国了。
在前一个周五下午，我们的CEO把我们叫到他的办公室，我们发现，我们位在美国东南部的技术支援专家已经成功地复制了同样的问题。我们的总裁当晚因为这个问题赶回公司，CEO也安排在当晚将我们送到美国技术支持办公室。我急忙打包行李，踏上了我首次的里尔喷射机(Lear jet)飞行之旅。
飞机上的迷你酒吧有助平息紧张的神经。几小时后，我们终于坐上计程车前往办公室，当时我们已经足够清醒，能与司机就美国政 治到参战等极端观点任意辩论。过了午夜后，我们终于扺达，并短暂的睡眠后直奔办公室而去。
立即检查程式码
这个办公室拥有的PABX设备具备能够产生流量的特殊软件，可驱动第二部测试中的PABX设备。尽管我们已经在我们的实验室中使用相同的测试软件进行相同的设置，但这套系统不知为何，每隔几小时便会产生一次故障。我们花了24小时仔细研究这套系统，一次次地检查讯号，撷取执行中的CPU程式码并重新读取组合语言程式码。
一切似乎没有什么不妥，但错误仍然接连发生。幸运的是，我们发现一个罕见但不断重复的特定音讯故障，这将我们的关注范围缩小到了系统中的特定音讯交叉点。这种特殊的音讯故障是指引我们的最佳明灯，我立即设置了分析仪的CPU追踪器以撷取这个可疑音讯交叉点设备的暂存器写入周期。到当天深夜，疲劳和烦躁一度让我过早做出结论：我们在追逐的是一个软件故障。不过我并未说出口，而是重新考虑这个导致错误状态的交叉点是否是由硬件故障所导致。
共 2 页：1 2
电子工程专辑
