To: TEDennis who wrote (1466 ) 12/4/1997 11:23:00 AM From: TEDennis Respond to
My responses to Ron Bishop's email ...I thought I made it clear that I understood that CSGI's product was designed as an inhouse tool. My comment was intended to point out that it would be a handicap when the client wants to do the conversion activities themselves. Ron Bishop made the comment himself at the stockholders meeting that their main competitors were clients desiring to make the changes themselves. Other vendors license their tool to the end user (PTUS, SEEC, others). Not licensing to end users is a limiting factor in the amount of revenue that could be generated. According to CSGI, their plan doesn't count on this revenue. However, my opinion is that leaving ANY revenue on the table is a sin. This is just my impression. Not necessarily a problem. Code conversion is one thing. Understanding the interrationships between applications, the operating system, code preprocessors, user exits, file structures, and various other site dependent considerations is another. CSGI's tool will do a fine job of converting source code that is sent to them. I think they'll encounter surprises with some of the preprocessors until they gain a LOT of experience with them. The primary mainframe vendors have been attacking environmental problems for years and they still run into surprises. I doubt that an off-mainframe solution will have been able to solve them. If an application environment is 'vanilla', CSGI's conversion should be OK. Indeed, this was explained incorrectly to me. I revisited the notes that I took during the demo, and it says that 30% of the date field candidates must be verified by the user. That percentage was around what I've seen produced by other off-mainframe tools (actually, a little low but I didn't say that in my prior writeups because I didn't want to rain on their parade). There are certain environmental situations that will vary the percentage significantly. One of those is multi-csect load modules and the logic flow through those multiple programs. To my knowledge, there are no off-mainframe tools that properly deal with that situation because to do so requires access to the executable load modules. I still maintain that advertising a 'fully automated Y2K solution' is stretching the truth beyond acceptable limits. If the phrase were changed to 'fully automated Y2K code conversion', then I wouldn't so readily attack it. Still, though, 'fully automated' anything is unlikely. It still takes real people to define what an application (or unit of work) is, determine all its related entities, collect the pertinent source data, setup the conversion rules, perform the conversion, package the results, and ship them back to the client, who will then implement the changes, test them, and implement into production (hopefully). What CSGI has 'fully automated' is the code conversion step. But, I think that's what all the others have done, too. You'll never get me to agree that anybody has a 'fully automated Y2K solution'. That would be a 'silver bullet', which doesn't and won't exist.
