Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Let's Build a Procedure

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Let's Build a Procedure

    ** 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.


  • #2
    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.

    Comment


    • #3
      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...

      Comment


      • #4
        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

        Comment


        • #5
          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

          Comment


          • #6
            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!

            Comment


            • #7
              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.

              Comment


              • #8
                Let's Build a Procedure

                ** This thread discusses the article: Let's Build a Procedure **
                Comparing CALL and CALLB is a typical mistake most RPG programmers make. The reason they do this is because IBM foolishly tried to get people to use CALLB in place of CALL before RPG IV even had subprocedures. That was just stupid. The bulk of the overhead of a CALL is in the RPG Cycle start-up routine. So if you simply replace a CALL with a CALLB and compile the second RPG IV program as a module, you save nothing substantial and you add the complexity of CRTRPGMOD as avrahamn stated. I never advocate doing this kind of thing; in fact I will be an ass about it to the point where I would say if anyone tells you to do it that way, they don't know what they're talking about. You can use CRTBNDRPG with procdures, you just have to change the DFTACTGRP(*YES) parameter to DFTACTGRP(*NO) and it works fine. I use it everyday. If you modularize you code (multiple modules, then you use PDM option 15, CRTRPGMOD for the secondary modules and then use options 14, CRTBNDRPG with DFTACTGRP(*NO) and a binding directory. It is not difficult, it is just new and different. There are things that make it difficult, but you can ignore all that stuff if you want. Trying to do too much too soon will lead to accidents and some people are put off by accidents. Others, see them as learning experiences. You can never go to the Moon if you're affraid of making a mistake here and there.

                Comment


                • #9
                  Let's Build a Procedure

                  ** This thread discusses the article: Let's Build a Procedure **
                  An excellent article and discussion. I don't think the trasformation from subroutine to procedure could have been more dramatically clearer. rd

                  Comment


                  • #10
                    Let's Build a Procedure

                    ** This thread discusses the article: Let's Build a Procedure **
                    I am still puzzled how do I know in which service program or module is the procedure. Lets say a program has in itself 5 service programs and 15 modules. When I see the name of any given procedure how do I know in which service program is that procedure and where is the source of it. After all that we need to say to IBM that our time is very valuable and before we will accept their innovations, they need to make it as easy to use as what is was in the old way and even easier. Also I need to have a command which is a must for any program with many parameters, and I cannot do it with a procedure.

                    Comment


                    • #11
                      Let's Build a Procedure

                      ** This thread discusses the article: Let's Build a Procedure **
                      Is your boss going to accept from you that you can not do it? My buss Know that I can do it and even much more. The only question is if it pays to do. Is it better than before. I need a real comparison of all the benefits of CALL-PARM and commands, all the disadvantages, and compare it to Prototype-Procedure-Module-Service Program. One day IBM may come to us and announce that they discovered something new: There is no need any more for all those extra steps of binding and prototyping. just use CALL-PARM, and You could even use keyword names instead of parameters just by position (COMMANDS).

                      Comment


                      • #12
                        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. Judging the quality of code by it's line count is dangerous and misleading. Take the two snippets below. Which is better code? if a(x)='end' ... endif if x>%size(a) ... else if a(x)='end' ... endif endif --buck

                        Comment


                        • #13
                          Let's Build a Procedure

                          ** This thread discusses the article: Let's Build a Procedure **
                          > One day IBM may come to us and announce > that they discovered something new: There > is no need any more for all those extra steps > of binding and prototyping. just use CALL-PARM, > and You could even use keyword names instead > of parameters just by position (COMMANDS). I do this all the time, in addition to using subprocedures. --buck

                          Comment


                          • #14
                            Let's Build a Procedure

                            ** This thread discusses the article: Let's Build a Procedure **
                            > I am still puzzled how do I know in which > service program or module is the procedure. Your source control system tells you. > When I see the name of any given procedure > how do I know in which service program is > that procedure and where is the source of it. When you see the name of a program how do you know which library it is in, and where the source is? > Also I need to have a command which is a > must for any program with many parameters, > and I cannot do it with a procedure. From a design perspective, a subprocedure should be thought of like a function. It is closer to SQRT than it is to an entire program. The CPP would call several functions (which are the subprocedures). If a subprocedure has many parameters, it is probably too big. --buck

                            Comment


                            • #15
                              Let's Build a Procedure

                              ** This thread discusses the article: Let's Build a Procedure **
                              I disagree with that particular advice, buck. Too many IT people push itsy bitsy functions, code only the size of the screen, and other programmer oriented constraints on usefulness of code. Examples are always pathetic and usually a freakin formula or something, with one return parm and not even a nod to reality. My short suggestion is that a subprocedure should be more like a small standalone program that we would write under RPGIII without setting *INLR on, and an input parm code to close, etc., that we have used in place of subprocedures and especially a separate module subprocedure that we would bind to a program or service program. I think the subprocedure as BIF is is also good, although I've never written anything in BIF form, but not limited to that. That's just a thought ot two coming from the approach of the questions of the poster. Thanks for your insights as always, buck. rd

                              Comment

                              Working...
                              X