Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Let's Build a Procedure

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

  • #16
    Let's Build a Procedure

    ** This thread discusses the article: Let's Build a Procedure **
    Hi Ralph! > I disagree with that particular advice, buck. Not a problem - that's why we have discussion lists! :-) > Too many IT people push itsy bitsy functions, > code only the size of the screen, and other > programmer oriented constraints on usefulness of code. You've hit the nail exactly on the head here. Generally the point of these limitations on the programmer are there because the programmer can't hold the whole thing in his head at once. There is genuine room for disagreement on exactly how big is 'too big' and how small is 'too small.' In general though, I find that large parameter lists are a red flag in the 'too big' direction. For most of us RPGers, we're accustomed to very large programs, and many small units seem overly difficult to manage, so we stick to larger code units rather than smaller. > Examples are always pathetic and usually a > freakin formula or something, with one return > parm and not even a nod to reality. It's true that examples are usually off the wall, but that is not the fault of the concept - just the teacher. To me, the true value of subroutines is measured by the way the programmer's thinking shifts from large, amorphous blocks to smaller, concise functions. If you look at the way the rest of the programming industry writes code, you'll find that many small-ish functions is the way things have shaken out over 20 years ago. Everything from small 1 or 2 screen programs to mammoth applications like the Social Security system are written this way. On the other hand, if your shop has a good set of practices in place to do this sort of thing with a small program (no LR, call it one last time to shut down, naming conventions for the scratch variables to hold the results) then I say Bravo! Because you're already reaping the benefits of reasonably small code blocks and thinking in terms of functions. --buck

    Comment


    • #17
      Let's Build a Procedure

      ** This thread discusses the article: Let's Build a Procedure **
      To me, the true value of subroutines is measured by the way the programmer's thinking shifts from large, amorphous blocks to smaller, concise functions. If you look at the way the rest of the programming industry writes code, you'll find that many small-ish functions is the way things have shaken out over 20 years ago. Everything from small 1 or 2 screen programs to mammoth applications like the Social Security system are written this way. On the other hand, if your shop has a good set of practices in place to do this sort of thing with a small program (no LR, call it one last time to shut down, naming conventions for the scratch variables to hold the results) then I say Bravo! Because you're already reaping the benefits of reasonably small code blocks and thinking in terms of functions. --buck I agree, buck. The concepts can be applied to RPG/400 as well, and are in well written systems. I think the large parm list as indicator of an out of control scope for a function, routine, method, standalone program, etc. is right on. Scope should be reasonable and useful and general enough to be used as building blocks to use again and again. For the poster, prototyped parm subprocedures with local variables enforce and type check the modularity and should be the norm, not something that is hard to figure out when to use. rd

      Comment


      • #18
        Let's Build a Procedure

        ** This thread discusses the article: Let's Build a Procedure **
        One big advantage of using commands vs. positional prameters is standarization. For example: prameter LVLCHK() is used on many IBM Commands (CRTPF, CHGPF, CRTLF, CHGLF, Etc.). When we see the parameter LVLCHK we know right away what the meaning is. If we would have to call that same routine vs an API bound or unbound call, we would not know the meaning of each parameter. More about the great advantage of commands The least IBM could do for us is to extend the procedures to allow refer to them via a command type interface, or to allow the creation of commands on the top of a procedure.

        Comment


        • #19
          Let's Build a Procedure

          ** This thread discusses the article: Let's Build a Procedure **
          I guess my suggestion is to submit a Design Change Request. A link to the DCR can be had in the FAQ at http://faq.midrange.com --buck

          Comment


          • #20
            Let's Build a Procedure

            ** This thread discusses the article: Let's Build a Procedure **
            Hi all. I need some expert advice on procdures. From what I have read we have to have a PI statment in a (sub)procedure and a PR statement with the same parms in the calling program (Main procedure?) I have also seen suggestion to use /Copy to replicate these in the code. My question is this: If I create a member to be used by the /Copy that only has the parameters listed, no PI or PR line in it. Then can I code just a PR line in the main procedure followed by /Copy to get the parms in there and in the subprocedure just code a PI line followed by the /Copy? I would like to do this so if the parms should change for any reason I can just change them in the copy member and recompile anything using them instead of having to go into each procedure and change them. I am new to procedures so it is all still a little fuzzy to me but this seems to make sense from a maintenance standpoint.

            Comment


            • #21
              Let's Build a Procedure

              ** This thread discusses the article: Let's Build a Procedure **
              > From what I have read we have to have a PI statment > in a (sub)procedure and a PR statement with the same > parms in the calling program (Main procedure?) Yes, exactly. The PI designates the code that implements the procedure and the PR designates the prototype so that the compiler can match up your use of the procedure with it's definition. The reason for the separate PR is that you might have the PI in a service program (which you don't have the source code for), and then the compiler can't know the proper definition. More or less. > I have also seen suggestion to use /Copy to > replicate these in the code. Here, 'these' means the PR specs. > My question is this: If I create a member to be > used by the /Copy that only has the parameters > listed, no PI or PR line in it. Then can I code > just a PR line in the main procedure followed > by /Copy to get the parms in there and in the > subprocedure just code a PI line followed by > the /Copy? Sure, but that doesn't save you much effort, and it divorces the parameter list from the procedure name and return value. As in, what procedure do these parameters belong to? d inpPath * const d inpCCSID 5a const > I would like to do this so if the parms should change > for any reason I can just change them in the copy member > and recompile anything using them instead of having to > go into each procedure and change them. Yes, this is exactly right. If you find that you have the PI code in the same program as the PR code, then you probably want to consider using a service program instead of embedding the procedure many times into multiple source members. From a slightly different perspective, you probably shouldn't be changing the paramater list too often, unless it's to add new *NOPASS parameters at the end. If you change already-deployed procedures, you need to be very careful to get them all, or you'll be supporting multiple versions of them, which is generally undesirable. Normally, I'll create a new one if the parameter list has to change in the middle... Hope this helps. --buck

              Comment


              • #22
                Let's Build a Procedure

                ** This thread discusses the article: Let's Build a Procedure **

                Code

                Comment

                Working...
                X