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

  • TechTip: Activation Group Architecture for RPG ILE

    Ralph, I'm no expert on CGI but been reading/playing a lot with it lately. On the other point, you say CGI jobs can effectively be never ending and are "server jobs". I will have to see what a CGI "server job" is. These are never ending jobs controlled by the HTTP server. Now that sounds impressive, but the HTTP server is just another never ending job in subsystem QHTTPSVR. What's the job name? The HTTP server name - whatever you called it when you defined it via HTTP://YOUR400:2001 . With CGI, I saw where one vendor made a big point of keeping some CGI jobs resident for obviously much better performance. The CGI jobs are always resident. Maybe you're talking about the programs the CGI jobs call. What happens is, when the HTTP server passes the request to your program, it swaps the current user profile from QTHMHTTP to QTHMHTP1 (or your own user profile, depending on HTTP config). And you can keep the CGI layer thin and have it communicate to your own batch server via data queues. In MVC architecture, the CGI could be just a Controller. Chris

  • #2
    TechTip: Activation Group Architecture for RPG ILE

    Yes, greatly, thanks. rd

    Comment


    • #3
      TechTip: Activation Group Architecture for RPG ILE

      Yes, the vendor may have been talking about how it handled the app programs the CGI jobs called. Thanks for the clarifications, Chris. rd

      Comment


      • #4
        TechTip: Activation Group Architecture for RPG ILE

        "But you may well have converted your RPG III code to RPG IV but not gone to ILE." I'm not sure why you would have done this. Once you're at RPG IV, there's no gain by staying in non-ILE, with the possible exception of not having to fix a few things that you'd have to fix eventually (such as override scope and whatnot), and all manner of good things to be had, such as procedures. "Don't forget the command line ." While I have a little bit of a problem with an application design that has people calling things from the command line, there's still a reasonable growth path. Start out with every RPG program having a display file being set as ACTGRP(*NEW), all other RPG programs being ACTGRP(*CALLER). Move things from *NEW to *CALLER if it becomes evident they are never called from a menu (or a command line). However, further thought tells me that this won't fare as well in batch. In a standard configuration of i5/OS, all batch jobs use QSYS/QCMD to invoke their commands, and since QSYS/QCMD is OPM, that means any program called this way using *CALLER would end up in the DAG, a potentially bad thing. It's less disastrous in theory, since the entire thing goes away when the job ends, but still not a good practice. I wonder if there's an ILE equivalent to QCMD? Joe

        Comment


        • #5
          TechTip: Activation Group Architecture for RPG ILE

          Typo... QTMHHTTP and QTMHHTP1 are the HTTP user profiles (normal GET and CGI request respectively). I'll also add that the HTTP server stuffs the HTTP header values (CONTENT_LENGTH, REQUEST_METHOD, etc) into environment variables for which ever CGI job gets handed off the request and if the form method is POST, the body of request (form name/value pairs or whatever was POSTed, maybe via a Java HttpURLConnection output stream) is available as "standard input" to the CGI program. The CGI program then writes "stardard output" back to the HTTP server. Chris

          Comment


          • #6
            TechTip: Activation Group Architecture for RPG ILE

            I was cranking out a trigger program when I read this article on AGs. The resulting discussion got me to thinking about the method I use for implementing database triggers and wondering if I need to reconsider the implementation. The method I use implements the trigger using two RPG IV programs, both of which specify *CALLER for the AG. The first program is the actual trigger program attached to the database file but it is only a "stub" whose sole function is to receive the two parameters ( trigger buffer & length) and using those parameters, call a second program which is responsible for actually processing the trigger event. I use *CALLER on both programs since most everything I've read indicates that the trigger should perform its processing in the same AG as the program that caused the trigger to fire. Since I have no control over what type of program or user action may cause the trigger to fire should I be using a different AG than *CALLER? Am I confused in thinking that the trigger processing program should be in the same AG as the program that caused it to fire? TIA, Brian

            Comment


            • #7
              TechTip: Activation Group Architecture for RPG ILE

              Ralph Daugherty wrote: > ... Then I guess I'll have to use RCLACTGRP periodically if necessary. > ... Ralph, you probably don't mean RCLACTGRP *ELIGIBLE, but if you do, eek, never ever use that. It's much too blunt a tool to be safe. If you mean RCLACTGRP someNamedActrp, then it can be ok, but you have to be very careful. One problem you can have is when you reclaim an activation group for a service program. Program AG1 in actgrp AG1 calls service program AG2 in actgrp AG2: 6 > call ag1 DSPLY hi from AG1 DSPLY hi from AG2 6 > rclactgrp ag2 Activation group AG2 deleted. 6 > call ag1 DSPLY hi from AG1 Tried to refer to all or part of an object that no longer exists. Me, I have sworn off using any RCLACTGRP. I have had a couple of nightmare debugging sessions where I was trying to solve a problem that would not have existed if I had not used RCLACTGRP. Now, I sign off and back on, no matter how much I really really do not want to sign off. And even with a named activation group, I would never advocate using RCLACTGRP from the command line. If I were going to use it, it would only be from within an application, if I was sure that the activation group was not being used by anything else. Here's an excerpt from the extended help for RCLACTGRP: An activation group should only be reclaimed if it will never be needed again within the same job. Otherwise, errors and unpredictable results may occur if other programs later attempt to access the resources that were reclaimed. Therefore, this command should normally only be used in the controlling program of an application. Specifying ACTGRP(*ELIGIBLE) requires full knowledge of the job environment. Otherwise, unpredicable results can occur.

              Comment


              • #8
                TechTip: Activation Group Architecture for RPG ILE

                Well, thanks for that enlightenment! I am sure you just saved me some similar time in debugging hell. I was responding to Jon's references to it, and the tearing down of the activation group, and how the objects don't really go away. I also had just read his link of the Seven Deadly Sins, and yes, RCLACTGRP *ELIGIBLE is one of them. It's a development aid, it's labelled as such, restricted from command line prompt, I don't see how you can be much clearer about it, although I'd never heard of it, which I think was supposed to be the point. In lieu of a suggestion of how activation groups would be architected in the typical environment most of us have, an ERP or two or three with custom programming, much of which is not compiled using named activation goup (in other words, most a mix of RPG/400 and RPG IV with default activation group *YES), I went with the best explained suggestion I had seen, a global named activation group, such as all custom programs compiled with DOW500INC named activation group. However, much of everything else would still in OPM land. Because I still have no idea if everything just keeps accumulating in the activation group once ended with *INLR, and this would seem to be a bad thing, and Jon talked of tearing it down, I postulated that perhaps at the end of each menu option CL controlling program would be this RCLACTGRP to clean up to keep everything ever done by BUSYUSER to accumulate until sign off. On the other hand, I noted that IBM defaulted ILE compiles to one named activation group, QILE, with no indication that they shared my concerns. So I ended up saying I would forego RCLACTGRP for now until it somehow became known that doing that is as bad a memory hog as Java. Now I don't think I even have that option because surely there will be sync problems with calls between programs in different activation groups. Thank you for pointing that out. So we are back to the extremes of *NEW for everything which was of course way too much overhead, to one name QILE or yourcompanynamehere which could also be just as way too much overhead, as if for example, every OPM program we ran while signed on didn't really go away when we exited. I think we all understand that's bad. It's no better because it's ILE in an activation group. Convenient? Maybe, and maybe OS/400 one level architecture doesn't care about such things. But we need to know to have a clue about what is a reasonable approach for a normal ERP environment, not special convenient or cool environments. So I am definitely scratching RCLACTGRP as an option. The other option was more granularity, but I don't know, even starting up an activation group everytime someone takes a menu option is quite a bit much. What will work as well as OPM? That's all. Thanks for the heads up, Barbara. rd

                Comment


                • #9
                  TechTip: Activation Group Architecture for RPG ILE

                  I hate this terminology. Should read: However, much of everything else would still be in OPM land. Because I still have no idea if everything^H^H^H *THE NAMED ACTIVATION GROUP ILE PROGRAMS* just keep accumulating in the *NAMED* activation group once ended with *INLR,

                  Comment


                  • #10
                    TechTip: Activation Group Architecture for RPG ILE

                    "So I am definitely scratching RCLACTGRP as an option. The other option was more granularity, but I don't know, even starting up an activation group everytime someone takes a menu option is quite a bit much." No, it's not. It's an operation measured in milliseconds (think of a single disk I/O), which added to user think time is negligible. The problem with creating and destroying activation groups occurs when you are doing hundreds or thousands of them per transaction, as you would in an all *NEW environment. No, lacking an overriding reason to do otherwise, I see no compelling argument to avoid the *NEW/*CALLER architecture, especially as your systems get more modular with lots of small, oft-called subprograms. Joe

                    Comment


                    • #11
                      TechTip: Activation Group Architecture for RPG ILE

                      Ok, if that's the gist of creating an activation group, then your contention would be the best way to go, Joe. The everything is either *NEW or widely scoped named activation groups such as QILE are too extreme. But I will have to make note of Barbara's suggestion on how to keep *CALLER from being called into the DAG. rd

                      Comment


                      • #12
                        TechTip: Activation Group Architecture for RPG ILE

                        Absolutely. I intend to do the same; it seems like a reasonable /COPY to put into any program that might run into DAG difficulties. Joe

                        Comment


                        • #13
                          TechTip: Activation Group Architecture for RPG ILE

                          Ralph Daugherty wrote: > Now I don't think I even have that option because surely there will > be sync problems with calls between programs in different activation > groups. > I haven't seem this problem with program calls, only with _service_program_ calls. > So we are back to the extremes of *NEW for everything which was of > course way too much overhead ... I don't think *NEW adds much overhead to an application. And if you were going to do RCLACTGRP anyway, *NEW just provides a safe way of doing the RCLACTGRP.

                          Comment


                          • #14
                            TechTip: Activation Group Architecture for RPG ILE

                            Yeah, I agree that makes the most sense. Thanks for the help on all my questions. Much appreciated, Barbara. rd

                            Comment


                            • #15
                              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 ILE0

                              Comment

                              Working...
                              X