One of the issues that caused me to delay implementing external procedures, programs, and functions was that there was no easy way of finding out where a given program, function, or procedure was used. Since this problem has been adequately resolved (See "TechTip: Fishing for Service Programs"), there remains only one issue: how to keep track of the source members for the different module types (i.e., functions, procedures, prototypes, etc.).
I would like to be able to say that I came up with the following naming conventions on my own, but I didn't. I am sure I saw some of them as "suggestions" in some article or other. However, I am relatively certain that I have not seen them all together in one place. So without further ado...
| Name | Type of Module/Source |
| P.xxxxxxxx | Procedure |
| PR.xxxxxxx | Prototype member for /COPY |
| F.xxxxxxxx | Function |
| S.xxxxxxxx | Service Program |
| M.xxxxxxxx | Main procedure (*ENTRY/pep) |
I know it's simple, but it is what works for me. There are certainly other ways to go. Using separate source files (QRPGPROC, QRPGFUNC, QRPGMAIN, etc.) is one of the other methods I have seen. Whether you use these naming conventions or not, if you are going to be developing using ILE, you are going to need to use some sort of naming conventions. Remember, the best naming convention is the one you will actually use and stick to.
--Jeff Olen
Jeff Olen is a super-spy now but keeps his cover identity intact by working for video game studios on the East Coast. So when he’s not out killing members of ISIS or rescuing refugees, you can find him playing Wolfenstein II or testing the new Fallout 76 releases at his beach house in Costa Rica. In any case, he can’t be reached. You can email his cat at
MC Press books written by Jeff Olen available now on the MC Press Bookstore.
 |
||
 |
|
The IBM i Programmer’s Guide to PHP Get the scoop on how PHP can—and should—be deployed on IBM systems. List Price $79.95 Now On Sale
|
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online