Bryan's RPG IV Journal
Using /COPY for Prototypes
Q. You've recommended placing prototype (PR) definitions in copybook(s), then using /COPY to copy the prototypes into the modules that need them. At our company, some programmers place not only the prototypes in copybooks but also the procedure interface (PI) definitions too. Could there ever be a good reason to do this? Here's an example of a copybook:
You might get a small maintenance advantage of having both definitions in the same /COPY member. But storing both definitions in the same /COPY member requires the added complexity of conditional compilation (and your example includes the beginning P-spec for the procedure, but not the ending one, which I find confusing), and I would discourage it.
Unless you're using the procedure's source member itself as the /COPY member, then using conditional compilation to copy only the PR definitions. Then, I can see the advantage. Here's an example (using your code):
/If Defined(GetInterest_Pr)A. Putting PR definitions in a /COPY member makes sense because the PR must be in every compile unit that refers to a procedure. But the PI definition needs only to be in one place -- the procedure's compile unit itself.
D GetInterest PR
D @@DSName 10 Const
D @@DSPtr *
D CIRulesPtr *
/Endif
/If defined ( GetInterest_Pi )
// ----------------------------------------
// Function : get Interest Info
// ----------------------------------------
P GetInterest B Export
D PI
D @@DSName 10 Const
D @@DSPtr *
D CIRulesPtr *
/Endif
You might get a small maintenance advantage of having both definitions in the same /COPY member. But storing both definitions in the same /COPY member requires the added complexity of conditional compilation (and your example includes the beginning P-spec for the procedure, but not the ending one, which I find confusing), and I would discourage it.
Unless you're using the procedure's source member itself as the /COPY member, then using conditional compilation to copy only the PR definitions. Then, I can see the advantage. Here's an example (using your code):
/If Not Defined(PR_Only)Then, in every module that uses GetInterest, you'd include /COPY statements along the following lines:
H Nomain
/Endif
/If Not Defined(GetInterest_Parms)
// -------------------------------------- GetInterest Prototype
D GetInterest Pr
D @@DSName 10 Const
D @@DSPtr *
D CIRulesPtr *
/Define GetInterest_Parms
/If Defined(PR_Only)
/Eof
/Endif
/Endif
// ------------------------------------------------------------
// Procedure: GetInterest
// Function: Get interest information
// ------------------------------------------------------------
P GetInterest B Export
D PI
D @@DSName 10 Const
D @@DSPtr *
D CIRulesPtr *
// ... (The rest of the procedure)
P GetInterest E
/Define PR_OnlyThis technique keeps the prototype in the module where it's used so it doesn't require an extra source member to be maintained. It also facilitates useful "piggybacking" of structures needed for the call.
/Copy GetInterest
// ... More /COPY statements to other procedures
/Undefine PR_Only
Log of Journal Entries |
|
Use this scrollable blog map to view other journal entries: |
|
|
| It is your responsibility to ensure procedures, techniques, and code used from this website are accurate and appropriate for your installation. No warranty or support is implied or expressed. |
 |
| Privacy and Email Policy |
| AS/400®, eServer, i5/OS, IBM i, Integrated Language Environment®, iSeries, OS/400®, RPG/400®, System i5, VisualAge®, and WebSphere® are trademarks of IBM Corporation. Note: IBM® System i is the latest member of the family of eServer iSeries. This site might refer to System i as System i5, iSeries, or AS/400. |
|
If you are having trouble navigating the menu at the top of this page, you may use the following scrollable site map instead: |
|
|
International visitors: