If the previous article left you curious about what an I/O Server is, this one will explain it with a little help from an expert. Keep reading to find out more!

Last time around, I mentioned that some business rules can be moved directly to the database as constraints and your input/output code can also go somewhere else: an I/O Server. One of the experts I discussed this topic with is Patrick Sheehy, of Global Modernization Champion at Tembo Technology Lab (the company behind AO Foundation). Patrick was kind enough to share the company’s view on I/O Servers, which I share in italics below.

I/O Servers

To truly isolate the application from the database, an Input/Output (I/O) Server provides an elegant abstraction layer that hides the details of the database access from the application layer. A well-planned I/O Server implementation presents a uniform and simple access methodology for all table and index interactions (from multiple applications and even languages, if needed), enforces specific access methods for various operations, offers greater data security and simplifies maintenance by isolating the access details. An I/O Server also allows for some “atomic” operations not possible through the base database access methods.

Typically, every physical file, logical file, table or index (collectively “files” from here on) should have a separate I/O Server, typically a procedure compiled as a module and then bound into a service program. Depending on the size of the database (number of files), a single service program containing all the modules may suffice, or multiple service programs may make organization easier. Because the I/O Server abstracts typical file access, all operations should provide full records where appropriate and externally relate to a single file (internally, they may reference more than one file; more on that shortly).

For situations where the environment requires functions that return partial records (for example, only name and address instead of the full customer record) or data from multiple files, a variant on I/O Servers referred to as Enterprise Servers fulfills these needs. Enterprise Server functions lean more toward utility services, whereas I/O Servers provide essential input and output processing. Although the distinction may seem subtle, maintaining the difference prevents the I/O Server concept from getting diluted and ultimately lost.

Semantically, the database owns the I/O Servers associated with its files. In a single application environment, this may seem like a grey area, but in a multiple application environment, the distinction crystallizes. A single set of I/O Servers for the files in a database can service all the native applications accessing the database, simply by binding the I/O Server service program.

For data security, the files and the service programs should share the same owning user profile and the service program creation should specify to use the owning user profile’s authority (USRPRF(*OWNER) on the CTSRVPGM command). Depending on the need for external query capability, set public authority on the files to *USE (to allow read/query access) or *NONE (to prevent access outside of the application). In either case, having public authority restricted to read access or less prevents external data manipulation from outside of the application. The application then becomes the gatekeeper to ensure only authorized users may change the data.

On behalf of Tembo Technology Lab, Patrick also generously provided an example and the respective explanation, which I will introduce here and continue explaining in the next article:

A Sample I/O Server

All I/O Servers for a given database should implement the exact same parameter set to simplify programming and maintenance. Parameter sets may vary between databases as needed to address complexities, especially for Enterprise Servers, but maintaining consistency within the suite provides substantial advantages. Much of the benefit comes from the ability to reuse patterns between server modules (i.e., cut and paste based on standard templates).

A very functional I/O Server parameter pattern consists of three elements. The following example derives from an actual IBM i application. The three parameters include:

• Action Code—This tells the I/O Server what function to perform. A typical code set may contain some or all of the following (as well as others):
  • I—Insert new record
  • U—Update record
  • D—Delete record
  • R—Read by key
  • UI—Update record or insert if not found
  • Sn—Set limit to “n” number of key fields (where “n” is an actual number less than the total number of key fields, such as “S2” for a file key with three or more fields)
  • Gn—Find greater than “n” number of key fields
  • RN—Read next (based on a partial key set by a previous Xn action)
  • RF—Read Forward from the file cursor position
  • RB—Read Backward from the cursor position
  • X—Close the file
• Record Pointer—This points to the data storage of the information for either an input or output operation, such as a record to write, storage to receive a record or space for a result set. If unnecessary for the operation (Delete, for example), set the parameter to NULL.
• Key (optional) —This provides the key fields for operations requiring a key. If unnecessary for the operation (Insert, for example), set the parameter to NULL.

NOTE: For Actions that limit the number of significant key fields, the procedure should ignore any fields provided beyond that number.”

Within the I/O Server module for a given file, best practice recommends that each action have its own discrete procedure. Within each procedure, select the most appropriate method to accomplish the task based on performance, personal understanding and other pertinent factors. For single record operations, the built-in RPG operations may still offer as good or better performance in many cases than SQL (despite a strong push from certain corners of IBM to convert everything to SQL). Likewise, read operations that may return result sets (not just a single record) necessitate using SQL. An SQL novice may also choose initially to implement the I/O Server procedures using the RPG built-in operations, then upgrade to SQL as their knowledge of the latter topic increases.”

Sounds interesting, right? Next time, I’ll explain this idea in more detail, examining the sample code kindly provided by Patrick.