Information Technology Reference
In-Depth Information
is nothing more than the previous eight statements above, beginning with the
define
and this saves us some work. In this case, we have brought lines into our program from
another source, namely the copy member
acctmemb
.
We need that member in some library of copy code from which we can extract it when we
run or compile our program. The needed lines will be present when we run our program
because they have been extracted from a copy library. We should probably have a
separate library for all our copy members and also another library for all our programs.
This helps in keeping track of where everything is. Also, if someone else will be in charge
of maintaining the programs and copy members, we can tell him where to find the stuff.
Depending on your system and its naming conventions, you may be able to create
a copy library called
PROD.COPYLIB.
Since you also have need for a similar test library, that one might be conveniently called
TEST.COPYLIB.
The name of the two libraries for the computer programs could be simply
PROD.SOURCELIB
and
TEST.SOURCELIB.
You could call these libraries by some other names but these above suggestions are
probably easier to remember and more meaningful.
Getting back to the copy member, it has a few advantages. The obvious one is that
if we change it, we won't have to change every program that uses it. If we didn't have that
copy member and we changed the layout for the account file record, one program would
have the change but other programs wouldn't. The result might be that the other programs
would abend. Even if they didn't, someone looking at the other program without the
modification to the layout might get misinformation about fields in the record since what
the program has is out of date.
Using the copy member might require every other program to be recompiled since
the program as it was compiled earlier would have had the old layout until we compile it
again. However, that is a bit easier than adding three new fields to every program that
uses that copy member. In the case of the P language, we won't need to do anything else
because the execution of our programs is dynamic. This means that when we run them,
the version of the copy member as it currently exists is extracted from the copy library. In
our case the process couldn't be easier. For other systems it may not be that simple.
We can use copy members for structures, procedures or for lines in a program that
are found from one program to the next, such as counters and heading layouts for reports.
This could come in quite handy for some kind of date routine or file access that is used
repeatedly. On the other hand, I have seen programs with one copy member after another
so that it takes some effort to see what the program is doing. You really have to expand
the code to get the entire program in front of you since
copy
acctmemb
doesn't really tell you what fields are in the record. That's the disadvantage.
