Paul: This brings up an interesting point. Why not keep information such as this in the database where, one might properly argue, it belongs?
For years I did this but it dawned on me I couldn't slice and dice anything. As a result I simply created a single "change" file with about ten attributes. Then all my change descriptions, change dates, purpose of changes, who made changes, programs and processes changed, etc are placed in this one file. Now I can easily produce an "Enhancement and Resolutions" report with all changes. The code simply contains the original creation date, the data last changed, and the people responsible for each. The record key of the "changes" file is the date and time. Once this is accomplished I can create a wrapper around the editor and/or a trigger on the program file (depending on a slew of issues). In addition, I can link the "changes" to local O/S files that contain project documents, and other such helpful documents. Just a thought. :-) bill > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Paul Trebbien > Sent: Wednesday, September 28, 2005 8:35 AM > To: '[email protected]' > Subject: RE: [U2] Good Programming Practice Question......... > > Regarding the origin and revisions to software, DataFlo > programmers pretty much have followed the policy where you > try to flag all revisions in the software using the following > convention: > * Baseline changes use just a rev#, for example rev 01 > * DataWorks use a rev# starting with a C, for example REV C1 > * Custom & Customer Programmers using a rev# starting with Z, > for example REV Z1 > > Here is an excerpt illustrating this from a heavily > modified program (from one of my customers): > > 0015: ********************* D/W CUSTOM REVISIONS > ***************************** > 0016: ** Z5,04-20-04,KT-22,pault: Print SURCHARGE in footing > instead of CUR. > 0017: ** Z4,03-15-02,KORE,EWY: Display NET xxx DAYS > 0018: ** Z3,01-03-02,KT-3024,CWV: Add copper credit to output > 0019: ** Z2,04-24-00,KT2002,CWV: Remove REV 22, ALLOW ZERO > DOLLAR INVOICE PRINT > 0020: ** Z1,04-10-00,KT2001,CWV: Identify if report or proc > 0021: ** 1C,03-05-99,39705,GEH: Added custom MFG PART number print > 0022: ************************ R E V I S I O N S > ***************************** > 0023: ** 24,12-17-98,APP-079,EMW: Change dates to 4-digit year. > 0024: ** 23,04-07-99,AR-1103,ABC: Print total with 2 decimal places. > > 0048: ** 00,09-11-95,AR-825,MLP: Rewrite at Rev 2. > > and the revisions are flagged like so: > > 0084: * REV 1C > 0085: READV MFGPART.FLG FROM F.TABLE,"PRT-CUST-PART",2 ELSE > MFGPART.FLG="N" > 0086: * END REV 1C > > 0096: ZERO.LI="" ; * REV 4 > > 0158: * REV 7 Assign DTL "" > 0159: DTL = "" > 0160: * END REV 7 > > 0938: * REV Z5 > 0939: * WORKVAR=WORKVAR:DISCPCT"R#6":" CUR" > 0940: WORKVAR=WORKVAR:DISCPCT"R#6":" SURCHARGE" > 0941: * END REV Z5 > > Note: > * Revving your work this way usually makes it fairly easy > to see what > was added (REV 1C and REV 7) and what was changed (REV Z5). > * Usually the baseline revisions are removed in a major software > release - only in the baseline software. > * When we 'upgrade' the software for a customer, for customized > software components (i.e. Programs, Procs, Reports), we merge > the baseline revisions into the customized software or visa > versa (easier route). Using comparison tools the differences > in the software component is pretty easy to find and usually > pretty clear as to what to change. > > Have a Great Day! > > > Paul Trebbien > > Kore Technologies, Senior Support Tech. > > "Solutions that work. People who care." > > V 858.678.0030 F 858.300.2600 W koretech.com > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Marilyn Hilb > Sent: Wednesday, September 28, 2005 7:48 AM > To: [email protected] > Subject: RE: [U2] Good Programming Practice Question......... > > > Two items I have thought of. > > 1. In addition to putting a modification tag at the top of > the code with who/date/what, we also will assign a job number > to the mod in addition to a No for the mod. Such as mod 01. > Then throughout the code where the changes are made we put a > tag such as *<<01>> start and *<<01>> end or, just a single > tag at the end of the line if only one or two lines being changed. > This makes the changes very easy to search for and spot > should there be problems in the new code. > 2. Consider when to use a paragraph and when to use a > program. Paragraphs > (proc) certainly has their uses, but when the paragraph gets > to using IF, Case, locate, etc seems time to use a program. > For two reasons. One being while paragraphs (at least in SB+) > can do a lot, getting it to do everything a program can do > can be difficult. If you have an involved paragraph, sooner > or later you'll be adding to it and find you can't easily add > what you want to add, that it needs to be a program. Second > reason being some of the commands are different syntax in a > paragraph vs a program, why learn/memorize or have to look up > two different syntaxes? > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
