RE: Procedure names vs. production support

Rick,
Option 1 or 3 are good.
To solve the documentation issue, I would move towards using HTML-based
helptext and document each procedure. That way a procedure name may be typed
into the search engine of the htmlhelp and quickly locate the procedure.
I do this with the RPG xTools and it seems to work fine.
You can download the documentation for xTools to see what I'm talking
about--no cost or registration involved in doing that--at the following URL.
www.rpgxtools.com
Then click on the link on the top right-hand corner that says "Download the
html-based helptext". 
HTH
-Bob


-----Original Message-----
From: rpg400-l-bounces+cozzi=rpgiv.com@xxxxxxxxxxxx
[mailto:rpg400-l-bounces+cozzi=rpgiv.com@xxxxxxxxxxxx] On Behalf Of
Rick.Chevalier@xxxxxxxxxxxxxxx
Sent: Thursday, February 17, 2005 10:31 AM
To: rpg400-l@xxxxxxxxxxxx
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.