Practical RPG: Processing Stream Files, Part 2
In part 1, we processed a directory. In part 2, we process one file in that directory.
Written by Joe Pluta
Stream files are not database files.
While that statement is obvious to programmers, it's not always clear to the greater community. The end users, the folks whose jobs we are supposed to be supporting, use various forms of stream files to store their data, and they don't understand why we can't for example just "use this spreadsheet" as part of our application. And while that's an interesting philosophical discussion, as programmers we sometimes have to simply get things done, and that in turn means taking whatever data the user sent us. I've spent a lot of time over the years importing data primarily from Excel—and more specifically from comma-delimited files. Two techniques exist: CPYFRMIMPF and parsing the data in RPG. CPYFRMIMPF is a completely different animal that perhaps can be covered another day. Today, I just want to talk about parsing a stream file.
Practical RPG: Processing Stream Files, Part 1
We've all had to process a folder full of files from a PC or a UNIX machine; today we learn how to do it programmatically.
Written by Joe Pluta
If you're like me, you strongly believe that the IBM i is the best choice as your business integration hub. It talks just about any language, can handle any kind of data, and has unparalleled reliability. In fact, it's a prefect interpreter between other systems in your infrastructure. One of the things that IBM has focused on over the years is a fantastic capability to support stream files. Whether it's the UNIX-like capabilities of QShell, the stream file capabilities of commands like CPYFRMIMPF, or the ability to write C programs to directly access the files, there isn't a stream file requirement that can't be met by the IBM i.
Practical SQL: GET DIAGNOSTICS
SQL can be something of a black box, but the GET DIAGNOSTICS statement allows you to peek under the hood.
Written by Joe Pluta
SQL is especially powerful at set-based database operations: those operations that affect multiple rows at once. One of the coolest things a programmer can learn is how to write a single SQL statement that updates a whole set of records, all without the requirement of any sort of looping mechanism whatsoever. But usually not long after comes the realization that at some point you have to know how many records you updated. In the beginning, that was only available through the use of the little-known and obscurely named SQL result variables. This article shows you how that goes away with the GET DIAGNOSTICS statement.
