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.


-----Original Message-----
From: Bill Haskett

Thought I'd try the VCATALOG verb and got:

errno=2: No such file or directory
Program 'BUILD.HEADING' does not verify.
Top of "DTABP" in "VOC", 3 lines, 28 characters.
*--: P
001: LD
002: @ABO_SYS\BP
003: @ABO_SYS\D_BP
*--: EX
Quit "DTABP" in file "VOC" unchanged.
LIST DTABP SAMPLING 5 12:06:01 Dec 22 2011 1

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.



----- 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

Reply via email to