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/
