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.
Rafael Victória-Pereira has more than 20 years of IBM i experience as a programmer, analyst, and manager. Over that period, he has been an active voice in the IBM i community, encouraging and helping programmers transition to ILE and free-format RPG. Rafael has written more than 100 technical articles about topics ranging from interfaces (the topic for his first book, Flexible Input, Dazzling Output with IBM i) to modern RPG and SQL in his popular RPG Academy and SQL 101 series on mcpressonline.com and in his books Evolve Your RPG Coding and SQL for IBM i: A Database Modernization Guide. Rafael writes in an easy-to-read, practical style that is highly popular with his audience of IBM technology professionals.
Rafael is the Deputy IT Director - Infrastructures and Services at the Luis Simões Group in Portugal. His areas of expertise include programming in the IBM i native languages (RPG, CL, and DB2 SQL) and in "modern" programming languages, such as Java, C#, and Python, as well as project management and consultancy.
MC Press books written by Rafael Victória-Pereira available now on the MC Press Bookstore.
 |
||
 |
|
Evolve Your RPG Coding: Move from OPM to ILE...and Beyond Transition to modern RPG programming with this step-by-step guide through ILE and free-format RPG, SQL, and modernization techniques. List Price $79.95 Now On Sale
|
|
||
 |
|
Flexible Input, Dazzling Output with IBM i Uncover easier, more flexible ways to get data into your system, plus some methods for exporting and presenting the vital business data it contains. List Price $79.95
Now On Sale
|
|
||
 |
|
SQL for IBM i: A Database Modernization Guide Learn how to use SQL’s capabilities to modernize and enhance your IBM i database. List Price $79.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online