Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Enhance Your Legacy RPG III Apps

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

  • #16
    Enhance Your Legacy RPG III Apps

    ** This thread discusses the article: Enhance Your Legacy RPG III Apps **
    Any use of modular capabilities, even prototyped subprocedures, require a named activation group Actually, this is a bit misleading. If you compile your main programs as *NEW and all the rest as *CALLER, there is no need to specify a named AG on your CRTxxx command. Such a strategy is often cited for those who don't really know how to architect their ILE application. When I say ILE, I mean ILE activation groups, etc., not RPG IV. An alternative strategy is the simple expedient of using a single named activation group. I mention this to counter the oft-heard complaint that ILE is too complex; in particular I often hear that activation groups are difficult to understand, much less implement. iSeries activation groups are designed to allow for incredible flexibility and as such present many options; many possibilities to the ILE newcomer. But like all other aspects of programming, one does not NEED to use all the flexibility available. The single named AG is simple to use and fulfills the requirements of many RPG shops who want to use subprocedures but don't want to re-architect their code base to use ILE. I agree completely that every professional programmer (that is, getting paid to write programs) should understand simple and common CIS concepts like bound modules. --buck Well, daggone this terminology. Thanks for the clarification, buck. I was just trying to differentiate between ILE activation groups and the default activation group that OPM RPG III and CL programs run in. It's probably a detail that was better not taking into account. The redbook warns against using the default *NEW activation group for CRTPGM. I would liken it to starting a new JVM for every Java program called or a new environment for every script called, etc. It's easy to see how inefficient that is. A named activation group is the default for CRTBNDPGM, which is what I was advocating. Part of the laziness I was talking about is advocating the standalone RPG IV program compiles with *NEW that both don't take advantage of modularity and then run in the most inefficient form possible. Your take on it is what RPG programmers should be exposed to instead as professional programmers. rd

    Comment


    • #17
      Enhance Your Legacy RPG III Apps

      ** This thread discusses the article: Enhance Your Legacy RPG III Apps **
      The redbook warns against using the default *NEW activation group for CRTPGM. I would liken it to starting a new JVM for every Java program called or a new environment for every script called, etc. It's easy to see how inefficient that is. First, it's nowhere near the overhead of starting up the JVM. The creation of a new activation group is fine for occasional use, such as at the beginning of a menu option. I suggest running a benchmark and comparing the timing of JVM startup and AG creation to get a good idea of the relative overhead. Second, the concept of *NEW/*CALLER is actually quite beneficial for a number of reasons, including the ability to leave files open in called programs and not have to revisit them to "shut them down". Many people who rely heavily on programs that don't set on *INLR have had to implement a way to shut down all those called program; ending the AG is a fast and painless way to do that! In fact, the *NEW/*CALLER concept is a great intermediate step from OPM to ILE without having to rearchitect called programs to service programs or bound modules. I think the AG concept may be overkill for lots of people; witness the confusion among people as to what is shared in an AG - it's not uncommon for a programmer to get the idea that a named AG will share data across jobs (which it does not!). Named AGs also need to be explicitly shut down; failure to do so can lead to object and record locking issues, as well as the dreaded "I recompiled, but nothing happened" problem. Joe

      Comment


      • #18
        Enhance Your Legacy RPG III Apps

        ** This thread discusses the article: Enhance Your Legacy RPG III Apps **
        The redbook warns against using the default *NEW activation group for CRTPGM. I would liken it to starting a new JVM for every Java program called or a new environment for every script called, etc. It's easy to see how inefficient that is. First, it's nowhere near the overhead of starting up the JVM. The creation of a new activation group is fine for occasional use, such as at the beginning of a menu option. I suggest running a benchmark and comparing the timing of JVM startup and AG creation to get a good idea of the relative overhead. Second, the concept of *NEW/*CALLER is actually quite beneficial for a number of reasons, including the ability to leave files open in called programs and not have to revisit them to "shut them down". Many people who rely heavily on programs that don't set on *INLR have had to implement a way to shut down all those called program; ending the AG is a fast and painless way to do that! In fact, the *NEW/*CALLER concept is a great intermediate step from OPM to ILE without having to rearchitect called programs to service programs or bound modules. I think the AG concept may be overkill for lots of people; witness the confusion among people as to what is shared in an AG - it's not uncommon for a programmer to get the idea that a named AG will share data across jobs (which it does not!). Named AGs also need to be explicitly shut down; failure to do so can lead to object and record locking issues, as well as the dreaded "I recompiled, but nothing happened" problem. Joe Again, good clarification. Thanks, Joe. I likened it in concept, not actual times. The default of *NEW for every program is what the redbook warned against and what I referred to, not architected occasional startup such as the beginning program of a job that you mention. I have used that approach myself. Good that the difference is clarified. Also, buck suggested one named activation group similar in my opinion to the default activation group to run OPM programs. The caveats you mention are more applicable to keeping a handle on multiple named activation groups instead of equivalent *NEW's it appears to me. I am checking the redbook again on what it says about the *NEW/*CALLER group and named activation group. Either way, the options should be clear to people and a discussion like this really helps do that. rd

        Comment


        • #19
          Enhance Your Legacy RPG III Apps

          ** This thread discusses the article: Enhance Your Legacy RPG III Apps **
          The redbook warns against using the default *NEW activation group for CRTPGM. I would liken it to starting a new JVM for every Java program called. Ralph, I am confused by your terms here. What is a java program (a class a set of classes, or something else)? I am no java guru so I am interested to know how would one java process start another java process inside the same JVM ? My understanding is the exec method of the runtime class starts a process that is outside the JVM. I know we can run multiple threads in the JVM

          Comment


          • #20
            Enhance Your Legacy RPG III Apps

            ** This thread discusses the article: Enhance Your Legacy RPG III Apps **
            The redbook warns against using the default *NEW activation group for CRTPGM. I would liken it to starting a new JVM for every Java program called. dave400 wrote: Ralph, I am confused by your terms here. What is a java program (a class a set of classes, or something else)? I am no java guru so I am interested to know how would one java process start another java process inside the same JVM ? My understanding is the exec method of the runtime class starts a process that is outside the JVM. I know we can run multiple threads in the JVM I'm sure not a Java guru, just a beginner, but I'll explain what I meant. The Building AS/400 Applications with Java refers to both Java programs and applications the same, that of a program associated with a class as in for example if we were to use the CRTJVAPGM command to compile bytecode into an AS/400 program object. It also compares a Java package to an RPG program in the sense of a set of subprocedures roughly approximating the methods in a set of classes in a package with say one class with a main() method being the start of the program. The likeness I was making to compiling all RPG programs with the default *NEW activation group would be any java class of any appreciable size invoked from a different package to be pictured as starting up in a new JVM rather than running in the current one, not that it would work and of course Joe is right, more overhead than starting an activation group, but still the RPG IV redbook says there would be serious performance problems with a new activation group for every program as you can imagine. The analogy may not have been very good but it did raise some questions and helped me in trying to answer them. Also, I meant CRTPGM from CRTRPGMOD modules in an earlier post. rd

            Comment


            • #21
              Enhance Your Legacy RPG III Apps

              ** This thread discusses the article: Enhance Your Legacy RPG III Apps **
              The caveats you mention are more applicable to keeping a handle on multiple named activation groups instead of equivalent *NEW's it appears to me. Not really, particularly the "I changed the program and nothing happened" issue. With a named activation group, you must explicitly end it via the RCLACTGRP command (I think there may be an API as well), wheras with *NEW/*CALLER, as soon as the program with *NEW ends, the activation group is reclaimed. In a development environment especially, it's one less thing to worry about whenever I recompile. The place where it kills you is when you have a subprogram that you call hundreds or thousands of times; spawning thousands of short-lived activation groups is definitely a bad idea. Joe

              Comment


              • #22
                Enhance Your Legacy RPG III Apps

                ** This thread discusses the article: Enhance Your Legacy RPG III Apps **
                Yes, as mentioned above by ____, the "Who knew ... Wizard's Guide to RPG/4" is an excellent, excellent resource. Check it out.

                Comment


                • #23
                  Enhance Your Legacy RPG III Apps

                  ** This thread discusses the article: Enhance Your Legacy RPG III Apps **
                  > Well, daggone this terminology. You said it Ralph! --buck

                  Comment

                  Working...
                  X