Eccox test squad offers a service to improve the functional and technical completeness of applications during the specification, design, logical, and physical phases using test case construction techniques, and to validate the operation of the systems following construction until the final homologation through the execution of the test cases.

In the early phases, the cell focuses on the verification/existence of test requirements that were omitted or inadequately constructed and, as it advances to the logical, physical and construction phases, focuses on the details and adequacy of the test plan and test cases. In the final phase, i.e., the integrated tests and homologation, it operates the effective execution of the test cases that will prove or not prove the correct operation of the constructed functions. The Test Cell can be included in the services of the Integrated System Certification Cell.

Eccox has been working since its founding in 1992 with CobolTM and ASSEMBLER IBM®. This made their intellectual capital and skills in these languages allow to create a team prepared for any type of program creation and routines, conversion and migration of versions, releases and the migration of these languages from each other.

The sites that work with the mainframe platform end up being reactive in the update of versions of Cobol and maintenance of programs and routines in Assembler due to the scarcity of labor specialized in these languages.

There is a convenience of the market in reducing Cobol and assembler languages as much as possible. The great part of this convenience is because in the last two decades the mainframe platform has also evolved reactively trying to accommodate the amounts charged by its operating system and subsystems. Software development and applications based on DevOps, Agile, and Value Stream have turned to other platforms bringing the developer workforce to other languages. With the creation of the Cloud, it was tried once again to reduce the mainframe space and consequently its traditional languages. The security of the platform, the correct and rational vision of an effective Total Cost Ownership (TCO), and the platform’s suitability for technological advancement once again showed the strength of the mainframe in global industries. Similarly, the languages accompanied these variations and Cobol has been strengthening, assembler has become part of the curriculum of courses offered by manufacturers and the routines written in assembler are treated as a legacy to be organized and even replaced by other languages that meet the original performance requirements of when these routines were created, and the assembler language was absolutely necessary for this.

If you want to modernize your languages in a rational and structured way, please contact us. We will be ready to help you transform digitally with the correct appropriation of your version and/or language migrations.

The Eccox team for more than 30 years has mostly developed satellite interfaces between systems, applications, and APIs primarily in integrated testing. Tests within the mainframe, or even transactions originated from Linux® or Windows® when they access the databases in the mainframe (Ex. DB2® IMS®) often go through the particularities of a given client. These are data anonymization projects, specialized ETLs, legacy data originating from older systems, as well as data streaming that need to serve as input for certain tests. Sometimes, an essential routine for the periodic testing of a new transaction must be developed in assembler and from there is where we enter with specialized labor to integrate the needs of our customers. In practice we noticed that a correct integration through cataloged routines, properly documented, greatly assist in the present and especially in the future of that application regarding the maintenance of these routines and the debugging of them. It’s worth much more in terms of costs to hire our workforce with experience in any type of environment integration.

Reliable Test Environments to consume anonymized data for massive testing executions with full data referential integrity between the applications and databases for required testing scenarios.
Test Environment Baseline (data matrix) to supply testing needs and data combinations with integrity providing the data matrix environment that feeds the current test processes and future updates and reuses.
Provide the relationships trees from production databases building reduced and anonymized data stored-in based on the business application logics and regulatory criteria to:

• Supply tests and future demands to reuse allowing total or partial reprocessing to generate a new environment and / or perform incremental loads of data in target environments to feed development, integration testing, acceptance, etc. to meet each testing need conditions.
• Knowledge transferring to customer team support and update the data environments.
• Ensure the completion of testing batch processes running the same production processing batch chains, via a zero-touch process of batch tests, by your preferred scheduler tool at the new testing data processing environment.