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

  • #31
    TechTip: Activation Group Architecture for RPG ILE

    ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
    So the answer is RTFM? LOL rd

    Comment


    • #32
      TechTip: Activation Group Architecture for RPG ILE

      ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
      "Can you be more specific? What problems/issues have you seen or know about? Thanks." The problem is that it is almost impossible to be specific. Simple fact - ILE programs were not designed to run in the default AG. In fact the design of ILE prohibited them from running there for a long time. The rule was relaxed mainly because far too much OS level software would have had to be rewritten. Since there was no funding available for that, the decision was made to allow it. But - the majority of design accommodations made limited to those needed for IBM's own software to run. Simply put - you need to know a hell of a lot about ILE in order to safely run ILE applications in the default AG. You don't need to know very much about ILE in order to do it safely and right! It is a long time since I last encountered a problem - 'cos I learned my lesson! A lot of brain cells have died since then but one of the things I recall involves files. Can't remember the exact sequence but the really annoying one was when a file could not be used because it was not open, but any attempt to open fails because it is already open! The problems arise because ILE programs are "sticky" i.e. when you set on LR they don't really go away. They remain in the activation until the AG goes away. It is impossible to "clean up" without destroying the AG. But if they are running in the default they can only be cleaned up by ending the job. A bit drastic! Complain to IBM and they'll just say "don't do it" (Doctor doctor it hurts when I bang my head into the wall ...". Barbara can probably recall a few other gems - or else check the archives at Midrange.com or the SystemiNetwork.com - it has been discussed many times. Much of what we learned over the years was encapsulated in the article "The Seven Deadly Sins of ILE" which you can find at the IBM Magazine web site www.ibmsystemsmag.com - I'd give you the URL but the direct links to that article won't work right now for some reason - you can only reach it by searching. You might also enjoy "ILE Mythconceeptions" which you can find here - this links works: http://www.eservercomputing.com/iser...&sid=10&id=842 Jon

      Comment


      • #33
        TechTip: Activation Group Architecture for RPG ILE

        ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
        Thanks for the additional info and links, Jon. I can provide this link which has both articles: http://www.partner400.com/ArticlesEXTRA3.htm I'm pretty sure I've read both before but I get more comprehension the second time around when I have a specific question. Based on IBM defaulting to the one QILE named activation group, there doesn't appear to be any concern that ILE programs used in a job "not really going away" when they are ended will mount up. On the other hand, IBM is completely anti-5250 interactive and maybe they are just thinking in terms of small batch jobs (e.g., CGI) which won't accumulate the efforts of an interactive user. They also along with other software vendors don't appear too concerned anymore about how much memory their software requires. At this point I'll stick with the global named activation group for a software system without using RCLACTGRP at intervals within the job unless I come to find that this is an out of control memory hog ala Java. Then I guess I'll have to use RCLACTGRP periodically if necessary. Thanks again for the insight, Jon. rd

        Comment


        • #34
          TechTip: Activation Group Architecture for RPG ILE

          ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
          You probably know this Ralph, but for the benefit of others who might read this thread I think I need to clarify a couple of things in your post. "Based on IBM defaulting to the one QILE named activation group, there doesn't appear to be any concern that ILE programs used in a job "not really going away" when they are ended will mount up." This might be read by some as meaning that the QILE is actually the default activation group and can therefore be cleaned up by RCLACTGRP. Nothing could be further from the truth. QILE is merely the default Activation Group _name_ used by IBM. When referring to the default activation group we usually use the term DAG - so that at least it also has a name that sounds like a named AG!! The DAG _cannot_ be cleaned up by anything except the job ending. One other point "maybe they are just thinking in terms of small batch jobs (e.g., CGI)" is a bit misleading. For batch jobs it is certainly true - but CGI jobs are server jobs and therefore can effectively be never-ending. Performance would be horrible if a "batch" job were created fo each transactioThe job tends to be established for the connection and maintained until the connection is ended. Jon

          Comment


          • #35
            TechTip: Activation Group Architecture for RPG ILE

            ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
            "http://www.partner400.com/ArticlesEXTRA3.htm" Yup - I know about that one Ralph - it is my web site I didn't reference it because some of the links no longer work and I am waiting for the magazine to fix them. Thanks for the publicity though! Jon

            Comment


            • #36
              TechTip: Activation Group Architecture for RPG ILE

              ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
              Yes, I was talking about ILE, and that would be "IBM defaulting the ILE compile named activation group parameter to QILE". I didn't specify the default is in the ILE compile command. On the other point, you say CGI jobs can effectively be never ending and are "server jobs". I will have to see what a "server job" is. I have in the past had dataq "server" jobs that were never ending, but it was a batch job that read a dataq. I called it a server job because it was never ending. With CGI, I saw where one vendor made a big point of keeping some CGI jobs resident for obviously much better performance, and it was my understanding from IBM doc that at some place, and I don't recall if CGI specific or not, one could configure the job to stay resident, but recommended against more than five due to performance reasons on the other side, which would be resources. I've had batch jobs sitting on EOFDLY reading an input file, and again I called it a "server" job because it was designed to loop on an input, but it was a batch job. I will have to see whether server job is terminology or a different class of job in OS/400, and what the difference is. rd

              Comment


              • #37
                TechTip: Activation Group Architecture for RPG ILE

                ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                You're welcome. The links to those articles worked great. I will add that to my bookmarks. rd

                Comment


                • #38
                  TechTip: Activation Group Architecture for RPG ILE

                  ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                  "I will have to see whether server job is terminology or a different class of job in OS/400, and what the difference is." What the IBM docs are referring to is the difference between persistent CGI and non-persistent. In the case of persistent it can become a problem because there is effectively a mini-job for each user. Too many users doing lots of different things = problems. Non-persistent CGI - the norm - keeps a number of server jobs active - four by default - and they service requests as they come in. Your first request may be handled by job 1 - your second by job 3. This is why in conventional CGI programming the programmer has to maintain state between message pairs. Just like in the "good old days (not!)" of S/36 MRT jobs or CICS or ... But - and this is the important bit - the individual server jobs do not go away unless and until you shut down the HTTP server. Hope this helps. Jon

                  Comment


                  • #39
                    TechTip: Activation Group Architecture for RPG ILE

                    ** This thread discusses the article: TechTip: Activation Group Architecture for RPG ILE **
                    This is part of the problem. Sometimes the links work and other times leave you with a blank screen. I'm glad they worked for you. Jon

                    Comment

                    Working...
                    X