When using embedded SQL to read data, I have the option of retrieving one row or multiple rows with one fetch. Does fetching more than one row at a time improve program performance?

–Neil

I’d like to think it does, Neil. It seems to me it should. Here are the comments of John, a reader who claims that a multiple-row fetch is appreciably faster.

I have used fetch with multiple-occurrence data structures in order to read multiple records at once and minimize the use of FETCH in the program. The execution of a FETCH is quite resource intensive and slow.

More and more in RPG applications these days, it seems we need to process data that comes from “the dark side.” Translation: from a non-i system. This data could be coming from a browser screen via an RPG CGI program, from a CSV (comma-separated values) flat file, from an XML document, or myriad other ways. One thing these dark sources often have in common is that data that should be numeric often isn’t–at least not by RPG’s definition. So common is the issue of invalid numeric data that one of the recommendations from IBM on using the XML-INTO operation code

In the last Admin Alert, I started discussing four techniques for encrypting i5/OS backups for greater protection and to satisfy auditors and government agencies. Last week, I focused on software techniques. This week, I’ll turn my attention to hardware-based encryption techniques. I’ll look at what options are available when you purchase specific hardware for your system and how those devices affect your backup strategies.

What Hath Come Before

As I explained last week, you generally have four options to encrypt backup media from your i5/OS systems.

1. Software encryption through IBM‘s Backup Recovery and Media Services (BRMS) licensed program (i5/OS