Procedure names vs. production support

[<Rick.Chevalier@xxxxxxxxxxxxxxx>]

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.