IBM Cognos Axiant 4GL

IBM Cognos Axiant Migration Planning Guide

Moving Forward with IBM Cognos Axiant 4GL

A move forward with IBM Cognos Axiant 4GL can represent up to five different types of migration:

• Indexed files to relational databases

• Character to graphical interfaces

• Proprietary to open systems

• Server-centric to distributed applications

• File-based to graphical, client/server development

What must change in existing development or deployment environments varies according to the target architecture you have defined. However, a move from IBM Cognos PowerHouse to IBM Cognos Axiant 4GL always includes a move from file-based to graphical, client/server development.

In the past, each of the five migrations would have warranted enough attention to be addressed with individual schedules. That luxury is rarely available today. You'll probably combine some or all of these migrations into a single project.

Moving from Indexed Files to Relational Databases
A move from indexed files to relational databases is the first kind of migration you may be planning. Most PowerHouse applications began as indexed file systems, including:

• TurboIMAGE

• KSAM

• RMS

• C-ISAM

• DB2/400

These file systems concentrate on the persistent storage of data and do little to encode or enforce business rules. Datatype support is fairly rich, but restricted to character and numeric data. Data design for indexed file systems is flexible and doesn't require normalization. Access to these systems is almost always strictly controlled through the IS organization.

IBM Cognos PowerHouse automatically provides the functionality needed to work with indexed file systems. It also handles difficult tasks such as data integrity, rollback, multi-user conflicts, and security in every QUICK(R) and QTP(TM) program. The programmer only has to specialize details when they do not meet the norm.

In the past few years, a number of indexed file systems have been moved to relational databases. Often, due to IBM Cognos PowerHouse's open nature and consistency across platforms, it was faster not to exploit the relational database and normalize the data. Thus, even though an RDBMS is being used, the data is still managed as if it were in an indexed file system.

Relational databases compare to their indexed file predecessors as a modern automobile compares to a horse-drawn carriage. Both can travel the same roads, but they require different handling, and the automobile offers greater flexibility and power than was ever considered for the carriage. Relational databases available to IBM Cognos Axiant 4GL customers include:

• ORACLE

• IBM DB2

• Sybase ASE

• Microsoft SQL Server

• ORACLE Rdb

• ALLBASE/SQL

• Sybase SQL Anywhere

Relational databases are not just data storage systems, they are also processing engines. They allow you to code business rules and to program using their own language -- SQL (Structured Query Language). To improve performance and achieve more open applications, you may need to change data design and application processing when moving to relational systems.

The Implications of Normalizing Data Definitions
The first step of any move to relational is to normalize the data. So much has been written about this topic that it hardly needs explanation here. There is one major decision to make wherever non-normalized data has been used: do you keep the highest or lowest level definitions? For example, the following PDL code is typical of many IBM Cognos PowerHouse systems:

ITEM ORDER-DATE ZONED SIZE 8
ITEM DATE-PARTS REDEFINES ITEM ORDER-DATE
BEGIN STRUCTURE
	ITEM ORDER-YEAR ZONED SIZE 4
	ITEM ORDER-MONTH ZONED SIZE 2
	ITEM ORDER-DAY ZONED SIZE 2
END STRUCTURE

Some programs in the application access ORDER-DATE and others access ORDER-YEAR, ORDER-MONTH, and ORDER-DAY. This redefinition is not valid in a normalized database. Either ORDER-DATE must be discarded and the components of the definition used in the database, or the other way around. One way to help make this decision is to review the code that uses this record structure to determine which is used more frequently.

Another common instance of non-normalized data is an array. Arrays are regularly used in indexed file systems for things such as months of the year. These too should be normalized, probably requiring greater changes than do redefinitions. Often arrays are handled with loop structures and/or occurs clauses in programs. These structures must be changed when the arrays are normalized.

As you can see, changes to data definitions require changes to programs. The less normalized your data is, the greater the effort. IBM Cognos Axiant 4GL is designed to help you with this process by finding non-normalized data via the Migration Profile. In the case of substructures, it actually "flattens" the data by keeping only the lower-level definitions. In the case of arrays, it tells you where they exist and that they need to be removed.

Supported Data Names
Even if you don't have to do much normalization, you may find that you must change the names of data items. Different databases support different naming standards. In the previous example, the data names would have to change -- probably to an underscore -- in a move to most relational databases because a dash is not a valid character for names. Thus, ORDER-DATE would become ORDER_DATE, a change that would have to be reflected in every program accessing ORDER-DATE.

Special characters and lengths of names may need to change with a similar impact on programs.

IBM Cognos Axiant 4GL will find these problem names during the migration process and provide a Change Manager to address them.

Supported Datatypes
Whenever you change file systems or databases, support for datatypes must be considered. Many databases support datatypes that are unique to that environment. An example of this is the Gfloat datatype on OpenVMS. Data stored in non-standard datatypes must be migrated more carefully than data in common datatypes.

This may also have an impact on programs. If numeric datatypes are changed, accuracy or precision may differ, resulting in visual differences when data is displayed by screens or reports.

Transaction Management
For indexed file systems, transactions are managed by the programmer. With IBM Cognos PowerHouse, transactions are handled automatically and transparently unless the programmer chooses to override IBM Cognos PowerHouse's defaults. These defaults assume no functionality on the part of the underlying file system.

This assumption is untrue for relational databases. While Axiant 4GL provides high-level control over transaction management, there are differences from the behavior of indexed file systems.

A good example of this is the concept of rollback. Since IBM Cognos PowerHouse handles rollback for indexed files, it is easy to predict rollback behavior regardless of what the user does. With relational databases, rollback behavior depends on when the last commit was done and how individual databases process such situations. Because the functionality is not under Axiant 4GL's control, what was successful with an indexed file may be unacceptable with the more complex relational database activity.

Disabling the database functionality and handling it all in IBM Cognos PowerHouse is not the answer. The database offers advantages here that shouldn't be discarded. Rather, the answer is to:

• Review the behavior of the application

• Understand how and when data is committed to the database

• Understand how many read and write transactions are active

• Understand how the program acts in a rollback situation

Cognos has Relational Interface courses that address this issue in detail. See the section Cognos Training Services for more information.

Using the Power of the Database Engine with IBM Cognos PowerHouse
Since the IBM Cognos PowerHouse engine and the database engine can jointly handle processing, you should pay careful attention to which engine is being asked to do which part of the processing. In general, data access is best handled by the database.

In IBM Cognos Axiant 4GL, this is made possible through the inclusion of SQL/DML (Data Manipulation Language within SQL) in the IBM Cognos PowerHouse language. An SQL SELECT statement can replace the input phase of many QUIZ and QTP programs. This includes the following IBM Cognos PowerHouse statements:

• ACCESS

• SORT and SORTED

• SELECT

• CHOOSE

Further, SQL/DML can replace whole requests in QTP. It may be more efficient to use SQL/DML than OUTPUT statements.

However, replacing IBM Cognos PowerHouse code with SQL/DML is not always preferable. The IBM Cognos PowerHouse language offers a rich capability that is not fully available in SQL. For example, parallel linkage such as

ACCESS A LINK TO B AND TO C

is very simple to specify in IBM Cognos PowerHouse. The equivalent SQL/DML is much more complex, and is not likely to be much more efficient. In this case, the ACCESS statement is the better choice.

While SQL/DML is more efficient in most situations, it is crucial when using the fat-client topology. You don't want to send 100,000 rows of data to your PC so that three records can be selected. You want to let the database do that work and only send the three records over the network. SQL/DML is the way to do this.

IBM Cognos Axiant 4GL makes it easy to change the input phase of batch programs to use cursors. During migration, you can request IBM Cognos Axiant 4GL to do this for you automatically.

The improved performance of SQL/DML is less of an issue for QUICK screens because they usually deal with smaller numbers of records. The only exception to this is the WHILE RETRIEVING loop for DESIGNER files.

The Migration Profile in IBM Cognos Axiant 4GL can help you substitute SQL/DML for existing syntax in reports and runs.

Open Databases vs. Vendor RDBMSs
When moving to a relational database, you must choose between databases such as ORACLE and Sybase ASE -- which can be called open databases because they are available on so many platforms -- and hardware vendors' databases such as ALLBASE/SQL, Rdb or Microsoft SQL Server , which are popular choices for MPE/iX, OpenVMS and Windows systems. IBM Cognos Axiant 4GL supports these type of databases, so your decision should be based on application requirements.

Unlike open databases, vendor databases cannot be ported to as many other platforms supported by IBM Cognos Axiant 4GL. However, open databases don't access legacy data as easily and are often more effort to migrate. The choice between open and vendor databases may be determined for you if the vendor database has already been purchased as part of the operating system.

Before making a decision, it is important to consider what client/server topologies you'll be using. These are described in the section About IBM Cognos Axiant 4GL, under the heading Supported Deployment Topologies.

Using ODBC with Indexed File Systems
One option that may appear attractive is to leave data in indexed file systems and access them via ODBC from applications running on Windows. This is certainly possible, but should be examined closely for two reasons. First, ODBC is relational, which means that data normalization, transaction management, and data naming standards must still be addressed. This may result in no savings at all.

Secondly, many ODBC drivers for legacy data systems lack the robust capabilities demanded by a IBM Cognos PowerHouse or IBM Cognos Axiant 4GL application. They may be adequate for read access, but not able to handle multi-user concurrency for creating and updating data. You should, therefore, carefully test any ODBC driver before deciding to use it with a migrated application.

Moving to DISAM
IBM Cognos Axiant 4GL supports DISAM as an indexed file system under Windows. You can make use of DISAM just as you would an indexed file system under any other platform.

Moving from Character to Graphical Interfaces
A move from character to graphical interfaces is the second kind of migration you may be planning. One major reason to move to IBM Cognos Axiant 4GL is to gain a graphical interface and integration with other tools in the Windows environment. IBM Cognos Axiant 4GL helps you to do this by providing migration utilities as well as by importing IBM Cognos PowerHouse Client applications. IBM Cognos Axiant 4GL's default GUI forms and inheritance also reduce the effort involved. A move from character to graphical interfaces will present other challenges that must be met by design changes.

Graphical interface design is challenging, and personal taste affects this effort more than any other in information technology. You should involve the end users when developing a standard, but it won't be possible to account for everyone's taste.

The best way to achieve a standard is to understand what is already in place in the user environment. The Windows operating systems provide a consistent user interface that should be matched in your IBM Cognos Axiant 4GL application. (This interface is documented in The Windows Interface Guidelines for Software Design by Microsoft Press, 1995.) If the users commonly use a suite of products such as Microsoft Office, these have a standard menu and toolbar that should be incorporated in the GUI design.

Managing form real estate can be especially challenging. It is common in IBM Cognos PowerHouse applications to pack as much information onto a single screen as possible. The result is very crowded screens but fewer moves between screens. This is the opposite of good GUI design, and these screens almost never fit in a Windows form unless the users have 1024 x 768 support or better. As a result, you may need to significantly redesign screens by splitting them up or using different controls, such as pop-up text fields or graphical data.

IBM Cognos Axiant 4GL helps you move from a character-based to a graphical interface through a combination of screen conversion and inheritance. It can convert an imported terminal screen to a GUI screen. This utility gets you started quickly and reduces tedious effort -- it does not produce a final design. IBM Cognos Axiant 4GL also allows forms to inherit their basic look and feel. Its default repository gives you a good starting point. As GUI design proceeds, changes will be identified that are required on all forms. Remember that only the form that provides the basic design needs to change, since changes to it are then inherited by all programs.

Through its "thin-client" capabilities, IBM Cognos Axiant 4GL lets you focus on designing the right graphical environment for your users while minimizing the underlying change to your IBM Cognos PowerHouse application.

Moving from Proprietary to Open Systems
A move from proprietary to open systems is the third kind of migration you may be planning. Applications coming from MPE/iX, OpenVMS, AOS/VS, and OS/400 are unlikely to be truly "open" applications. IBM Cognos PowerHouse is deeply integrated with these environments, which were chosen because of their unique capabilities. However, advantages become liabilities when moving such applications to other systems.

IBM Cognos Axiant 4GL can handle all the issues that arise inside IBM Cognos PowerHouse programs. It will identify IBM Cognos PowerHouse code that is machine specific and recommend changes to more open processing.

Often moving to another platform means changing data sources, which is discussed earlier under the heading Moving from Indexed Files to Relational Databases. This leaves three areas to be addressed:

• Command files

• 3GL code

• Operating systems

Migrating Command Files
A great deal of processing power is contained in operating system command files -- UDCs, DCLs, COM files, CLI files, and scripts. If you move to a different environment, especially a graphical one such as Windows, your command files cannot move forward. You must find an open solution.

The first thing to assess is whether your command files need to come forward at all. A quick review of an application may turn up hundreds of such files. However, a detailed examination may find that most of them address operating system requirements and are no longer needed for a Windows application. Almost all applications can leave some command files behind.

Command files that must come forward, especially when moving to UNIX systems, will require that a few changes be made repeatedly to each file. These can best be handled through editor scripts or utilities such as Perl. The key is to understand the changes and identify repetitive tasks. The 12-step IBM Cognos Axiant 4GL Planning Template should help you.

Migrating 3GL Code
Many IBM Cognos PowerHouse applications include some components developed in 3GLs such as COBOL, Fortran, or C. While IBM Cognos Axiant 4GL can bring forward IBM Cognos PowerHouse code, it cannot address programs written in other languages.

As with command files, the first thing to do is assess whether you really need to bring forward your 3GL programs. Often these programs are vestiges of older systems, never rewritten in IBM Cognos PowerHouse. (They weren't broken so they didn't need to be fixed.) You should consider abandoning these programs and rewriting them in IBM Cognos Axiant 4GL where possible. This will be the case for many COBOL programs.

Rewriting Fortran or C programs in IBM Cognos Axiant 4GL isn't recommended if they perform complex mathematical calculations. Instead, find a compiler for the new environment that will closely represent the old environment. You may be able to rewrite these programs in C++ in the Windows environment.

You should consider the interfaces between IBM Cognos Axiant 4GL and the 3GL programs. Changes in compilers or systems may have caused inconsistencies, such as word boundaries in passing lists. The online help in IBM Cognos Axiant 4GL and the documentation for the compiler should provide the details you need to decide how to handle 3GL programs.

Migrating Operating System Functions
Some of the greatest challenges may result from overlooked facilities of the original operating system. This can range from a message stating that a batch job has completed to complex functions such as mail systems. What can be worse is that the integration may not be designed into the system, but happen at the user level.

The solution to this problem depends on the client/server topology chosen. Server-based functionality need not change at all, while mobile solutions require complete replacement. The IBM Cognos Axiant 4GL Migration Planner suggests that you take inventory of all such facilities and decide whether to replace or integrate them.

Moving from Server-Centric to Distributed Applications
A move from server-centric to distributed applications is the fourth kind of migration you may be planning. Because a client/server application may require different machines to interact, consider new approaches to application design, deployment, and management. In particular, review the methods and policies used in your current server-centric environment for:

• Application and data security

• Backup, recovery, and data distribution

• Software update distribution

• User interface

• End-user support

• Capacity planning and performance management

Divide services and data management between client and server only after carefully considering the relative performance strengths of each.

Integrating IBM Cognos Axiant 4GL Applications with Complementary Software
Your migration plans should consider the software that must work with an IBM Cognos Axiant 4GL application. Identify each software component and determine its requirements. Then compare requirements to ensure that the various components will integrate successfully. Pay particular attention to:

• Client or server network protocols

• Client or server database application programming interfaces (APIs) or drivers (ODBC drivers or gateways)

• Adherence to company or application user interface standards

• License management

Application Design Considerations
Before you model the application architecture, you should consider the following questions:

• What are the key components from a performance point of view?

• What are their execution frequencies?

• How much data will be transmitted over a network?

• How much data must be replicated?

In many cases, both services and data management are best handled with a relational database, which can support complex processing in the data location through SQL, stored procedures, and trigger-based processing.

Change applications originally designed for non-relational data access to take advantage of the available client, server, network, and database resources.

IBM Cognos Axiant 4GL and IBM Cognos PowerHouse support a common SQL syntax based on industry-standard SQL (SQL92 Entry Level) for relational databases. Modules that are written using this SQL are highly portable across relational data sources. Through SQL,IBM Cognos Axiant 4GL applications are able to exploit the power of the data server.

Moving from File-Based to Graphical, Client/Server Development
Moving from file-based to graphical, client/server development is the fifth and last kind of migration. It is the one move that must by definition be part of any migration directly from IBM Cognos PowerHouse to IBM Cognos Axiant 4GL.

The following table compares the IBM Cognos PowerHouse and IBM Cognos Axiant 4GL development environments.

Attribute	IBM Cognos PowerHouse 4GL	IBM Cognos Axiant 4GL
Components	Files, editors, and file systems	Objects, workspaces, and repositories
Data Definitions	Dictionary	Respository
Default File System	Indexed	Relational
Program Creation	Syntax with default code	Wizards and inherited objects
Development	Edit syntax and compile files	Manipulate objects, define properties, code procedures, and build applications
Deployment	Move .q*c files to production location	Package an applet for multiple deployments Create an Install process for users.
Reuse	USE files and copy code	Inheritance and rules

Home | Legal Notices | Privacy Statement | Site Map
Performance Management | Business Intelligence | RSS Feeds

Copyright © 2008 Cognos ULC (formerly Cognos Inc.), an IBM Company. All rights reserved.

Cognos is a world leader in business intelligence, performance management, data integration, enterprise risk management, olap reporting, analytics software, bank branch profitability, retail performance management, supply chain visibility, customer profitability, Oracle business intelligence, and balanced scorecarding for the enterprise.