Re: Procedure names vs. production support

Use the call stack for the actual program name?

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+rob=dekko.com@xxxxxxxxxxxx
02/17/2005 11:31 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
<rpg400-l@xxxxxxxxxxxx>
cc

Subject
Procedure names vs. production support







I'm trying to advance development in our shop to using procedures for 
specific business logic and combining them into service programs.  The 
issue I'm coming up against involves how to name the procedures.  If an 
error occurs in a production run the message will identify the procedure 
receiving the error, which may or may not be the name of the source 
member, causing confusion and delaying problem resolution.  I have listed 
the options I have come up with so far.

Option 1 is to give the procedures descriptive names so that developers 
can more easily identify what the procedure does.  For example, WrtPmtRec 
if the procedure writes a payment record.  This is the option I'm trying 
to sell but I'm having trouble coming up with a documentation method that 
would solve the production support issue.

Option 2 is to name the procedure the same as the actual source member 
(currently 1 procedure = 1 module = 1 source member) so that the person on 
call can more easily identify the source member of the procedure in error. 
 For example, the WrtPmtRec procedure would become SP4351M.  This is the 
counter proposal I have received.  It solves the production support issue 
but I think it will make development harder as the names have become 
cryptic.

Option 3 is to use descriptive names for both the procedure and the source 
member.  I like this one but over time I think we would run into naming 
conflicts with similar procedures.

I'd like to hear opinions on these options and how others on the list have 
resolved this situation in their environment.

TIA,

Rick


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.