|
Scott, go to bed! it's late! ;) > *CURRENT is used to signify that this list is the "latest edition" (most > recent version) of your service program's interface. *PRV says that > it's not the most current, but rather an old version of it. > Why does that matter? Well, when you compile a new program that uses the > service program, which set of routines do you want it to use?! Obviously, > the "current" version. So, you need a way to tell the compiler which one > is "current". > Just, every time you add a subprocedure, or a group of them, to your > service program, go into the binding source, and change the old interface > to *PRV, and add a new group where the new subprocs are added, making that > new one the *CURRENT. Ok, I think i've got it. stop me when I'm wrong.. Does this means you can have multiple *PRV export symbol lists? The combination of the exports in each list creates the signature that a previously compiled SP uses. Programs that use the SP and are (re)compiled will always use the *current. As long as that signature doesn't change (by keeping an *prv export list in the binder source when recompiling the SP), the programs that use the old version of the SP don't need to be recompiled. So, what happens if you change an existing subproc? If you change the prototype, then obviously you'd need to recompile all programs that use that subproc. at that point, what do you do to your binder source? Since all 'signatures' with that proc listed will have changed, do you need to recompile all programs that use the SP? What if you don't change the prototype, only the calcs of the subproc, do you still need to recompile? do you change the binder source? > > I've tried reading the ILE concepts guide, but i'm still fuzzy on these > > topics. Everytime I look at that thing, my eyes start to gloss over. > That's unfortunate. These things are, IMHO, rather simple things. Too > many people are afraid of them.. If IBM would write manuals that are > easier to read, it would sure help!! They are simple for those with exposure to more oo type languages, but us old strait line procedural rpg hacks, it's not very intuitive. IBM does a great job with reference manuals, but when they start to talk about concepts, they fall a little short. This has helped a bunch. Thanks again, Rick
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.