| 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: /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. 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: /Define PR_Only This 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. |
Special pricing for the Ontario area. Book a 5-day onsite class for as little as USD $900/day. Get a price quote today. Ask for offer CA900.
5-day minimum, special terms apply.