Brian,
Is the stamp just
VERSION = "123" ,?
Could you explain what you mean by "cutting routines", I've either
never heard that term or my "old timers" is kicking in.
dale
On 08/01/2013 06:09 AM, Brian Leach wrote:
David
I add version stamps to my code that compile into the object code, so at
least I can easily check that the source and object (including that in
catdir) matches what I expect. That's at least a small and easy step in the
right direction, though that doesn't rule out changes that don't update the
stamp of course.
The stamps are always updated by my cutting routines and then the items are
then added to source control as part of the cut... If you did something
similar you can always diff what you've got against your source code control
system rather than reinventing the wheel.
Brian
-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Hona, David
Sent: 01 August 2013 10:49
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing
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
_______________________________________________
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
