RE: Procedure names vs. production support

[rob@xxxxxxxxx]

And who uses exhaustive testing tools to test every possible line of a 
program because 3 lines have changed?  Even the if %status=DiskIsFull 
lines?

As others have said, unless you monkeyed around with some global variable, 
a change to a particular subprocedure does not necessitate a test to the 
whole service program.  Use the source compare utility.

Then again, you could either have a testing tool in place, or a home grown 
script to validate the service program and just bang it out.  For example, 
when I create a new subprocedure in the service program I may write a 
Quick&Dirty in my library to throw several values in there and then dsply 
the returned variable.  I suppose it wouldn't be that hard to say write a 
test script that would stop at the exception (or some other action). 
Combine all these Q&D's into one testing script.

Rob Berendt
-- 
Group Dekko Services, LLC
Dept 01.073
PO Box 2000
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





<Rick.Chevalier@xxxxxxxxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
02/17/2005 05:49 PM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
<rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: Procedure names vs. production support







Bob,

Actually, probably more the opposite direction.  There is a pronounced 
lack of standards here and reluctance to implement any new ones.  I'm 
trying to get ahead of this one before every developer has placed their 
version of how it should be done into production.

Back to the one procedure, one module issue.  I don't mean to beat a dead 
horse here, but I'm trying to come up with new/better arguments for 
combining multiple procedures into a single module.  I haven't made much 
progress to date.

The issue revolves around testing.  With multiple procedures in a source 
member I would be required to test each one even though only one has 
changed.  This could add significant time to the testing process.  That's 
why I started advocating the one procedure, one module model.  Am I making 
a mountain out of a mole hill?  I've tried convincing my manager that it's 
not necessary to test things that haven't changed but it's pretty much a 
non starter at the moment.

Rick

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Bob Cozzi
Sent: Thursday, February 17, 2005 4:20 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: Procedure names vs. production support


Rick,
Well, option 2 is not something that will make you end up in Purgatory
but... :)
Like Crocodile Dundee says "You can live on it, but it tastes like $h#%.
In other words, it will do the job, but why bother when there are so many
better alternatives.
Back in the days of the System/32, software development houses used names
like BB0050 to identify programs. The sequence number was used as sort of 
a
program flow sequencing identifier. BB0050 would call BB0060 which would
call BB0080, etc.
Today that kind of naming (for sequencing or not) is very out-dated and
rarely used except in the largest of shops that have total control over
everything from the program name, down to the names used for work fields.
If that's your situation (or something near to it) I would consider 
showing
them what Microsoft does with some of its class libraries and how the C
runtime library is grouped. While you do see an occasional one proce to 
one
module association going on, it is the exception and not the rule.
-Bob


Privileged and Confidential.  This e-mail, and any attachments there to, 
is intended only for use by the addressee(s) named herein and may contain 
legally privileged or confidential information.  If you have received this 
e-mail in error, please notify me immediately by a return e-mail and 
delete this e-mail.  You are hereby notified that any dissemination, 
distribution or copying of this e-mail and/or any attachments thereto, is 
strictly prohibited.

-- 
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.