The stamp I use assigns a dummy variable using strings that contain
searchable keys. That means when the code is compiled these strings end up
unaltered in the object code string table, so that they can be easily found
and extracted.

For example:

       VERDATA := 'Version=001000136;'
       VERDATA := 'VerBeta=;'
       VERDATA := 'VerDate=16637;'
       VERDATA := 'VerProd=mvPDF;'
       VERDATA := 'VerTM=mvPDF;'
       VERDATA := 'VerCopy=2013 Brian Leach Consulting Limited;'
       VERDATA := 'VerCo=Brian Leach Consulting Limited;'
       VERDATA := 'VerDesc=Produce a PDF Document by merging data;'
       VERDATA := 'CatName=PDF.MERGE;'
       VERDATA := 'VerModule=GENERAL;'
       VERDATA := 'VerModVer=002003022;'
       VERDATA := 'VerHist=19 JUL 13 1.0.136 Release 2.3.22;'

A useful addition is that I have a I Descriptor that returns this, so I can
list the source or object file and rip out these details:

LIST pdf.bp.O "PDF.MERGE" 01:02:24pm  01 Aug 2013  PAGE    1
pdf.bp.O...................... Version.. Version
Description............................... Module Version

PDF.MERGE                      1.0.136   Produce a PDF Document by merging
data             2.3.22

I did put some free code on my website to do this - look for mvStamp.

As for cutting or build scripts, these refer to anything that builds your
software.. every site should have something to do this, to ensure a smooth
and automated transition from test to live or for deployment.

In my case, the build process usually consists of a script written in
vbscript (WSH) that runs the various client side builds (for Delphi, C#
etc.) then uses UniObjects to execute a server side cutting paragraph
passing the new version number. This typically updates the version stamps,
recompiles everything, handles any platform builds (most of my stuff runs on
UniVerse, UniData, QM and D3), updates a README document from my task
system, adds them all into revision control, then calls mvInstaller to build
the release package. Then control passes back to the vbscript to assemble
the setup (InstallShield or visual studio) and zip  the resulting setup
ready for upload.

I did think about kicking off all the unit tests as well but I prefer to do
that after a test installation.

All of which took some setting up to begin with but has saved enormous
amounts of time and agony since.


-----Original Message-----
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of dale kelley
Sent: 01 August 2013 12:27
To: U2 Users List
Subject: Re: [U2] [UD] BASIC Code Failing


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.


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 mailing list

Reply via email to