|
We do exactly that, Buck, and then list all the service programs in a single binding directory, and add that binding directory to our create command defaults, so that programmers don't even have to think about it. All procedures are then available to all programs. We also put all the prototypes in a single source member and use the "IF Defined" compiler directive so that only requested prototypes are copied into the actual programs that need to use them. The prototypes source member itself, then becomes the universal list of all publicly-available procedures. With this scenario, programmers who only want to "use" procedures don't need to concern themselves with the nitty-gritty details of how they are implemented. All they have to do is select a procedure from the prototype list, include the prototype's copy member in their program, and use it. What we don't have that I would like to see is some sort of nice cataloging utility. Something that presented the procedures graphically in a tree-chart, by function, would be wonderful. Does anyone have anything like that? > -----Original Message----- > From: Buck Calabro [SMTP:Buck.Calabro@commsoft.net] > Sent: Wednesday, September 12, 2001 12:09 PM > To: midrange-l@midrange.com > Subject: Wrapping API in service program > > As I work with more and more APIs, I want to wrap them in my own > procedures. > I want to make these procedures available to others in my shop; service > programs seem just the ticket. My first thought was to wrap each API > "family" in it's own service program, so I'd have one service program for > user spaces, one for retrieving program information, etc. This seems a > fair > balance because a single program will only need to bind to a few service > programs in order to work. > > 1) Any contrary ideas? > 2) Any practical experience to support/refute this plan? > > Buck Calabro > Commsoft; Albany, NY > Visit the Midrange archives and FAQ at http://www.midrange.com > "As a rule, men worry more about what they can't see than > about what they can." -- Julius Caesar > > > _______________________________________________ > This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing > list > To post a message email: MIDRANGE-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l > or email: MIDRANGE-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/midrange-l. ************************************************************************************************************************************************************************************************************ This message originates from Lincare Holdings Inc. It contains information which maybe confidential or privileged and is intended only for the individual or entity named above. It is prohibited for anyone else to disclose, copy, distribute or use the contents of this message. All personal messages express views solely of the sender, which are not to be attributed to Lincare Holdings Inc., and may not be copied or distributed without this disclaimer. If you received this message in error, please notify us immediately at MailAdmin@lincare.com or (800) 284-2006. ************************************************************************************************************************************************************************************************************
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.