> > > 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
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.