Re: Re: Re: Webfacing source changes ?

> > > You successfully webfaced 5000+ screens.
> >
> > Yes, and with earlier versions of the WF tool.  The conversion got
> > better and better with each successive version.
>
> Just for a bit of equal opportunity advertising here: converting code
> generated by a code generator is the worst possible test scenario.

By this, Joe means that RPG/DDS created by Synon is all the same.  Little
variation.  He's right, but is deflecting my original point which was that
if someone is looking at WF now, it is undoubtedly better than it was when I
tested it.   Bye the bye, I also tested WF against several hundred typical
hand-coded RPG/DDS programs, and the same level of improvement was noted in
them as well.

There are two points under consideration:
1) The act of converting.  This got better with each release of
     WDSCi partly because IBM learnt about larger projects,
     but mostly because the lab is under orders to (imagine this)
     improve with each release.
2) The act of viewing/running the end result.  This got better
     with each release because the lab made the resultant
     HTML data stream smaller and smaller, and also
     improved the traffic-handling servlets as well as the
     number of beans used.

> In fact, the only thing you're saying is that WebFacing works with Synon
> generated code, but not well enough for you to use in production (for
> whatever reason).

Technically, this statement is fairly accurate (when did I ever fit 'only
saying'?), but we aren't using PSC/400 for the exact same reasons we aren't
using WebFacing.  (And we looked at it too.)

Let me be clear: We are a software vendor and live in a different universe
from the end-user community.  We use Synon to generate our code, which adds
a level of complexity above hand-coding.  When we make a change, Synon
deletes the RPG and DDS and re-creates the source from the Synon model
repository.  That means that we can't use out of the box tools (WDSCi Code
Designer) to make customisations on the green screen side that get carried
into the GUI side by the conversion process.  Each and every conversion is
the like first time.  This is a huge headache.

Change management is a significant part of our life here.  Having to track
related IFS objects created by  a conversion tool is a pain.  Especially
when you have to mesh that source tracking with tracking the QSYS objects
created by Synon.  Some of this could be alleviated by a more sophisticated
change management package, but then there's the deployment.  We need to
package the appropriate IFS objects with the appropriate QSYS objects in
'dot release', 'patch' and 'full install' scenarios.  Then design a new
install process that handles the IFS and QSYS objects, with appropriate
'back this patch out' support.  Et cetera.

WAS/Tomcat experience ranges from expert to non-existent in our current and
potential customers.  Sizing an iSeries to run the WAS workload on top of
the rest of the workload isn't cheap.  Tomcat is free of purchase costs, but
it and WAS require ongoing know-how to install, support and upgrade.  This
is true even if you intend to run your servlet engine on PC hardware (which
is another level of complexity to contend with for some sites.)  Who is
responsible for teaching our customers the right stuff?  And who's phone
will ring first when they can't access their software because 'something' is
awry?

Readers:  Please evaluate all vendor software against YOUR code base.  Run a
typical change management cycle and see how easy/hard it is to deploy
changes to the GUI end-user.  Just because we don't use WF or PSC/400
doesn't make them the wrong tools for YOU.  Just because we use newlook
doesn't mean that it is the right tool for YOU.  Everywhere are trade-offs;
there is no glass slipper.  If anybody wants a further conversation on this,
PLEASE include this paragraph when you snip.

Private email is certainly welcome.  Take out the trash to email me:
bucktrash at commsofttrash dot net
  --buck