The following is a summary of my observations taken during a personal visit to CSGI's headquarters in Phoenix, AZ on 11/26/97. I have provided my opinions for information sharing purposes only. This information is not to be considered investment advice. Perform your own due diligence prior to investing in any of the companies mentioned in this post.
Disclosure: I currently own CSGI stock, as well as ALYD, PTUS, TPRO, and VIAS. I trade in and out of those Y2K stocks frequently, as well as a few others.
CSGI's management was kind enough to permit an onsite visit so I could get a first hand look at their technology. They feel their toolkit and associated service are unique in the industry. The primary purpose of my visit was to understand exactly what the tool does, and how it compares to other tools from other companies that make similar claims.
CSGI feels that their tool stands out from the rest of the products because it is "fully automated" in certain phases of the Y2K remediation process. After listening to a presentation given by Jeff Richards (VP of Marketing), I understand more about why they think they are unique. Their toolset evolved from some platform/environment migration tools to the current version which supports the Y2K remediation process. As such, their prior competition consisted of other tools professing the same migration functionality which have also been enhanced to perform Y2K remediation. I am not knowledgeable in the migration area, but it seems to me that their competitors would have been the likes of Forecross (FRX.U). I looked at that tool several years ago when it was an IDMS to DB2 conversion/migration tool. I was not impressed.
CSGI's toolset was developed as a migration tool to support their migration services. A client would make the decision to migrate their applications and send CSGI their source code and associated copy books, job control files, etc.. It was built as an inhouse tool and not intended to be used by a client. The user interface is an indication of that. There really isn't one, other than a very rudimentary 'menu' system.
The toolset was built in 'C' on a UNIX platform, and is intended to be used by UNIX techies. Those people tend to be very line command oriented, so a user interface isn't really "necessary". However, the lack of any kind of formal interface makes the demo of the product pale in comparison to other tools with more currently accepted (and expected) GUI's. The main drawback of this is that the tool can't really be sold/licensed easily to end users for their own use. This will be a competitive knockoff when the Y2K fever gets really hot and heavy in late 98/99. There will be quite a training rampup required even for their 'partners', who license the technology and perform conversions at their own datacenters.
The tool works by analyzing all components of an application. Note that the term "all" is their word, not mine. Depending on the environment being remediated, CSGI succeeds to varying degrees. They're quite strong in Bull, Unisys, and DEC (or so they tell me; I'm not qualified to make a judgement on that). They've recently added Hewlett Packard support for the Millennium Enterprises HP3000 conversion, so I would expect that they're still in learn mode in that environment. They advertise IBM support. While it does analyze and convert native IBM COBOL source code, they are weak in the support of MVS environments. They will be in learn (and, big surprise!) mode in that environment (or, in reality that MIX of environments) for a long, long time.
The analysis of the components builds an Oracle database consisting of all entity (individual component, such as program, data field, etc.) information. Logic flow information is included in the Oracle data. That is what is used to determine which fields are dates. There are "seeds" defined by the client for those off-the-wall naming conventions, but the majority of the find-a-date processing is done automatically by determining the point of origin of the contents of each field. Typically, a date enters an application from a System call or user input. These are defined to the analyzer to help it perform the analysis. 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.
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.
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.
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. It uses 4 digit expansion for all conversions, but intercepts the I/O (Input/Output) statements to 'grow' and 'reshrink' the data from/to 2 digits for those occassions when windowing is the conversion method chosen. Note that this is not the "inline windowing" used by some other vendors' conversion products, so they avoid many of the issues involved with nested IF's, etc. However, there is a significant performance penalty that the application pays for the overhead of converting from/to 2 digit format. This is especially true considering the technique they used to perform that function. I consider that proprietary to their solution, so will not discuss the details here.
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. If the client chose 4 digit expansion, the appropriate file conversion utilities are provided.
In summary, CSGI has a conversion tool that performs the functionality required to make source code Y2K compliant. It is absolutely NOT "fully automated". Certain portions of the process have used automated capabilities to enhance the speed and reliability with which they are accomplished. They have the same environmental problems as many of their competitors when it comes to IBM MVS. However, they appear to have a leg up on their competition for the non-IBM environments.
As to my investment in CSGI ... I will continue to hold my existing CSGI shares. Again, the comments made in this post are my opinions and are NOT to be construed as investment advice.
If you have any questions, please ask.
Regards,
TED |
