RE: Source Naming conventions

<snip>
Hello. I'm curious as to how people name their rpg source members. I'm
coming into a new shop where everything is pretty much open to however I
want it to be. We currently use 2 packages for most of our production
processing and most of my code and the existing code are interfaces into
one or both of these systems. I can break the systems down into 2 digit
codes AA and BB we'll say for now. Should I make all my programs fall
under one of these categories? AA0001, AA0002, BB0001, etc... I have
some code that interfaces with AA, but could be subcategorized as EDI.
I could name these EDI0001 or AAEDI0001. Also some Physical Inventory
programs. PI0001? AAPI0001.
</snip>

Surprised that server hasn't blown up with this one.

I use extremely strong standards. I think when you get into ILE
development, this gets to be critical. Without naming standard that
support ILE development, it is a nightmare. Everything is detailed
below. Here is summary.

Physical and logical files

SSNNNN - Physical file.
SSNNNN_L01 - SS - Subsystem, NNNN = Type of file, L = Logical.
SSNNNN_I01 - SS = Subsystem, NNNN = Type of file, I = Index.
SSNNNN_V01 - SS = Subsystem, NNNN = Type of File, V = Voice.

Example.

XVLCTF - System Utilities - Last Compile tracking file.
XVLCTFI01 - System Utilities - Last Compile tracking file - Index 01.

Programs, display files, print files, temporary files, QM Queries.

SSNNNN - Top level where SS = subsystem, NNNN = sequential number
starting with one.
SSNNNN_M01 - Module one(RPG, CLLE, C, etc).
SSNNNN_M02 - Module two.
SSNNNN_D01 - Display file.
SSNNNN_P01 - Print file one.
SSNNNN_P02 - Print file two.
SSNNNN_T01 - Temporary table one.
SSNNNN_Q01 - QM Query form.
SSNNNN_Q01 - QM Query form.

AP0001 AP program.

AP0001_D01 - Display file.
AP0001_P01 - Print file one.
AP0001_T01 - Temporary File
AP0001_M01 - Module one.
AP0001_M02 - Module two.
AP0001_Q01 - QM Query Form.
AP0001_Q02 - QM Query

Service program.

SSNNNN - Service program name where SS - subsystem, NNNN - Program
function.
SSNNNN_M01 - Module 01 (Any type again).
SSNNNN_M02 - Module 02.
SSNNNN_B - Bindery
SSNNNN_PR - Prototype.

XVERRH - Service program. Standard error handler.
XVERRH_PR - Prototype.
XVERRH_B - Bindery.
XVERRH_M01 - RPG Module one.
XVERRH_M02 - RPG Module two.
XVERRH_M03 - RPG Module three.

Details:

Naming standards by object type.

Physical and Logical Files.

Physical file = SSNNNN where

S = two digit subsystem (XV = System Utilities, PO = Purchasing, AR=
Accounts Receivable, etc)
N = File use. For example. MAST = Master, LCTF = Last Compile Tracking.

So XVLCTF or POMAST or APCHCK.

Logical files are SSNNNN_Lnn(Logical) or SSNNNN_I01(Index) or SSNNNN_V01
where

SSNNNN physical file based on.
L = Logical File
I = Index
V = View
N = Sequencial number starting with 01. This assumes that you are
creating the physical with the primary key. If not, the first logical is
00 for the primary key.

So for example,

XVLCTF_L00
POMAST_I01
APCHCK_V01

Programs, print files, display files and QM Queries.

SSNNNN Top level program.
SSNNNN_M01 - Program module.
SSNNNN_D01 - First Display File.
SSNNNN_P01 - First Print File.
SSNNNN_T01 - First Temporary Table.
SSNNNN_Q01 - QMQRY form.
SSNNNN_Q01 - QMQRY query.

S = Subsystem.
N = Numeric number starting with 0001.
M = Module
D = Display File
P = Print File
T = Temporary File
Q = QMQRY.

So taking an example.

Program AP0001 as two modules, a temporary file, a display file and two
print files and a QM Query to produce a report.

AP0001 - Top Level.
AP0001_D01 - Display File.
AP0001_P01 - Print File one.
AP0001_P02 - Print File two.
AP0001_M01 - RPG module 01.
AP0001_M02 - RPG module 02.
AP0001_T01 - Temporary work file.
AP0001_Q01 - QM Query.
AP0001_Q01 - QM Form.

The modules get bound together to form one program AP0001. In another
example, module two might be a CLLE module or whatever. The point is
that I do not module type. Just M for module can it can be anything, for
example a "C" module.

Finally a service program. The only difference is in a service program,
I use an identifier to describe the function instead of a number so

XVIFSX - Integrated file system API's
XVUSPC - User Space API's
XVERRH - Standard Error Handler.
ARPRIC - A/R Pricing API's

Etc.

So XVIFSX has two modules, a prototype and bindery.

XVIFSX - Top Level.
XVIFSX_B - Bindery.
XVIFSX_PR - Prototypes.
XVIFSX_M01 - RPG Module 01.
XVIFSX_M02 - RPG Module 02.

XVERRH has three modules, prototype and bindery.

XVERRH - Top level.
XVERRH_B - Bindary
XVERRH_PR - Prototype.
XVERRH_M01 - RPG Module one - Throw functions.
XVERRH_M02 - RPG Module two - Message storage functions.
XVERRH_M03 - RPG Module three - ILE error handling functions.

The last piece, I put the four character code on each procedure I export
from a service program so

ERRH_Throw
ERRH_Rethrow
ERRH_GetLastMessageId
USPC_CreateUserSpace
USPC_GetPointerToUserSpace

In other words, I always know what service program the function came
from.