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

Hi Michael

It is more than not recompiling everything.  If the db change changed the fields size you must review the logic of any affected program.
What I propose means you need only review the logic of  the programs that actually use the added (changed) fields, whoopee!.

Frank

On 07/07/2022 10:29 am, Michael Quigley wrote:

So what you gain by the method is not recompiling everything. I'm not sure it's worth it for that--but if it works for you, hooray!

Michael Quigley
Computer Services
The Way international
www.TheWay.org

-----Original Message-----
message: 2
date: Wed, 6 Jul 2022 16:07:50 +1000
from: Frank Kolmann <Frank.Kolmann@xxxxxxxxx>
subject: 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