Silicon Investor (SI) -- The First Internet Community

STOCKTALK

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: TEDennis who wrote (1366)	11/21/1997 9:22:00 PM
From: TEDennis	Read Replies (2) \| Respond to of 3391

All: To help clear up (or make worse) some of the flap over "fully automated" and "assistant" tools ... here's just a small example of the challenges that "automated" tools face .. This is a scenario that many of the toolsets have trouble solving ... There are 2 programs in a system (OK, so it's a SMALL system) ... A File is shared between the 2 programs. PGMA creates the file. The current date is determined by an operating system interface and stored in the header record (1st record in the file) as the date of creation of the file. It will be stored in YYMMDD format (971121 is Nov 21, 1997). Let's give that date field a name ... how about "CTL-DATE". Lots of other records are then appended to the file. They are insignificant for this discussion. PGMA then completes execution and ends. Everybody goes home for the night. The next morning, the operator fires up PGMB, which reads the file. PGMB, however, uses a different record descriptor, so the field that contains the "CTL-DATE" is called "CREATED". And, instead of being defined as a numeric field, it's defined as a character string (display). To ensure that we're using the correct version of the file, PGMB checks CREATED against a parameter supplied to it by the computer operator. The operator supplies the prior day's date in a control card and PGMB stores it in a 6 character work area. Let's call that work area "TEST-CREATED". Note that since this was not an operating system date interface, there's no way to tell what type of data is on the card. We don't know it's a date other than from the context of what the operator did. Programmatically, we don't know. PGMB then compares the 2 six character fields to ensure that the correct file is being read. If the data in the CREATED field doesn't match the data in the TEST-CREATED field, then either it's the incorrect file, or the operator screwed up and entered the wrong date. So ... how does the automated date conversion tool know that: 1) PGMB's TEST-CREATED field is a date 2) PGMB's CREATED field is a date It's impossible without additional information. PGMB has no basis for determining that either field is a date. Perhaps there is some documentation that would assist someone trying to determine what needs to be fixed. Most likely, there won't be. You have to rely on the 'application expert' who knows what the programs do, and why. If either field can be determined to be a date, then the ASSUMPTION can be made that they are both dates. This will be correct over 99% of the time (I hope). A manually assisted conversion tool would have to ask the programmer which of the fields in PGMB are date related. Without some intense analysis of the entire application, this can't be done automatically. A "fully automated" conversion tool requires application level analysis ... not just program source code. The tool would be able to link PGMA and PGMB together by their association with the file. This would be done through logical association of the programs' source codes, through the COBOL I/O (Input/Output) interface with the operating system, and through the job control language (JCL) that executes both programs. PGMA's CTL-DATE field could be determined to be a date by the fact that it received the value from an operating system date interface. By knowing that the 2 programs are using the same file, then the fields can be 'equated' by relative offsets within the record. Thus, we can determine that PGMB's CREATED field is actually a date. And, therefore, TEST-CREATED is also a date. And, the above scenario is the SIMPLE case !!! Yes, there are tools that attempt to do the above application level analysis. Some are successful, some aren't. Some tools don't even try. They won't do well as an "automated" solution. TED

To: TEDennis who wrote (1366)	11/21/1997 11:19:00 PM
From: tech	Read Replies (1) \| Respond to of 3391

>> CSGI's tool would be about on an even keel with what MatriDigm's tool is touted to do for the conversion phase. << Ted, help me here I am a little confused. Wasn't MD's tool based on batch binary ? Did they ever address windowing and field expansion, or do they now ? CSGI's tool was used in the Millennium Conversion. From reading the press releases and what Pat Kemmer, of Millennium Enterprises, says on the back of the CSGI's annual report, this project was started, finished, and tested. No errors were found and the code was put back into production. Did any of MD's projects reach the testing stage ? If so, how did they do ? Has there been anyone else that has developed a tool with the automation factor that ConSyGen claims, used this tool to actually convert code, test the code, and find no errors ? Thank you for your help.