Re: Avoid Level checks was ( Generic RPG File Handler for File I/O using OA

Hi Michael

Yes, that is correct.  Added fields will not be seen in preexisting LFs.  That is the precise point of the method.

You need to create a new LF to now reference the added fields.
Then you need to review all programs that need to reference the added filed.

Looks to me that in your example, the change to add the field was not properly analysed in the first instance.

However even if you used only SQL how is it possible for the preexisting SQL to reference your added field? You still need to change the SQL.

Yes there are no shortcuts to managing database and systems.  But in the end I was almost paralysed with fear and despair when  a database change was needed.

The method I propose helps greatly isolate the change to ONLY the programs that must refer to the new field, you find those programs and change them knowing that other unrelated programs need not even be recompiled.

PS .  I am a total advocate of SQL, but only after IBM implemented full-outer-join. IMO it is a shame that new hires are not properly educated, be it in educational facilities or inhouse, on the power of the SYSi.

Frank


On 06/07/2022 9:25 am, Michael Quigley wrote:

We tried that. It can be (not necessarily is, but*can* be) a recipe for a mess.

We had a logical file used in many programs. I don't recall whether we just made a field mandatory or it was added to the physical file. Regardless, the programs using the pre-existing logical never considered this now critical field. After a couple years, we had to dig into the cause of the problems we had seen arise in the system where the physical file was central. We finally discovered that several programs were ignoring a field not on the logical and leaving us with a bunch of bad data.

Using the technique described can be functional, but just like using LFs referencing the PF file format, you've got to pay attention and do research and modify other programs to keep all your data clean. I've found that even when IO may seem to be so ideally suited to native file access. The more productive route (in the long view) is to use SQL.

Note that in the example above, we would still have had to modify programs to deal with the now critical field. There really aren't any shortcuts to managing the database and system, but overall I have found SQL to be far more efficient. Plus new hires brought in to work on IBM i for the first time, are more comfortable and productive when SQL is used.

Michael Quigley
Computer Services
The Way international