Re: [U2] [UV]Corrupted object in global catalog
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: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of bpa...@serta.com Sent: Saturday, 29 December 2012 2:32 AM To: u2-users@listserver.u2ug.org 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 U2-Users@listserver.u2ug.org 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 U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
[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 U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV]Corrupted object in global catalog
Brian, I am not familiar with the Ideal flavor. However, I do know that there are several differences in how some commands work between the native UniData and Pick flavor. The LOCATE command comes to mind and has burned me a few times. Depending on the line of code, it may still compile, but will be looking at the wrong multi-value level (@FMs instead of @VMs, etc.) One of the things I have done to get around this (in UniData) is to use force the program to compile in the flavor that is not native to the account I am in. For example, if I am in a native UniData account, but I want the program to use Pick syntax, the first line of code would be: $BASICTYPE P I hope that helps of at least points you in a useful direction. JRI -Original Message- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of bpa...@serta.com Sent: Friday, December 28, 2012 10:32 AM To: u2-users@listserver.u2ug.org 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 U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV]Corrupted object in global catalog
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? -Original Message- From: bpaige bpa...@serta.com To: u2-users u2-users@listserver.u2ug.org 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 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 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 U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users ___ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
Re: [U2] [UV]Corrupted object in global catalog
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 bpa...@serta.com To: u2-users u2-users@listserver.u2ug.org 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 U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
