Re: design issue and /copy statements

[rob@xxxxxxxxx]

We have this large /copy statement that copies in numerous PI's, data 
structures, etc.

1)  Several people were getting anal about it because it defined variables 
that they didn't use.  Their concern was:
a)  Those pesky messages at the bottom of the compile about unreferenced 
variables
b)  Did they take up additional memory?
c)  Did the program take up more disk space?
d)  Don't want to use any existing code.  My way is the only way.  I want 
to use these same variable names for other meanings.  Or, they were 
finally willing to bend and start using the /copy, but there were several 
conflicting existing variables.

2)  Numerous of the system api's have like (and unlike) data structures. 
Putting them in there was causing problems.  Granted, some of this would 
be fixed with qualified data structures but that met with some resistance. 
 The like data structures were cool and could easily be handled with 
conditional compilation.  You know, those data structures "format 0200 is 
like format 0100 with these additional fields...".  However, some were 
radically different.

Now our big /copy is being more of a /include with nested /includes.  That 
way, if you don't want to look up a bunch of the individual members, you 
can.  Also, if you want just the individual /include you can do that 
instead.  The nesting allows us to change just the individual and it will 
also be changed in the big honker.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin