General

Question: Why would I want to convert my database to NonStop SQL?
Answer: A complete answer would take a long time, but a short list of benefits are:

1. Overcome Enscribe limits and improve performance accessing the data with the legacy application.
2. Use the online database maintenance features of NonStop SQL that eliminate application downtime.
3. Take advantage of the powerful data access capabilities of NonStop SQL (both /MP and /MX) for marketing analysis, data mining and ZLE functionality.
4. Improve access to the database through industry standard SQL-based reporting and query tools. Eliminate the need to “program” reports.
5. Improve programmer productivity through the use of SQL data access vs. Enscribe.
6. Migrate the application to an ANSI-standard database; build a portable application without having to start over with new application development.

Return to Top

Question: What are the basic requirements to convert my Enscribe database to NonStop SQL.
Answer: Any K, S, or future model of NonStop, with an NSK version of D40 or greater will support Escort SQL. In addition to the basic NSK software, the NonStop SQL runtime support must be licensed.

Escort SQL will require DDL dictionaries that contain an accurate description of the application data.

Application source is not required; Escort SQL works directly with object files.
The Enscribe database must consist of entry-sequenced, key-sequenced, and relative files. Unstructured files are not convertible to SQL.

Return to Top

Question: What are the basic steps in an Escort SQL migration?
Answer: After installing the Escort SQL software, the application object programs are “prepared” through a simple, one-time process requiring a second or two per program. When the object files are ready, they can be tested for “pass through” mode (no SQL database) and placed in production. This should have no effect on the overall operation.

The database is migrated, usually a few files at a time. This involves a SQL table design process, creating the production SQL tables, loading the Enscribe data into the SQL tables, and then restarting the application processes with the SQL tables replacing the Enscribe files.

Once the data migration is complete, you have many options as described below.

Return to Top

Question: How long will it take to convert my applications and data to NonStop SQL.
Answer: Installing Escort SQL and converting the application programs are truly a less-than-one-day task. The bulk of the time required for migration is in the design of the SQL tables, loading the data from Enscribe files, and testing.

The design of the SQL tables will depend on how simple the Enscribe files and records are. If (1) the data records can be described with simple DDL, (2) data representation is standard, (3) Enscribe DB is “relational”, (4) the use of REDEFINEs and ARRAYs is minimal, and (5) each file contains a single record type, then the SQL DB design and data conversion can be accomplished rapidly.

More typically, a legacy Enscribe database accumulates complexity due to business requirements to add features without redesigning all applications and reloading all data. A major goal of Escort SQL is to eliminate these legacy features and produce a well-designed SQL database for future development.

Escort SQL has many features to transform, modernize, and “normalize” the new SQL database in the migration process. Use of these features, however, adds to the work during the migration, but will pay off handsomely in future productivity when using the database.

Testing is, of course, mandatory. You will, however, quickly learn that application modules work the same on the SQL database as they did with the Enscribe database. The risk and testing effort should be less than a database change that requires recompiling the application programs.

Return to Top

Question: Does Escort SQL maintain both my existing Enscribe files and the new NonStop SQL tables?
Answer: No. Escort SQL is a migration tool to replace the Enscribe files with well-designed NonStop SQL tables. With Escort Journaling you can keep a dual copy during the post-migration phase for fallback purposes.

Return to Top

Question: What are the risks involved in the migration?
Answer: No migration is risk-free, but the Escort SQL approach is far simpler and safer than a traditional legacy database migration. Because it requires a small team and simple steps, the entire project will succeed. A traditional migration requires coordination of a far larger collection of people and resources; the complexity of managing the traditional migration is a leading cause of failure.

Escort SQL enables the database migration through a series of simple and incremental steps that (1) can be thoroughly tested and (2) have quick fallback scenarios.

If production problems arise, you can easily drop back to the Enscribe files. With the Escort SQL Journaling product, you can keep the old Enscribe files synchronized with the new SQL tables to allow a fallback with no loss of data.

Once the database has been migrated, any changes to the applications (such as using embedded SQL) can be performed incrementally, changing, testing, and installing one module at a time. A traditional database migration requires all programs to be changed and installed using a Big-Bang approach.

Return to Top

Question: What are my options after the migration?
Answer: When the production data is in NonStop SQL tables, you may use the NonStop SQL tools to manage the physical database and industry-standard tools such as ODBC to access the data.

For the production application, there are three basic possibilities:
1. continue to make all modifications using Enscribe programming, or
2. program new application modules (or updates to existing modules) with NonStop SQL, or
3. rewrite the entire application using NonStop SQL.

Choice 1 is good if database management and external access is the primary objective. Most customers adopt choice 2, as the cost of choice 3 for a large application may be quite high.

On the other hand, if application portability or modernization is a major goal, using Escort SQL is the least-risk method to achieve that objective. The rewrite can proceed, a few modules at a time, with a small, dedicated, team. Ongoing business development is not impacted and the risk of the Big Bang is eliminated.

Return to Top

Question: I hear that Carr Scott are also the technology providers for HP's NonStop AutoTMF product. Is there any benefit if we are already using NonStop AutoTMF in our move from Enscribe to NonStop SQL?
Answer: Yes, because Carr Scott software developed both Escort SQL and NonStop AutoTMF using the same intercept technology, if you already have AutoTMF installed and running, your programs are already prepared to do the interception for either or both functions. Once you have licensed Escort SQL the transition is very simple.
 

Functions and Features
Return to Top

Question: What programming languages and environments are supported?
Answer: TAL, PTAL, C, and COBOL85 applications are supported. Both TNS and TNS/R (Native) environments are supported. Other languages will be supported on request.

Return to Top

Question: Can I run ENFORM reports or ENABLE programs against migrated SQL tables?
Answer: Yes, and they usually run faster. A "prepared" version of ENFORM/ENABLE operates on the migrated SQL tables just as if those tables were still Enscribe files. ENFORM reports can be produced from any combination of SQL tables and Enscribe files. Even “compiled” ENFORMs can be executed with no modifications.

Return to Top

Question:  Can I mix Enscribe calls to a mapped table with embedded SQL statements to a table in the same program?
Answer: Yes. Programs containing both SQL statements and Enscribe calls are referred to as hybrid programs.

Return to Top

Question: Will Escort support SQL/MX?
Answer: Escort SQL is currently compatible with SQL/MX access to SQL/MP tables.
Support for SQL/MX tables will be implemented when it is practical to do so and customers require it.

Question: How many people are needed to migrate to NonStop SQL?
Answer: A SQL-knowledgeable DBA, or equivalent, will be required to design the new SQL database using the Escort file conversion features. A small operations team may be needed to coordinate the database conversion, data loading, testing, and production “go-live” of the SQL database.

Since no application source needs to be modified, or even recompiled, changes to application programs are not required during the database migration.

There is no need to dedicate programming resources or disrupt the ongoing business-related development, testing, and installation of updates to the application. As indicated above, you decide just how much reprogramming of the application is required to meet your goals.

Return to Top

Question: How will Escort SQL affect my application’s performance?
Answer: Customers usually see an overall performance improvement, but there are both negative and positive factors.

On the negative side, processes will typically experience a few seconds of additional delay in the startup phase when files are being opened. CPU use will increase due to the processing of data column-by-column in NonStop SQL.

NonStop SQL (and, thus, Escort SQL) has much improved I/O performance due to its sophisticated buffering techniques. If your system is less than 80% CPU busy, you should see better response times and batch throughput. Beyond that, you may need additional CPU resources.

It should be noted that application’s performance is almost the same as an embedded (compiled) SQL program that performs the equivalent I/O operations. There is very little extra cost for the Escort translation of the Enscribe operation to SQL.

Return to Top

Question: How much NonStop SQL training will I need?
Answer: If you do not have NonStop SQL in your current environment, basic SQL operations training is highly desirable.
 
Expertise in SQL database design will be helpful in making decisions on database conversion issues.

Some familiarity with SQL performance (i.e., MEASURE counters) will be helpful, but the SQL generated and executed by Escort SQL is relatively simple, so it will not be necessary to understand optimization of complex query plans.

Since application programs do not need to be modified for Escort SQL, application programmers need training only if you want to start programming new applications in SQL. This can occur incrementally, since the rest of the programming staff can continue to program using Enscribe programming.

Return to Top

Question: How much production downtime will be required to convert to NonStop SQL?
Answer: Very little, even if you have 1000’s of Enscribe programs and 100’s of gigabytes of Enscribe data to convert.

The application must be stopped and immediately restarted, one time, in order to execute application object files that are enabled (or “prepared”) to use Escort SQL.
By using the Escort SQL Journaling feature, the NonStop SQL tables can be loaded and synchronized (at low priority) while the production application is still up and executing. When the SQL tables are ready, the application must be shut down and restarted to start using the SQL tables as the production database.

You may wish to convert the Enscribe DB in stages, a few files/tables at a time to minimize risk. With Journaling, each stage will require a shutdown and immediate restart of the application processes.

Return to Top

Question: How much extra disk space will I require?
Answer: A SQL table is usually requires less space than the equivalent Enscribe file; when the migration is complete you should have more free space than before.

During the data migration, you will need to have space for both Enscribe files and their converted SQL tables, but, by proceeding in stages, only a few files/tables need be duplicated at any one time. After each stage, the Enscribe files may be deleted and the space recaptured.