SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : CSGI ...READY FOR TAKE-OFF! -- Ignore unavailable to you. Want to Upgrade?


To: tech who wrote (1446)12/1/1997 8:08:00 PM
From: TEDennis  Read Replies (1) | Respond to of 3391
 
tech: >>The company through its press releases has put out the idea that they have a solution that is quite different than many of their competitors.<<

If you're telling me that you made your CSGI investment decision based on press releases made by a company trying to make a name for itself with claims of uniqueness ... and now you're telling me that an SI poster's opinions are going to convince you to change your investment position ... then I'm afraid you're a very naive individual.

Frankly, I don't think that's the case. You seem brighter than that.

Surely you've seen other companies claiming uniqueness. Beauty is in the eye of the beholder. Some people buy Fords, some buy Chevys. Take a look at their Marketing literature. Don't they all claim "bigger, faster, slicker, quicker" ????

In regards to CSGI ... they have a niche that will serve them well. As long as they don't go too far beyond their capabilities, they should make a profit. Code conversion is a need. CSGI can supply that need. So can many other vendors.

Now, if we can just convince them to get off their "fully automated" horse ...

Best of luck with your decision,

TED



To: tech who wrote (1446)12/1/1997 8:14:00 PM
From: TEDennis  Respond to of 3391
 
tech: >>if ConSyGen states that they are the only company that they know of to have automated the identification and conversion phases, then they are lying ? <<

This is one of those unsupportable and unattackable statements. They can't prove that they don't know of other companies that do the same thing, and you can't prove that they do know. A reasonable man, however, would assume that they had done their own due diligence from a competitive standpoint. Some of the comments made during my visit makes me think they didn't.

Sometimes you can't see the forest for the trees. Especially if you're one of the trees.

TED



To: tech who wrote (1446)12/1/1997 9:41:00 PM
From: TEDennis  Read Replies (2) | Respond to of 3391
 
tech: Answers to your questions to my answers to .... well, heck ... here they are.

#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 ?

Reply -"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)."

+++++++++++++++
You say you arrived at this conclusion from "body language", and lack of "eye contact". I don't know about others, but I would feel more comfortable if this conclusion could be based on something a little bit more concrete.

OK, fine. YOU take your 20+ years of IBM software development experience in multiple complex MVS environments down there. YOU talk with them for more than 5 minutes about various IBM environments. YOU look at the blank expression in their eyes that indicates they haven't the foggiest notion what you're talking about. Then, YOU decide whether or not you should pursue a more indepth discussion. I only had a couple of hours to absorb as much information as I could. If I'm wrong, then I'm wrong. If I'm right, then ... well ... insert your favorite "I told you so" comment here.

#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?

Reply -" 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."

+++++++++++
Where does ConSyGen fit in amongst the companies mentioned above ?

CSGI is about mid-tier. Their conversion tool works. However, it is not an end user tool and therefore has a handicap when comparing it to others that can be touched and felt by a real user. Yeah, I know it's not supposed to be an end user tool. If it were, the user interface (lack of) would make it a laughingstock.

#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.

Reply-"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."

+++++++++

So, in other words, if ConSyGen states that they are the only company that they know of to have automated the identification and conversion phases, then they are lying ? If ConSyGen is not telling the truth and there are other companies who have both an automated search engine and a automated conversion, then why do these other companies require hundreds and hundreds of programmers ? What allows ConSyGen to only need 30 people instead of hundreds of people?

Are you also stating that the other companies you mentioned have a process that not one single line of code is converted by a programmer?

The hundreds of programmers are not there to convert a line of code at a time. They are there to help the client gather the data, determine all the pieces and parts, determine the conversion rules, etc. Programmers or progarmmer-types play a role in just about every step of the process. End users don't know how to do these things without being guided. They've never done them before. Could the other tools be done with absolutely no programmer intervention? Probably, but the overall process would be hampered just as CSGI's is. And, remember, CSGI hasn't tackled a major effort yet. It gets lots more complex than the stand alone applications they've converted (like the simple one at Motorola, which by the way still hasn't been tested). So, it remains to be seen whether they only "need" 30 people.

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 ?

Reply-"No need to answer this. They aren't the only one."

+++++++++++

Could you please list the other vendors, or companies who meet all of the following conditions:

1. Have an automated search engine
2. Have automated the conversion phase
3. In the conversion phase not one line of code is converted by a programmer. Although a programmer may set up the rules for the conversion, the actual conversion is done automatically.

Sigh ... OK, listen closely. The Y2K conversion market consists of several vendors who claim to automatically find dates and convert them to be Y2K compliant. The names have been listed on the prior posts. There are more. If you really think CSGI is the only vendor that can do it, then put your life savings there and hope for the best. Or, believe me and others who tell you they aren't the only ones.

#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 ?

Reply-"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."

++++++++++++++

Has MatriDigm ever started, finished, and tested a project ? If so, what were the test results ? Other than MD's "claims" no other conversion house, that I know of, tests the clients code. ConSyGen never claimed to do testing anyway.

I've been waiting for this one. "Has MD ever started, finished, and tested a project?" I don't know, but just because I don't know doesn't mean it hasn't happened, does it? (If you'll remember, you used that argument yourself a few days ago. Pardon me for using your own logic against you.)

#10. Isn't it true that during this entire process not one single line of code is converted by a programmer ?

Relpy-"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."

++++++++++++++++

So you consider defining the rules as converting code ? Are there other toolsets that the programmer establishes the rules and then the actual conversion is done automatically ? If so, do any of these companies claim to be able to convert 5 to 10 million lines of code with only 2 to 3 people. If so, which ones ?

I have to ask again, if the CSGI toolset is nothing special, then why do they only need 30 people while others have to hire hundreds and hundreds of programmers ?

Well, first of all, we're not sure they only "need" 30 people. If they had 50 more people, could they handle more sales calls, more demos, more proof-of-concept pilots, create better marketing materials, have better Investor Relations? I think so. As an aside, if this toolset and process are so perfect, why doesn't everybody use it? Because of competitive claims and successful pilots by more visible vendors, that's why. Do you think these other major vendors are making deals with the other conversion vendors to do the conversion if their tools don't work? I don't. And, if you stop and think about it real hard, you won't either.

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.

Reply-"PTUS, MatriDigm, SEEC. Maybe others."

++++++++++++++++

If what you say here is true, then there is nothing special about ConSyGen. What the company has stated is a lie and they have mislead investors by saying that they have a different kind of solution than what was available from other companies.

You are for a FACT stating that PTUS, MatriDigm, and SEEC, all have an automated search engine and a automated conversion, in which not one single line of code is converted by a programmer?

======================

Well, you said it, I didn't. "there is nothing special about ConSyGen".

I'll say my peace again, and then I'll no longer spend time on this subject ... CSGI has a tool that works within a defined set of parameters. They are not the only fish in the sea. But, there will be plenty of conversion work to go around. They'll get their fair share. And, with their small 'burn rate', they should make a profit.

If that's not good enough for you to consider holding your investment, then you'd rest better at night if you went elsewhere with your investment dollars. As for me, I'm holding.


Best of luck,

TED