tech: Here are the answers to the questions you asked. They are my opinions, and should not be used as a basis for making a stock buy/sell decision.
I'm really not interested in arguing back and forth about the subjectiveness of the "fully automated" phrase that you and some others seem to be hung up on. I'm stating my opinion here, and that's all I'm going to say about it.
TED
*******************
"They advertise IBM support. While it does analyze and convert native IBM COBOL source code, they are weak in the support of MVS environments."
1. Where did you get the idea that they are "weak" in MVS ? Was that something that you were told, or does that conclusion come from something else ?
I didn't say they were weak in MVS. I said they were weak in the support of MVS environments. Native MVS should be OK. I arrived at this from the interpretation of body language and lack of eye contact when I mentioned various MVS environmental considerations. Also, lack of support for various IMS and CICS entities (to name just a few).
"Currently, CSGI estimates that 70% of all fields that are identified as date candidates are "for sure". The other 30% are identified and listed for the client to make the final determination."
2. How does this 70 / 30 ratio compare to other companies who have similar toolset that automatically find date fields ? How does this ratio compare to the tool vendors who license their tools such as PTUS, DDIM, PLAT ?
DDIM is not a tools vendor. They are a services vendor with access to tools. PLAT is a mainframe tools and services vendor and thus in a different 'tier' of suppliers. Mainframe tools can do a better job of "automatically" finding date fields because they execute in the environment where the code resides and thus circumvent the problems inherent in off-mainframe solutions. The reasons for this are beyond the level of an investment chat board. If you're interested in details, I suggest you call one of the mainframe vendors of solutions (CA, CPWR, PLAT, VIAS) for an eye opening experience. PC or Unix based tools are what you should be comparing CSGI with (PTUS, SEEC, MatriDigm, etc.). Since they all use the same type of algorithms (following data through the logic), then they'll all find the same types of dates, depending on the environmental entities that are provided to the analysis. Like I said before, there will be a percentage or two difference, but no major benefits of one over the other.
3. How many companies, if any, are you aware of that can find 70% of date occurrences and then provide a detailed list of the others fields that may be "suspect" ?
Different vendors handle this differently. Most of them provide a full list of fields that have been identified as candidates, with a corresponding 'likelihood' for each individual field. You can accept all the fields above a certain 'likelihood' as being dates, then scrutinize the remaining ones as you would with CSGI's solution.
"CSGI claims their date find algorithms are better than their competitors' algorithms. I don't think so. Other tools perform the same kind of search algorithms, using the same kind of seeds, and performing the same kind of logic flow analysis. Perhaps there will be a percent or two different one way or the other, but I would say that in the overall scheme of things they're about as effective as others I have seen."
4. Could you please specify what others you have seen and where these companies fall in the year 2000 sector. i.e. are they near the upper or lower end of the spectrum?
I documented the other companies in a prior post where I hyperlinked to the writeups I did on PTUS, MatriDigm, and VIAS. PTUS and MatriDigm are in the higher-middle, VIAS is in the upper tier. I have also done competitive analysis of companies like CPWR, DDIM, etc. None of them are technological leaps ahead of any of the others. They might use different techniques, but they will arrive at the same or similar answers.
"The list of candidate dates is sent back to the users for validation in report format. Note that this is OK for a small application (1 million lines or less), but for a larger application the report becomes too large to be of use (thousands of pages). To help alleviate the paper overload, CSGI also sends the information to the client in CDF format (Comma Delimited File) so they can load it into their own database handler, such as Microsoft's Access or Excel products."
5. How does CSGI's handling of this aspect differ from other companies ?
The mainframe tool vendors obviously have the edge here. The client already has interactive access to the database that is built, so there's no need to print all that stuff. When the list is created, MatriDigm and PTUS provide prebuilt files and corresponding file browsers to aid in the review process. I assume other off-mainframe vendors would do the same. Requiring the client to load a CDF file is archaic. And, that's being polite.
6. How would you rather see it done ?
Answered in (5)
"After each date on the list of candidates is verified as a date or rejected as a non-date field by the client, the conversion rules are defined for each field. This is done in conjunction with the client. Then, they push a button, and it automatically finds all occurrences of each date field and converts the definition to be Y2K compliant. "
7. You state that "they push a button, and it automatically finds all occurrences of each date field and converts the definition to be Y2K compliant." Are you aware of any other companies that can "push" a button and then have code converted WITHOUT any programmers touching a single line of code ? If so, please state which ones.
All of the 'automated' conversion utilities do that. That's why they exist. What good would it do to build a conversion utility that has to be manually driven? They tools are driven by rules. Those rules are used to determine which action to take on which fields. That's what computers are for. There are some 'conversion assistant' tools that are designed to walk the programmer through the change process (DDIM's SystemVision 2000 for one). It's really nothing more than a bunch of EDIT macros with an ISPF frontend.
8. If CSGI is the only one, or one of the only ones, that can convert code "automatically", then does that give them any kind of advantage over companies who have to hire hundreds and hundreds of programmers to convert code ?
No need to answer this. They aren't the only one.
"The converted code is then delivered back to the client, untested. It can't be tested because CSGI doesn't have the client's data or environment."
9. CSGI has always claimed to be a "conversion house", therefore testing is left to the client. What other companies that consider themselves "conversion houses" test the code for the client ?
MatriDigm has a step in their process that tests each individual changed line of code to ensure it performs the same as it did prior to the conversion. That doesn't alleviate the need for client testing within the environment, however.
"In summary, CSGI has a conversion tool that performs the functionality required to make source code Y2K compliant. It is absolutely NOT "fully automated".
I am a little confused here. I thought you stated that CSGI has a toolset that Automatically finds 70% of the date occurrences and provides a detailed list of the other 30% that are suspect. You also stated that once the "conversion rules are defined for each field" then, "they push a button, and it automatically finds all occurrences of each date field and converts the definition to be Y2K compliant."
10. Isn't it true that during this entire process not one single line of code is converted by a programmer ?
Actually, they're all converted by a programmer. A CSGI programmer. One who defines the rules for each field to be converted. Consider your 'automated' tax return program. It does it all automatically ... after you provide the numbers in the right place. But, it's not "fully automated", otherwise it would collect all the data, do the calculations, sign the form, and mail it for you.
11. Are you aware of any other companies that have the combination of a automated search engine and an automated conversion?, if so, could you please list the ones you know.
PTUS, MatriDigm, SEEC. Maybe others.
12. If companies who only have automated search engines to find date occurrences, then have to hire hundreds of programmers to actually convert the code, can call themselves "automated", then what should CSGI call themselves ? Doesn't the fact that they have automated both the identification and the conversion phases set them apart ?
They'd be OK if they'd just drop the "fully" phrase. Yes, they have used automation to help the process, and yes it will go a long way towards reducing the amount of time it takes. No, they're not that much different from their competitors.
13. If we are going to criticize CSGI for calling themselves "fully-automated", then should the companies who claim automation, while not even having automated the conversion phase, fall under even worse criticism ?
You're assuming they're "fully" automated. They're not.
" However, they appear to have a leg up on their competition for the non-IBM environments."
14. Could you please explain what you mean by "leg up", what advantages do they have ?
They support the non-IBM mainframe environments. Most of the 'new kids on the block' attacked the biggest one first (IBM) and will attack the smaller revenue potential environments later. This gives CSGI the edge (leg up) in the non-IBM environments. Their tool has been in use as a migration assistant in the non-IBM environments for years. |
