Embed Size (px)
Citation preview
BUILDING BRIDGES
SMART DCI®
plugs your legal application into the new world
ADABAS/Natural
page 2 of 12 | Whitepaper SmartDCI ®
Contents
1. The SmartDCI® Product Range. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 SmartDCI®: The Dynamic Converter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 The SmartDCI® Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Variable Mapping of the DB Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Changing Over Step-by-Step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Static Analysis of the Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Static Analysis of the Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Dynamic Analysis of the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 Application Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.5 Requirements for a Complete Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Changing Over . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1 The SmartDCI® DCIWorkbench . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.2 Parallel Operation with SmartDCI® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Quality Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3.1 The Test Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3.2 The PKS CLOG Reference Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3.3 Customer Test Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.4 Staff Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4 Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. Scope of Operation/Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Optional ADABAS Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Locking Mechanism. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 ADABAS Functionalities not yet supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Descriptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 FormatBuffer/SearchBuffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3 Data Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.4 ADABAS Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Unsupportable ADABAS Functionalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Dirty Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2 ADABAS Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4 ADABAS Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.1 ISN Sortation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.2 RETAIN SET. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.3 Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Adapting SmartDCI®/Customer Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Post-Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
page 3 of 12 | Whitepaper SmartDCI ®
1. The SmartDCI® Product RangeWhen it comes to the confl icting priorities of maximum investment protection (of applications and the business processes mapped in them) and the desire for more fl exi bility, integration, recognized standards and mod-ern or more cost-effective operation, gateways can help protect your existing, tried-and-tested applications while technically adapting them to changed conditions and consolidating the data management within a company.With SmartDCI®, the transparency gateway for relation-al database systems, ADABAS C applications can be quickly and securely migrated to a relational database without having to make any modifi cations to the source code.
1.1 SmartDCI®: The Dynamic Converter
SmartDCI® is based on a “transparency gateway” technology. The idea behind this is both simplistic and convincing: the database interfaces beneath the appli-cations are swapped. Every application based on ADA-BAS C communicates with the database via one single system interface – the ADABAS direct call interface ADALNK (depending on the respective environment, the interface is called ADALNC, ADALNU etc.). This applies to Natural applications as well as Assembler, Cobol or PL/I apps. These system interfaces are replaced once by SmartDCI® (Figure 1).
Nothing changes for the applications. The ADABAS spe-cifi cs remain just the way they are without having to make any additional adjustments, e.g. ISNs, super and sub-descriptors, multiple fi elds, period groups, etc. In short: On the “outside”, SmartDCI® has the same interface the applications expect, while “underneath,” it’s working to-gether with the new relational database system.
■ No modifi cation of source code
■ Completely language-neutral
■ No different parsers, generators or procedural concepts are needed for applications that have been coded in different languages
■ Little testing needed
Because the source code remains unchanged and only an access layer has been newly implemented and con-fi gured at the system level, only the parity of the results of queries and transactions has to be verifi ed; the logic of the system itself does not have to be retested.
1.2 The SmartDCI® Architecture
At runtime, all calls to the ADABAS database are mi-grated by the SmartDCI® middleware – automatically and completely unnoticed by the applications – and sent to the target relational database before the results are returned to the applications in a classical ADABAS for-mat. The translation of the data, and their structure and formats at runtime are controlled through an internal re-pository which is stored in the database.
1.3 Variable Mapping of the DB Model
When creating the SmartDCI® repository, you can in-dividually decide whether to map every multiple fi eld (MU) and every period group (PE) to the relational tar-get scheme. For the application, access to these fi elds
Natural
ADALNK
COBOLRead File A by Descriptor D … End Read
L3, L3, L3, L3, … RC
Move 41 to FWRMove 3 to DCIDMove “L3” to CMDMove “DDJ” to 8BMove “” to VBMove “AA, AB, AC1-8, AE“ to FBCall “ADABAS”Using CB, FB, RB, 5B, VB, IB
Natural
SmartDCI®
COBOLRead File A by Descriptor D … End Read
L3, L3, L3, L3, … RC
Move 41 to FWRMove 3 to DCIDMove “L3” to CMDMove “DDJ” to 8BMove “” to VBMove “AA, AB, AC1-8, AE“ to FBCall “ADABAS”Using CB, FB, RB, 5B, VB, IB
ADABAS
RDBMS
1 SmartDCI® as middleware
ADABAS Interface (ADALNK*)
Call Analysis
Repository layer
RDBMS Interface
Smart DCI®-Repository
Applicationtables on
RDBMS
Action generation
SQL statementgeneration
DB action layer
Natural/Cobol Smart DCI®
2 The SmartDCI® architecture
page 4 of 12 | Whitepaper SmartDCI ®
remains transparent. SmartDCI® makes the processed data available to the application in the usual format.
There are two fundamental types of mapping: normali-zation and column compression.
In this case all MU/PE fi elds are normalized and stored in the RDBMS, i.e. for every one of these fi elds, a separate table is created which is linked with the main table via primary/foreign key relations. The original ADABAS-ISN is used as a key column here.
For the fi rst variation show above, the contents of an MU/PE fi eld are stored in a container column in the main table. At the same time, SmartDCI® processes the data from this fi eld at runtime and, as expected, makes the contents of the individual attributes of the MU/PE fi eld available to the application. The second variation can be used for cases where a small number of attributes from the MU/PE fi eld are expected. For every attribute of the MU/PE fi eld, a column is created in the main table. Again, SmartDCI® makes the processed data available to the application at runtime.
The fi nal decision on the mapping of ADABAS structures in the RDBMS has to be made in view of the specifi c performance requirements and the specialized data use. This is then dealt with during the specifi c adaptations made in the changeover phase (see section 2.3).
2. Migrating Step-by-StepThe following sections provide a more detailed overview of the individual steps involved in the changeover.
2.1 Analysis
The analysis phase plays a key role when it comes to suc-cessfully reaching the goal of migrating from ADABAS. As previously mentioned, the analysis provides vital information from the application on:
■ Risk / security of migration
■ Changeover procedure
■ Necessary adaptations to SmartDCI® or the application
■ Effort/expenditures of changeover
■ Complexity of application
■ Anticipated performance
The SmartDCI® product range supports three types of analyses (Figure 4).
2.1.1 Static Analysis of the Sources
For the static analysis of sources, all Natural and COBOL sources are currently supported, since all information on the database calls that is visible in the application sourc-es is collected with an analysis tool. This information is then made available as a detailed overview in the form of HTML pages. With this overview, questions like the following can be answered:
■ Which database statements occur how often with which clauses and options (Figure 5)?
■ Are all of the database call statements used by the ap-plication supported by the latest SmartDCI® version?
■ Which DB fi les are referenced by which DDMs and what calls can be made to them (Figure 6)?
ISN PersNr Name Languages(PE) Language Level3 4711 Mueller English 3 French 2 Spanish 1
ISN PersNr Name3 4711 Mueller
ISN BOC Language Level3 1 English 33 2 French 23 3 Spanish 1
Normalization
Personnel master data
Personnel_master_data Personnel_master_data_Languages_PE
3a Schema Mapping I
ISN PersID Name WorkU (MU) 4711 Mueller 20.04.2001 24.05.2003 16.07.2005
Column Compression
Personnel master data
ISN PersID Name WorkU3 4711 Mueller 20.04.200124.05.200316.07.2005
Personnel_master_data
ISN PersID Name WorkU_1 WorkU_2 WorkU_33 4711 Mueller 20.04.2001 24.05.2003 16.07.2005
or
3b Schema Mapping II
Static analysis of the sources
Static analysis of the data model
Dynamic analysis of the database calls within the application
NaturalCobol
ADABASFDT
ADABASCLOG
4 Analysis of the application
page 5 of 12 | Whitepaper SmartDCI ®
5 Natural source analysis I
6 Natural source analysis II
page 6 of 12 | Whitepaper SmartDCI ®
7 Dynamic analysis of the ADABAS CLOG
8 Application Explorer
Missing
NotRefer-enced
referenced objects are marked in the source code
Call Hierarchy Called-by HierarchySource-Code
2.1.2 Static Analysis of the Data Model
The static analysis of the data model is based on the ADABAS DB model information from the DDMs or ADAREP. The following is analyzed:
■ how many ADABAS fi eld types MU and PE there are in the ADABAS DB model the application is based on
■ how complex the ADABAS special fi elds are (e.g. multiple fi eld in period groups)
■ how and which descriptor types are used
This analysis provides us with answers as to whether SmartDCI® has to be adapted for the migration of the analyzed application and how complex the data model is.
2.1.3 Dynamic Analysis of the Application
Based on a preferably representative ADABAS CLOG created on the important application parts (dialog and batch), the runtime DB access behavior of the appli-cation is analyzed. The result of this analysis is a list of the direct calls that have actually been transmit-ted (Figure 7). This in turn answers the question as to whether SmartDCI® has to be adapted for the migration of the analyzed application, and also give some initial indications of the hotspot’s potential performance.
A statistic is also contained that shows which fi les or fi elds were not referenced in the database calls. This way in the analysis phase, an attempt can be made in an iterative process to systematically add these calls in a CLOG later on, thus refi ning the analysis even further.
2.1.4 Application Explorer
For every type of reengineering and even for transferring an application to another database system, application mining is an important part of the analysis. The Appli-cation Explorer tool from the SmartDCI® product range facilitates many tasks when querying the application that’s set to be changed over (Figure 8):
■ A complete dependency analysis of all Natural objects (such as programs, subprograms, MAPs, DDMs, LDAs etc.). At the same time the call-by and called-by hierarchy is displayed graphically. Individual Natural object types can be included or excluded from this diagram
■ In conjunction with this is the possibility of source code navigation through the call-by or called-by hierarchy of the app
■ All of the application’s objects are listed in an overview
■ Retrieval of missing sources
■ In which modules and in which place dynamically composed program calls take place
■ Which objects are not statically referenced by other objects, i.e. are accessed dynamically or denote source code that is no longer needed
This Application Explorer is also available for third generation program sources.
page 7 of 12 | Whitepaper SmartDCI ®
2.1.5 Requirements for a Complete Analysis
The following information is needed for an in-depth analysis:
Static Analysis:
■ A complete description of the ADABAS schema information on the physical database in the form of ADABAS fi eld description tables (FDTs) of all ADABAS fi les or DDMs for schema evaluation as supplied by the ADABAS tool ADAREP or Predict.
■ If possible, all or some of the application sources. Preferably a representative sample of modules with access to complex ADABAS fi les (fi les with a large number of period groups, MU fi elds, MU fi elds in period groups and descriptors on MU fi elds or period groups). If a number of programming languages (e.g. Natural and COBOL) are used, similar example sources are needed from every language.
Dynamic Analysis:
■ ADABAS offers the possibility of logging database calls, the so-called CLOG or ADABAS command log. The different parameters to be logged can be entered here. For an analysis of the application’s access behavior, a CLOG from a representative test run is needed which includes:
- the entire control block- the format buffer- the search buffer
The ISN buffer, value buffer and record buffer are not necessary for an analysis at the start of a project, so the CLOG remains relatively small.
■ When migrating, a second, more comprehensive recording including value buffer and record buffer is needed at the start of a project for testing purposes (see section on quality assurance). In addition, the data fi le of the recording is also needed for this test. When doing the ADABAS data unload, it’s important here that the data fi le is exported with the original ISN.
■ Also very helpful are the statistics on the number of calls to all ADABAS fi les (fi le usage) and the number of times different ADABAS direct calls (command usage) were accessed, as provided by the func-tion “Session Monitoring” in the ADABAS ONLINE SYSTEM or the Nucleus shutdown statistics.
2.2 Planning
Based on the analysis, a detailed project plan for migra-tion is drafted together with the user during the planning phase for the changeover. A spec sheet is also com-piled, which contains a list of the ADABAS functionalities that have to be supported for the application’s migration by SmartDCI®.
After this phase, an obligatory offer is drawn up.
2.3 Changing Over
The actual changeover is done in four steps (Figure 9):
1. Creation and fi lling of the SmartDCI® repository
2. Generation of the relational target database objects according to specifi ed mapping rules
3. Data migration to the RDBMS and comparison of the data between ADABAS and RDBMS
4. Project-specifi c adaptation of SmartDCI® and performance optimization
1. Creating and Filling the SmartDCI® RepositoryThe repository is the information control center of the SmartDCI® middleware. The repository is located in the relational database and contains all the information about the ADABAS C data model and its desired map-ping in the RDBMS. The SmartDCI® package includes the Repository Generator and Object Generator tools. The Repository Generator reads the information on the physical ADABAS DB model from the FDTs of the ADA-BAS fi les. Information on the desired schema mapping of the multiple fi elds and period groups is added to this information. At the same time, it can be determined for each individual multiple fi eld and every period group if they should be mapped fully normalized as a table or as a container fi eld in RDBMS. If needed, information from the NATURAL DDMs is also added. Based on this infor-mation, the repository generator creates the SmartDCI® repository in the target database and fi lls in the tables with the desired information.
2. Generating RDBMS ObjectsThe Object Generator creates all of the application’s RDBMS objects (tables, indices, etc.) from the mapping rules stored in the repository in the target database.
3. Data MigrationData migration is done through a DATA loader tool from PKS with the help of the mapping rules stored in the repository. The data decompressed from the ADABAS
ADABAS
1 2
3
RDBMS
ObjectGenerator
RepositoryGenerator
Data Loader
ADABASApplicationFiles
SmartDCI®
RepositoryRDBMSApplicationFiles
9 The Changeover
page 8 of 12 | Whitepaper SmartDCI ®
database with ISN serves as raw data. Finally, a com-parison tool is used to ensure that the data has been correctly loaded into the RDBMS. For this purpose, each individual ISN is compared binarily and the result is logged.
4. Project-Specifi c CustomizationThe analysis of the application and the data model de-livers the information about which ADABAS function-alities are being used by the application to be migrated. If ADABAS functionalities are being used that are not supported by the latest SmartDCI® version, a decision will be met together with the customer as to whether SmartDCI® should be adapted to these needs, or whether any eventual adaptations in the application would make more sense for functionality or performance reasons.
5. Exchanging the Link Module with SmartDCI®
There are two possibilities of integrating SmartDCI® middleware:
1. The ADALNK library is replaced by the DCILNK library with the same name. At runtime, the modifi ed library is then reloaded. No new application module has to be created here. If you have to access the ADABAS C database, the original ADALNK library has to be restored.
2. A new application module is created with the SmartDCI® interface, which dynamically reloads the DCILNK library at runtime. In such, the original ADABAS application module remains untouched and can be easily used anytime parallel to the new SmartDCI® application module.
2.3.1 The SmartDCI® DCIWorkbench
With the controlled and intuitive interface of the DCIWork-bench (Figure 10), you can execute SmartDCI® functions as well as the functions and utilities of the target data-base system without even having to be familiar with them, access them or manually parameterize them.
The DCIWorkbench also offers you the possibility of specifi cally intervening in processes to steer them or make modifi cations. Data structures and fi eld names can, for example, be changed this way. The migration of ADABAS to RDBMS is thus repeatable, transparent and quite easy.
The main tasks are essentially:
■ creating a project and copying the sources and information needed for it
■ creating a repository on the target platform
■ fi lling the repository with the SmartDCI® administration information and the ADABAS FDT information
■ modifying the repository according to your own specifi cations
■ creating a target schema in the database
■ loading the ADABAS source data into the target database
■ implementing changes or extensions to the schema
■ further developing the schemata
■ generating Natural SYSTRAN fi les for DDM information
10 Screenshot of the Repository Editor
page 9 of 12 | Whitepaper SmartDCI ®
2.3.2 Parallel Operation with SmartDCI®
SmartDCI® is set up so that migration can be done fi le by fi le (Figure 11). This means that at one point calls to fi les 44–88 are routed to the RDBMS, while calls to fi les 41–43 simultaneously still work in ADABAS. File 40 is processed in both database systems. This allows for “smooth-sailing” migration.
■ SmartDCI® allows for a mixed mode between RDBMS and ADABAS C
■ At the fi le level, you can determine whether a fi le is in ADABAS C, in the RDBMS or parallel in both databases
■ Via the 2-phase commit from RDBMS, the integrity of the transactions is ensured
■ Migration can thus be done step-by-step according to e.g. subject areas or based on external requirements
2.3.3 Quality Assurance
SmartDCI’s® QA concept is based on three test strat-egies independent of one another. All together these ensure that database calls from the application migrated to RDBMS are functionally identical with the original ADABAS app.
■ The test suite
■ The CLOG reference record
■ The test paths specifi ed by the customer
2.3.3.1 The Test Suite
The SmartDCI® test suite consists of a collection of test cases at the direct call level (Figure 12). The test cases check the various ADABAS direct calls in different com-binations of the call options, descriptor types, format buffer, search buffer, etc. (subtests). A test interpreter in-terprets the test scripts and then sets off the respective calls against ADABAS. In doing so, the interpreter logs all return dates, return codes, etc. from ADABAS in log fi les. In the next step, these calls are set off against SmartD-CI®/RDBMS and their answer is compared with the infor-mation from the log fi les on the behavior of ADABAS. The test case can only be passed if all answers from Smart-DCI® are identical with those from ADABAS.
2.3.3.2 The PKS CLOG Reference Record
A representative reference record of the ADABAS data-base for the most important dialog and batch runs denotes another important test strategy for application
migration with SmartDCI®. Certain functions from the application are logged during operation. In doing so, the following scenario has to be executed in an isolated test system:
■ First all involved test datasets are saved
■ The SmartDCI® recording module is activated to record the complete control block, format buffer, search buffer, ISN buffer, value buffer and record buffer
■ After this, the application’s test cases relevant for take-over are run through (random samples) and recorded in an extended log fi le of the app
■ The dataset is also saved after recording
Together with the stored data, this recording can later be run against the confi gured SmartDCI® in a sort of macro reader, and must display the same behavior and results (return data and return codes) as the original run in ADABAS (Figure 13).
ADABAS
RDBMS
Test 1
Loop (count < 10)Call L3 ……… END LOOP
Subtest 1Subtest 2Subtest 3
Test 2Subtest 1Subtest 2
Test 3…
Testsuite (>2000 Subtests)
Scriptlanguage
Direct Call L3
Direct Call L3
Compare bufferand returncode
CB, FB, SB, VB, RBCB, FB, SB, VB, RBCB, FB, SB, VB, RB…
Log-file
TestsuiteInterpreter
ADABASDirect CallInterface
SmartDirect CallInterface
12 SmartDCI® test suite
ADABAS
RDBMS
Clog 1Call 1Call 2…Call N
Clog 2Call 1Call 2…Call N
Clog 3…Clog N
(CB, FB, R B, VB, S B, IB)(CB, FB, R B, VB, S B, IB)…
ADALNK
SmartDCI®
Application
Identical?
Call Adabas
Recording of direct call and all
Automated comparisiondirect call and all buffers
z.B. READ File_A by Descriptor_D (i.e., L3, L3, … RC)
Play back direct call
Play back direct callMapping Adabas to SQL
SQL
13 Automated tests
Natural COBOL
ADALNK*
SmartDCI®
File 40, 41,42, 43
File 44, 45, 46, 47, 48RDBMSADABAS
11 Parallel Operartion
page 10 of 12 | Whitepaper SmartDCI ®
2.3.3.3 Customer Test Paths
The test paths in the application are another module of quality assurance. Because the customer is best familiar with his application, he specifi es the various test paths. This means that the customer determines the paths through his application (dialog and batch), which from his perspective are vital, complex or critical for the changeover. He specifi es which input data deliver which results from the application in ADABAS. SmartDCI® now also has to deliver the same results.
2.3.4 Staff Training
At the end of the project or analog to it if necessary, employees are trained how to use, administer and further develop the application in the new environment.
2.4 Startup
To start with, RDBMS has to be installed on the target platform, and a database instance and the respective users, roles etc. have to be created. After the successful conclusion of the tests in a test system as described in the section on quality assurance, installation and con-fi guration is done in the productive system. After the installation of the SmartDCI® product range, live data are migrated with the Loader Tool and the Compare Tool is used to ensure that the data have been correctly loaded. Finally, the ADABAS call interface is replaced by SmartDCI®. All of the application’s database calls are now done in the relational database via SmartDCI®. As previously described in section 2.3, SmartDCI® offers the possibility of operating two databases in parallel. This opens up the possibility of simultaneously working with two databases during the initial phase, thus ensur-ing the greatest possible degree of security.
2.5 Maintenance
SmartDCI® is continually being further developed by PKS. Support and product updates are available through an optional maintenance contract.
3. Scope of Operation / Restrictions In following, the direct calls and ADABAS functionalities supported by SmartDCI® are listed.
3.1 Optional ADABAS Functionalities
3.1.1 Locking Mechanism
SmartDCI® supports two fundamentally different locking mechanisms in the target RDBMS.
■ Use of SELECT … FOR UPDATE (this debars the targeted release of a certain dataset lock)
■ Use of RDBMS-specifi c locking mechanisms like e.g. the ORACLE DBMS_LOCK package (dataset lock invisible on the “outside”)
3.2 ADABAS Functionalities not yet supported
3.2.1 Descriptors
■ Hyper descriptors
■ Phonetic descriptors
3.2.2 FormatBuffer / SearchBuffer
■ Highest occurrence indicator (e.g. “MU1-N”)
■ SQL signifi cance indicator notation (e.g. “AAS.”)
■ Field series notation (e.g. “AA-AD.”)
■ Edit mask notation (e.g. “AA,15,E1.”)
■ Space notation (e.g. “AA, 5X, BB.”)
■ Text insertion notation (e.g. “AA,’ text ‘,BB.”)
3.2.3 Data Types
■ Floating point data type (format: ‘G’)
■ Long alpha (alphanumeric data type up to 16KB)
3.2.4 ADABAS Calls
■ C1 (write a checkpoint)All current “data protection” information is written to the ADABAS “data protection” log fi le
■ C3 (write checkpoint)Prompts the writing of the checkpoint (data protection log and block number)
■ C5 (write user data to protection log)Writes user data in the ADABAS data protection log fi le
■ L1/L4 with command option 1 = ‘F’Outputs the next highest unused ISN number for a specifi c fi le. The number is ascertained by accessing the fi le control block (FCB)
■ L3/L6 with change in directionIn ADABAS the direction can be easily changed dur-ing a reading loop. Unfortunately, this is either not possible with SmartDCI® in an RDBMS or it requires setting off a new SQL statement, which would lead to a signifi cant decline in performance
■ MC (multi-call)Allows multiple ADABAS calls to be set off in order to reduce the amount of interprocess communication
■ RI (release record from hold status)Targeted clearance of a dataset block via the ISN. This feature is not supported when using the RDBMS ‘SELECT … FOR UPDATE’ lock mechanism
■ S5 (fi nd coupled ISNs)Provides the datasets for a fi le that is interfaced with another fi le through the ISN
■ Limit time for Sx callsUsed to set a limit (in seconds) for all initial Sx calls
page 11 of 12 | Whitepaper SmartDCI ®
■ Compressed ADABAS record length informationIf a format buffer is specifi ed in the ADABAS control block, the compressed dataset record length is output for all reading calls
■ ADABAS security mechanism (password/cipher code)When accessing secure ADABAS fi les, the corre-sponding password and cipher code are entered in the ADABAS control block
■ ADABAS triggers & stored proceduresTriggers are special functions that are automatically called for certain events. Stored procedures are functions that can be called via certain USER calls
Some of these ADABAS functions, which are not supported by SmartDCI®, are not used with the latest Natural version.
Principally speaking, direct calls can also be set off via a CMADA in Natural. For this reason, a detailed analysis of the application as described in Chapter 2 is the only way to fi nd out if the application or SmartDCI® has to be modifi ed.
3.3 Unsupportable ADABAS Functionalities
3.3.1 Dirty Read
The so-called “dirty read,” sometimes also referred to as a transaction isolation level 0, is a major problem when migrating from ADABAS to Oracle. At this level, all changes in the database are immediately visible to all other users, even without “commit.” In a modern RDBMS, however, this level is not supported! Programs that use exactly this procedure have to be adapted to the new database concept.
3.3.2 ADABAS Calls
■ L2/L5 (read in physical order) Outputs the datasets in the row that were physi-cally stored in the fi le. When migrating, this physical structure cannot be migrated, which means that the sortation will be different after migration is fi nished
■ ADAM keys (ADABAS direct access method)Allows direct access to the datasets (without an inverted list)
3.4 ADABAS Compatibility
SmartDCI® tries to emulate every ADABAS behavior as well as it can. Depending on your needs though,this ADABAS behavior can be somewhat moderated.
3.4.1 ISN Sortation
By default ADABAS basically always sorts according to the ISN if no descriptor has been specifi ed. This is also emulated as such by default in SmartDCI®. If, however, this type of ISN sortation is not needed, it can be de-activated in an external confi guration fi le. This way all FIND commands without the SORTED BY add-on will be executed with a much better performance by the RDBMS. Additional database operations for sorting the
query output are then inapplicable. ISN sortation is nor-mally only needed in cases where the ISN value is sup-posed to indicate the age of the dataset. In other cases, this sortation can be skipped without having to fear any functional effects on the application.
3.4.2 RETAIN SET
Hit quantities can be generated in Natural /ADABAS and stored in so-called RETAIN SETs. These query outputs can be linked to other hit quantities at any time.For example:
FIND NUMBER EMPLOYEE WITH NAME > ‘M’ RETAIN AS ‘NAME-SET’
FIND NUMBER EMPLOYEE WITH ‘NAME-SET’ AND SALARY > 4000 RETAIN AS ‘NAME-SET’
The fi rst Natural FIND statement outputs all datasets with the NAME > ‘M’ and stores these query out-puts under the name ‘NAME-SET’. For the second FIND statement the query output is linked with the second condition SALARY > 4000’ and stored again under the same name. This way only those employees can be found in the ‘NAME-SET’ query output whose NAME > ‘M’ and SALARY > 4000.
SmartDCI® generates these RETAIN SETs in two different ways:
1. The search criterion is expanded accordingly and the query output is recalculated. Unfortunately though, the number of these operations cannot be executed infi nitely because the performance becomes slower with every ex-pansion. Links or extensions to the query output like this should therefore be kept to a minimum. For this same reason, the ADABAS snapshot attribute of a RETAIN SET cannot be mapped, i.e. a query output previously ascer-tained in the RETAIN SET will be replaced by the newly calculated query output upon the next FIND command. Based on the above example, the following SQL state-ment was generated during the second FIND command:
SELECT COUNT(EMPLOYEES_ISN) FROM EMPLOYEESWHERE NAME > ‘M’ AND SALARY > 4000;
2. If it’s necessary to hang onto the RETAIN SETs be-yond a FIND command (much like it is in ADABAS), this behavior can be activated for each individual fi le in the SmartDCI® repository. This way SmartDCI® now tries to retain the query output through a quantity indication in an SQL statement and upon the next FIND command, adds this query output to the new search or links it with the new query output, respectively.
Here again is an example for the second FIND com-mand:
SELECT COUNT(EMPLOYEES_ISN) FROM EMPLOYEESWHERE EMPLOYEES_ISN IN (<ISN1>, <ISN2>, ...) AND SALARY > 4000;
page 12 of 12 | Whitepaper SmartDCI ®
This ensures in every case that the originally calculated hit quantity is taken into account at the next FIND com-mand regardless of whether or not datasets have been modifi ed.
3.4.3 Log File
Every time a SmartDCI® application is launched, some information on the current application is stored in the ‘dcitask.log’ the fi rst time the database is accessed. This log fi le is stored in the respective working directory. For every process, the start-up time, corresponding process ID and the Natural ET user is output in the log fi le.
3.5 Adapting SmartDCI®/ Customer Applications
The in-depth analysis of the application delivers the in-formation on the functionalities that are not supported by the latest SmartDCI® version, yet are indispensable for migration. Together with the customer, a decision can be made as to whether SmartDCI® should be adapted to these needs, or if modifi cations to the application would be more sensible, perhaps for e.g. performance reasons.
4. Post-MigrationIn addition to the cost reduction, some other new pos-sibilities also arise after successfully migrating. Where complex, vulnerable interfaces previously had to be manually managed and comprehensive data analy-ses had to be manually developed, a wide range of tools based on one standardized platform can now be used – from standard tools for data administration to BI software and data warehouses. In addition, the data urgently needed in different applications can be shared and swapped with each other at the database level. New business processes can be developed with new applica-tions and more agile technologies in parallel and based on the same data, and they can adopt the functions of the legacy applications step-by-step. And developers, designers and system staff alike will be progressively introduced to the new technologies and development processes. At the same time, end users’ acceptance of the applications remains as high as ever.
The following new possibilities arise here:
■ Access via SQL (ODBC interface)
■ Access via Java (JDBC interface)
■ Data integration in other apps
■ Reporting with modern reporting tools
■ Integration of existing data in modern business processes
You’ve entered the New World … without leaving the Old World behind.
PKS Software GmbHGeorgstraße 1588214 Ravensburg /Germany
Telefon: +49 (0) 751 5 61 40-0Telefax: +49 (0) 751 5 61 40-500
www.pks.com
