RE: Fast400 Value to iSeries community is less than zero

> -----Original Message-----
> From: Steve Richter
>
> Changing your appl design as a workaround to IBM's pricing of interactive
> CPW is more proof of how CFINT hurts our platform.

While I don't much like the CFINT issue, I still think everyone should be
thinking client/server anyway.  If all of our systems were client/server, we
wouldn't be worried about CFINT.

I design the infrastructure once, and now I have all the benefits of
client/server design.  A single point of entry (and change!) for my business
logic, a single place for auditing and security, the ability to change my
database layout independent of my applications, and the ability to move my
database and business logic to other machines, even other platforms.
Client/server design provides unparalleled flexibility for what is really a
very small cost.  Let's review your objections:


> When you add a  layer ( in
> this case many layers ) to any software, you increase its complexity. That
> is bad.

By separating out the business logic into a called program, you've done
almost all the work necessary for a client/server design.


> Instead of your "interactive presentation layer" calling a common
> pgm to apply the dsply entry to the database, your approach is to fill a
> data struct,

And how to you send the data to your common program?  Unless you either are
passing a trivial amount of data, or you like maintaining huge parameter
lists, you pass a data structure.  No difference.


> write to a dtaq,

You call a the server API rather than calling the update API.  Not a lot of
difference there.


> hope the server job is running, wait for a
> response from the server.

This is all part of your server API.  Write it once, and forget about it.
If you've never written a client/server architecture, it's challenging, but
once you've done it, you're done.  And this is the bulk of the difference
between the two approaches.


> And then you have to code and document
> the server job.

As opposed to coding and documenting the update API.  No difference.


> Very complex. If you have a good appl design reason to do
> this, fine.
> But if it is done because of IBM's pricing of interactive CPW
> then, that is
> not fine.

So, in essence, the difference between calling an update API and using a
client/server design is that you have to write the client/server
infrastructure.

Once.

Do that, and you have all the benefits of client/server, plus the added
benefit of reducing your interactive CPW requirements.

So the only thing stopping you is the fact the work involved in designing a
solid, robust client/server API.  I know it sounds a bit daunting, but I'll
be honest with you, it's not that difficult.  I teach one in a week that's
pretty much usable for any sort of iSeries application; it's currently in
heavy use in of all things a COBOL implementation.

Joe Pluta
www.plutabrothers.com