Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

TechTip: Activation Group Architecture for RPG ILE

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

  • #16
    TechTip: Activation Group Architecture for RPG ILE

    ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
    ** This thread discusses the Content article: TechTip: Activation Group Architecture for RPG ILE **
    ** This thread discusses the Content article: TechTip: Activation Group Architecture for RPG ILE **
    Assume a program can be a called program or a standalone program. For example: If Program A is called from a menu, the parameters passed into it tell it to behave as a standalone program. If parameters passed into it differ, it operated as a called program and jumps to a different introductory screen. In turn, Program A can call other programs that may or may not also behave in the same dual function. How would activation groups affect this scenario? Your explanation was good, but my big problem with AGs is that they are rarely well explained, thus the value is nebulous. I remember playing with them and not being able to get data into called programs properly. Rather than try to figure out the problem I just chose to ignore them since, prior to AGs I never had that problem.

    Comment


    • #17
      TechTip: Activation Group Architecture for RPG ILE

      ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
      It is not clear to me what you _want_ to happen. The notion of a program being stand-alone or a called program sounds more like a COBOL view of the world. Are we talking RPG or COBOL here? Is the question how to handle a program that sometimes should tear down the universe and sometimes should allow others to do it? If so then you are going to need named Activation Groups to make that work. Under those circumstances you can either destroy the AG through RCLACTGRP back at the menu level from which the root program was called - or (and this might fit your scenario better) your prorgham when acting in a stand-alone mode could issue a call to CEETREC to bring down the AG on its return. There is nothing in the world of AGs that would account for screwed up parameters though - That's what you mean by "get data into" right? Unless of course you are playing games with pointers. Jon

      Comment


      • #18
        TechTip: Activation Group Architecture for RPG ILE

        ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
        Nice overview of the *NEW/*CALLER view of the world Joe. This is the approach used by most C based systems as it most closely mimics the ANSI C behaviour. The only problem with the *CALLER approach is that at some point some idiot is going to call the program from the default AG. ILE programs just weren't designed to run that way and there can be "interesting" side effects. If, as I suspect you do Joe, one strictly controls the environment and only ever uses *NEW on menu level programs and only ever calls *CALLER programs from such a menu level then the scheme you propose is a good one and can work very effectively. Personally I prefer to use named AGs and do the clean up myself as and when required. Jon

        Comment


        • #19
          TechTip: Activation Group Architecture for RPG ILE

          ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
          If you want a program that will sometimes be a top-level program and sometimes a subprogram, create it with *CALLER. Then for the cases where you want it to be the top-level program as a standalone application, call it from a *NEW wrapper program. For example, say your problem program is PGMX. Create it in *CALLER, and call it normally from your applications. Create another *NEW program called say PGMX1, and have PGMX1 call through to PGMX. When you want to call the PGMX as a standalone app, call the wrapper PGMX1 instead. If your applications are only called through menus or commands, it doesn't really matter what the programs are called.

          Comment


          • #20
            TechTip: Activation Group Architecture for RPG ILE

            ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
            want to now much on named activation group and also its related performance issues.

            Comment


            • #21
              TechTip: Activation Group Architecture for RPG ILE

              ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
              If you have a *CALLER program that would be a problem when called from the default activation group, you could have it call a *CALLER program to check its activation group and issue an exception if it is the default AG.
              Code

              Comment


              • #22
                TechTip: Activation Group Architecture for RPG ILE

                ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                The few columns I've read on this that explained best recommended just including all related programs in the same named activation group. I believe one suggestion was even as broad as the name of the company developing the software, for example one's own company for custom software. In a perspective that some of us could understand, say an ERP like BPCS, would a named activation group be better as SSA (for say interacting with other related SSA ILE products), BPCS, or INV for the programs in that module, ORD for those, etc., or even greater granularity, such as a named activation group for each source of job calls such as menu options? If the purpose of granularity is to avoid some type of conflict (open data paths?), then does it take every program to have it's own activion group (*NEW) to get the same behavior as with OPM, in other words, paths only shared with the specified override, etc.? And why would anyone want to "tear down" the activation group before the job ends? What would be the criteria involved in that? In other words, if everything is "it just depends", what does it depend on? Based on what little guidance there is, a global named activation group seemed best that would end along with the job, but that's just a wild guess backed up by maybe a couple of cogent explanations along those lines, even after all these years. rd

                Comment


                • #23
                  TechTip: Activation Group Architecture for RPG ILE

                  ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                  Ralph Daugherty wrote: > The few columns I've read on this that explained best recommended just including all related programs in the same named activation group. I believe one suggestion was even as broad as the name of the company developing the software, for example one's own company for custom software. > > In a perspective that some of us could understand, say an ERP like BPCS, would a named activation group be better as SSA (for say interacting with other related SSA ILE products), BPCS, or INV for the programs in that module, ORD for those, etc.? > > And why would anyone want to "tear down" the activation group before the job ends? What would be the criteria involved in that? > > In other words, if everything is "it just depends", what does it depend on? > > Based on what little guidance there is, a global named activation group seemed best that would end along with the job, but that's just a wild guess backed up by maybe a couple of explanations along those lines, even after all these years. > > rd It depends on whether you want the application to start fresh each time it's called, or whether it's worth the trouble to manually reinitialize the parts you need to start fresh, while being able to have other parts already initialized. It's a toss-up between simplicity/maintainability vs a possible performance benefit of not having to reopen files etc. And the way Joe described the problem, the issue was not one of reopening files across calls to the main application anyway; he was describing the difficulty of ensuring that _all_ the programs in the application got ended properly when the application itself ended. If it's your goal to have the application close everything when it ends, using *NEW *CALLER seems ideal. I wasn't particularly endorsing the *NEW *CALLER scheme of handling activation groups when I replied to the other comments. IANMOAAP (I am not much of an application programmer) so I'm not really qualified to endorse one actgrp scheme over another. That said, I do think the *NEW *CALLER scheme _is_ a good one ...

                  Comment


                  • #24
                    TechTip: Activation Group Architecture for RPG ILE

                    ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                    If you're saying what I think you're saying, Barbara, then in my example of a person signed on to an application menu such as BPCS or any other software, if all the application programs have the same named activation group of 'BPCS' as I've seen suggested before, then every program that the person causes to run with menu options and entries on the screen would stay up in memory with files open and variables retaining their values until the person signed off? Holy cow. No wonder we would have to "tear down" the activation group. To be brutally honest, this is too important to remain in the state it is. There probably is no greater impediment to using ILE functionality than this unbelievably fuzzy cloud over how to architecture activation groups. In this case, a Swiss knife isn't cutting it. rd

                    Comment


                    • #25
                      TechTip: Activation Group Architecture for RPG ILE

                      ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                      It's going to be fun to answer today because I can refer back to answers from Jon and Barbara, and thus look really smart by association . Anyway, the problem is this: subprogram SUB2 can be called from a menu or from main program MAIN1. Should it be *NEW or *CALLER? I'm going to make an assumption here: SUB2 has a display file. If the program doesn't have a subfile, then it can't really be called from a menu usefully. Well, Barbara made a great point. This is a good place for you to create a wrapper program MAIN2: make SUB2 *CALLER, and write a second program MAIN2 which passes all the parameters through to SUB2 but which specifices *NEW. MAIN2 would be called from the menu, SUB2 from other programs. However, this does create double maintenance and might not be acceptable. So in that case, I would err on the side of *NEW for SUB2. The worst that would happen would be that when MAIN1 calls SUB2, SUB2 would run in its own activation group until it ended, at which point you would return to MAIN1's activation group. You might lose some economies of restart, but since SUB2 has a display file, it is slowed down to the level of operator think time anyway. That is, it's not a program that will be called thousands of times a second, so the overhead loss of creating an activiation group is not likely to be an issue. Thus, my rule of thumb is this: if a program is called from a menu and only a menu, use *NEW. If a program is never called from a menu, use *CALLER. For program called both ways, either create wrappers for them as Barbara suggested, or use *NEW (easier with a very slight performance penalty). There is the issue of programs with USROPN display files. This is a more complex issue, but luckily it's a pretty rare one, and maybe I'll address it another day. Joe

                      Comment


                      • #26
                        TechTip: Activation Group Architecture for RPG ILE

                        ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                        Just to add to this, I've architected one system (a BPCS shop floor control system interface) with subprograms that kept *INLR off and registered in a central job file to be shut down as needed, for example, when not called for some period of time, or on demand. It was probably a little too resource intensive for the time in 1995. Traditionally I think it's been handled more like Java garbage collection, say for a called program in a loop that is left with *INLR off while being called repeatedly in a loop, but when the loop or routine is exited and it goes 'out of scope', then one last call is made to end it. This does not require any bookkeeping, plus it probably won't be needed elsewhere in the program anyway. They would be handled by service programs now, which end with the program they're bound to, and I wouldn't architect a number of programs that just sort of float around in the job retaining the value and file positions of their last use. So I guess we need to use a global activation group name and make a RCLACTGRP call in CL's initiated by menu options before exiting back to the menu to avoid *NEW *CALLER bookkeeping and inadvertant calls of *CALLER programs into the OPM activation group. And for large intensive batch jobs, it would have to be invoked periodically in the job stream after major portions of the job are completed. Even for an entirely ILE, non-OPM environment, it seems the opposite is the case in that too many *NEW programs will have intensive overhead , and not enough will have perhaps large amounts of *CALLER program resources in the job until a high level *NEW is ended (by signing off if nothing else). I don't know, I guess the question is, why would someone want programs to hang around in memory initialized and retaining most current use values when not being actively called by, say, a program loop? Isn't that an extremely expensive way of computing, similar to running out of Flash memory or something? Isn't a dataq server more appropriate? rd

                        Comment


                        • #27
                          TechTip: Activation Group Architecture for RPG ILE

                          ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                          I have to respectfully disagree here. First, you can only call programs from DFTACTGRP (the DAG) if you have programs running in the DAG. And you SHOULD only have that if you have OPM programs. And really, you want to get away from the OPM if at all possible, especially since it's pretty easy, at least in an RPG shop. I don't know how hard it is to convert from COBOL to ILE COBOL, but RPG IV to ILE RPG is pretty simple. Well, if you're a combination RPG III/IV shop then it's a little more difficult, but if you have RPG III code in production you're not really ready for ILE anyway. If, though, all of your programs are ILE, there's no reason to be running in the DAG that I can see. And in any case, I don't think it's *NEW you have a problem with, it's *CALLER. And I would submit that *CALLER is almost required for subprograms. If I segregate my application into multiple named AGs, then I can't share a subprogram across multiple AGs. I would have to make use of the nifty AG wrapper technique, and write the subprogram with *CALLER and then call it from different wrapper programs. Which would actually be silly, because at that point it would be much easier to just call the *CALLER version and make sure that nobody calls that version from OPM. And as Barbara points out, if you were really worried about it, you can include a common *INZSR check for called programs that looks to see if they're running in the DAG and if so throws an exception. Joe

                          Comment


                          • #28
                            TechTip: Activation Group Architecture for RPG ILE

                            ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                            Oh poo, Ralph. It's NOT difficult. If you wrap everything in the same activation group, it's pretty much equivalent to the old non-AG model. What stays open depends on what sets on *INLR and what doesn't. An activation group allows you to take advantage of some of the cool parts of modular programming that are afforded by leaving off *INLR (lazy initialization, caching files, and so on) without having to put in a specific methodology for shutting down those called programs. Ending the activation group in effect performs a *INLR on all programs in the activation group. Now, if you wanted to go further into the AG analysis, you can get quite complicated. AGs are "control boundaries", which have some real implications but they're subtle and require some research. If you want to understand these, read the ILE concepts manual. Here's one example: if I call a service program in a different named AG than my own, I can't access its internal variables with a pointer. This can be very important from a security standpoint. The guidelines for advanced ILE issues probably are very different for different sites. I suppose it might be nice to have some sort of cheat sheet with a bunch of checkmarks that you fill out which then tells you the best AG implementation for you, but unfortunately there is no such thing today. For now, you have to RTFM. Joe

                            Comment


                            • #29
                              TechTip: Activation Group Architecture for RPG ILE

                              ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                              "Well, if you're a combination RPG III/IV shop then it's a little more difficult, but if you have RPG III code in production you're not really ready for ILE anyway." But you may well have converted your RPG III code to RPG IV but not gone to ILE. When you have such compatibility mode programs the problems are the same as if you were still using RPG III. "And you SHOULD only have that if you have OPM programs." Don't forget the command line . "I don't know how hard it is to convert from COBOL to ILE COBOL, but RPG IV to ILE RPG is pretty simple." RPG is indeed pretty easy, but COBOL is more of a problem as you really do get into trouble if you have any non-ILE programs in the mix. You can create horrendous performance problems.

                              Comment


                              • #30
                                TechTip: Activation Group Architecture for RPG ILE

                                ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                                Jon, "ILE programs just weren't designed to run that way and there can be "interesting" side effects." Can you be more specific? What problems/issues have you seen or know about? Thanks. Chris

                                Comment

                                Working...
                                X