|
Hi, > You must have the prototype in the module or program containing the > procedure so the compiler can make sure the prototype matches the > procedure interface. Hence the recommendation for a copybook > containing the prototype so it will be the same in both places (the > program using the procedure and the program defining/containing the > procedure). No, the much simpler reason is the vast number of programs using these smart functions and/or procedures! And if you take those that you do not code (APIs or other software vendors software), that makes sense! For instance, if you bought a "library" of useful functions (e.g. center any string, ...), you just include the copy in the source and have a binder directory with the necessary service program(s). You can see the UNIX style APIs (for IFS files, sockets, ...) as one of these librarys. You have it already. Just build your own copies out of the C sources, that's the hurdle of understanding, and they're the same as any other function you code. (And: in WDSC's 5.1 LPEX, you have a window popping up with the prototyping info. That's worth it! :-) > My opinion has always been that the prototype is there simply to make life > easier for the compiler team. A better way to do this would be to have the > procedure interface an easily accessible part of the program object. The > compiler could look here to make sure I'm using the correct parameters, I > wouldn't have to manage separate copybooks of prototypes, and a part of the > DSPPGM command could show the parameters for each procedure. That would have been indeed nice and would have saved several programmer's life years looking for parameter mismatches. And it would have helped the call interface to convert the data to the format the other program expected it (just think of zoned and packed, ouch, there's this ache between the ears again :-). And it would have lifted the curtains of security of obscurity a bit... :-) -- Mit freundlichen Grüssen / best regards Anton Gombkötö Organisation und Projektleitung Avenum Technologie GmbH Wien - Salzburg - Stuttgart http://www.avenum.com
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.