迫在眉睫 　　随着公元2000年的临近，全世界计算机系统面临的2000年问题已迫在眉睫。如处理不当，会出现文档被错误撤消、系统被关断等危险。 　　所谓2000年问题，是指计算机系统对年号的表示不是采用4位数，而是为了简化起见只用后两位数表示。例如1980年表示为“80”，而2000年后的年号将变成“00”或“0X”。这样计算机会把2001年误认为1901年，因而铸成大错。由此会使得对2000年后的日期，以及需要进行的时间期限计算、时间先后比较等各种处理都出现错误。 　　不仅仅是到了公元2000年1月1日才会出现2000年问题，如果计算机系统要处理有关3年后日期的工作，则从1997年起便会出现问题。 　　由用户企业自己开发出来的应用程序和由厂家提供的操作系统等基本软件，都有可能成为引起2000年问题的原因。2000年问题的“症状”表现为： 　　（1）在计算天数和判定先后时，会发生大小关系正好颠倒的情况。例如出现“00”减“99”的情况时便是如此，由此得不到正确的结果，因而便会进行错误的处理。 　　（2）指定保存期限的文档，会因期限计算错误而被错误撤消。 　　（3）程序和系统可能因此而无法工作。 　　（4）在图表、打印用的程序中，通常会对简化的年号自动加上两位“19”然后输出，于是本应输出“2000”，结果输出了“1900”。 　　（5）通常越新的数据使用越频繁，所以系统会把新的数据放在最容易访问的位置，以缩短对其访问的时间，但是如果不解决2000年问题，反而会把2000年的数据当成老数据对待。结果，访问的时间反而加长了。 　　问题严重 　　美国著名的加特纳（Gartner）集团的一份调查报告认为：全世界90％的计算机应用系统将在1999年全部陷入瘫痪。因为2000年问题将使日益普及的信用卡支付系统、所有含有日期的计算机交易系统（如证券交易等）、计算系统以及关系到国计民生的大型系统，都陷于瘫痪。虽然每一应用系统中大约只有4％的码段（程序的内容）需要改写，但这些码段却遍布在系统的90％的模块中，这意味着需要对数以百万计甚至更多的码段进行挑选并对其改写，而一旦在改写中出现错误，不仅前功尽弃，而且还要花数倍于改写的时间去寻找错在哪里，再对其进行修改使程序恢复正常。 　　问题的严重性还在于不是所有的人对此都足够重视。部分信息部门的负责人存在着以下的认识误区： 　　（1）认为2000年问题只是简单的技术问题，以为只要把原来表示年份的二位数转换为四位数字即可。殊不知仅要寻找哪里存在需要进行这样转换的数字便牵涉到许多方面。除了计算机系统本身和用户所用程序外，还涉及所要使用的文件和数据。一般性的维护工程无法完成这种转换。这种转换是涉及所有部分的费时费钱的工作。 　　（2）以为还有足够时间。实际上到1999年12月31日只有约一百多个周末。因为在银行和企业中，只有周末才允许进行有关测试、改造。假定一个系统有8000个程序，每个程序有1500行，进行转换工作便需24个人年。可见时间的紧迫。 　　（3）认为车到山前必有路。以为自然会有人提供自动转换工具。殊不知不是所有语言都有转换工具，不是所有平台都有转换工具，而且任何工具都无法发现同日期有关的全部项目。所以最后仍有一半以上工作需要人力去完成。 　　（4）以为可以依靠承包商来完成转换工作。殊不知承包商如果未完成任务，不过罚点款。银行自己因无法开业、数据混乱而带来的商业损失、信誉败坏而造成的坏影响是难以估计的。 　　如何解决 　　一般可从操作系统和应用程序两个方面着手，来解决2000年问题。 　　从应用程序着手，通常分四步来进行：首先是进行大致的分析，划分出需要对付的部分，确定作业方针。其次，确定出程序和数据中的问题所在。第三，对不同修改方案估计其作业量和效果后，进行权衡以确定修改方案。最后，对程序和数据进行修改，然后进行测试。 　　对程序和数据的修改，通常使用两种典型方法：一是把文档数据本身的年号都扩充为四位数。另一种是仍保持数据为两位数，只对程序进行修改。后一种方法由于作业量少，负担也不那么集中，所以比较多的人都建议采用后一方法。 　　不仅是用户使用的应用程序，而且生产厂家提供的操作系统、编译程序、数据库等基本软件，也无法对付2000年问题，所以各厂家都在推出能对付2000年问题的新版本。当然，版本升级后也要对应用程序的运行情况进行测试。 　　在对待2000年问题的过程中，还需要注意不同厂家的产品，在所进行的转换数据工作中，使用不同的准则。特别是用两位数转换数据时，一定要知道它是到哪一年为止才要当成2000年后的年号处理。这一处理准则必须处处保持一致。□