Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Let's Build a Procedure

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

  • mikespec
    replied
    Let's Build a Procedure

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

    Code

    Leave a comment:


  • buck.calabro@commsoft.net
    Guest replied
    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

    Leave a comment:


  • Guest.Visitor
    Guest replied
    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.

    Leave a comment:


  • buck.calabro@commsoft.net
    Guest replied
    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

    Leave a comment:


  • avrahamn@coop.co.il
    replied
    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.

    Leave a comment:


  • R.Daugherty
    replied
    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

    Leave a comment:


  • buck.calabro@commsoft.net
    Guest replied
    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

    Leave a comment:


  • R.Daugherty
    replied
    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

    Leave a comment:


  • buck.calabro@commsoft.net
    Guest replied
    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

    Leave a comment:


  • buck.calabro@commsoft.net
    Guest replied
    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

    Leave a comment:


  • buck.calabro@commsoft.net
    Guest replied
    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

    Leave a comment:


  • avrahamn@coop.co.il
    replied
    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).

    Leave a comment:


  • avrahamn@coop.co.il
    replied
    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.

    Leave a comment:


  • R.Daugherty
    replied
    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

    Leave a comment:


  • R.Cozzi
    replied
    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.

    Leave a comment:

Working...
X