On 28/12/12 17:18, Wjhonson wrote:
> Are you certain that catdir is not an O/S directory?
> If so, you should be able to tell the Create Date, seperately from the last
> "touched" date (read), or the last update date as well.
> You should have three dates associated with each directory entry, no?
>
That depends pn the O/S (and, in linux at least, on the mount flags too)
>
Cheers,
Wol
>
> -----Original Message-----
> From: bpaige <[email protected]>
> To: u2-users <[email protected]>
> Sent: Fri, Dec 28, 2012 7:32 am
> Subject: [U2] [UV]Corrupted object in global catalog
>
>
> Greetings, all!
>
> We have recently upgraded to the latest version of our vendor's software, and
> in the process have gone from Pick flavored accounts to Ideal flavored
> accounts. This has drastically changed the way programs are cataloged, as we
> are now using the global catalog directory (catdir, aka GLOBAL.CATDIR).
>
> We have discovered that some of the object code in the global catalog is
> corrupted (for lack of a better term). It looks like some of the object code
> files were somehow truncated. Since we don't discover this until someone
> notices that a program is behaving oddly, or working differently between the
> different servers (dev, test, production), and since the date stamp on the
> file in the catdir directory is the last time someone ran the program (as
> opposed to the time it was actually cataloged), it is impossible to tell if
> the object code was 'bad' from the beginning or got corrupted somewhere along
> the way.
>
> At this point, we can just recatalog everything. It would be a royal pain,
> but it is possible to do. That would ensure everything was all good right
> now, but doesn't do anything to make sure it stays that way.
>
> Does anyone know if there is a command we can ruin or some other way to
> verify object code in the global catalog? We would much rather monitor this
> proactively than wait until a user runs into a mysterious issue that we can't
> explain - or worse, runs something that ends up corrupting data because of a
> problem with the object code.
>
> Of course the ideal would be to figure out what's corrupting the object code
> to begin with - or to be able to determine if it was somehow corrupted in the
> initial install and we're just running into the bad pieces now. Without
> being able to monitor the object code and see when/if it gets corrupted
> again, though, that's going to be almost impossible.
>
> Any assistance would be greatly appreciated!
>
> Thanks!
> Brian
_______________________________________________
U2-Users mailing list
[email protected]
http://listserver.u2ug.org/mailman/listinfo/u2-users
