Commonly Asked Questions About ILE Activation Groups

[David Abramowitz]

Jon Paris wrote: Do you mean the only place you have been _allowed_ to use it? You could convert your entire system to RPG IV tomorrow, compile with DFTACTGRP(*YES) and you probably wouldn't notice the difference. Considering the power of the CVTRPGSRC command (free) and other similar tools (not free) there really is no excuse (IMO) not to go to RPG IV. I do remember attending a seminar a few years back where the opening line was "You do not have to use ILE features in order to use RPG IV." You might remember that too!! Dave

[J.Pluta]

Commonly Asked Questions About ILE Activation Groups

This is an important issue. You can use nearly all of the capabilities of RPG IV wihtout going to ILE. In fact, the only thing you can't use is procedures. You CAN use prototyped calls to external programs and APIs, you just can't bind to service programs or use internal procedures. What you do get is incredible. Long field names, new field types, a plethora of powerful BIFs, the ability to get rid of indicators, easier interface to APIs, the list goes on and on. Joe

[J.Pluta]

Commonly Asked Questions About ILE Activation Groups

Since my advocacy of *NEW/*CALLER is well known, I wanted to stay out of this and let everybody weigh in. But let me respond now: First, I think Jon's point is that ACTGRP(*CALLER) called from OPM programs will eventually bite you. It will work fine for a while, but eventually it will break, and when it does you will be in for a world of hurt. I absolutely concur. Don't do that, it's a time bomb. On the other hand, I don't agree quite so fully with Susan's assessment of *NEW/*CALLER, particularly her concern that shops won't get it right. Yes there is a possibility of programming it wrong, but there's a possibility of programming anything wrong. If you really thoguth that was an issue, you could program all of your *CALLER modules to check for the activation group via the QWVRCSTK API. Because while the idea of a single named activation group with RCLACTGRP as necessary works for some people, it doesn't work for me. That's because I have to count on some external program to be sure that my stuff is initialized correctly, whereas with *NEW/*CALLER I know that when my *NEW program ends, the next time it starts it starts with a clean slate. If I'm counting on that and the calling program "forgets" to perform a RCLACTGRP, then I may get errors that can be every bit as painful as those caused by running in the default activation group (and sometimes very difficult to diagnose, because they're data specific and depend on the LAST time the program ran). Joe

[JonFParis]

Commonly Asked Questions About ILE Activation Groups

" You might remember that too!!" I'm assuming that was aimed at the OP David and not me - actually there's a pretty good chance that it was me that said it! This mixed-up notion that RPG IV must use ILE is the sad result of IBM having chosen a really silly name for the compiler i.e. ILE RPG. And yes I was part of the group that made that decision and yes I didn't fight it hard enough!!

[gantner]

Commonly Asked Questions About ILE Activation Groups

I certainly agree with you that if choosing between *CALLER and *NEW as a default, I much prefer *NEW. Personally, however, I wouldn't choose either of those as a default. I don't see a compelling reason not to use the current (as of V5R3) default of QILE. In one of my earlier posts, I explained my reasons for preferring a named AG over *NEW, so I won't repeat myself here. IBM changed the default on CRTPGM in V5R3. They very, very rarely change shipped defaults. I have to believe it's because they saw enough shops having problems with *NEW as the default as it was prior to V5R3. One thing I'd like to point out related to your post - the programmer only needs to make sure that variables are properly initialized with *CALLER IF the called program is NOT setting on LR. Even with *CALLER, LR closes files and reinitializes static variables in the main procedure as it did before. The exceptions to this are variables specifically marked STATIC in subprocedures. I suspect you know this and these are the ones you are concerned about initializing, but I wanted to make sure other readers don't get the wrong idea about initialization and *CALLER. All that said - if *NEW in thoughtful combination with *CALLER is working for you and your shop, keep up the good work. Staying out of the DAG is the primary goal and it sounds like you've found a workable solution for your applications.

[David Abramowitz]

Commonly Asked Questions About ILE Activation Groups

I have always enjoyed the seminars that you and Susan conduct. The quote stuck in my mind, and I use it wherever appropriate. Dave

[Guest.Visitor]

Commonly Asked Questions About ILE Activation Groups

"You do not have to use ILE features in order to use RPG IV." It is amazing how certain phrases inspire us as words of wisdom, while to the statesman it would be just another statement. In 2000, I was locked in a battle of opinions with my I.T. Manager who was of the view that RPGIV meant dealing with ILE and nobody had ILE expertice. My repeated answer was exactly what you quoted from Paris. Well, finally she was replaced by a new manager who gave me a free ticket with the condition, "If anything goes wrong, it will be your ass that will be grass". A couple of years later, and I had left the company by then, everything was converted to ILE and /free!!!

[jeffolen4]

Commonly Asked Questions About ILE Activation Groups

Wasn't it Bob Cozzi who first called the activation groups aggravation groups? I would still agree with that. ;-) Jeff

[jacobus]

Commonly Asked Questions About ILE Activation Groups

[jacobus]

Commonly Asked Questions About ILE Activation Groups

I didn't know that *CALLER and *inLR *on causes the static variables in the main procedure (i.e. the global variables), i only thought about the files being closed when *inLR is *on, but i didn't really give it much thought. Because, to keep it simple, i don't use *inLR to control resource mgt, only AG's. So in case of *NEW i set *inLR *on just for compatibility (but in fact it has no use because everything is cleanup up already), and in case of *CALLER i never set *inLR on because it gets complicated and unnecessery tot take into account the situation that only the files must be closed and global vars initialized, but nothing else. It's all or nothing. In most cases, u want to use *CALLER to keep files open, and to keep the globals. If further control is necessery one can explicitly reinitialize vars and use %open and open (with usropn etc). In my opinion, this results in more clear code, without too many side effects and "insider" information. gr. jacobus

[jrbromm]

Commonly Asked Questions About ILE Activation Groups

The programs not seeming to be fixed after we change them probably fall into the first category where it was called from a program that had not yet set on LR, although wouldn't ending those calling programs with LR clear that pointer so subsequent calls should get the correct program without doing RCLRSC? The second scenario wouldn't exist in our environment because of my second issue, that of the bleeding edge. "Allowed" would be a better term than "able". That comment was both tongue-in-cheek and a dig - "If it ain't broke, don't fix it." There are times that I think if IBM's Datamaster was still in production, they'd still have me coding in Basic. I have run our programs (about 1500 of them) through a converter and compiled them, taking only a few hours, and the only problems I've had were due to some coding style issues. We had some flags *like defined to *IN90 which were being used for 'Y'/'N' values rather than '0'/'1', and we had some loops based on *ON = *OFF using a LEAVE statement to exit the loop. Both were OK in the OPM programs but would not compile after converting. Some minor code changes, and those programs compiled. That was done two years ago but none of it is being used yet. Meanwhile we still keep maintaining our old programs.

[MCWebsite.Staff]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
** This thread discusses the Content article: Commonly Asked Questions About ILE Activation Groups **
0

[Guest.Visitor]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
Activation groups always seemed to be a solution in need of a problem. Long ago when I studied Linux I learned an interactive command that created an independent session immediately beneath the current session. This environment was completely independent of the initial level. Unfortunately, I have been away from Linux for years and I don't remember it ... the command is a pretty basic one, as I recall. Once I learned the Linux command, I developed the impression that activation groups were a complicated emulation of this simple Linux feature. When programming on the AS/400, I gave up on activation groups because I had problems getting common program features to communicate with other common program features. Also, and most importantly, I could not see any obvious value. Yes, I read explanations such as yours that advertised great improvement being added by keeping program levels separate. On a practical level, it actually seemed to add complexity without adding any value ... at least with regards to most programming situations. All articles about activation groups seem to take the position your programs will be 'better' if you use them. The revelation is always followed by a complicated and technical analysis that rarely makes the value seem obvious or practical. Te overall impression is that IBM is trying to sell computers and keep programmers busy by creating a false impression of some kind of technical snobbery and a vague sense of superiority for those who use this obscure feature. So, to come to the point, Please provide a list of moderate length that illustrates common program situations where adding programming to support activation groups will demonstratively improve the use of the program ... and I don't mean by using a stopwatch to measure program runtime. Prove me wrong.

[jgolds2]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
One could, and some have, raised the same objections about ILE in general. It seems to boil down to the ability to run C modules.

[JonFParis]

Commonly Asked Questions About ILE Activation Groups

** This thread discusses the article: Commonly Asked Questions About ILE Activation Groups **
Since I was involved in the design and introduction of ILE from the beginning, perhaps you'll allow me to at least partly address this. With the massive increases in power/$ ratio over the years it is easy to forget that back in the CISC hardware days, program to program calls were an expensive business. There was no way to efficiently perform high volumes of calls. The need to run C programs on the box in order to attract new tools and applications etc. made it imperative to address the call speed issue. We were also wrestling with a number of other issues relating to isolating and protecting resources. A new program model was needed to achieve this. It was simply not possible/practical to get what was needed out of the old model. ILE was born out of these needs. Subsequently the decision was made to introduce a new version of RPG that embraced this model and RPG IV was born. This too was vital since more and more RPG programmers were becoming familiar with languages like C and Pascal and wanted the ability to have fast calls to functions written in RPG. Similarly ILE COBOL and CL came along for the ride. Had RPG not moved to this new world, RPGers would have screamed long and loud and would probably still be screaming today some 12+ years later. Unlike COBOL, RPG can very effectively live in both worlds. If you don't want the new features such as subprocedures and the ability to bind to procedures in other languages (C, COBOL, Java) then you don't need to use them. If you choose to live in this world you run in compatibility mode i.e. DFTACTGRP(*YES) and Activation Groups can be ignored. If you want to exploit the new features then you need to be aware of ILE concepts such as Activation Groups and scoping. You can make it as simple or as complicated as you like. If you don't want or need the application isolation capabilities provided by AGs don't use them. Simply run all of your ILE code in QILE and leave it at that. Hope this provides a little perspective.