Re: Externalizing I/O

Justin,

"If an existing column was changed in the PF, all the RPG programs that use it will fail with level check errors."

Part of the issue is that you shouldn't be using the PF, or rarely using it. Programs should be accessing only the fields they need through views or logical files. That way you can minimize the number of programs that need to be recompiled.

Now if you have changed a field definition, then programs that use that field will need to be reviewed and, nearly always, changed.

Using views or logical files is easiest if you are planning a new database, but it can gradually be retrofitted to an existing database. And in both cases if requires discipline to keep in place.

This approach isn't externalizing IO, and I'm honestly not sure how, or if, I'd go about externalizing IO, but I throw this into the discussion mix. (Using SQL views and pushing as much logic as possible back into the database might be something to consider.)

I wrote this article about it back in 2009:

<http://mcpressonline.com/programming/rpg/use-a-logical-file-layer-to-minimize-recompiles-from-field-additions.html>

Sam

On 10/27/2016 9:02 AM, Justin Taylor wrote:

Let me explain the issue I'm trying to solve so we're both on the same page. Traditionally, RPG references a PF directly and is tied to the record format at compile time. If an existing column was changed in the PF, all the RPG programs that use it will fail with level check errors. This is rather than having them run over bogus data. So the question is how to get the data to/from that PF without tying every RPG program to a static format.