ITPub博客

首页 > Linux操作系统 > Linux操作系统 > PROGRAM RS_ROUTINE 的“來”

PROGRAM RS_ROUTINE 的“來”

原创 Linux操作系统 作者:leniz 时间:2009-01-18 13:01:59 0 删除 编辑

    小生在Debug Routine时遇到一件怪事,就是原来都可以进行Simulate Update 的Data Package 突然没办法进入Debug了,就是怎么试都不进Update Rules的代码段而是直接跑出结果,虽然到处加 Break-point(断点)还是不起作用。

        这个问题我遇到过,我当时的结论是第一次可以进 Update Rules 的代码段,但是第二次(不退出Monitor界面)Simulate Update时就不会进入 Update Rules,退出重来也的确可以了,所以问题一直都没有去深究。 但是这次轮到小生了,而他的操作可能和我的不一样,所以导致退出Monitor重新进入进行Debug时也还是无法进入Update Rules 的代码界面,问题在哪里?

        我检查了断点,排除那种要条件才进入的断点设置,发现断点是设在必经之路,所以这一点可以排除了,那么接下来,我判断是不是代码改动了,所以无法进入。 于是我重新导入一份数据  , 做了一次Simulate Update,结果是进入了Update Rules 的代码段,我把Update Rules的代码进行了细微的改动,并重新进入Monitor界面进行 Simulate Upldate,结果证明我的推断错误,因为这次也顺利的进入了Update Rules的代码界面,那么问题在哪里? 前后存在哪里不一致的地方。

       进过数次对比,发现这一切和一个Program有关,这个Program的名称为“RS_ROUTINE",只要你进入Update Rules界面,这个程序就会自动变成当前你所打开的Update Rules中的代码,如果你目前仍在代码界面,而有其他人打开他的代码,那么”RS_ROUTINE"就会自动变成他的代码,即RS_ROUTINE为BW 系统中最后打开的Update Rules ,而这个规律的得出,可以完全解释这个原因,因为小生在第二次进行Simulate时,有其他人打开他们的Update Rules代码,所以小生此时进行Simulate,进行Debug,系统无法进入断点,当时按照这种思路去测试发现正如所想,那么问题是不是就是如此?

     我重新进行了测试,和之前的推断大相径庭,失望。 新的理由有待查询,标记在此。

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/554557/viewspace-541347/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 节后开工
请登录后发表评论 登录
全部评论

注册时间:2008-05-31

  • 博文量
    448
  • 访问量
    1126709