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
** 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