Here's some options for you...
1. Verify it is cataloged in Global Catalog The subroutine !EXIST subroutine was created for Prime INFORMATION compatibility and does a simple check to verify the program is catalogued only. Check out the source code in UV account APP.PROGS, EXIST. 2. Verify Object code matches The VCATALOG verb is also used to verify the compiled object in your BP object file and the Global Catalog space are the same. (Interestingly, on my UV11.1.9/AIX system, VCATALOG isn't working! :-( ). 3. Extract detailed object code header data Finally, writing your own custom verification utility combining VLIST verb and/or Gyle Iversons' excellent (NB: I understand he will soon close down this website) SRS.UV.HEADER subroutine to extract header information from the global catdir and your BP object file for comparison purposes. URL: http://www.srs4uv.com/srs_uv_header.htm -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Saturday, 29 December 2012 2:32 AM To: [email protected] 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 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material not intended for Public use. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is strictly prohibited. If you received this communication in error, please notify the sender and delete the material from any and all computers or devices. _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users ************** IMPORTANT MESSAGE ***************************** This e-mail message is intended only for the addressee(s) and contains information which may be confidential. If you are not the intended recipient please advise the sender by return email, do not use or disclose the contents, and delete the message and any attachments from your system. Unless specifically indicated, this email does not constitute formal advice or commitment by the sender or the Commonwealth Bank of Australia (ABN 48 123 123 124) or its subsidiaries. We can be contacted through our web site: commbank.com.au. If you no longer wish to receive commercial electronic messages from us, please reply to this e-mail by typing Unsubscribe in the subject line. ************************************************************** _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
