Hi Brian That's a good idea to do what you have done and do in mvStamp...
I guess what I'm also look at is that the use of MD5 checksums (for example) is a 'well known/accepted and platform independent' mechanism to verify files are 'as they should be'. Hence, in theory you quickly detect changes that have occurred to the object, source and catalog version in simple independent way without even referencing back a source control system. Plus in UV BASIC you now have the ENCODE and ENCRYPT functions to help you check/secure your code - if you so desire - post-implementation. Here's simple compilation comparison before and after...obviously you can extend it to the source changes in catdir, etc. $ openssl md5 /my/PROGRAMS/BP.O/test123 MD5(/my/PROGRAMS/BP.O/test123)= 7e3743a1ac709cca2f9e1dd034e19048 $ nbasic BP test123 Compiling: Source = '/my/PROGRAMS/BP/test123, Object = '/my/PROGRAMS/BP.O/test123 *************************************************************************************************************** Compilation Complete. $ openssl md5 /my/PROGRAMS/BP.O/test123 MD5(/my/PROGRAMS/BP.O/test123)= 080524f5d4da1c363298e2e538d3cf49 $ openssl md5 `cat /.uvhome`/catdir/'*test123 MD5(/usr/ibm/uv/catdir/*test123)= 05b3b02a4369915e448af6837160ac8f $ Regards, David -----Original Message----- From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Brian Leach Sent: Thursday, 1 August 2013 11:13 PM To: 'U2 Users List' Subject: Re: [U2] [UD] BASIC Code Failing Dale 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='' 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. Brian -----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 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 _______________________________________________ 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
