Or you could use a product such as PRC to take care of sandboxing (personal copies) and versioning and backups and tracing history and all of that sort of thing. All while automating the whole life-cycle, bringing best-practices and compliance to the party.
Oops ... did I say that out loud? Predictably, Susan [SJ] Date: Wed, 20 Oct 2004 22:00:31 -0400 From: "Mark Johnson" <[EMAIL PROTECTED]> Subject: Re: [U2] [UD] running a subroutine I learned a method years ago and even had it published in Spectrum. I'll recap it here. Say you have one BP. I create another file called BP.ARCHIVE whereby I put all of the prior versions of code for any programs that I make changes to. I have a utility that I call DCOPY (stands for Dated COPY) that does 2 things. DCOPY BP UPDATE 1. Copies the current version of UPDATE to BP.ARCHIVE UPDATE_102004. It puts the date at the end. 2. Throws you into EDIT BP UPDATE as that's probably the next step anyway. If you do it more than once on a day, I append <dot>1, <dot>2 to the date suffix. Gone are the pathetic NEW, TEMP, REVISED, OLD, HOLD, SAVE, V2, V3 and other suffixes as you are really left with BP UPDATE and many items in BP.ARCHIVE that start with UPDATE and have a useful date suffix. The problem with OLD and NEW is they don't tell you when they became OLD or NEW. A similar discipline i use for temp files is to create-file PRODUCT_102004. First, its name clearly doesn't look on-line. Second, I EDIT DICT PRODUCT_102004 README and write a little reason why I created it in the first place. Often it's to protect a subset of data when making a mass change. Later, whether days, weeks or months, I can review these dated archive files and determine if I need them to backup the changes that I made. Usually I can delete them. PRODUCT.NEW or PRODUCT.SAFE doesn't tell me anything. Am I the only programmer with multiple environments (clients) that continues to follow in the footsteps of prior sloppy programmers. It appears that most on this forum are full-time programmers for a specific software company or large end user. Just curious. Thanks - ----- Original Message ----- From: "Allen E. Elwood" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 20, 2004 9:14 PM Subject: RE: [U2] [UD] running a subroutine > I just have one all purpose test program called BBB (BBBecause it's easy to > remember AND type) > > This way when I test something, I just put in a STOP above the previous test > stuff and then stick my new statements above that. This way if I ever need > to go back and see if I tested a snippet of code that is close to what I > need, I can just look at all the code and see. This has saved me a bunch o' > hours through the years in that I never have to think of a unique name for a > test program, and it becomes a historical record of programming examples > that come in quite handy. > > I always like to have an AEE.BP file for my utilities, as well as a XXX.BP > file for the clients files with the XXX being replaced with client's > initials. The Manage-2000 system that I've worked a lot with has SCADS of > .BP files for all the different modules and one gets used to seeing 6 pages > of .BP's when listing the voc.......... > > I agree with you that having a bunch of .bp's with upgrade and upgrade.new > is WAY more than scary and just outright sloppy. I am a firm believer in > the XXX.BP and OBSOLETE.BP. This way obsolete code gets deleted from the > XXX.BP and put into the OBSOLETE.BP and there is no question of what it is, > and yet it's a real timesaver to be able to go back to OBSOLETE.BP and > resurrect a function that the client said was dead, and then half a year > later wants to know what happened to the function! I always make the > OBSOLETE.BP a file, instead of a directory, and that prevents anyone from > compiling any of the programs in it. > > I use the XXX.BP as I have had clients running multiple companies with > different versions of the same code (like AP.CHECK printing) for their > different divisions and yet they want the names to stay the same for ease of > use. It's just another safeguard when copying and installing programs that > you can see you're copying the CPI version of a program into the CPI.BP file > instead of just a BP file which could have been in the RED account or the > CPI account. > > Just my couple of pennies on this subject.........:) > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson > Sent: Wednesday, October 20, 2004 17:18 > To: [EMAIL PROTECTED] > Subject: Re: [U2] [UD] running a subroutine > > > True, but don't throw the baby out with the bathwater. If the program gets > sophisticated enough that starts using COMMONS or INCLUDES, then write a > real test program. Perhaps 90% of standard stupid test programs can be > eliminated with PRINT. > > When I get a new client, I suggest and allow myself time to clean up BP > items that I deem useless. I see BP items called TEST, TEST2, DATE, > DATETEST, BOB, BOB1 etc that all exist for testing little things. Same with > the MD (VOC). > > If the programmer wants to have a test program library, don't use the > standard application library. Thus when people like me get involved, I don't > have to wade through the little programs that may or may apply. > > I'm actually with a multi-programmer client now that has enlisted me to > create some programming rules and disciplines. I've got a pretty good list > of my favorites and am open for some more ideas from anyone else. > > My categories will not cover programming standards. I'm specifically > attempting to enforce some naming rules for programs and/or files, as well > as documenting changes and how to archive program changes short of a whole > revision system. > > I dare not venture into the actual code. I just don't like a BP file > littered with prior versions of programs like UPDATE.OLD, UPDATE.HOLD, > UPDATE.TEMP, UPDATE.NEW, UPDATE.OLD.NEW etc. I will stand on my soapbox and > declare these residual source records as being lazy and thoughtless. > > The original program, UPDATE, hopefully still is the real version. When I > see UPDATE.NEW, I want to strangle someone as they now deviated from a sane > naming convention and then their next revision will be UPDATE.NEW2 or > UPDATE.NEW.NEW (I'm not kidding. I've seen this crap everywhere). > > Then there's UPDATE.OLD or UPDATE.OLD2 which is OK as long as none of those > suffixed versions are on line. If they're obsolete, move them to another > file so SEARCH or FIND doesn't gather them. I've seen every variation of > these suffixes and know that my research will be that longer to weed through > the false positives. > > Sorry for my soapbox. I just like a nice & tidy BP file. > > P.S. Don't flame me for the name UPDATE. I'm being concise with a functional > name. > > > ----- Original Message ----- > From: "Stu Glancy" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, October 20, 2004 12:49 PM > Subject: Re: [U2] [UD] running a subroutine > > > > Criticisms for Mark: > > > > Your concept won't work if there are commons that need to be set in the > > calling program. However, with the use of named commons they can be set > > in a test program and then use your print which includes the "$INCLUDE > > file named.commons" in the command line. (For those who don't know, > > named commons remain in memory between programs and can be used again > > until you logout.) > > > > > > > > Bill H. wrote: > > > > >Mark: > > > > > >The program at http://www.pickwiki.com/cgi-bin/wiki.pl?BPTest doesn't > even > > >have these limitations. > > > > > >This wiki has some pretty nice free programs. I like to take the > non-mvDbms > > >attitude: it's free so use it. :-) We should all post our free programs > > >there. > > > > > >Bill > > > > > > > > > > > >>-----Original Message----- > > >>From: [EMAIL PROTECTED] > > >>[mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson > > >>Sent: Wednesday, October 20, 2004 5:54 AM > > >>To: [EMAIL PROTECTED] > > >>Subject: Re: [U2] [UD] running a subroutine > > >> > > >> > > > > > >[snipped] > > > > > > > > > > > >>In fact, I welcome any criticisms or limitations anyone would have > against > > >>establishing this PRINT command to handle everything. I know of 2 > > >>limits: 1) > > >>No hanging ELSE or THENs. 2) Cannot use READNEXT. Other than that I'm > all > > >>ears. > > >> > > >>My 3 cents. > > >> > > >>----- Original Message ----- > > >>From: "Peter Olson" <[EMAIL PROTECTED]> > > >>To: <[EMAIL PROTECTED]> > > >>Sent: Tuesday, October 19, 2004 8:43 AM > > >>Subject: RE: [U2] [UD] running a subroutine > > >> > > >> > > >> > > >> > > >>>"but i want more!" > > >>> > > >>>found it! > > >>> > > >>>0001: PQ > > >>>0002: HSELECT > > >>>0003: H EVAL "SUBR(' > > >>>0004: A\2 > > >>>0005: H', > > >>>0006: A3 > > >>>0007: H )" FROM VOC FIRST 1; > > >>>0008: P > > >>> > > >>>now it's > > >>> > > >>>tcl>TS AGE.DATE -2224,42 > > >>> > > >>>Cool.... thanks! > > >>> > > >>> > > >------- > > >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/ > ------- > u2-users mailing list > [EMAIL PROTECTED] > To unsubscribe please visit http://listserver.u2ug.org/ ------------------------------ Date: Wed, 20 Oct 2004 22:03:31 -0400 From: "Mark Johnson" <[EMAIL PROTECTED]> Subject: Re: [U2] [UD] running a subroutine I use a single, ever growing BP called T that is maybe 400 lines long but has an END at line 12. I also have a MD proc with the X. I learned that trick years ago from a secretary who used Word or WordPerfect and didn't want to clutter her folders with hundreds of little one-shot letters. She Inserted a new page at the beginning, wrote her letter and then just printed the first page. It kept a tidy archive of all the little stuff. Mark Johnson - ----- Original Message ----- From: "Allen E. Elwood" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 20, 2004 9:14 PM Subject: RE: [U2] [UD] running a subroutine > I just have one all purpose test program called BBB (BBBecause it's easy to > remember AND type) > > This way when I test something, I just put in a STOP above the previous test > stuff and then stick my new statements above that. This way if I ever need > to go back and see if I tested a snippet of code that is close to what I > need, I can just look at all the code and see. This has saved me a bunch o' > hours through the years in that I never have to think of a unique name for a > test program, and it becomes a historical record of programming examples > that come in quite handy. > > I always like to have an AEE.BP file for my utilities, as well as a XXX.BP > file for the clients files with the XXX being replaced with client's > initials. The Manage-2000 system that I've worked a lot with has SCADS of > .BP files for all the different modules and one gets used to seeing 6 pages > of .BP's when listing the voc.......... > > I agree with you that having a bunch of .bp's with upgrade and upgrade.new > is WAY more than scary and just outright sloppy. I am a firm believer in > the XXX.BP and OBSOLETE.BP. This way obsolete code gets deleted from the > XXX.BP and put into the OBSOLETE.BP and there is no question of what it is, > and yet it's a real timesaver to be able to go back to OBSOLETE.BP and > resurrect a function that the client said was dead, and then half a year > later wants to know what happened to the function! I always make the > OBSOLETE.BP a file, instead of a directory, and that prevents anyone from > compiling any of the programs in it. > > I use the XXX.BP as I have had clients running multiple companies with > different versions of the same code (like AP.CHECK printing) for their > different divisions and yet they want the names to stay the same for ease of > use. It's just another safeguard when copying and installing programs that > you can see you're copying the CPI version of a program into the CPI.BP file > instead of just a BP file which could have been in the RED account or the > CPI account. > > Just my couple of pennies on this subject.........:) > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson > Sent: Wednesday, October 20, 2004 17:18 > To: [EMAIL PROTECTED] > Subject: Re: [U2] [UD] running a subroutine > > > True, but don't throw the baby out with the bathwater. If the program gets > sophisticated enough that starts using COMMONS or INCLUDES, then write a > real test program. Perhaps 90% of standard stupid test programs can be > eliminated with PRINT. > > When I get a new client, I suggest and allow myself time to clean up BP > items that I deem useless. I see BP items called TEST, TEST2, DATE, > DATETEST, BOB, BOB1 etc that all exist for testing little things. Same with > the MD (VOC). > > If the programmer wants to have a test program library, don't use the > standard application library. Thus when people like me get involved, I don't > have to wade through the little programs that may or may apply. > > I'm actually with a multi-programmer client now that has enlisted me to > create some programming rules and disciplines. I've got a pretty good list > of my favorites and am open for some more ideas from anyone else. > > My categories will not cover programming standards. I'm specifically > attempting to enforce some naming rules for programs and/or files, as well > as documenting changes and how to archive program changes short of a whole > revision system. > > I dare not venture into the actual code. I just don't like a BP file > littered with prior versions of programs like UPDATE.OLD, UPDATE.HOLD, > UPDATE.TEMP, UPDATE.NEW, UPDATE.OLD.NEW etc. I will stand on my soapbox and > declare these residual source records as being lazy and thoughtless. > > The original program, UPDATE, hopefully still is the real version. When I > see UPDATE.NEW, I want to strangle someone as they now deviated from a sane > naming convention and then their next revision will be UPDATE.NEW2 or > UPDATE.NEW.NEW (I'm not kidding. I've seen this crap everywhere). > > Then there's UPDATE.OLD or UPDATE.OLD2 which is OK as long as none of those > suffixed versions are on line. If they're obsolete, move them to another > file so SEARCH or FIND doesn't gather them. I've seen every variation of > these suffixes and know that my research will be that longer to weed through > the false positives. > > Sorry for my soapbox. I just like a nice & tidy BP file. > > P.S. Don't flame me for the name UPDATE. I'm being concise with a functional > name. > > > ----- Original Message ----- > From: "Stu Glancy" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, October 20, 2004 12:49 PM > Subject: Re: [U2] [UD] running a subroutine > > > > Criticisms for Mark: > > > > Your concept won't work if there are commons that need to be set in the > > calling program. However, with the use of named commons they can be set > > in a test program and then use your print which includes the "$INCLUDE > > file named.commons" in the command line. (For those who don't know, > > named commons remain in memory between programs and can be used again > > until you logout.) > > > > > > > > Bill H. wrote: > > > > >Mark: > > > > > >The program at http://www.pickwiki.com/cgi-bin/wiki.pl?BPTest doesn't > even > > >have these limitations. > > > > > >This wiki has some pretty nice free programs. I like to take the > non-mvDbms > > >attitude: it's free so use it. :-) We should all post our free programs > > >there. > > > > > >Bill > > > > > > > > > > > >>-----Original Message----- > > >>From: [EMAIL PROTECTED] > > >>[mailto:[EMAIL PROTECTED] Behalf Of Mark Johnson > > >>Sent: Wednesday, October 20, 2004 5:54 AM > > >>To: [EMAIL PROTECTED] > > >>Subject: Re: [U2] [UD] running a subroutine > > >> > > >> > > > > > >[snipped] > > > > > > > > > > > >>In fact, I welcome any criticisms or limitations anyone would have > against > > >>establishing this PRINT command to handle everything. I know of 2 > > >>limits: 1) > > >>No hanging ELSE or THENs. 2) Cannot use READNEXT. Other than that I'm > all > > >>ears. > > >> > > >>My 3 cents. > > >> > > >>----- Original Message ----- > > >>From: "Peter Olson" <[EMAIL PROTECTED]> > > >>To: <[EMAIL PROTECTED]> > > >>Sent: Tuesday, October 19, 2004 8:43 AM > > >>Subject: RE: [U2] [UD] running a subroutine > > >> > > >> > > >> > > >> > > >>>"but i want more!" > > >>> > > >>>found it! > > >>> > > >>>0001: PQ > > >>>0002: HSELECT > > >>>0003: H EVAL "SUBR(' > > >>>0004: A\2 > > >>>0005: H', > > >>>0006: A3 > > >>>0007: H )" FROM VOC FIRST 1; > > >>>0008: P > > >>> > > >>>now it's > > >>> > > >>>tcl>TS AGE.DATE -2224,42 > > >>> > > >>>Cool.... thanks! > > >>> > > >>> > > >------- > > >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/ > ------- > u2-users mailing list > [EMAIL PROTECTED] > To unsubscribe please visit http://listserver.u2ug.org/ ------------------------------ Date: Thu, 21 Oct 2004 14:02:29 +1000 From: Bruce Nichol <[EMAIL PROTECTED]> Subject: Re: [U2] [UD] running a subroutine Goo'day, At 12:00 21/10/04, you wrote: <snip> >Am I the only programmer with multiple environments (clients) that continues >to follow in the footsteps of prior sloppy programmers. Mate, I've been following in my own footsteps for years ..... and cursing the stupid b........ that preceeded me..... Ah well! What's life without a few self-made challenges? ~8^)) >It appears that most >on this forum are full-time programmers for a specific software company or >large end user. Just curious. > >Thanks > > >----- Original Message ----- >From: "Allen E. Elwood" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Wednesday, October 20, 2004 9:14 PM >Subject: RE: [U2] [UD] running a subroutine > > >-- >Incoming mail is certified Virus Free. >Checked by AVG Anti-Virus (http://www.grisoft.com). >Version: 7.0.280 / Virus Database: 264.12.0 - Release Date: 19/10/04 Regards, Bruce Nichol Talon Computer Services ALBURY NSW 2640 Australia Tel: +61 (0)411149636 Fax: +61 (0)260232119 If it ain't broke, fix it till it is! - -- Outgoing mail is certified Virus Free. Checked by AVG Anti-Virus (http://www.grisoft.com). Version: 7.0.280 / Virus Database: 264.12.0 - Release Date: 19/10/04 - -- Outgoing mail is certified Virus Free. Checked by AVG Anti-Virus (http://www.grisoft.com). Version: 7.0.280 / Virus Database: 264.12.0 - Release Date: 19/10/04 ------------------------------ End of U2 Users Digest V1 #317 ****************************** ------------ u2-users-digest 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/
