Re: IBM i upgrades / Dev Tools

I am curious how this conversation pans out.

The only sure thing in these conversations seems to be that after a
suitable amount of posturing, the do-it-yer-self-er who is creating the
application does what suits themselves best.

Deployments were **painful** and missed deadlines were many
because of complexity.

The "complexity" and "risk", perhaps has more to do with having multiple
language environments, multiple skill sets. The design and architecture are
really very clean.

For example, and going back to Nathan's example, what if some INSERTs
should send a confirmation email and others shouldn't;

Those types of requirements still exist regardless of whether the logic is
performed in front of a trigger, or behind it. The real question is how
would a procedure which is running "behind a trigger" determine the
"should" and "shouldn't".

The answer (generally) is for the "caller" to set a flag which modifies the
behavior of the procedure. A flag may be set in the record-buffer, an
environment variable, or essentially any means of inter-process
communication.

A trigger "mediator" may also set a number of environment variables and
parameters which are common, such as whether the caller is 5250, or not,
the user ID, Job attributes, etc.

At the end I guess what I am getting at, Nathan, is that there is more than

one way to skin a cat.

I don't think the old "skin a cat" metaphor applies very well to
architectural issues like this. The long-term ramifications are too
significant. Do you plan for the future, or not?