|
On Fri, 13 Jun 2003, Richard B Baird wrote: > > I remember seeing them discussed before, and I think they have something to > do with optionally defining portions of a copybook to your program...... > Yeah... but it's not just /copy that can be optionally defined. You can optionally define any source. For example, if I'm writing a program, sometimes I put a bunch of debugging messages into it to try to find that one, particular, stubborn error. So, I add a bunch of DSPLY op-codes. Maybe something like this: c key chain myfile c if not %found c kfld1 dsply c kfld2 dsply c kfld3 dsply c eval msg = 'record not found!' c return ERROR c endif In this example, I added debugging messages to show the values of 3 key fields. Before putting it live, I'll take these debugging things out. But, what happens, if later I need to debug it again? So, instead, I do something like this: c key chain myfile c if not %found /if defined(DEBUG) c kfld1 dsply c kfld2 dsply c kfld3 dsply /endif c eval msg = 'record not found!' c return ERROR c endif Now, if I want to put it into production, all I have to do is compile it without defining DEBUG. When I need the debugging code to solve a problem, I can re-enable it just by defining DEBUG. Compilng it WITH debug: CRTBNDRPG MYPGM SRCFILE(MYLIB/SRCF) DEFINE(DEBUG) Or without: CRTBNDRPG MYPGM SRCFILE(MYLIB/SRCF) Another use of /define logic would be something like the close() prototype. Both sockets and IFS APIs use the *same* API call to close the connection. the close() API. I have a /copy file for sockets. I have a /copy file for IFS. Great. But now, if I write a program that uses BOTH sockets and IFS (which is very common! at least for me!) I have a conflict because the prototype for the close() API is defined in both places. So, I have code like this in both /copy members: D/if not defined(CLOSE_PROTOTYPE) D close PR 10I 0 ExtProc('close') D desc 10I 0 value D/define CLOSE_PROTOTYPE D/endif Now they never conflict, since only the first one to be /copy-ed in gets used. Since they call the same API, it doesn't matter which prototype I use... but this way, I can have it defined in both /copy files withotu conflict. Another example is my HTTPAPI project. HTTPAPI is capable of working with SSL, or without SSL support. I used /define to exclude the SSL suppor for people who do not need it. When you need SSL, you install some additional licensd programs from IBM, and then compile HTTPAPI with WITH_SSL defined. Bingo! SSL works. People who don't need SSL, can compile and run HTTPAPI without having to install the SSL licensed programs. Since WITH_SSL is not defined, the compiler ignores the SSL sections of code. those are just a few examples. > am i right? what does it buy you other than the memory needed to define > these specific specs? IMHO, the memory isn't a huge concern. For "what does it buy you" see above. > > by defining all prototypes of a SP to your program, does it bind all > functions from the SP even if you don't use them? > > in otherwords, if you have 20 functions in a service program with an > associated prototype copybook, and you include the entire copybook in your > main module, does it bind all functions to the program? and conversely > only including the prototypes of the functions you actually use cause only > those functions to be bound to the program? > I'm pretty sure that it does not bind them unless you use them. I haven't actually experimented to test that, however. I certainly don't put "/if defined" around ALL of my prototypes. I only use it when I absolutely need to, such as the cases listed above. Having to /define every single prototype I want to include seems very awkward to me -- and what would it buy me? Maybe a SLIGHTLY smaller object size? And, what does this topic have to do with binder language?!
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.