Re: Procedure names vs. production support

["Paul Morgan" <pmorgan@xxxxxxxxxxxxxx>]

Rick,

How about another option?  Use descriptive names in your prototype like
option 1 but use source member procedure names in the module like option 2.
Use the EXTPROC keyword on the prototype to link the two together.  When a
runtime error occurs they will see the source member procedure name in the
error message.  For your example the prototype would look like:

D WritePaymentRecord... // why abbreviate when you don't have to?
D                       PR                    EXTPROC('SP4351M')


If a run time error occurs you would receive a message of 'The call to
SP4351M ended in error'.

Paul

-- 
Paul Morgan
Senior Programmer Analyst - Retail
J. Jill Group
100 Birch Pond Drive, PO Box 2009
Tilton, NH 03276-2009
Phone: (603) 266-2117
Fax:   (603) 266-2333

Rick wrote:

>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.