Tech -
The big picture is that CSGI has a toolset that can automatically find and convert code. Regardless if it is better or worse than PTUS, VIAS, SEEC, ZITL. The fact is that the toolset works
Wether or not the tool works really isn't the point. What is important is to know the boundaries within which the tool works.
The whole problem of automagically 'fixing' code is rife for misunderstanding on both sides of the table. On balance the clients really don't have much of a clue what kind of code they have. And perhaps worse, they don't know (and have a heck of a time admitting) that they don't know.
So... a perfectly good tool can flop in a major way when applied to the wrong problem set.
And, please, please let's not loose sight of the fact that CSGI is only attempting to address the smallest part of the complete problem... remdiation/fixing.
- 33% planning (this includes inventory, assessment, impact, etc.)
- 17% fixing/coding <-- where CSGI fits
- 25% unit test (remember that Motorola pilot is still waiting to be tested!!)
- 25% system test.
As you (or TED?) pointed out, when the client sends 'a system' (whatever that is... believe me this is a decidedly non trivial problem) to CSGI, CSGI has to do analysis on the received components (programs, copybooks, mapsets, JCL, etc.) to determine if the client actually sent all the correct pieces.
It is a very rare client indeed that can easily find all the relevant components of "a system". Once you start looking at systems, they rather look like Klein bottles ("A one-sided topologic surface having no inside or outside"). Determining where one system ends & another one begins is a very difficult problem that the client typically expects the vendor (CSGI in this case) to resolve.
- David |
