Software Product versus Software Solution

We believe a solution is designed not simply to withstand change but to embrace it. Software product evolution is still a 'bolted onto the outside' affair when in fact, the mechanisms to support ongoing and sometimes radical change, must be baked in from the start.

All Forecross solutions are built on a series of modular parsing, analysis and transformation engines we call XCODE, that interface with client-specific, customizable rules engines to create fully automated, functionally equivalent applications in the target environment.

New releases of Forecross software are typically the result of adapting proven client-specific rules into the XCODE engines, thereby offering future clients a better baseline solution where few or no unique rules need to be defined.

Because our software and migration methodology are constantly informed by hands-on project experience and client requirements, each Forecross migration solution is far superior to our competitors in four main areas: Database Definition (Schema) Conversion, Data Conversion, Program Conversion, and Automated Testing Support.

We also offer a vendor comparison checklist to facilitate your evaluation process: Vendor Comparison

×

XCODE Architecture

Close

Database Definition (Schema) Conversion

• True relational structure - Using our baseline schema conversion (without applying any of the numerous customizations already built into the software), Convert/IDMS-DB™ creates relational tables - one table per record type, with primary and foreign keys properly defined, as well as physical record-id keys.
  
  
• No additional tables - All Forecross Convert products generate a 'natural' database definition with both business keys (i.e. primary keys and foreign keys), and record-id keys to better support physical access and aid in performance tuning. And we do it WITHOUT additional tables.
  
  None of the competitors delivers a clean, truly relational database structure. Their tools leave you with 'data' tables that roughly match the IDMS record types, plus 'relationship' tables that tie the data together. This product design limitation presents significant drawbacks for the client, such as:
  
  
  1. On-going learning curve - Both for those who must maintain the application post-migration and for any new development staff using the converted database.
     
     
  2. Performance nightmares - Consider an IDMS program that needs to display all 10 employees in the Sales department. After translation by Convert/IDMS-DB™, this program will read the database once for the department record and once for each of the 10 employees (a total of only 11 reads). The competitors' code will read the department table, then the first associated employee relationship table, then finally the first employee table. To get all 10 employees, this program will perform 21 separate database reads - or virtually double the I/O Forecross generates.
     
     
  3. Increased risk - If one of the relationship tables is corrupted, it is nearly impossible to reconstruct the fact that those 10 employees are in the Sales department, other than going back to the last successful backup. Relationship tables create an unnecessary burden on the database and application code, and therefore on the DBAs and application programmers. Consider the average network database with 500 record types and millions of rows of data in each. Many of these tables can be related to each other resulting in perhaps 1,000 relationships. The competitors' approach creates 500 data tables plus 1,000 relationship tables - a total of 1,500 tables, three times the size of the original database structure! Add to this the fact that database access is doubled - maintainability and good performance are lost in the bargain.
     
     
  4. Legacy tools - With other vendors, changing the database definition post-conversion may involve using the vendors' leave-behind proprietary tools to re-generate the SQL database definitions. Programmers already reluctant to admit any knowledge of your legacy DBMS will not want to participate in ongoing maintenance of such applications and databases.
     

Data Conversion

• Up-front automated data analysis - This unique parameter-driven process identifies any bad data that may be hiding in the database giving your staff a head start in cleaning it up.
  
  
• Guaranty that no data will be left behind - Forecross data conversion architecture ensures that all data is extracted, independent of any structural issues in the database. Certain databases can mask broken relationships and data that does not comply with the rules defined in the schema.
  
  Forecross uses a multi-access approach to data extraction and provides database statistics and hash totals in addition to robust error reporting to ensure referential integrity.

Program Conversion

• No proprietary tools - Forecross conversions involve no leave-behind products that must be licensed or used once the migration is complete.
  
  Other vendors rely heavily on proprietary utilities that must be used when making modifications to the database structure or online programs, essentially causing these components to be 're-converted' whenever changes are needed.
  
  
• No proprietary execution environments - The Convert products generate standard command level CICS programs that are compatible with any mainframe or server environment that supports this transaction server. There is no dependence on a vendor's proprietary transaction servers, or the associated ongoing maintenance costs and risks.
  
  
• Industry-standard COBOL - The Convert products generate code that uses only mainstream COBOL programming techniques, as well as ANSI-standard SQL to implement functionally equivalent business applications in the target environment.
  
  Two examples of the importance of generating industry-standard COBOL are:
  
  
1. No Recursive COBOL - A technique infrequently used decades ago primarily by systems programmers, recursion is no longer supported by many of today's COBOL compilers. Delivering a modernized application that depends on an unsupported and often poorly understood architecture is not part of the Forecross solution.
   
   
2. No Conversational CICS COBOL - Since the debut of CICS, IBM has always strongly recommended against using conversational programming for business transactions involving user input. This remains true even today, despite significant advances in the ability of the CICS transaction server to manage resources. In today's age of small, independent, stateless messages, creating monolithic conversations diminishes the value of the solution going forward.
   
   
• Maintainability of generated code - A side-by-side comparison conducted by a client's technical staff responsible for maintaining two applications, one modernized by Forecross and the other by a competitor, revealed Forecross as the winner. The competitor's code was deemed unmaintainable, as it used an arcane architecture and techniques that most of the world's COBOL application programmers never use and don't understand.
  
  
• End reliance on sunsetting legacy technologies - Forecross leaves our clients with no future dependence on legacy programming expertise.
  
  In contrast, maintaining migrated IDMS applications by going back to the original ADSO or IDMS schema source is cumbersome and requires ongoing IDMS expertise. You lose any benefit your IDMS modernization might have delivered in terms of reducing dependency on a dwindling number of IDMS resources in the future.
  

Automated Testing Support

Forecross has two unique testing tools, TestSentinel™ and I/O Navigator™, which can dramatically decrease testing time - usually the biggest and costliest part of any migration project.

• TestSentinel™ is a capture/replay system that highly automates equivalence testing for both batch and on-line programs. The basic methodology is to capture all of the input and output information to and from a program prior to migration. The captured input is then replayed into the migrated program and the output from the replay execution is automatically compared to the output data the pre-migration version of the program. If there are differences, a report is produced to assist in quickly identifying the problem.
  
  It also automatically compiles a branch and path analysis coverage report that shows which parts of the program logic have and have not been executed. If it is then determined that the code coverage was insufficient, additional or alternative test data can be prepared and another capture/replay executed to ensure sufficient code coverage.
  
  
• I/O Navigator™ completely tests all database access before and after conversion. It verifies that all client data can be accessed correctly and navigated properly. I/O Navigator™ can be run at any stage of a migration project, and does not require the creation of test scripts. Run in retrieval mode against any network database (empty or not) and a corresponding SQL database, it creates results of every type of navigation possible for the records and sets based on their original schema definition. The results can then be automatically compared and any issues resolved long before the conversion and testing of any application programs.
  
  In combination with the Forecross Data Evaluator™, which is used to verify the content of the data, I/O Navigator™ ensures a successful conversion of the client's schema, data, and database access programs.
  
  

Return to Top