Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Variable Scope: Global vs. Local Variables

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

  • Variable Scope: Global vs. Local Variables

    ** This thread discusses the article: Variable Scope: Global vs. Local Variables **
    ** This thread discusses the Content article: Variable Scope: Global vs. Local Variables **
    0

  • #2
    Variable Scope: Global vs. Local Variables

    ** This thread discusses the article: Variable Scope: Global vs. Local Variables **
    More flexibility, and no need to worry abot name colision. The same could be accomplished by having each suroutine using its unique set of names. For example: all local names of sub01 will start with s01_. If we use Subprocedures, and subprocedure A call subprocedure B, Subprocedure B is not able to access variables used in subprocedure A, but is able to access variables used in mainline.

    Comment


    • #3
      Variable Scope: Global vs. Local Variables

      ** This thread discusses the article: Variable Scope: Global vs. Local Variables **
      When I code an EXSR, BEGSR, ENDSR op code I feel like I am going backwards in my own personal development. While it is true that procedure B cannot see all the variables from procedure A, the thought behind subprocedures is to "compartmentalize" code so that each subprocedure handles one task or function. I personally have started coding sub-procedures instead of subroutines when possible. I prefer to use the capability of coding globally and locally scoped variables. Now I'm trying to wean myself from SEU so that I only use WDSC. 25 years of green screen is difficult to overcome!

      Comment


      • #4
        Variable Scope: Global vs. Local Variables

        ** This thread discusses the article: Variable Scope: Global vs. Local Variables **
        The SQL pre-compiler does not support variable scoping. One has to be careful not to use the same variable names in the main calcs and subprocedures. Otherwise the program may end up using a global variable where the program logic called for a local one.

        Comment


        • #5
          Variable Scope: Global vs. Local Variables

          ** This thread discusses the article: Variable Scope: Global vs. Local Variables **
          There's always tradeoffs, and there's no free lunch. When compartmentalized, global access must be replaced by parm passing. When passing parms, all the parms necessary for every procedure called must be given to the top most procedures and passed along through every procedure in the chain, unless provisions are made to obtain them another way at those lower levels. Sounds simple enough, until more functionality is added and a new procedure is called. Then one or more new parms is usually needed, and the normal course is to have to add parms to the top most procedures called that eventually call the new procedure. And those parms have to be added to every procedure called in between. I ran across this in Java and ended up using a getter and setter approach, that is every procedure making multiple getvar calls for each of the parms needed for that procedure. The same problem and solution will be required anytime data is only accessible through parms. It's not hard but it's not something for nothing either. As usual, I always say that we didn't do badly all these years the way we did things. There's a reason we did it, and a reason it worked so well. Nothing is ever new, just different tradeoffs able and willing to be made. rd

          Comment


          • #6
            Variable Scope: Global vs. Local Variables

            ** This thread discusses the article: Variable Scope: Global vs. Local Variables **
            I still use them all the time, although very little in procedures. IMO, they are good ways to break a solution into easier-to-understand parts. New techniques and paradigms do not necessarily make older ones obsolete. For example: Structured Programming. Those books/articles from the 70's still apply to writing code, regardless of where that code resides.

            Comment


            • #7
              Variable Scope: Global vs. Local Variables

              ** This thread discusses the article: Variable Scope: Global vs. Local Variables **
              I hated C and was glad to get rid of it in late 80s. However I fell in love with C++ when I started it a couple of years ago. Until then, I did not like subprocedures as it looked very cumbersome and especially because there was a way out ... subroutines!!! In C++, I had no option but to write C++ subroutines which translates as SubProcedures in RPG. This took my discomfort with SubProcedures away. Now it is the subroutines that I am an uncomfortable with. With subroutines I have to keep a track of which variable gets modified where. In subprocedures I dont need to. I use either local variables or I RETURN value (or DS) but never modify global variables.

              Comment


              • #8
                Variable Scope: Global vs. Local Variables

                ** This thread discusses the article: Variable Scope: Global vs. Local Variables **
                I do what the client wants. Most of them are just starting to use procedures in their code. I have one who just started using ILE syntax a couple of years ago. I code to the shop standards and try to get them to see how a new way can help them. But, they may need to maintain the code when I'm not there and don't want to see something their staff doesn't understand. Last week, I had to change a S/34-style program. It uses a primary file with multiple secondary files and matching records. And, almost all 99 indicators. No structure statements such as IF and DO; all COMP and GOTO. The change I had to make was simple and I just made it in the same style. Tom.

                Comment


                • #9
                  Variable Scope: Global vs. Local Variables

                  ** This thread discusses the article: Variable Scope: Global vs. Local Variables **
                  Hi Hassan! I'm completely the opposite: I rather like C but dislike C++. There's just too much cruft in C++ for my tastes, much of it due to the difficulty of trying to graft OO onto a compiled language. In my opinion, if you want to do OO, use a language better suited to it, like Python. Cheers! Hans

                  Comment


                  • #10
                    Variable Scope: Global vs. Local Variables

                    ** This thread discusses the article: Variable Scope: Global vs. Local Variables **
                    You can use SQL statements in procedures but the precompiler defines a data structure for every statement redefining the same 64 bytes again and again but what really upsets me is that the pre-complier puts the data structure into global storage instead of in the procedure they are coded in so you end up with a big bunch of storage allocated in the global storage that could be defined in the procedure as local storage. I just wish IBM would gets it's act together with SQL. ILE has been out for 12 years and the precompiler is still making dynamic calls instead of ILE subprocedure calls to a service program. Gees!!

                    Comment

                    Working...
                    X