• The ATP Engine is a one-time cost per site, regardless of the number of environments (production, QA, test, training, disaster recovery, etc.).
• ATP Developer Seats are priced by concurrent seat and include volume discounts.
• ATP End-User Seats are also priced by concurrent seat and include volume discounts.

The first year of ATP maintenance is included in the initial price. A 20% annual maintenance fee is collected after year one based on current list price.

Advanced and its partners are able to provide these cost estimates that are very tailored to each customer environment.

No. The use of an organization’s Natural syntax in any environment or documentation for any reason does not violate any law. The same holds true for COBOL, Java and any other coding languages.

The Natural syntax from your existing applications is moved to Windows and executes in the Windows environment as a rich client.

The Natural syntax from your existing applications is moved to Windows and executes in the Windows environment as a rich client.

The ATP engine reads the Natural syntax as data and interprets the processing at a byte level to produce results that are identical to Natural that executes in the mainframe environment.

No Software AG licenses are required for ATP processing of any of the Natural syntax. No Software AG licenses are required for processing of the new relational databases (SQL Server, Oracle or Db2), nor for the execution of the COBOL or C# batch programs that are converted to process against the new database.

All Adabas databases are converted to SQL Server, Oracle or Db2. These conversions are performed as a service by Advanced using our automated toolset. Each resulting relational database will have the same functionality and traversal capabilities as the current Adabas database. Our tool will also create Natural or COBOL programs to allow you to extract the data from Adabas into a format that is ready-to-load to the new relational database.

The new relational database contains base tables, child tables and grandchild tables for each of the MU and PE instances, allowing the new database to include the table-to-table relationships expected in a relational data model. Access to the MU and PE data is handled by the ATP engine so that the Natural program code receives the data back in the expected view format.

The new relational database includes only those field types that are definable in the new database (small integer, integer, decimal, etc.). All packed and binary data is transitioned to the relational data type when it is extracted from Adabas during the database conversion. The new applications while executing continue to view the data as if it were packed or binary. The content of the relational database tables are completely native to the relational technology.

All existing mainframe Adabas data is transitioned to a valid data type in the new SQL Server, Oracle or Db2 LUW database. Each Adabas data field is written to an extract file in a display format, so that even packed and binary fields are written as display fields. The EBCDIC extracted data files are converted to ASCII by FTP, SFTP or similar transmission utilities as the data is transmitted from the EBCDIC environment to the ASCII target environment. Because of this complete change from EBCDIC to ASCII, there will likely be differences in some sort sequences when numeric and alphanumeric data is represented in the same data field.

The ISN numbers are preserved during the extract process. New row occurrences will receive the next available ISN number using the optimum mechanism provided by the new relational database management system. In SQL Server and in Db2, an Identity Column is used. In Oracle, a Sequence Object is used. From the Natural program perspective, the ISN is used and managed exactly as it is in Natural today.

No changes are required to any of your Natural programs in order to process against the new relational database. The ATP processing engine interprets the Natural “READ” and “WRITE” syntax and creates SQL syntax to perform the same data access and update against the new relational database.

All authentic versions of Windows are supported.

We recommend that our customers begin using ATP with the latest version of SQL Server.

The new ATP applications perform very well. The ATP environment is designed for speed, stability and accuracy in all of its processing. To date, all of our customers have experienced online response times that are very similar to the response time on the mainframe as long as there is no latency in the server and network configuration at the customer site.

The outputs from the Construct generator are Natural programs and components. These Natural syntax outputs are moved to the ATP environment for execution if they execute online in Natural, and are converted to either C# or COBOL if they are intended for batch execution. We do not process the Construct syntax itself.

The Advanced solution includes many new ATP objects that provide the same functionality. Advanced develops new objects to replace the former routines as we encounter these in customer code.

No. The Predict files are not part of the ATP or the Advanced conversion process. Online Natural application run interpretively – how does ATP solve that problem? The ATP processing engine allows the online Natural syntax to continue to operate interpretively.

We deliver a C++ Visual Studio solution called “ATP Interfaces” that allows the current Natural syntax to make the Call as it does today. The ATP Engine processes the Natural Call statement which passes an XML string defining the called program and parameters to “ATP Interfaces”. ATP Interfaces can be customized to call other routines or process requests internally. Upon return, parameter values are passed back to the ATP engine where they are placed in variable storage. All source code for “ATP Interfaces” is delivered to our customers.

To date, we have never had a request for such an interface. Depending upon how the initiation works in z/OS, it is possible that the “ATP Interfaces” solution could be utilized.

Again, we have never had such a request. The “ATP Interfaces” solution could again prove useful.

Yes, but in different ways. MVS ensures thread integrity through Task Control Blocks and provides settings and safety measures within the CICS run-time. Windows tracks activity using Process IDs that ensure that a run-unit completes or is rolled-back completely. Both environments protect the transaction integrity.

Advanced converts the batch Natural programs as a service to COBOL, Java, or C# so that the new programs can operate in eavJES, our batch run-time environment, or a batch run-time environment provided by a third-party vendor.

Advanced converts the batch JCL and procs to process against the new relational database, to execute the new batch programs, and to use utilities for the new languages/databases instead of for Natural and Adabas. The new JCL and procs will operate in eavJES (or another selected off-mainframe 3rd party batch run-time environment).

Yes. The ATP Developer workbench includes full documentation on all Natural and COBOL applications, including program-to-program flow, logic flow, complexity, impact analysis and more. The Advanced Enterprise Application Viewer (eav™) is actually built into the ATP Developer workbench.

Yes. Our eavJES batch run-time solution enables this functionality.

Batch programs can execute depending on the features utilized, but this is not advised in a production run-time environment.

• The application data lives on any database server (for Oracle, SQL Server and Db2) or the mainframe (for Db2 for z/OS).
• The eav instance that holds the Natural syntax lives on SQL Server that is typically on a database server.
• The ATP engine can be installed on individual desktops, OR in a Windows Server environment executed via a Citrix, Terminal Services or similar connection by multiple users via a web page. Advanced does not provide the connection software.
• Only one copy of the program execution map exists regardless of the number of users ATP caches program execution maps into memory as needed at run time (like Microsoft Word or Excel).

For Oracle, SQL Server and Db2 LUW, ATP uses ODBC. For Db2 on z/OS, ATP uses a Wire Protocol Driver that is delivered as part of ATP.

Access to the ATP online applications is managed using Active Directory. An interface from ATP the Active Directory is delivered as part of the ATP solution. The concept of Natural Security is replaced through the ATP layering of the target applications. ACF2, RACF and Top Secret batch access security can remain unchanged if the target environment for batch is z/OS and Db2, but these security tools are not used for the ATP online runtime.

Currently, the two security mechanisms are independent.

• Adabas Database Conversion is performed as a one-time service by Advanced. Pricing is based upon the number of Adabas FDTs and includes the delivery of the DDL for the new SQL Server, Oracle or Db2 databases. This conversion also includes delivery of Natural or COBOL programs to extract the Adabas data from any Adabas instance so that the data can be loaded to the new databases using the SQL Server, Oracle or DB2 load utilities. Volume discounts will be applied.
• Batch Program Conversion of Natural and/or Adabas COBOL programs is performed as a one-time service by Advanced. Pricing is based upon the number of Natural and COBOL batch programs and subroutines requiring conversion. Volume discounts will be applied.
• JCL Conversion to use the new COBOL or C# programs and the utilities for the new relational databases is performed as a one-time service by Advanced. Pricing is based upon the number of JCL streams and Procs requiring conversion. Volume discounts will be applied.

The Natural developer will be able to use the interactive debugger, what-you-see-is-what-you-get (WYSIWYG) screen painting, check-in/check-out, dual run mode and more. If you would like to learn about the full range of features, get in touch with us today.