I tried VCATALOG on a directly catalogued item and received the same error. The help does say it checks the global catalog file.
I usually compare the time/date stamps on the original vs the compiled as we usually only compile immediately after saving the record. Colin -----Original Message----- From: Bill Haskett Thought I'd try the VCATALOG verb and got: :VCATALOG DTABP BUILD.HEADING BUILD.HEADING errno=2: No such file or directory Program 'BUILD.HEADING' does not verify. :AE VOC DTABP Top of "DTABP" in "VOC", 3 lines, 28 characters. *--: P 001: LD 002: @ABO_SYS\BP 003: @ABO_SYS\D_BP Bottom. *--: EX Quit "DTABP" in file "VOC" unchanged. :LIST DTABP SAMPLING 5 LIST DTABP SAMPLING 5 12:06:01 Dec 22 2011 1 BP.................... 123CONV.ASCII ACCT-INDEX ACCT.REINDEX ACH.CREATE ACH.PROCESS 5 records listed I read the documentation and don't know where I went wrong. I did make sure the problem occurred after I disconnected. I was using a UO connection and made sure the connection was killed, logged off, and tried again with the connection restarting each time I tried again. I also ran the Dell hardware tests and all results showed no problems. The weird thing about the checks, a few days ago, is one of our beta testing clients was running checks all day. It was just me that was having problems. Secondly, the other problem we were all having was limited to one dbms account. The same code ran just fine on all the other accounts. Last night I restored the application code account from a few days ago. A look at the date/time stamps for the "_" object code shows nothing unusual. One program was recompiled during the last total recompilation on Aug 19, while another was recompiled on Oct 24. Thanks, Bill ------------------------------------------------------------------------ ----- Original Message ----- *From:* WTerhune > You might try checking the source/object with VCATALOG after a problem occurs and before you recompile. What I'm hearing Bill say is that object code on disk has changed (apparently). As someone else suggested - check time/date of object also to see if this has changed after what you believe to be the last compilation. > > If a problem occurred, but did not re-occur after exiting and starting a new udt session - that feels like 'flaky memory' or some problem with udt.exe that has corrupted the memory for that process (think exception violation). If the only correction is to generate new object code (that presumably is not identical to what had been used), then you start thinking about disk or utilities that could touch files/objects on disk. > > Wally Terhune > U2 Support Architect > Rocket Software _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users