In UV we're had similar strange problems with seemingly unchanged source/object code - not work as per normal and things going amiss for no good reason...once we found the object code in BP and the catalog space were mismatched and simply re-catalog'd it. Another time we re-compiled a program - as it was always invoked via RUN BP PROGNAME... in both instances the problem seem to go away. This was in a controlled product environment so it's in highly unlikely someone could of or would've changed the code...
In UV you can do a VCATALOG to verify the BASIC object to what is actually catalogued... All of these issues made me wonder if our implementation routines need to have a more robust. More robust in terms of storing some control information for both pre/post verification - hence being able to detect 'unauthorised changes' through the various stages. This could include calculating and storing (say) MD5 (etc) hashes on the source and object to cross verify changes. Hence, make it more easy to detect object or source changes outside the authorised/control deployment process... without having to go through every single file and comparing to tape or disk backups, etc., etc. -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Bill Haskett Sent: Wednesday, 31 July 2013 6:06 AM To: U2 Users List Subject: Re: [U2] [UD] BASIC Code Failing John: That's an interesting thought. We do backups of the application account every night, so I do have the last 10 days object code in a backup (plus the last four months weekly backups). I'll look at this the next time it happens. Thanks, Bill Untitled Page ------------------------------------------------------------------------ ----- Original Message ----- *From:* jhes...@momtex.com *To:* U2 Users List <u2-users@listserver.u2ug.org> *Date:* 7/30/2013 11:01 AM *Subject:* Re: [U2] [UD] BASIC Code Failing > I would also consider the possibility of data corruption at the > hardware level. Granted, I would expect that you'd also occasionally > find anomalies within your source code and data files if this were the > case, but I don't know how your filesystems are set up. If the object > code has become corrupt, that would explain why recompiling fixes the > problem. The newly created object code will be stored on a new > location in the filesystem. Fortunately this possibility is very easy > to test for. Just make a copy of your application account on > alternate storage and wait for the problem to recur. When it does, > open the live object file and your backup copy in an editor with diff > capability (Notepad++ is a good one) and see if they still match. > > -John ************** 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
