|
Jeff, >why do you do it the way you do? I'm with you. One global binding directory. One module per service program, named the same as the service program and using *Caller. One bindery source per module / service program, with current and previous signatures for all exports in that service program. Multiple functions per service program, but grouped by categories. For example: - String functions - Date functions - Data queue functions - User space functions - User index functions - WS and DSPF functions - Etc. For each I have a /copy member with the respective prototypes. Other copy members have prototypes for various APIs using ExtPgm(). Either way, all I have to do is name a /copy, and I have a set of related procedures at my disposal. Everything is extremely simple to implement, maintain, and use. I have yet to have any problems with doing it this way. Even without a change mangement system or sophisticated make utility for dependencies. Doug
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.