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 

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-----
[] On Behalf Of Bill Haskett
Sent: Wednesday, 31 July 2013 6:06 AM
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing


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.  

Untitled Page

----- Original Message -----
*To:* U2 Users List <>
*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
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: 
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

Reply via email to