Creating your own BIF

[J.Wells]

I'm ignorant when it comes to procedures. Therefore, I was very pleased that Douglas Handy posted the code example using the procedure named RtvObjCnt. Using his example, I was able to create a program that contained a VERY SIMPLE procedure. If I want to use this procedure in another program, what is the best method for doing so? I know that I could simply copy it into each program (or /COPY), but is there a way to make it standalone so that minimal effort is needed to use it in other programs? Thanks, Joe

[S.Mildenberger]

Creating a service program is the way to go. For some examples, look at the RPG IV redbook http://www.redbooks.ibm.com/abstracts/sg245402.html Also, reading the ILE Concepts Manual would be very helpful. Make sure you use binder source when creating the service program, it allows additional procedures to be added without having to recreate existing programs. Try checking these out and if you have further questions just ask. Scott Mildenberger

[Guest.Visitor]

Joe, You have a couple of options. The first step is to create your subprocedure in a seperate module. You would create the module using the crtrpgmod command. In the source for the module specify nomain in the H specs. Once you have this step completed, you have two way that the subprocedure can be used. The first is bind by copy, the second is bind by reference (service program). I would use bind by copy if the subprocedure will only be used in one program, otherwise I would use bind by reference. In the module that will call the subprocedure, you will need a prototype that describes the parameters of the subprocedure. I would use /copy to copy the prototype definition. I create one prototype member per module and place it in another source file. I use qprotosrc. To create this module, you will also want to use crtrpgmod. After you have your two module created, you combine them using the crtpgm command. If you are going to bind your subprocedure by reference, you will need to create a service program containing your module/subprocedure. So if you have two modules, the first containing your main procedure and the second containing your subprocedure the creation commands would be: crtrpgmod module1 crtrpgmod module2 crtsrvpgm srvpgm1 module(module2) export(*all) crtpgm pgm1 module(module1) srvpgm(srvpgm1) I have left out a lot, I would look at the ILE concepts manual for more detail, or post more questions as you work through each step. David Morris

[D.Handy]

Joe, I was able to create a program that contained a VERY SIMPLE procedure. GREAT! It doesn't matter that the procedure is simple. I have service programs where many of the routines are very simple and sometimes only a couple of lines long. But it allows me to increase the readability by naming the procedure according to its function. You'll soon find that subprocedures are a terrific addition to the language. They continue to be my favorite addition to RPG. I'll second the motion to recommend reading the Redbook. It should be required reading for every RPG programmer, IMHO. I rarely code a subroutine anymore. Forget the warning in the RPG manual about subprocedures being slower than subroutines. It rarely matters in the big picture, and ignores the fact that many subroutines need moves either before or after the subroutine (or both) to work around the lack of parameters. There are just too many advantages to using subprocedures, even if they are only needed by current module/program. One nit: don't call your own procedure a BIF because a BIF by definition is, well, built-in. Hans & Company can create a "built-in" function; we can create a subprocedure. Mostly only a semantic difference, although they can pull a few tricks that we can't since we don't have full operational descriptor support. In essence, that means they can more intelligently handle parameters of various types. For example, they can tell the type, length, and decimals of a numeric field allowing them to do a %editc(), whereas we cannot do the direct equivalent. Doug

[J.Wells]

Thanks to everyone for their quick replies! I will keep you posted as I progress. Thanks, Joe

[Guest.Visitor]

Joe; If you would like a slightly more involved example of using a service program, look at the attached zip file. The zip file contains the source code for some programs I wrote to display data queue information. The programs do not have all the functionality that I want, but they do work. I have had several request for these programs from other programmers, so I thought I'd just put them up on the forum for anyone to get. Hope this helps in your quest for education!:-) Jerry Hensley

[J.Wells]

O.K. I have created a module and a service program and then created another module that uses the first module and then created a program binding the two together and it WORKS! Now, I have showed it to my supervisor and manager and they are impressed. However, they want to know (and I do too), what is the real advantage to this vs. a call program? Thanks, Joe p.s. - I am not a 'code cowboy' and they are not trying to squelch new ways of doing things - we are just trying to learn and make informed decisions of what is best for our situation.

[S.Mildenberger]

Joe, Some of the advantages of using service programs that contain small well defined functions are 1)It is easy to create small procedures within a service program than creating a program to call. 2) The procedure's can return a value resulting in a function that can be used in expressions. Code such as 'if not valid_splc(new_splc)' can be used to validate input values. This is more readable than calling an external program and checking a parm or from embedding the code to do this validation in every program that needs it. 3) Fewer side affects because the procedures can have all local fields, unlike calling a subroutine which is affecting globally defined fields. You can also enforce whether a procedure can change parameter values or not. All parameter passing is defined instead of being done through global fields. 4) Facilitates code re-use, a library of service programs with small well defined procedures will make it easier to reuse functionality that has already been developed. 5) Mis-matches in procedure parameter types/values are caught at compile time instead of run time. Those are just some of the things I think of right away. I recommend that you take some very commonly used functions that are used throughout your system and create service programs for them. Then start using them, I know it makes it a lot easier for me to write better code in less time. We have database files that are only accessed through service programs, imagine how easy it is to change the layout of this file. All changes are localized to one place. Of course, your programmers have to have discipline to use the procedures and not the file itself or this falls apart. My advice is to start small and just keep building, we are really glad we did. Scott Mildenberger