As promised, let’s go over some I/O Server sample code. Again, with the precious help of Patrick Sheehy of Adsero Optima.

In the previous TechTip, I introduced the concept of I/O Server. Now let’s explore a sample I/O Server so that you can better grasp the concept, starting with its header, available here.

As you can see, everything has comments and is carefully organized, as a modern RPG piece of code should be. Note that there’s a function for each operation. Before discussing the sample code, here’s an important note from Patrick Sheehy:

“Not all actions may apply to all files. For a given file (particularly logical files or indices), certain functions may be omitted from the I/O Server (although a generic “not supported” procedure may make the programmer’s life easier for the excluded operations). Likewise, the I/O Server may allow an “atomic” operation (from the user perspective) not possible using the base database operations. For example, when modernizing (and normalizing) a typical IBM i database, the effort often splits large monolithic files into smaller tables with discrete data sets. A new joined logical typically gets created to represent the “old” perspective of the original fie.

If a feature within the application provides update capability for the original file perspective, this could require an extensive rewrite, since DB2 for i does not allow update via a joined logical file. However, an I/O Server for the joined logical file easily provides the functionality available for the original file. Hidden in the “guts” of the Insert and Update procedures for the joined logical, the code can split the input record and write the fields to the multiple new, normalized tables. To the application programmer (and end user), the function remains virtually the same, with minimal recoding.”

You can find the code for the PUT and UPD functions here. Notice the error-handling for each set of operations, provided via MONITOR/ENDMON groups. It’s another good example of the “damage control” particularly important when writing data to the database. Finally, Patrick added a brief discussion about activation groups from the I/O Server perspective, which is something some programmers might not be familiar with:

“I/O Servers require some understanding and consideration of how activation groups impact database access. An activation group provides an isolated pool for memory and other resources required to run a program. A job can own many activation groups and activation groups can nest while maintaining their isolation from each other.

Activation groups come in three basic “flavors”; the Default Activation Group (DAG), system managed activation groups, and named activation groups. A fourth option uses the caller’s activation group, which while useful, still requires basic understanding of the first three definitions.

The DAG supports the OPM and does not support ILE features like procedures, service programs, and binding directories. Since this series of articles [RPG Academy] presume moving to modern RPG (i.e., ILE), avoid having a program run in the DAG by either compiling the source files to *MODULE objects using the CRTRPGMOD command before creating the actual program using CRTPGM, or specify DFTACTGRP(*NO) on the CRTBNDRPG command.

A system managed activation group (specified by the ACTGRP(*NEW) parameter on the CRTPGM command) provides the ILE equivalent of the DAG. The system creates a new activation group whenever the program executes and cleans up the resource pool when the program terminates. For programs called frequently (especially within the same job), this results in significant overhead as the operating system creates and reclaims the activation group on each invocation. Therefore, use ACTGRP(*NEW) sparingly.

A named activation group (ACTGRP(name)) may require more explicit work by the application, but provides operational and performance advantages. The first time the program executes, the system creates the activation group. The activation group then remains in existence within the job until the application explicitly reclaims the resources using the RCLACTGRP command, or the job itself ends. Until either of those occurs, subsequent calls to the program within the job use the already running activation group, significantly reducing program initiation time.

Service programs can also use a named activation group, but use this option very sparingly and with significant care. While this may offer a level of performance advantage for a very commonly used procedure in a service program (for example, if many different programs running in many different jobs all call a certain procedure often, the named activation group for the service program allows all the callers to share the same activation group), it carries significant risk. Any global or static variables used within the service program become accessible to every caller, effectively rendering the service program “stateless” with regard to any particular job and potentially introducing both unexpected results and security holes.

The last option, to use the caller’s activation group (ACTGRP (*CALLER)), runs the program or service program within the activation group of the calling program or procedure. This removes the overhead of creating a new activation group while at the same time isolating the invocation to the current program stack (avoiding the global variable issue noted above). This works best for procedures invoked by other procedures such as service programs. Likewise, avoid running programs such as the entry point for an application using the caller’s activation group. Such practice could result in an ILE program running under the DAG (if executed from the command line), which both defeats the isolation advantage of activation groups and clutters the resource pool used by the operating system. For most application entry points, a named activation group provides the greatest advantage.

Regarding nested activation groups, if a new activation group comes into existence (for example, through an external program call) during the lifespan of another activation group, activities within the nested activation group do not impact the activities in the original activation group. If the original activation group contains an open commit cycle and the new activation group performs an operation within its own commit cycle (including the actual commit), the latter operation has no effect on the original activation group’s commit cycle. The original commit cycle remains open until a commit or rollback operation occurs under the auspices of the original activation group.”

You can find the complete source of the I/O Server program here.

In summary, there are times when it’s not feasible at all or would require a massive amount of effort to move a certain business rule to the database. Using referential integrity constraints will certainly take you a long way, and using I/O Servers to free your program’s code of the database operations part is useful, but sometimes it is simply not enough. Once you’ve achieved this level of modernization, you’re ready to move on to the next stage: taking advantage of DB2’s advanced functionalities.

I’d like to end this topic with a very, very big “thanks!” to Patrick Sheehy and the rest of the fantastic team at Adsero Optima, without whom these last few articles would have been impossible.