Let's Build a Procedure

[miller_ste]

Let's Build a Procedure

** This thread discusses the article: Let's Build a Procedure **
I agree with Joel. Procedures are very useful for functions and logic that can be used over and over again from different programs/applications. The easiest way to code the Procedure Interface is with the /COPY. This allows you to code the PI in one place and replicate it wherever you need it. In fact with a combination of /IF /DEFINE /UNDEFINE you can make your source code very clean. Forget the S36 we are on the iSeries now and it is a very different environment. I can think of several functions that can be coded as a procedure that will work in most businesses Get Price, Get Tax, Get Rate, etc. If you are coding these over and over again in subroutines and I know many programmers are, you are missing the point. Don't forget, you can execute a procedure from a CLLE program too! Why are RPG programmers so reluctant to use procedures? They have been around for about ten years now. By now we should be beyond procedures and digging into free form RPG, other languages, and systems. Change is hard, but not changing is paralyzing. Is your boss going to accept from you that you can not do it? No, he will find someone else who can.

[miller_ste]

Let's Build a Procedure

** This thread discusses the article: Let's Build a Procedure **
Code the procedure in an RPGLE source member as shown in the example. Be sure to code an H spec H NOMAIN at the beginning of your source member. Compile the member using option 15 CRTRPGMOD. In order to call the procedure, you must bind it to a program that will call the procedure using CALLB, CALLP, or using an EVAL statement. You can also call a procedure from a CLLE (CL ILE Program) using CALLPRC PRC(Procedurename) PARM(input)RTNVAL(procedurereturn parameter). Here the RTNVAL parameter will accept what is passed back from the procedure. Good Luck!

[joelcochran]

Let's Build a Procedure

** This thread discusses the article: Let's Build a Procedure **
This is a big question, so my response will be far from all inclusive, but here goes: Basically, you create *MODULE objects and the "bind" them together using the CRTRPGMOD command. In this case one for the calling program and one for the procedure. This binding occurs when you run the CRTPGM command. There are two kinds of Binding: 1) Bind by Copy. In this approach, you reference the *MODULEs in the CRTPGM command's MODULE attribute. All of these *MODULEs are then COPIED into the *PGM object. This makes larger programs, and if the same one is copied over and over and over, it creates a maintenance headache should ou ever need to change a *MODULE. 2) Bind by Refernce. In this approach, you include a reference to the object you wold like the program to use at run time. This refernce is either a *SRVPGM using the BNDSRVPGM attribute of the CRTPGM command, or is contained in a *BNDDIR and referenced using the BNDDIR attribute. A binding directory is a just a listing of references. This approach is much easier to maintain in the long run, and since the objects are not copied into the *PGM, the programs are smaller. I would recommend learning how to create service programs to hold your *MODULEs, and then listing that *SRVPGM in a binding directory. Now you can reference the binding directory in your RPGIV code by adding an H-Spec like: h bnddir("MYLIB/MYDIR") Now you don't even have to reference it on the CRTPGM command. Joel Cochran http://www.rpgnext.com

[joelcochran]

Let's Build a Procedure

** This thread discusses the article: Let's Build a Procedure **
There is nothing wrong with using /copy for prototypes. We aren't talking about program logic here, so you don't really have the pitfalls that originally had programmers running away from /copy. Also, the fact that you used to do something similar on the 36 does not make it a bad approach today. Not writing external procedures because you have to compile them with a different command is just silly! And what makes "CRTBNDRPG" the "regular" way? If it bothers you that much, compile EVERYTHING with CRTRPGMOD and then use the CRTPGM command. At least this way, you only have to fiddle with one approach. And binding is hardly difficult, it's just different than traditional RPGIII. Obviously, I disagree that making it reusable is different. I think it is very easy, and if you aren't doing it, you are selling your RPG skills short. Now, for your expected "improvements": 1. I kind of agree here: the procedure could match the calling prototype to the PI statement. But in all honesty, this is not a big deal. And by forcing me to have the prototype in the procedure also, I know that I've already created it appropriately so that it can be used in calling procedures. 2. Modules are not executable. Binding is at the heart of ILE, so you really can't avoid it. The exception is putting a *MODULE directly in a binding directory, which has a number of flaws of its own and not a practice I would recommend. Second, binding directories, while they are SUPER, are completely optional. So basically, if you don't like the "extra" coding for them (which is minimal), then don't use them. But that means opening a maintenance nightmare of binding by copy every module you reference in your program... for EVERY program. This approach would make ANYONE dislike ILE. 3. Again, what's a regular program? I'm not sure what you are getting at here... 4. Now you are talking tools, not environment. This is the kind of thing that VisualStudio adds for Windows development. It has nothing to do with the language itself or program construction. I don't usually respond to this kind of stuff, but postings like this tend to discourage people from experimenting and learning ILE, and in this case that is unjustified. Are there some new things to learn with ILE? Of course. Is it different than "the way we've always done it?" Absolutely. Is ANY of this a reason to naysay ILE? NO! And this is NOT a step backwards. This has nothing to do with "PC Users" vs. "AS/400". CALL-PARM was great, but limited. You can do everything you did with CALL-PARM and much more, and in a safer more productive manner using ILE enhancements. Joel Cochran http://www.rpgnext.com

Let's Build a Procedure

** This thread discusses the article: Let's Build a Procedure **
Hi, I would like to "cut my teeth" on an easy procedure. I have in mind a procedure to take separate address fields (street, city, state, zip, country) and string them together into the typical address for an envelope. I think with the example in the article I can write the procedure and call it from the program. But can you take it one step further - how do I compile it, and then I think I have heard about binding etc... Of course this has probably been covered lots of times and in lots of places. But I appreciate the simplistic, low level, of the article, so please continue...

[avrahamn@coop.co.il]

Let's Build a Procedure

** This thread discusses the article: Let's Build a Procedure **
Now in this example You gave, instead of 3 lines of code, more than a dozen lines were used. Besides that, it cannot be compiled with the regular compilation - CRTBNDRPG. It needs to have CRTRPGMOD and binding afterwards. If wee need it for reusability of code, anyway it is not so easy to use, Every program that calls it need to have a prototype. I am aware that we could use a /copy compile directive. but that takes us to the old system 36 days where the only way to make reusable code is by having /Copy directives of AUTO REPORT. Also the linking and binding technics take us to the old days old SYSTEM36 with the Linkage Editor. All this may be good for PC users that did not taste the ease of use of just a plain CALL-PARM statement. We - AS400 Users that got used to the simplicity of CALL-PARM, for us it is step backwards. As for speed, anyway must of the heavy usage is on file openning etc. I made a test of Bound module with one file to open and almost did not find any diference Between CALL and CALLB. The big diference was when i changed to end the program with RETURN instead of *INLR. I am expecting from IBM the following changes in order to make the use of procedures really more productive: 1. Not needed to code the Prototye twice. The calling program should find it from the called procedure. 2. On CALLB - find the module in the Library list. No need the extra coding of binding directory ETC. 3. On a regular program, there is an option to create a command, and then use it with the Command Interface that is so vital when calling programs with many parameters. Imagine the so popular used command CPYF, if we would need to use it like a procedure an count which parameter we are on. 4. Same as with User Defined Commands, F4 on SEU prompts us for its parameters, similar to it we should be able to do with user defined procedures.

[MCWebsite.Staff]

** This thread discusses the article: Let's Build a Procedure **
This is a discussion about Let's Build a Procedure.

Click here for the article.