Ibm Cognos Application Development Tools Ibm Cogno Powerhouse 4Gl

IBM Cognos Application Development Tools
IBM Cogno PowerHouse 4GL
Version 8.4G for OpenVMS
Migration Planning Guide Migration Planning Guide
IBM Cognos PowerHouse

8.4
Type the text for the HTML TOC entry
IBM Cognos PowerHouse 4GL Migration
Planning Guide
Product Information
This document applies to IBM Cognos PowerHouse 4GL 8.40G and may also apply to subsequent releases. To check for newer versions of
this document, visit the IBM Cognos Information Centers (http://publib.boulder.ibm.com/infocenter/cogic/v1r0m0/index.jsp).
Copyright
Licensed Materials - Property of IBM
© Copyright IBM Corp. 1982, 2010.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
IBM, the IBM logo, ibm.com, Cognos, Axiant, and Powerhouse are trademarks or registered trademarks of International Business Machines
Corp., in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of
IBM trademarks is available on the Web at www.ibm.com/legal/copytrade.shtml.
Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or
both.
Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Table of Contents
About this Document 5

Overview 5
Getting Help 5
IBM Cognos PowerHouse 4GL Documentation Set 6
IBM Cognos PowerHouse Web Documentation Set 6
IBM Cognos Axiant 4GL Documentation Set 7
Chapter 1: Migration Choices 9
Key Migration Decisions 9
Choosing the Target Platform 9
Choosing the Target File Systems 10
Choosing the End-User UI 11
Choosing the Migration Method 11
Choosing the Migration Timing 12
Moving Forward 12
Chapter 2: The Target Platform: UNIX or Linux 13
Platform Differences 13
Directory Paths 13
File Names 13
Operating System Commands 14
System Management 16
PowerHouse 4GL Differences 17
Subfiles 17
Designated Files and Environment Variables 18
The Default Editor 18
Case Sensitivity 18
Interrupt Control 18
$POW 18
PHD and PDL 19
PDL 19
QSHOW 21
QUTIL 21
QDESIGN/QUICK 21
QTP 23
QUIZ 24
After the Migration 25
PDL 25
QDESIGN/QUICK 25
QKGO 25
QTP 25
QUIZ 26
Moving Forward 26
Chapter 3: The Target Platform: Windows 27
Platform Differences 27
Folder Separators 27
File Names 27
Operating System Commands 28
System Management 29
PowerHouse 4GL Differences 30

3
© Copyright IBM Corp. 1999, 2010
The Command Prompt Window 30
PowerHouse 4GL File Extensions 30
Paths in File Names 30
Subfiles 31
Designated Files and Environment Variables 31
The Default Editor 31
Interrupt Control 31
$POW 32
PHD and PDL 32
PDL 33
QSHOW 34
QUTIL 34
QDESIGN/QUICK 34
QTP 36
QUIZ 37
After the Migration 38
PDL 38
QDESIGN/QUICK 38
QKGO 38
QTP 39
QUIZ 39
Moving Forward 39
Chapter 4: The File Systems 41
Migrating from RMS ISAM 41
Indexed to Indexed 41
RMS ISAM to Relational 42
Migrating from RMS Files (Direct, Relative, Sequential) 48
Direct and Sequential Files 48
Relative Files 48
Mailbox Files (MBX) 49
Migrating from Relational 49
Datatype Mappings 50
Moving Forward 51
Chapter 5: The Migration Plan 53
The Twelve-Step Plan 53
Step 1: Define the Application 53
Step 2: Learn 53
Step 3: Take Inventory 54
Step 4: Identify What Will Be Migrated 54
Step 5: Develop a Plan 55
Step 6: Migrate The Pilot Application 55
Migrate with the Axiant 4GL Migration Tools 55
Migrate without the Axiant 4GL Migration Tools 58
Step 7: Assemble the Pilot Application 60
Step 8: Assess Steps 2 through 7 60
Step 9: Have Users Evaluate the Pilot 60
Step 10: Assess Steps 2 through 9 61
Step 11: Plan the Complete Migration 61
Step 12: Do the Complete Migration 61
In Conclusion 61
Index 63
4 IBM Cogno PowerHouse 4GL for OpenVMS

About this Document
Overview
® ® ®
This document describes how to plan your migration of IBM Cognos PowerHouse 4GL
® ® ® ®
applications from OpenVMS to a UNIX , Linux , or Microsoft Windows platform. It is
intended for system managers and developers who are familiar with the OpenVMS environment
and have a basic knowledge of UNIX, Linux, or Windows.
This document targets migrations from PowerHouse 4GL 8.40. If you are migrating from a prior
version, you may encounter additional issues due to version differences. We recommend that you
review these differences in the following documents:
• IBM Cognos PowerHouse 4GL Version 8.30 for OpenVMS Upgrade Guide
• IBM Cognos PowerHouse 4GL New Features
• IBM Cognos PowerHouse 4GL Release Notes
Unless otherwise indicated, where "Windows" appears in the documentation, it applies to the
Microsoft Windows operating systems. And unless otherwise indicated, where "relational
database" appears in the documentation, it refers to a relational database management system.
Chapter 1, "Migration Choices", gives an overview of the types of migration covered in this
guide. It also identifies the factors which will influence your choices for each type of migration.
Chapter 2, "The Target Platform: UNIX or Linux", discusses differences between OpenVMS and
UNIX or Linux that will have to be addressed during the migration.
Chapter 3, "The Target Platform: Windows", discusses differences between OpenVMS and
Windows that will have to be addressed during the migration.
Chapter 4, "The File Systems", contains a separate section for each of the OpenVMS file systems:
RMS ISAM (Indexed), relational, and RMS (Direct, Relative, Sequential). Each section lists the
target file systems available for the given source file system, and then discusses the work involved
in migrating between the two file systems.
Chapter 5, "The Migration Plan", describes the 12-step plan to perform the migration, including
everything from identifying training needs to editing data definitions. This is shown both with and
without the Axiant 4GL migration tools.
Getting Help
For more information about using this product or for technical assistance, go to
http://www.ibm.com/support. Under Choose support type, select Information Management, then
under Choose a product, select Cognos Application Development Tools. Under Cognos
Application Development Tools support, click Documentation.

5
About this Document
IBM Cognos PowerHouse 4GL Documentation Set

PowerHouse 4GL documentation, available on the IBM Cognos PowerHouse 4GL Books CD,
includes planning and configuration advice, detailed information about statements and
procedures, installation instructions, and last minute product information.
Objective Document
Install The IBM Cognos PowerHouse 4GL Getting Started document provides
PowerHouse 4GL step-by-step instructions on installing PowerHouse 4GL.
Review changes The IBM Cognos PowerHouse 4GL Release Notes document provides
and new features information on supported environments, changes, and new features for the
current version.
Get an The IBM Cognos PowerHouse 4GL Primer document provides an

introduction to overview of the PowerHouse language and a hands-on demonstration of
PowerHouse 4GL how to use PowerHouse.
Get detailed The IBM Cognos PowerHouse 4GL Reference documents provide detailed
reference information about the PowerHouse language and each PowerHouse
information for component.
PowerHouse 4GL The documents are
• IBM Cognos PowerHouse 4GL PowerHouse Rules
• IBM Cognos PowerHouse 4GL PDL and Utilities Reference
• IBM Cognos PowerHouse 4GL PHD Reference (OpenVMS)
• IBM Cognos PowerHouse 4GL PowerHouse and Relational Databases
• IBM Cognos PowerHouse 4GL QDESIGN Reference
• IBM Cognos PowerHouse 4GL QUIZ Reference
• IBM Cognos PowerHouse 4GL QTP Reference
IBM Cognos PowerHouse Web Documentation Set

PowerHouse Web documentation, available from the IBM Cognos PowerHouse Web
Administrator CD, includes planning and configuration advice, detailed information about
statements and procedures, installation instructions, and last minute product information.
Objective Document
Start using The IBM Cognos PowerHouse Web Planning and Configuration document
PowerHouse Web introduces PowerHouse Web, provides planning information and explains
how to configure the PowerHouse Web components.
Important: This document should be the starting point for all PowerHouse
Web users.
Install The IBM Cognos PowerHouse Web Getting Started document provides
PowerHouse Web step-by-step instructions on installing PowerHouse Web.
Review changes The IBM Cognos PowerHouse Web Release Notes document provides
current version.
Get detailed The IBM Cognos PowerHouse Web Developer’s Guide document provides
information for detailed reference material for application developers.
developing
PowerHouse Web
applications

About this Document
Objective Document
Administer The PowerHouse Web Administrator Online Help, available from within
PowerHouse Web the PowerHouse Web Administrator, provides detailed reference material to
help you during PowerHouse Web configuration.
IBM Cognos Axiant 4GL Documentation Set

®
Axiant 4GL documentation, available from the IBM Cognos Axiant 4GL CD, includes planning
and configuration advice, detailed information about statements and procedures, installation
instructions, and last minute product information.
Objective Document
Install Axiant 4GL The IBM Cognos Axiant 4GL Web Getting Started document provides
step-by-step instructions on installing Axiant 4GL.
Review changes The IBM Cognos Axiant 4GL Release Notes document provides
current version.
Get an The A Guided Tour of Axiant 4GL document contains hands-on tutorials
introduction to that introduce the Axiant 4GL migration process and screen customization.
Axiant 4GL
Get detailed The Axiant 4GL Online Help, available from within Axiant 4GL, provides
reference a detailed reference guide to Axiant 4GL.
information on
Axiant 4GL
Supported Environments
For the latest supported environments information, go to http://www.ibm.com/support. Under
Choose support type, select Information Management, then under Choose a product, select
Cognos Application Development Tools. Under Cognos Application Development Tools Support,
under Additional Support Links, click Cognos ADT Software Environments.
Migration Planning Guide 7

About this Document

Chapter 1: Migration Choices
This introductory chapter gives an overview of the types of migration covered in this guide.
Depending on your application, you may be able to make your migration choices directly from
this top-level chapter, or you may need to go into the detail chapters to aid in the decisions. In
either case, you can use the detail chapters that follow to understand and estimate the scope of
work involved in the migration.
Key Migration Decisions

The key decisions to make in planning your migration from OpenVMS are the following:
❑ What is the target platform?
• UNIX or Linux
• Windows
❑ What are the target file systems?
• relational
• indexed
• direct or sequential
❑ What is the end-user UI?
• Terminal (UNIX or Linux) or Command Prompt window (Windows)
• QKView (Windows)
• Windows GUI (using IBM Cognos Axiant 4GL)
• Web browser (using IBM Cognos PowerHouse Web)
❑ What is the migration method?
• using Axiant 4GL migration tools
• using editors and UNIX or Linux scripts
❑ What is the migration timing?
• concurrent (doing all of the above migrations at the same time)
• sequential
Choosing the Target Platform

To choose between UNIX, Linux, and Windows, look at the following:
• Scale of the application
Small to medium sized applications (generally those that are for the workgroup or
department) can run on either UNIX, Linux, or Windows, but medium to large sized
applications (departmental or enterprise) are best suited to larger UNIX environments.
• Cost vs. performance
Hardware, software, and services may cost less in a Linux or Windows environment.
However stronger UNIX machines may offer better response times.
• Platform knowledge
Are there other applications currently running (or planned) on either platform? Is there a
company or department standard? Does your IT department have experience with either
platform? This also affects the time it takes to migrate.
• File system

9
Have you already decided on a file system which is only present on one of the platforms?
(Note that a relational database does not have to be on the same platform that is running
your PowerHouse 4GL application. For example, an application on Windows can use
Oracle on UNIX.)
• End-user UI
Have you already decided on using the Windows GUI (using Axiant 4GL)? This only runs
on Windows (although the server could be on UNIX in a thin-client setup).
For detailed information on differences in PowerHouse 4GL between OpenVMS and UNIX or
Linux, see (p. 13).
For detailed information on differences in PowerHouse 4GL between OpenVMS and Windows,
see (p. 27).
Choosing the Target File Systems

The file systems that you migrate to will depend on the file systems you are currently using. Decide
first on the file system type (relational or indexed). You can then decide on the specific file system
within the chosen type. Factors affecting this decision are
• knowledge
Does your IT department have experience with one of the file systems? Are there other
applications currently running (or planned) on one of the file systems?
• simplicity
The migration process is simplest (and fastest) if you keep to the same file system type that
you have in your OpenVMS application. Your dictionary and programs will require minimal
changes, and your users will observe a minimum of behavior differences.
File System Simplest Migration Other Options

Relational Relational
RMS ISAM Indexed Relational

(Indexed)
RMS (Direct, Direct, Sequential

Sequential)
RMS (Relative) Indexed (Relative is not

available on UNIX,
Linux, or
Windows)
• cost and availability

These are important factors to consider, but are outside the scope of this guide.
• performance
Indexed files may be fastest for simple control file applications. Relational databases can be
even faster if you modify your application to use cursors. (Cursors process large sets of data at
a time. The trade-off is that this requires application changes.)
• functionality
Relational databases offer the greatest functionality. They have many automated features,
such as query optimization and database integrity processing. They also offer many
administration features to simplify maintenance.
• scale
Relational databases are the most adept at handling large amounts of data.
Keep in mind that the file systems do not have to be on the same machine, or even platform, as the
one your application is moving to. For example, your UNIX or Linux application could use
DataDirect ODBC to access an Microsoft SQL Server database on Windows.
For information on differences between the various source and target file systems, see "The File
Systems" (p. 41).

Choosing the End-User UI

The choices for an end-user interface are terminal, Web browser (using PowerHouse Web), and
Windows GUI (using Axiant 4GL). Factors affecting this decision are
• User knowledge: a terminal-style interface may be the best choice to minimize change for
existing users who use a terminal interface already. The QKView interface is also a
terminal-style interface, although it appears more GUI like. If you anticipate many new users,
a Web or Windows interface may be more intuitive and thus simplify training.
• developer knowledge
The developers writing applications with Axiant 4GL have to know Axiant 4GL’s
object-based environment. Similarly, the developers writing applications with PowerHouse
Web have to know some HTML.
• platform
A Windows GUI (graphic user interface) is only available if you are using Axiant 4GL, either
in fat-client mode on Windows or in thin-client mode with the server on UNIX, Linux, or
Windows.
• company needs, user needs, company standards, and cost
These are important factors to consider, but are outside the scope of this guide.
This planning guide does not cover this topic in further detail, since we do not recommend
changing the end-user UI at the same time as changing the platform and file system. (See
"Choosing the Migration Timing" (p. 12).) For further information on Axiant 4GL and
PowerHouse Web, see the IBM Cognos PowerHouse 4GL (p. 7), IBM Cognos PowerHouse Web
4GL (p. 6), and IBM Cognos Axiant 4GL (p. 7) documentation sets.
Choosing the Migration Method

You can choose to use Axiant 4GL's migration tools to assist the migration, even if you are not
migrating to Windows or an Axiant 4GL end-user UI. These tools include the following:
• a Migration Profile wizard to migrate subsets of the application
• a tool to convert between source and target file systems (for example, from RMS ISAM to
Oracle) and identify definitions requiring change (for example, coded records)
• a tool to identify program code requiring change as a result of the platform or file system
change, and another tool to make many of these changes automatically.
The alternative is to do the migration without Axiant 4GL, which can have both advantages and
disadvantages. Factors affecting this decision include the following:
• developer knowledge
If your developers already know Axiant 4GL, then the migration process with Axiant 4GL
requires less training.
• application scale
With large applications, the time invested in setting up Axiant 4GL as an intermediary process
can be recovered by the automated changes.
• target file system
If the source and target file systems are similar (for example, going from Oracle Rdb to
Oracle), then there would be less reason to use Axiant 4GL.
• target platform
If you are migrating to UNIX or Linux, IBM provides several command scripts to do the same
actions as some of the Axiant 4GL migration tools.
• target UI
If you are migrating to a Windows GUI (using Axiant 4GL), the Axiant 4GL migration tools
have the added benefit of creating the Axiant 4GL objects for your application.
• conditional compiles
If your applications require conditional compiles, using Axiant 4GL might complicate the
migration. The conditional compiles would have to be removed before the migration and
added back in after the migration was complete.
For information on planning a migration, both with and without the Axiant 4GL migration tools,
see "The Migration Plan" (p. 53).

Choosing the Migration Timing

When you plan any operation with multiple changes, the cleanest process is usually to make one
change at a time. This allows focus and fast identification of any unexpected issues that arise. For
example, if you have multiple PowerHouse 4GL applications that are independent, you should
migrate each one separately.
When you migrate a PowerHouse 4GL application, the three possible migration types are to
another platform, to another file system, and to another UI. Each of these migrations should also
occur separately.
You can migrate to the terminal UI on all platforms for all file systems. We recommend that you
postpone migration from one UI to another until after the platform and file system migrations
have been completed. This guide focuses on platform and file system migrations. For further
information on choosing an end-user UI, see the Axiant 4GL and PowerHouse Web
documentation sets.
The decision on whether to integrate the platform and file system migrations depends on costs,
time pressures, and whether the two migrations are tied to one another. Consider the following
scenarios.
Scenario A: Keeping the Same File System Type

This is the situation where you migrate to the file system recommended in the ’Simplest Migration’
column of the table on (p. 10). An example is migrating from RMS ISAM to Indexed. You
essentially only have one migration, the platform move.
Scenario B: Changing File System Types

An example of this situation would be RMS ISAM to relational.
The ideal process would be to isolate the two migrations. If your source file system is RMS and
your target file system is relational, you can first migrate to the target platform using an indexed
file system, then migrate from indexed to relational. Or you could migrate to relational on
OpenVMS and then migrate to the target platform.
The most common reasons for not following this approach are license costs, time pressures, and
company standards.
Scenario C: Merging File Systems

Every file system has its own issues to adapt to. If you have both RMS ISAM and relational in
your OpenVMS application, you may consider merging them all to one file system before
migrating to the new platform.
For example, suppose you have both RMS ISAM and Oracle on OpenVMS. If your target file
system is Oracle, you may want to move the RMS files to Oracle while still on OpenVMS, then do
a relational-to-relational migration across platforms. This simplifies the combined
platform-and-file-system migration. However, it adds to the migration time and costs. For these
reasons, this scenario is rare.
Moving Forward
"The Target Platform: UNIX or Linux" (p. 13) describes the changes you may have to make in
your PowerHouse 4GL application when moving to UNIX or Linux.
"The Target Platform: Windows" (p. 27) describes the changes you may have to make in your
PowerHouse 4GL application when moving to Windows.
"The File Systems" (p. 41) describes the changes you may have to make in your PowerHouse 4GL
application when changing to the various file systems on UNIX, Linux, or Windows.
"The Migration Plan" (p. 53) describes the 12-step plan to actually perform the migration. This
identifies everything from identifying training needs to editing data definitions.

Chapter 2: The Target Platform: UNIX or Linux
This chapter identifies the differences between the OpenVMS and UNIX and Linux platforms that
have to be addressed during the migration of a PowerHouse 4GL application. It also identifies the
differences within PowerHouse 4GL between the two platforms.
For information on differences specifically due to a change in file systems, see "The File
Systems" (p. 41).
Many of the differences between platforms require changes to file names as part of the migration.
The Axiant 4GL migration tools can perform many of these changes automatically. For
information on this and other aspects of actually moving your application from OpenVMS to
UNIX or Linux, see "The Migration Plan" (p. 53).
The command interface on UNIX and Linux is known as a shell. Two of the most popular shells
are the Bourne Shell (of which the Korn Shell is a superset) and the C Shell. PowerHouse 4GL
works equally under either shell. The only difference is that you use different shell commands
within your command scripts (which replace DCL command files), depending on the shell you are
running under.
Platform Differences
Directory Paths
UNIX and Linux use directories (folders) similar to OpenVMS, with the following differences:
• Directories are separated by forward slashes:
[USER1.REPORTS.SOURCE] becomes /user1/reports/source/
• The syntax for device names is the same as for directories and files:
DISK1:[USER1]REPORT.QZS becomes /disk1/user1/report.qzs
File Names
Case Sensitivity
Unlike OpenVMS, the UNIX and Linux operating systems differentiate between lowercase and
uppercase. Therefore any references to physical file names within your dictionary, source code,
and command files must be consistent with the physical file name.
For example, the file names MYFILE.qks, Myfile.qks and myfile.qks do not refer to the same
physical file under UNIX and Linux.
The UNIX and Linux standard is for all names to be lowercase. We recommend that you
eventually follow this practice, renaming your files to lowercase. However, you may wish to do
this at some future time, after your migration is successful. This reduces the number of
mismatches by accidentally referencing a file with the incorrect case.
Tip: Since UNIX and Linux operating system commands are generally in lowercase, most work on
UNIX and Linux is done with the keyboard Caps Lock key turned off.
For information on how case sensitivity affects PowerHouse 4GL, see (p. 18).
Periods in File Names

Like on OpenVMS, UNIX and Linux file names consist of letters, numbers, hyphens, and
underscores, so there are no issues in porting these to UNIX or Linux. UNIX and Linux also
support multiple periods in a file name (for example, billings.dev.qks or billings.prod.qks).

13
UNIX and Linux File Extensions

Like OpenVMS, UNIX and Linux use file extensions to identify file types (such as nightrun.qts or
nightrun.qtc). These are generally three characters long but not necessarily so. There are some
exceptions, such as scripts, the UNIX and Linux equivalent of command files, which usually have
no extensions.
For more information, see "PowerHouse 4GL File Extensions" (p. 17).
Length
OpenVMS file names are generally restricted to 78 characters in length, depending on the disk
type. All versions of UNIX and Linux allow more than that, usually 128 or 255, so you do not
have to shorten any file names.
Similarly, OpenVMS path names (for example, [NIGHTRUN.SALES.CORPORATE]) are
restricted to 78 characters in length, whereas UNIX and Linux path names allow up to 1023
characters.
Logical Names
OpenVMS applications, including PowerHouse 4GL, make frequent use of logical names to point
applications to files of different names or locations without editing the application. Environment
variables are the equivalent on UNIX and Linux.
You need to define these environment variables to match your OpenVMS equivalents, usually
defined within command files. For information on converting command files, see "Operating
System Commands" (p. 14).
For information on the command files for PowerHouse 4GL designated files (such as the default
PowerHouse 4GL resource file), see "Designated Files and Environment Variables" (p. 18).
Operating System Commands

OpenVMS OS commands can be found in DCL command files that you execute
• outside PowerHouse 4GL
• from within QDESIGN COMMAND statements and RUN COMMAND verbs
• in QTP and QUIZ programs using SET JOB (prefixed with $ or $$)
A great deal of processing power is contained in operating system command files. You must
translate all command files you have created into UNIX or Linux scripts. Individual OS
commands also have to be translated. (PowerHouse 4GL command files provided by IBM already
have the equivalent scripts provided on UNIX and Linux.)
If you have a large quantity of command files, an alternative is to purchase a third party
OpenVMS emulator on UNIX or Linux.
Before translating command files, you should assess whether they need to come forward at all. A a
detailed examination may find that many of them address OpenVMS requirements that are no
longer applicable in a UNIX or Linux environment.
Command files that must come forward require that a few changes be made repeatedly to each
file. This can best be handled through editor scripts (on either platform) or through UNIX and
Linux utilities such as PERL. The key is to understand the changes and identify repetitive tasks.
For more information, see "The Migration Plan" (p. 53).
Some Common Commands
Task OpenVMS UNIX, Linux

Shorten command names using an alias command files alias
Change working area SET DEFAULT cd

Task OpenVMS UNIX, Linux

Copy files COPY cp
Display all or part of text files TYPE cat, more,

tail
Determine disk usage DIRECTORY /FULL du

/TOTAL
Search for text patterns in a file SEARCH grep, egrep,

fgrep
Terminate a process or job that is running STOP /ID, kill

DELETE /ENTRY
Rename files RENAME mv
Display current working directory SHOW DEFAULT pwd
Delete files DELETE rm
Delete directories DELETE rmdir
Shorten file names using a logical name or ASSIGN, DEFINE, setenv, =

symbol :==
Sort information, merge files SORT, MERGE sort
Edit text or program files EDIT/EDT vi, ed, ex
Display a list of who is logged on the system SHOW USERS who
Run an executable RUN FILE1.EXE file1
Submit a batch job at a later time SUBMIT at
Example: Logical Names

Logical names are commonly used in OpenVMS PowerHouse 4GL applications to avoid
hard-coding specific directory paths. This makes the application more portable.
The UNIX and Linux equivalent is an environment variable, defined with the setenv command.
For example,
DEFINE PAY [ARCHIVE.PAY]
would be replaced with
setenv PAY /archive/pay
Example: A Batch Job
An OpenVMS DCL Command File, The UNIX and Linux Equivalent,

QUIZRUN01.COM quizrun01
$QUIZ quiz <<eof
ACCESS EMPLOYEES ACCESS EMPLOYEES
CHOOSE EMPLOYEE PARM CHOOSE EMPLOYEE PARM
REPORT ALL REPORT ALL
GO GO
1 1
2 2
EXIT EXIT
eof

An OpenVMS DCL Command File, The UNIX and Linux Equivalent,

QUIZRUN01.COM quizrun01
To execute: To execute:
SUBMIT QUIZRUN01.COM batch quizrun01
In the UNIX and Linux script, <<eof redirects the command input to the rest of the script until
encountering the eof string.
Path
On UNIX and Linux, an environment variable named "path" indicates which directories should
be searched through when the user (or a program) invokes the name of a command file.
OpenVMS has no equivalent to this variable (although you can set up a search path using a logical
name).
Be sure to modify the path variable for your user accounts to point to the directories containing
your command files. For example, set path = ($path /mgr_scripts/) if you are using the
Bourne shell, or setenv PATH $PATH:/mgr_scripts/ if you are using the C shell.
System Management
The change in platforms also means changes in application management. In particular, review the
methods and policies currently used for the following:
• application and data security
• backup, recovery, and data distribution
• software update distribution
• user interface
• end-user support
• capacity planning and performance management
File Versioning
UNIX and Linux do not support automatic multi-versioning of files (filename1.qks;3). All
applications that rely on access to previous versions of files should be reviewed and revised to
make copies of files before changing or to prevent changing them through file access control.
This will also result in different prompts appearing when you build or save a program file. Instead
of being asked to create a new version of a file, you are asked if you want the old one deleted.
Consider the example of CREATE DICTIONARY in PDL:
• OpenVMS (PDL): The file (name) already exists. Create new one? [Y/N]
OpenVMS (PHDPDL): Dictionary (name) already exists. Create a new version? [Y/N]
• UNIX and Linux: The file (name) already exists. Is it OK to delete? [Y/N]
File Access Control

The simplest level of application and data security is the UNIX and Linux file access control, very
similar to OpenVMS UIC protection.
• Every user on a Unix or Linux system has a unique username, and is a member of at least one
group.
• UNIX and Linux directories have access control properties that determine who can read,
write, or execute the files within them. Each file similarly has access control properties
determining read, write, and execute privileges.
• For both directories and files, you can control access at three levels: what your privileges as
the file owner are, what other members of your group can do, and what others outside your
group (’the world’) can do. There is no System (S) equivalent.
You can map your OpenVMS file access control directly to the UNIX or Linux equivalent (for
example, OpenVMS group access to UNIX group access). For information on how the different
file access control maps to PowerHouse 4GL syntax, see (p. 20).

PowerHouse 4GL Differences

This discussion identifies differences between PowerHouse 4GL on OpenVMS and PowerHouse
4GL on UNIX and Linux, with the exception of differences relating to the file systems.
For information on differences due to a change in file systems, see "The File Systems" (p. 41).
Note: Many of the differences between platforms require changes to file names as part of the
migration. The Axiant 4GL migration tools can perform many of these changes automatically. For
information on this and other aspects of moving your application from OpenVMS to UNIX or
Linux, see "The Migration Plan" (p. 53).
PowerHouse 4GL File Extensions

Like OpenVMS, UNIX and Linux use file extensions (such as nightrun.qts vs. nightrun.qtc).
These are generally three characters long but not necessarily so. There are some exceptions (such
as scripts, the UNIX and Linux equivalent of command files, which have no extensions as a
general rule).
PowerHouse 4GL file extensions are the same on UNIX and Linux as on OpenVMS, except for
being in lowercase. For example, the PDL dictionary source has an extension of .pdl and the
compiled dictionary is .pdc. For a complete list of designated files and their names, see the IBM
Cognos PowerHouse 4GL PowerHouse Rules document.
For information on the timing and methods for renaming your files, see "The Migration
Plan" (p. 53).
We recommend that you change all PowerHouse 4GL program calls to include the file extension.
Consider the following example: the following command looks for NITERUN.qts first and then,
if it cannot find it, NITERUN.qtc:
RUN COMMAND "qtp AUTO=NITERUN"
Running the source file can reduce performance, and it can cause errors if the source file does not
include a GO. It may also display your source code (if you omit NOLIST). If your intent was to run
the compiled program, change the call to
RUN COMMAND "qtp AUTO=NITERUN.qtc"
Subfiles
On UNIX and Linux, as on OpenVMS, the dictionary information for a subfile is stored in a
separate file from the data. Thus each name.sf has a corresponding name.sfd. The same is true for
portable subfiles, name.ps and name.psd. Portable subfiles have their data written in an ASCII
format, which facilitates porting them between platforms.
When moving portable subfiles from OpenVMS to UNIX or Linux, you must ensure that the tool
transferring the files (such as FTP) does not insert a linefeed character at the end of each record.
Subfile Locations
On OpenVMS, temporary subfiles are held in the SYS$SCRATCH directory (unless given a path
in the code). On UNIX or Linux, starting a PowerHouse 4GL component session creates a
temporary directory, phnnnn.tmp, to hold temporary subfiles and files. This directory is deleted
when the PowerHouse 4GL component session ends. This directory is unique for each logon
session, so two users running the same multi-pass report or multi-pass run do not read each
other’s temporary subfiles.
As on OpenVMS, temporary subfiles on UNIX and Linux are no longer available when you exit
the component. So an application that writes a temporary subfile in QTP then exits QTP and tries
to read that subfile in QUIZ does not work on either system.
As of version 8.43E for UNIX and Linux, you can tell QUIZ and QTP to retain temporary subfiles
by using the PHTEMPKEEP environment variable with the PHTEMP environment variable. If
PHTEMPKEEP is set, temporary subfiles are created in the location specified by the PHTEMP
environment variable so they are readily available for subsequent compilation passes. If you set
PHTEMPKEEP, you should delete the temporary subfiles when they are no longer required.

Designated Files and Environment Variables

Designated files are reserved for use as PowerHouse 4GL default files. Some of these names are
reserved for use as logical names (OpenVMS) or environment variables (UNIX, Linux) by
PowerHouse 4GL.
On UNIX and Linux, as on OpenVMS, PowerHouse 4GL also locates designated files by
searching for certain file extensions. For example, when you use the SAVE statement in QTP,
PowerHouse 4GL creates a file containing the source code in the current directory and appends
the file extension .qts to the filename. When PowerHouse 4GL searches for the file, it first
searches for a filename that has the extension .qts appended.
For a list of PowerHouse 4GL designated files, their file extensions, and their environment
variables, see the IBM Cognos PowerHouse 4GL PowerHouse Rules document.
The Default Editor

As on OpenVMS, the default editor used by a REVISE statement can be specified by the PHEDIT
environment variable. This defaults to the vi editor on UNIX and Linux.
Case Sensitivity
As mentioned on (p. 13), the UNIX and Linux operating systems differentiate between lowercase
and uppercase, so any references to physical file names within your dictionary, source code, and
command files must be consistent with the physical file name. In particular, note that PowerHouse
4GL executables and file extensions must be in lowercase.
For example,
RUN COMMAND "QTP AUTO=NITERUN.QTC"
must become
RUN COMMAND "qtp auto=NITERUN.qtc"
Or you can downshift the complete name:
RUN COMMAND "qtp auto=<path>/niterun.qtc"
The SYSTEM OPTIONS SHIFT as well as the SET <shift options> apply to relational columns
and tables but not physical file names. So the QDESIGN code, "SCREEN Test", results in a
mixed-case file named Test.qkc on UNIX or Linux.
Interrupt Control
The user can interrupt prompting within PowerHouse 4GL components by pressing the interrupt
keystroke in response to a prompt. On OpenVMS this can be Ctrl-C or Ctrl-Y; on UNIX and
Linux this is commonly Ctrl-C.
$POW
PowerHouse 4GL on UNIX and Linux does not use the POW(ERHOUSE) menu system as on
OpenVMS. The various PowerHouse 4GL components and utilities are run directly from OS
commands (as they can be on OpenVMS as well). The following table identifies the UNIX or
Linux OS commands equivalent to the POW Menu options:
Management Menu UNIX or Linux Command

01 Maintain PowerHouse Dictionary pdl
02 Report dictionary contents qshow

Environment Menu UNIX or Linux Command

10 Assign QUICK parameter file setenv qkgo file.qkg
11 Maintain QUICK parameter files qkgo
Development Tools Menu UNIX or Linux Command

20 Design QUICK screens qdesign
21 Run QUICK screens quick
22 Write QUIZ reports quiz
23 Perform QTP processing qtp
Utilities Menu UNIX or Linux Command

30 Edit a file vi
31 Use Mail mail
PHD and PDL

PowerHouse 4GL on OpenVMS supports two forms of dictionaries:
• A PDL dictionary, filename.PDC, is created by compiling a source file, filename.PDL, which
defines the dictionary objects.
• A PHD dictionary consists of four physical files: PHD00.PHD through PHD03.PHD. It can
be populated with dictionary definitions through two user interfaces:
• the PHD screen system (’01 Maintain PowerHouse Dictionary’ from the main menu of
POW, which takes you to the Dictionary Management menu)
• PHDPDL (a version of PDL which populates the four PHDnn.PHD files, rather than
filename.PDC)
PowerHouse 4GL on UNIX and Linux only supports the PDL dictionary format. It does not use
the PHD dictionary or its corresponding Dictionary Management menu system. You need to
convert your dictionary definitions to PDL, if you have not already done so. However this is a
required step of any platform migration. For more information, see "Step 6: Migrate The Pilot
Application" (p. 55).
The four PHD dictionary files on OpenVMS can be maintained by the PHDMAINT menu system.
PHDMAINT is not available on UNIX or Linux. With just a single dictionary file, filename.pdc,
dictionary maintenance on UNIX and Linux is command-line driven instead, using common OS
commands like cp (copy) and rn (rename).
For run-time environments on OpenVMS that could not use the PHD screen system, PHDADMIN
is a screen system for administrative functions like application and dictionary security changes.
PHDADMIN is not available on UNIX or Linux, as these functions can be achieved through edits
of the PDL source file.
PDL
OpenVMS, UNIX, and Linux support the full PDL syntax, so the only issues to be aware of are
platform differences.

Application Security Classes

The APPLICATION SECURITY CLASS and ASC statements on OpenVMS assign security with
any of the following methods: LOGONID, PASSWORD, PORTID, UIC or WEBLOGONID. On
UNIX and Linux, only the LOGONID (as of version 8.43E), UIC, and WEBLOGONID methods
are supported. This also applies to the APPLICATION SECURITY ID METHOD option of the
SYSTEM OPTIONS statement.
The Enhanced Application Security feature of PowerHouse 4GL on OpenVMS relates specifically
to OpenVMS security. There is no equivalent on UNIX or Linux.
Dictionary Security Classes

PowerHouse 4GL on UNIX and Linux does not use PHD (POW), and hence has no dictionary
security classes. The DICTIONARY SECURITY CLASS and DSC statements are only valid on
OpenVMS. This also applies to the DICTIONARY OWNER, DICTIONARY SECURITY ID
METHOD, and DSC ID METHOD options of the SYSTEM OPTIONS statement.
On UNIX and Linux, you make your dictionary secure through standard file security on the .pdl
and .pdc files.
Execution Time Parameters

PowerHouse 4GL on UNIX and Linux does not use execution time parameters (ETPs). The
EXECUTION TIME PARAMETER statement and the USER MODE statements are only valid on
OpenVMS.
FILE
The following FILE statement options are OpenVMS-specific. They can be dropped without
replacement, as they have no UNIX or Linux equivalents:
CAPACITY
RECORD FORMAT
SCOPE
SUPERSEDE
INDEX
The NULL option of the INDEX statement is only valid on OpenVMS. It is not needed or
available on UNIX or Linux.
Item Datatypes
The Item datatypes G_FLOAT and VMSDATE are only valid on OpenVMS. They can be found in
ITEM statements as well as ELEMENT x DEFAULT ITEM DATATYPE statements and USAGE
statements. On UNIX and Linux, use FLOAT SIZE 8 and DATETIME.
Be aware that you may face a loss of data when migrating any floating point numbers from one
platform to another. This is due to a loss of precision or significance; for example, 0.20 may be
stored as 0.199999....
For more information on floating point data loss, see the IBM Cognos PowerHouse 4GL
PowerHouse Rules document.
SET PRINT|NOPRINT
This option is only valid in PHDPDL. It has no equivalent on UNIX or Linux.
SYSTEM OPTIONS PATTERN ... RESERVE CHARACTERS [string]

The Reserve Characters string for PHD is six characters long ( []:=;& ). For PDL on all platforms,
including UNIX and Linux, it is seven characters long ( []:=;_& ).

QSHOW
SET GENERATE DEVICE
SET GENERATE DEVICE (for terminal, printer, or disc) is only valid on OpenVMS. On UNIX
and Linux, as on OpenVMS, the default for a GENERATE command is to write PDL to
qshogen.pdl.
SET REPORT DEVICE PRINTER

SET REPORT DEVICE PRINTER on OpenVMS allows the following options:
IDENTIFY|NOIDENTIFY
LOWERCASE|NOLOWERCASE
NOCHARACTERISTIC|CHARACTERISTIC
NOTE
NOTIFY|NONOTIFY
OPERATOR|NOOPERATOR
PRIORITY
QUEUE
RESTART|NORESTART
TRAILER|NOTRAILER
As these are OpenVMS specific, they do not exist on UNIX or Linux. The only SET REPORT
DEVICE PRINTER option on UNIX and Linux is the name of the printer string.
QUTIL
SET FDL|NOFDL
FDL files do not exist on UNIX or Linux, so this command is not valid.
QDESIGN/QUICK
Program Parameters
The following program parameters exist on OpenVMS but not on UNIX or Linux. They can be
dropped without replacement, as they have no UNIX or Linux equivalents.
BROADCAST
DCL|NODCL
DICTTYPE
DIRECT_FILE_BASE_ZERO
FASTREAD
FDL|NOFDL
INTSIZE6|NOINTSIZE6
NOUICBRACKETS
TERMPOLL|NOTERMPOLL
TRUSTED|NOTRUSTED
VMSDATE
DO EXTERNAL
Your application system may use 3GL programs (such as COBOL, Fortran, or C) either at the OS
level or from within PowerHouse 4GL DO EXTERNAL calls. As with command files, the first
thing to do is assess whether you really need to bring these forward. They may be vestiges of older
systems, no longer needed.
Rewriting 3GL programs in PowerHouse 4GL code is not recommended, especially if they
perform complex mathematical calculations. Instead, find a compiler for the new UNIX or Linux
environment. If you cannot find a compiler, consider rewriting the programs in C or C++.

You can remove the DESCRIPTOR option from your DO EXTERNAL calls on UNIX or Linux,
because it is OpenVMS-specific. All other DO EXTERNAL parameters are identical between
OpenVMS, UNIX, and Linux. However, they can hold different values and have different limits,
due to platform differences. For more information, see the IBM Cognos PowerHouse 4GL
QDESIGN Reference.
The UNIX and Linux equivalent to the OpenVMS BUILDEXTERNAL command procedure is a
script named BuildExternal. For more information, see the IBM Cognos PowerHouse 4GL
QDESIGN Reference.
3GL Locking
3GL programs on OpenVMS are able to bypass PowerHouse 4GL file level locking. This is
because PowerHouse 4GL components follow the cooperative locking strategy of the OpenVMS
Distributed Lock Manager (DLM), but 3GL programs you code yourself may not. PowerHouse
4GL on OpenVMS provides its own 3GL routines you can use to ensure cooperative locking.
UNIX and Linux locking is absolute rather than cooperative. Therefore the 3GL routines
provided for PowerHouse 4GL on OpenVMS are not needed on UNIX or Linux.
QKGO
To start QKGO on UNIX and Linux, enter the qkgo command. On OpenVMS, you may have
done this through the qkgomaint command or the PHD Screens.
If terminal (TIC) information is specified in QKGO, OpenVMS creates a context-binding file (for
example, FILENAMEB.DAT) and a key sequence file (for example, FILENAMEK.DAT) and one
or more terminal-group files (for example, FILENAMET.DAT). On UNIX and Linux, two files are
created for all three of these cases: filenameb.dat and filenameb.idx, filenamek.dat and
filenamek.idx, and filenamet.dat and filenamet.idx. PowerHouse 4GL must be licensed for
C-ISAM data access to do this.
On UNIX and Linux, the QKGO environment variable provides the same functionality as the
First screen field in the Construction and Maintenance Screen. This is equivalent to the QKGO
logical name on OpenVMS.
Similarly, on UNIX and Linux, the PHD environment variable provides the same functionality as
the Dictionary File field in the Construction and Maintenance Screen. This is equivalent to the
SETDICT OS command on OpenVMS.
PowerHouse 4GL on OpenVMS, UNIX, and Linux employs deadlock protection to avoid a
’deadly embrace’ between two processes attempting to lock the same file. However the manner in
which they do so is different. On OpenVMS, this is affected by QKGO parameters LOCK MESSAGE
WAIT and LOCK REQUEST WAIT. On UNIX and Linux, this is affected by QKGO parameters
LOCK ATTEMPTS, LOCK RETRY INTERVAL, and LOCK UNCONDITIONAL. For further information,
see the IBM Cognos PowerHouse 4GL QDESIGN Reference.
The following Execution Time Parameters exist on OpenVMS but not on UNIX or Linux. They
can be dropped without replacement, as they have no UNIX or Linux equivalents.
DRIVER
LOCK MESSAGE WAIT
LOCK REQUEST WAIT
MAX. PAGED MEMORY
SCREEN SECTION
SECONDARY BLOCKS
SELECTION SIZE
The Execution Time Parameter Field terminators controls data input. The default on
OpenVMS is F (full field), and the default on UNIX and Linux is M (manual).
Dynamic Function Keys are terminal specific rather than platform specific. On OpenVMS, DFK1
through DFK4 are mapped by default to GOLD1 through GOLD4. You maintain this mapping
on UNIX and Linux if you use a VT terminal (or terminal emulator).
The Color Display Attributes screen is only available on OpenVMS.
Editing a QUICK Initialization File (.QKI) is an alternative to using the QKGO screen system. If
you have a .QKI file on OpenVMS, it can be ported to UNIX or Linux as a text file. PowerHouse
4GL on UNIX and Linux ignores any OpenVMS specific parameters.

QTP
OpenVMS Syntax
The following statement options are OpenVMS-specific, and are not supported on UNIX or
Linux:
CHOOSE... SYSTEMVALUE [LOGICAL|SYMBOL]
SET DICTIONARY [TYPE PHD|PDC]
SET FILE ... SEMIEXCLUSIVE
SET FILE SIGNAL|NOSIGNAL [ON CLOSE]
SET FILE WAIT|NOWAIT [ON SEND|RECEIVE|FULL]
SORT ON ... RETAIN ORDER
SET JOB
On OpenVMS, operating system commands prefixed with a dollar sign ($) execute immediately.
Operating system commands prefixed with two dollar signs ($$) are not executed immediately but
are written to QTPSAVE.
On UNIX and Linux, operating system commands prefixed with a single exclamation mark (!)
suspend the current process, and execute the Shell command. Operating system commands
prefixed by two exclamation marks (!!) write the Shell command to the currently active save file
with one exclamation mark. For examples, see the IBM Cognos PowerHouse 4GL QTP
Reference.
All SET JOB options are OpenVMS-specific and are not supported on UNIX or Linux. They are:
AFTER [absolute-time][+|- delta-time]
[NO]CHARACTERISTICS number|string[[,]number|string]...
CPUTIME n
HOLD|NOHOLD
IDENTIFY|NOIDENTIFY
KEEP|NOKEEP
LOGFILE [name]|NOLOGFILE
NAME filespec
NOTIFY|NONOTIFY
PARAMETERS string [,string]...
PRINTER name|NOPRINTER
PRIORITY n
QUEUE queuename
RESTART|NORESTART
USER username
WSDEFAULT n
WSEXTENT n
WSQUOTA n
Subfiles
Indexed subfiles require that PowerHouse 4GL be licensed for C-ISAM data access.
As discussed in Chapter 4, First Record, Direct Files, direct files begin with record 1 on OpenVMS
but with record 0 on UNIX and Linux. Since subfiles are direct files, ACCESS ... LINK TO
RECORD n of *subfile1 becomes ACCESS ... LINK TO RECORD n-1 of *subfile1.
On OpenVMS, SUBFILE ... FORMAT permits values of 4|7|8, whereas valid values on UNIX and
Linux are 3|5|6|7|8. Since you are migrating to a new platform and format, you should remove the
FORMAT parameter.
Default Printer
On OpenVMS, the default printer is SYSPRINT or SYS$PRINT. On UNIX and Linux, the default
printer is obtained from the value of the environment variable, PH_PRINTER. If this variable is
not set, the system default printer is used.

QUIZ
OpenVMS Syntax
The following statement options are OpenVMS-specific, and are not supported on UNIX or
Linux:
SET JOB
are written to QUIZSAVE.
On UNIX and Linux, operating system commands prefixed with a single exclamation mark (!)
suspend the current process, and execute the Shell command. Operating system commands
prefixed by two exclamation marks (!!) write the Shell command to the currently active save file
with one exclamation mark. For examples, see the IBM Cognos PowerHouse 4GL QUIZ
Reference.
All SET JOB options are OpenVMS-specific and are not supported on UNIX or Linux. They are:
CPUTIME n
HOLD|NOHOLD
IDENTIFY|NOIDENTIFY
KEEP|NOKEEP
NAME filespec
NOTIFY|NONOTIFY
PRIORITY n
QUEUE queuename
RESTART|NORESTART
USER username
WSDEFAULT n
WSEXTENT n
WSQUOTA n
Subfiles
As discussed in Chapter 4, First Record, Direct Files, sequential and direct files begin with record
1 on OpenVMS but with record 0 on UNIX and Linux. As subfiles are direct files, ACCESS ...
LINK TO RECORD n of *subfile1 becomes ACCESS ... LINK TO RECORD n-1 of
*subfile1.
Indexed subfiles require that PowerHouse 4GL be licensed for C-ISAM data access.
On OpenVMS, SUBFILE ... FORMAT permits values of 4|7|8, whereas valid values on UNIX and
Linux are 3|5|6|7|8. Since you are migrating to a new platform and format, you should remove the
FORMAT parameter.
Default Printer
On OpenVMS, the default printer is SYSPRINT or SYS$PRINT. On UNIX and Linux, the default
printer is obtained from the value of the environment variable, PH_PRINTER. If this variable is
not set, the system default printer is used.
SET REPORT DEVICE

The following SET REPORT DEVICE options are only valid on OpenVMS:
AFTER
[NO]BURST

COPIES
FLAG|NOFLAG
FORMS
[NO]HOLD
[NO]IDENTIFY
[NO]LOWERCASE
[NO]CHARACTERISTIC
NOTE
[NO]NOTIFY
[NO]OPERATOR
PRIORITY QUEUE
[NO]RESTART
[NO]TRAILER
USER
After the Migration

After your application is up and running, you may want to take advantage of PowerHouse 4GL
features on UNIX and Linux that were not available on OpenVMS. Some of these are identified
below.
PDL
Indexes
The SEGMENT statement for C-ISAM files on UNIX and DISAM files on Linux allow a
DESCENDING option, not available on OpenVMS at the segment level. This indicates the order
in which segments are stored in the index.
QDESIGN/QUICK
Backwards Access
UNIX and Linux allow applications to read data records in reversed sequence. BACKWARDS is
an option on the GET verb, FIELD... LOOKUP, and the WHILE RETRIEVING verb.
QKGO
The following Execution Time Parameters exist on UNIX and Linux but not on OpenVMS. You
may want to investigate their value to your application. For further information, see the IBM
Cognos PowerHouse 4GL QDESIGN Reference.
EXT. SUBROUTINES, HP TERMINAL HAS LDW, LOCK ATTEMPTS, LOCK RETRY INTERVAL, LOCK
UNCONDITIONAL
Dynamic Function Keys

The Dynamic Function Keys screens on UNIX and Linux allow you to specify the type of function
key support in QUICK. The available options are Disabled, Fixed Standard, and Dynamic. You
can also control the appearance of function keys on UNIX and Linux through the Labels Active
and Bank Labels parameters. For further information, see the IBM Cognos PowerHouse 4GL
QDESIGN Reference.
QTP
SUBFILE
The INDEX and SEGMENT options of the SUBFILE statement for indexed subfiles allow the
DESCENDING option. This indicates the order in which segments are stored in the index.

QUIZ
SET SUBFILE
The INDEX and SEGMENT options of the SET SUBFILE statement for indexed subfiles allow the
Moving Forward
application when changing to the various file systems on UNIX, Linux, or Windows.
"The Migration Plan" (p. 53) describes the 12-step plan to perform the migration. This identifies
everything from identifying training needs to editing data definitions.

Chapter 3: The Target Platform: Windows
This chapter identifies the differences between the OpenVMS and Windows platforms that have
to be addressed during the migration of an IBM Cognos PowerHouse 4GL application. It also
identifies the differences within PowerHouse 4GL between the two platforms.
For information on differences specifically due to a change in file systems, see "The File
Systems" (p. 41).
Many of the differences between platforms require changes to file names as part of the migration.
The Axiant 4GL migration tools can perform many of these changes automatically. For
information on this and other aspects of actually moving your application from OpenVMS to
Windows, see "The Migration Plan" (p. 53).
Platform Differences
Folder Separators
Windows uses folders similar to OpenVMS. However folders are separated by backward slashes.
For example, the OpenVMS path
DISK1:[USER1.REPORTS.SOURCE]
would have a Windows equivalent of
C:\user1\reports\source\
File Names
Case Sensitivity
Like OpenVMS, Windows is not case sensitive. However, unlike OpenVMS, Windows allows
mixed case. In other words, TEST.qkc and test.qkc are considered the same name. For more
information, see "PowerHouse 4GL File Extensions" (p. 30).
Windows File Extensions

Like OpenVMS, Windows uses file extensions to identify file types (such as NITERUN.QTS or
NITERUN.QTC). These are generally three characters long but not necessarily so.
For more information, see "PowerHouse 4GL File Extensions" (p. 30).
Length
OpenVMS file names are generally restricted to 78 characters in length, depending on the disk
type. Windows allows 256 characters, so you do not have to shorten any file names.
Similarly, OpenVMS path names (for example, [NIGHTRUN.SALES.CORPORATE]) are restricted to
78 characters in length, whereas Windows path names allow up to 1023 characters.
Logical Names
OpenVMS applications, including PowerHouse 4GL, make frequent use of logical names to point
applications to files of different names or locations without editing the application. Environment
variables are the equivalent on Windows.
You need to define these environment variables to match your OpenVMS equivalents, usually
defined within command files. For information on converting command files, see "Operating
System Commands" (p. 28).

27
For information on the logical names for PowerHouse 4GL designated files (such as the default
PowerHouse 4GL resource file), see "Designated Files and Environment Variables" (p. 31).
Operating System Commands

OpenVMS OS commands can be found in DCL command files that you execute
• outside PowerHouse 4GL
• from within QDESIGN COMMAND statements and RUN COMMAND verbs
• in QTP and QUIZ programs using SET JOB (prefixed with $ or $$)
A great deal of processing power is contained in operating system scripts. Any command files you
have created have to be translated into Windows scripts (also known as batch files or batch
programs). Windows scripts can be executed from within a Command Prompt window or from
the Run action of the Start menu. Individual OS commands also have to be translated. (You do
not need to translate the PowerHouse 4GL command files provided by IBM. These have been
replaced on Windows by installed shortcuts.)
If you have a large quantity of command files, an alternative is to purchase a third party
OpenVMS emulator on Windows.
Before translating command files, assess whether your command files need to come forward at all.
A detailed examination may find that most of them address OpenVMS requirements that are no
longer applicable in a Windows environment. Almost all applications can leave some command
files behind.
Command files that must come forward require that a few changes be made repeatedly to each
file. This can best be handled through editor or word processor scripts on either platform. The key
is to understand the changes and identify repetitive tasks. For more information, see "The
Migration Plan" (p. 53).
Some Common Commands
Task OpenVMS Windows

Change working area SET DEFAULT CD
Copy files COPY COPY
Display all or part of text files TYPE TYPE, MORE
Terminate a process or job that is running STOP /ID, TASKKILL

DELETE /ENTRY
Rename files RENAME RENAME, REN
Delete files DELETE DELETE
Delete folders DELETE RMDIR
Shorten file names using a logical name or ASSIGN, DEFINE, SET

symbol :==
Example: Logical Names

Logical names are commonly used in OpenVMS PowerHouse 4GL applications to avoid
hard-coding specific folder paths. This makes the application more portable.
The Windows equivalent is an environment variable. It can be defined locally with the SET
command inside a script. For example,
DEFINE PAY [ARCHIVE.PAY]
would be replaced with
SET PAY=C:\ARCHIVE\PAY

Alternatively, it can be defined at the system level by right-clicking My Computer, selecting

Properties, selecting the Advanced tab, and selecting Environment Variables.
Example: A Batch Job
An OpenVMS Command File,

QUIZRUN01.COM The Windows Equivalent, QUIZRUN01.BAT
$QUIZ QUIZ
ACCESS EMPLOYEES ACCESS EMPLOYEES
CHOOSE EMPLOYEE PARM CHOOSE EMPLOYEE PARM
REPORT ALL REPORT ALL
GO GO
1 1
2 2
EXIT EXIT
To execute: To execute:
SUBMIT QUIZRUN01.COM QUIZRUN01.BAT
(or select Run from the Start menu)
PATH
On Windows, a system-level environment variable named PATH indicates which folders should be
searched through when the user or a program invokes the name of a script. OpenVMS has no
equivalent to this variable, although you can set up a search path using a logical name.
The PowerHouse 4GL install procedures place the PowerHouse 4GL install locations into the
PATH variable. Hence you can call QUIZ, for example, by simply typing the command QUIZ from
within any folder you may be working in within your Command Prompt window.
Be sure to modify the PATH variable for your user accounts to point to the folders containing
your scripts.
System Management
The change in platforms also means changes in application management. In particular, review the
methods and policies currently used for the following:
• application and data security
• backup, recovery, and data distribution
• software update distribution
• user interface
• end-user support
• capacity planning and performance management
File Versioning
Windows does not support automatic multi-versioning of files (filename1.qks;3). All applications
that rely on access to previous versions of files should be reviewed and revised to make copies of
files before changing or to prevent changing them through file access control.
This also results in different prompts appearing when you build or save a program file. Instead of
being asked to create a new version of a file, you will be asked if you want the old one deleted.
Consider the example of CREATE DICTIONARY in PDL:
• OpenVMS (PDL): The file (name) already exists. Create new one? [Y/N]
OpenVMS (PHDPDL): Dictionary (name) already exists. Create a new version? [Y/N]
• Windows: The file (name) already exists. Is it OK to delete? [Y/N]

File Access Control

The simplest level of application and data security is Windows file sharing, which has the
following features:
• Every user on a Windows network has a unique username, and is a member of at least one
group.
• You can grant or deny access to a folder or file by either Everyone (all network users) or
specified groups.
• You can allow or deny Read, Change, or Full Control access.
Windows also provides a Security tab on the Sharing and Security property sheet of every folder
and file. This is meant for file access among users on the same machine, whereas File Sharing is for
networked access.
PowerHouse 4GL Differences

This discussion identifies differences between PowerHouse 4GL on OpenVMS and PowerHouse
4GL on Windows, with the exception of differences relating to the file systems.
For information on differences due to a change in file systems, see "The File Systems" (p. 41).
For information on actually moving your application from OpenVMS to Windows, see "The
Migration Plan" (p. 53).
The Command Prompt Window

Since Windows has a graphical user interface and PowerHouse 4GL uses a character interface,
PowerHouse 4GL components run from within a Command Prompt window. To start a
Command Prompt session, select Run from the Start menu and enter CMD.EXE. Alternatively,
click the Start menu and select All Programs, Accessories, and then Command Prompt.
You can also start the PowerHouse 4GL components directly by clicking the Start menu and
selecting All Programs, IBM Cognos PowerHouse 4GL <version>, and then <component>. These
shortcuts to the Start menu were defined as part of the PowerHouse 4GL install process.
PowerHouse 4GL File Extensions

Like OpenVMS, Windows uses file extensions. These are generally three characters long but not
necessarily so. On Windows, PowerHouse 4GL saves its file extensions in lower case. For
example, the PDL dictionary source has an extension of .pdl and the compiled dictionary is .pdc.
Recall that Windows is not case sensitive, so you do not have to downshift your file extensions
within command files and source code.
For a complete list of designated files and their names, see the IBM Cognos PowerHouse 4GL
PowerHouse Rules document.
We recommend that you change all PowerHouse 4GL program calls to include the file extension.
For example, the following command looks for NITERUN.qts first and then, if it cannot find it,
NITERUN.qtc:
RUN COMMAND "QTP AUTO=NITERUN"
Running the source file can reduce performance, and it can cause errors if the source file does not
include a GO. It may also display your source code if you omit NOLIST. If you intended to run the
compiled program, change the call to the following:
RUN COMMAND "QTP AUTO=NITERUN.qtc"
Paths in File Names

On both OpenVMS and Windows, when you build a screen, run, or report without specifying a
path in the filespec, the compiled file (.qkc, .qzc, .qtc) is saved in the current location (from which
you ran the program).

On Windows, though, if you run a PowerHouse 4GL component from the default Start menu
shortcuts, this location is the product install location, by default. You can change this location by
modifying the Start in property of the component shortcut.
To avoid saving your files in the Start in location when you run a component from a shortcut, run
the component from a Command Prompt window in which you have moved to the desired
location with a CD command.
Subfiles
On Windows, as on OpenVMS, the dictionary information for a subfile is stored in a separate file
from the data. Each name.sf has a corresponding name.sfd. The same is true for portable subfiles,
name.ps and name.psd. Portable subfiles have their data written in an ASCII format, which
facilitates porting them between platforms.
When moving portable subfiles from OpenVMS to Windows, you must ensure that the tool
transferring the files (such as FTP) does not insert a line feed character at the end of each record.
Subfile Locations
On OpenVMS, temporary subfiles are held in the SYS$SCRATCH directory (unless given a path
in the code). On Windows, starting a PowerHouse 4GL component session creates a temporary
folder, phnnnn.tmp, to hold temporary subfiles and files. The temporary folder is created in the
location specified by the PHTEMP environment variable. This folder is deleted when the
PowerHouse 4GL component session ends. This folder is unique for each logon session, so two
users running the same multi-pass report or multi-pass run do not read each other’s temporary
subfiles.
As on OpenVMS, temporary subfiles on Windows are no longer available when you exit the
component. So an application that writes a temporary subfile in QTP then exits QTP and tries to
read that subfile in QUIZ does not work on either system.
As of version 8.41E for Windows, you can tell QUIZ and QTP to retain temporary subfiles by
using the PHTEMPKEEP environment variable with the PHTEMP environment variable. If
PHTEMPKEEP is set, temporary subfiles are created in the PHTEMP location so they are readily
available for subsequent compilation passes. If you set PHTEMPKEEP, you should delete the
temporary subfiles when they are no longer required.
Designated Files and Environment Variables

Designated files are reserved for use as PowerHouse 4GL default files. Some of these names are
reserved for use as logical names (OpenVMS) or environment variables (Windows) by
PowerHouse 4GL.
On Windows, as on OpenVMS, PowerHouse 4GL also locates designated files by searching for
certain file extensions. For example, when you use the SAVE statement in QTP, PowerHouse 4GL
creates a file containing the source code in the current folder and appends the file extension .qts to
the filename. When PowerHouse 4GL searches for the file, it first searches for a filename that has
the extension .qts appended.
For a list of PowerHouse 4GL designated files, their file extensions, and their environment
variables, see the IBM Cognos PowerHouse 4GL PowerHouse Rules document.
The Default Editor

The default editor used by a REVISE statement can be specified by the PHEDIT environment
variable. This defaults to the Notepad editor on Windows.
Interrupt Control
The user can interrupt prompting within PowerHouse 4GL components by pressing the interrupt
keystroke in response to a prompt. On OpenVMS this can be Ctrl-C or Ctrl-Y; on Windows this is
commonly Ctrl-C.

$POW
PowerHouse 4GL on Windows does not use the POW(ERHOUSE) menu system as on OpenVMS.
The various PowerHouse 4GL components and utilities are run directly from OS commands (as
they can be on OpenVMS as well) within a Command Prompt window. The following table
identifies the Windows commands equivalent to the POW Menu options:
Management Menu Windows Command

01 Maintain PowerHouse Dictionary pdl
02 Report dictionary contents qshow
Environment Menu Windows Command

10 Assign QUICK parameter file set QKGO=filespec
11 Maintain QUICK parameter files qkgo
Development Tools Menu Windows Command

20 Design QUICK screens qdesign
21 Run QUICK screens quick
22 Write QUIZ reports quiz
23 Perform QTP processing qtp
PHD and PDL

PowerHouse 4GL on OpenVMS supports two forms of dictionaries:
• A PDL dictionary, filename.PDC, is created by compiling a source file, filename.PDL, which
defines the dictionary objects.
• A PHD dictionary consists of four physical files: PHD00.PHD through PHD03.PHD. It can
be populated with dictionary definitions through two user interfaces:
• the PHD screen system (’01 Maintain PowerHouse Dictionary’ from the main menu of
POW, which takes you to the Dictionary Management menu)
• PHDPDL (a version of PDL which populates the four PHDnn.PHD files, rather than
filename.PDC).
PowerHouse 4GL on Windows only supports the PDL dictionary format. It does not use the PHD
dictionary or its corresponding Dictionary Management menu system. You need to convert your
dictionary definitions to PDL, if you have not already done so. However, this is a required step of
any platform migration. For more information, see "Step 6: Migrate The Pilot
Application" (p. 55).
The four PHD dictionary files on OpenVMS can be maintained by the PHDMAINT menu system.
PHDMAINT is not available on Windows. With just a single dictionary file, filename.pdc,
dictionary maintenance on Windows is driven by the Windows interface. (For example, drag and
drop to move the file, or CTRL+C to copy it.)
For run-time environments on OpenVMS that cannot use the PHD screen system, PHDADMIN is
a screen system for administrative functions like application and dictionary security changes.
PHDADMIN is not available on Windows, as these functions can be achieved through edits of the
PDL source file.

PDL
OpenVMS and Windows both support the full PDL syntax, so the only issues to be aware of are
Application Security Classes

The APPLICATION SECURITY CLASS and ASC statements on OpenVMS assign security with
any of the following methods: LOGONID, PASSWORD, PORTID, UIC or WEBLOGONID. On
Windows, only the LOGONID and WEBLOGONID methods are supported. This also applies to
the APPLICATION SECURITY ID METHOD option of the SYSTEM OPTIONS statement.
The Enhanced Application Security feature of PowerHouse 4GL on OpenVMS relates specifically
to OpenVMS security. There is no equivalent on Windows.
Dictionary Security Classes

PowerHouse 4GL on Windows does not use PHD (POW), and hence has no dictionary security
classes. The DICTIONARY SECURITY CLASS and DSC statements are only valid on OpenVMS.
This also applies to the DICTIONARY OWNER, DICTIONARY SECURITY ID METHOD, and
DSC ID METHOD options of the SYSTEM OPTIONS statement.
On Windows, you make your dictionary secure through standard file security on the .pdl and .pdc
files.

PowerHouse 4GL on Windows does not use execution time parameters (ETPs). The
EXECUTION TIME PARAMETER statement and the USER MODE statements are only valid on
OpenVMS.
FILE
The following FILE statement options are OpenVMS-specific. They can be dropped without
replacement, as they have no Windows equivalents:
CAPACITY
RECORD FORMAT
SCOPE
SUPERSEDE
INDEX
The NULL option of the INDEX statement is only valid on OpenVMS. It is not needed or
available on Windows.
Item Datatypes
The Item datatypes G_FLOAT and VMSDATE are only valid on OpenVMS. They can be found in
ITEM statements as well as ELEMENT x DEFAULT ITEM DATATYPE statements and USAGE
statements. On Windows, use FLOAT SIZE 8 and DATETIME.
You may face a loss of data when migrating any floating point numbers from one platform to
another. This is due to a loss of precision or significance; for example, 0.20 may be stored as
0.199999.... For more information on floating point data loss, see the IBM Cognos PowerHouse
4GL PowerHouse Rules document.
SET PRINT|NOPRINT
This option is only valid in PHDPDL. It has no equivalent on Windows.
SYSTEM OPTIONS PATTERN ... RESERVE CHARACTERS [string]

The Reserve Characters string for PHD is six characters long ( []:=;& ). For PDL on all platforms,
including Windows, it is seven characters long ( []:=;_& ).

QSHOW
SET GENERATE DEVICE
SET GENERATE DEVICE (for terminal, printer, or disc) is only valid on OpenVMS. On
Windows, as on OpenVMS, the default for a GENERATE command is to write PDL to
qshogen.pdl.
SET REPORT DEVICE

SET REPORT DEVICE PRINTER on OpenVMS allows the following options:
IDENTIFY|NOIDENTIFY
LOWERCASE|NOLOWERCASE
NOCHARACTERISTIC|CHARACTERISTIC
NOTE
NOTIFY|NONOTIFY
OPERATOR|NOOPERATOR
PRIORITY
QUEUE
RESTART|NORESTART
TRAILER|NOTRAILER
As these are OpenVMS specific, they do not exist on Windows. The only SET REPORT DEVICE
PRINTER option on Windows is the name of the printer string.
QUTIL
SET FDL|NOFDL
FDL files do not exist on Windows, so this command is not valid.
QDESIGN/QUICK
The Command Prompt
Because QUICK on Windows runs within a Console window (the Command Prompt) rather than
a terminal, the following areas of your application may be affected:
• handling of escape sequences
• use of fonts and line drawing
• adjusting the size of the QUICK window
• setting highlights and colors
Program Parameters
The following program parameters exist on OpenVMS but not on Windows. They can be
dropped without replacement, as they have no Windows equivalents.
BROADCAST
DCL|NODCL
DICTTYPE
DIRECT_FILE_BASE_ZERO
FASTREAD
FDL|NOFDL
INTSIZE6|NOINTSIZE6
NOUICBRACKETS
TERMPOLL|NOTERMPOLL
TRUSTED|NOTRUSTED
VMSDATE

DO EXTERNAL
Your application system may use 3GL programs (such as COBOL, Fortran, or C) either at the OS
level or from within QUICK DO EXTERNAL calls. As with scripts, the first thing to do is assess
whether you really need to bring these forward. They may be vestiges of older systems, no longer
needed.
Rewriting 3GL programs in PowerHouse 4GL code is not recommended, especially if they
perform complex mathematical calculations. Instead, find a compiler for the new Windows
environment. If you cannot find a compiler, consider rewriting the programs in C or C++.
You can remove the DESCRIPTOR option from your DO EXTERNAL calls on Windows,
because it is OpenVMS-specific. All other DO EXTERNAL parameters are identical between
OpenVMS and Windows, however they can hold different values and have different limits, due to
Note: The DO EXTERNAL call syntax on Windows has two formats or calling conventions,
named C and PASCAL. Check your 3GL provider to determine which of these two calling
conventions to use in the DO EXTERNAL call.
Windows has no equivalent to the OpenVMS BuildExternal command. On Windows, you
compile the external subroutines into DLLs.
3GL Locking
3GL programs on OpenVMS are able to bypass PowerHouse 4GL file level locking. This is
because PowerHouse 4GL components follow the cooperative locking strategy of the OpenVMS
Distributed Lock Manager (DLM), but 3GL programs you code yourself may not. PowerHouse
4GL on OpenVMS provides its own 3GL routines you can use to ensure cooperative locking.
Windows locking is absolute rather than cooperative. Therefore the 3GL routines provided for
PowerHouse 4GL on OpenVMS are not needed on Windows.
QKGO
To start QKGO on Windows, click the Start Menu, IBM Cognos PowerHouse 4GL <version>,
and then QKGO. On OpenVMS, this was done with the QKGOMAINT command or the PHD
Screens.
Windows has no terminal interface, just a command window. Therefore, the VTxxx-specific
terminal layout and function keys are not available on Windows.
On OpenVMS, the QKGO Maintenance system generates a different Terminal Interface
Configuration (TIC) file for each terminal type because the key codes are different. On Windows,
there is only one keyboard type for QUICK that corresponds to the PC keyboard.
If terminal (TIC) information is specified in QKGO, OpenVMS creates a context-binding file (for
example, FILENAMEB.DAT) and a key sequence file (for example, FILENAMEK.DAT) and one
or more terminal-group files (for example, FILENAMET.DAT). On UNIX and Linux, two files are
created for all three of these cases: filenameb.dat and filenameb.idx, filenamek.dat and
filenamek.idx, and filenamet.dat and filenamet.idx. To do this, PowerHouse 4GL must be licensed
for DISAM data access.
A default TIC file is also provided in the <installation_folder>\qkgo\resource folder. This TIC file
contains the key codes for all the keys and key combinations that can be mapped, as well as a set
of default key mappings that correspond to the PCANSI terminal type as defined for PowerHouse
4GL on UNIX and Linux. It can be modified as required to satisfy application requirements. To
access a TIC file, use the PHTICRS environment variable to point to the TIC file. It is
recommended that you make a copy of the default TIC file before modifying it. For more
information, see the IBM Cognos PowerHouse 4GL QDESIGN Reference.
On Windows, the QKGO environment variable provides the same functionality as the First screen
field in the QKGO Construction and Maintenance Screen. This is equivalent to the QKGO logical
name on OpenVMS.
Similarly, on Windows, the PHD environment variable provides the same functionality as the
Dictionary File field in the QKGO Construction and Maintenance Screen. This is equivalent to the
PHD logical name or the SETDICT OS command on OpenVMS.

PowerHouse 4GL on both OpenVMS and Windows employ deadlock protection to avoid a
’deadly embrace’ between two processes attempting to lock the same file. However the manner in
which they do so is different. On OpenVMS, this is affected by QKGO parameters LOCK
MESSAGE WAIT and LOCK REQUEST WAIT. On Windows, this is affected by QKGO
parameters LOCK ATTEMPTS, LOCK RETRY INTERVAL, and LOCK UNCONDITIONAL.
For further information, see the IBM Cognos PowerHouse 4GL QDESIGN Reference.
The following Execution Time Parameters exist on OpenVMS but not on Windows. They can be
dropped without replacement, as they have no Windows equivalents.
DRIVER
LOCK MESSAGE WAIT
LOCK REQUEST WAIT
MAX. PAGED MEMORY
SCREEN SECTION
SECONDARY BLOCKS
SELECTION SIZE
The Execution Time Parameters Field terminators controls data input. The default on
OpenVMS is F (full field), and the default on Windows is M (manual).
The Color Display Attributes Screen is only available on OpenVMS.
Editing a QUICK Initialization File (.QKI) is an alternative to using the QKGO screen system. If
you have a .QKI file on OpenVMS, it can be ported to Windows as a text file. PowerHouse 4GL
on Windows ignores any OpenVMS specific parameters.
QTP
OpenVMS Syntax
The following statement options are OpenVMS-specific, and are not supported on Windows:
SET FILE ... SEMIEXCLUSIVE
SET FILE SIGNAL|NOSIGNAL [ON CLOSE]
SET JOB
are written to QTPSAVE.
On Windows, operating system commands prefixed with a dollar sign ($) or a single exclamation
mark (!) suspend the current process, and execute the command. Operating system commands
prefixed by two dollar signs ($$) or two exclamation marks (!!) write the command to the
currently active save file with one exclamation mark. For examples, see the IBM Cognos
PowerHouse 4GL QTP Reference.
All SET JOB options are OpenVMS-specific and are not supported on Windows. They are:
CPUTIME n
HOLD|NOHOLD
IDENTIFY|NOIDENTIFY
KEEP|NOKEEP
NAME filespec
NOTIFY|NONOTIFY
PRIORITY n
QUEUE queuename
RESTART|NORESTART
USER username
WSDEFAULT n

WSEXTENT n
WSQUOTA n
Subfiles
Indexed subfiles require that PowerHouse 4GL be licensed for DISAM data access.
As discussed in Chapter 4, First Record, Direct Files, direct files begin with record 1 on OpenVMS
but with record 0 on Windows. Since subfiles are direct files, ACCESS ... LINK TO RECORD n of
*subfile1 becomes ACCESS ... LINK TO RECORD n-1 of *subfile1.
On OpenVMS, SUBFILE ... FORMAT permits values of 4|7|8, whereas valid values on Windows
are 3|5|6|7|8. Since you are migrating to a new platform (and format), you should remove the
FORMAT parameter.
QUIZ
OpenVMS Syntax
The following statement options are OpenVMS-specific, and are not supported on Windows:
SET JOB
are written to QUIZSAVE.
On Windows, operating system commands prefixed by two dollar signs ($$) or two exclamation
marks (!!) write the Shell command to the currently active save file with one exclamation mark.
Operating system commands prefixed with a single exclamation mark (!) suspend the current
process, and execute the Shell command. For examples, see the IBM Cognos PowerHouse 4GL
QUIZ Reference.
All SET JOB options are OpenVMS-specific and are not supported on Windows. They are:
CPUTIME n
HOLD|NOHOLD
IDENTIFY|NOIDENTIFY
KEEP|NOKEEP
NAME filespec
NOTIFY|NONOTIFY
PRIORITY n
QUEUE queuename
RESTART|NORESTART
USER username
WSDEFAULT n
WSEXTENT n
WSQUOTA n
Subfiles
As discussed in Chapter 4, First Record, Direct Files, sequential and direct files begin with record
1 on OpenVMS but with record 0 on Windows. As subfiles are direct files, ACCESS ... LINK TO
RECORD n of *subfile1 becomes ACCESS ... LINK TO RECORD n-1 of *subfile1.
Indexed subfiles require that PowerHouse 4GL be licensed for DISAM data access.

On OpenVMS, SUBFILE ... FORMAT permits values of 4|7|8, whereas valid values on Windows
are 3|5|6|7|8. Since you are migrating to a new platform (and format), you should remove the
FORMAT parameter.
Default Printer
On OpenVMS, the default printer is SYSPRINT or SYS$PRINT. On Windows, the printer
configuration for the current Windows session is used as the destination printer. To direct the
Report to another printer, change your printer configuration using the Control Panel. See your
Microsoft Windows documentation for information on printer configuration in Control Panel. Or
if you are running QUIZ from a Command Prompt window, you can specify the printer through
options on the Print command.
SET REPORT DEVICE

The following SET REPORT DEVICE options are only valid on OpenVMS:
AFTER
[NO]BURST
COPIES
FLAG|NOFLAG
FORMS
[NO]HOLD
[NO]IDENTIFY
[NO]LOWERCASE
[NO]CHARACTERISTIC
NOTE
[NO]NOTIFY
[NO]OPERATOR
PRIORITY QUEUE
[NO]RESTART
[NO]TRAILER
USER
After the Migration

After your application is up and running, you may want to take advantage of PowerHouse 4GL
features on Windows that were not available on OpenVMS. Some of these are identified below.
PDL
Indexes
The SEGMENT statement for DISAM files on Windows allows a DESCENDING option, not
available on OpenVMS at the segment level. This indicates the order in which segments are stored
in the index.
QDESIGN/QUICK
Backwards Access
Windows allows data records to be read in reversed sequence. BACKWARDS is an option on the
GET verb, FIELD... LOOKUP, and the WHILE RETRIEVING verb.
QKGO
The following Execution Time Parameters exist on Windows but not on OpenVMS. You may
want to investigate their value to your application. For further information, see the IBM Cognos
PowerHouse 4GL QDESIGN Reference.
EXT. SUBROUTINES, LOCK ATTEMPTS, LOCK RETRY INTERVAL, LOCK UNCONDITIONAL

Dynamic Function Keys

The Dynamic Function Keys screens on Windows allow you to specify the type of function key
support in QUICK. The available options are Disabled, Fixed Standard, and Dynamic. You can
also control the appearance of function keys on Windows through the Labels Active and Bank
Labels parameters. For further information, see the IBM Cognos PowerHouse 4GL QDESIGN
Reference.
QTP
SUBFILE
The INDEX and SEGMENT options of the SUBFILE statement for indexed subfiles allow the
QUIZ
SET SUBFILE
The INDEX and SEGMENT options of the SET SUBFILE statement for indexed subfiles allow the
Moving Forward
application when changing to the various file systems on Windows or Windows.


Chapter 4: The File Systems
This chapter contains a separate section for each of the OpenVMS file systems: RMS ISAM, RMS
(sequential, direct, and relative) and relational. In each section, we identify the target file systems
available for the given source file system, and then discuss the work involved in migrating between
the two file systems.
We discuss what must change during a migration in both the dictionary and the programs. Where
differences are major, we discuss details of specific target file systems.
This chapter discusses the PowerHouse 4GL differences between file systems. For a discussion of
the relative advantages of each file system, see "Migration Choices" (p. 9). For information on
moving the application files between platforms and other aspects of the overall migration process,
see "The Migration Plan" (p. 53). For more detailed information on how PowerHouse 4GL
works with relational databases, see the IBM Cognos PowerHouse 4GL PowerHouse and
Relational Databases document or consider attending the PowerHouse Relational Interface
training (Parts I and II).
Migrating from RMS ISAM

The most likely types of file systems you will migrate your RMS indexed files to are indexed or
relational ones. The former is simpler and less expensive. The latter is more powerful but requires
more migration work.
Indexed to Indexed
Both C-ISAM on UNIX and DISAM on Linux and Windows accept the vast majority of your PDL
syntax for RMS. This means that few changes are required to your application programs.
Datatype Mappings
PowerHouse 4GL makes few restrictions on datatype usage for keys and indexes. File systems, on
the other hand, are much more restrictive as to what is available, so PowerHouse 4GL maps its
datatypes to the best match available when the file is generated using QUTIL. In some cases, a
mapping that works well in RMS may not work well with C-ISAM or DISAM. You should review
your key and index datatypes and adjust them where appropriate. A table of these datatype
mappings can be found on (p. 50).
PDL
To change a PDL FILE statement to work with C-ISAM or DISAM, change the TYPE option from
RMS to CISAM (no hyphen) or DISAM. (On UNIX and Linux, the TYPE clause can optionally be
omitted.) For example:
FILE BILLINGS ORGANIZATION INDEXED TYPE CISAM ...
The following FILE options do not apply to C-ISAM or DISAM and must be removed:
• CAPACITY n (C-ISAM and DISAM files automatically expand as needed)
• RECORD FORMAT
• SUPERSEDE (C-ISAM and DISAM do not support file versioning)
DISAM Opens
Unlike RMS ISAM or C-ISAM, a DISAM file opened for Write or Append cannot be read until it
is closed. Review your programs to see if they are reading any RMS files opened for Write or
Append, and either issue a Close before the read or postpone the read.

41
With DISAM, Update Exclusive opens are not permitted.
RMS ISAM to Relational

You can migrate to a relational database in order to get the various advantages these systems offer
(such as set processing and structures that make data access cleaner and more flexible). Keep in
mind that the structural changes can make for a more complex migration of your data, and many
of the performance benefits are only realized after making changes to your application programs.
IBM currently supports the following relational database management systems.
UNIX and Linux Windows

®
IBM DB2
®
IBM DB2
Oracle Oracle
Sybase Sybase
DataDirect ODBC to SQL Server Microsoft SQL Server (via ODBC)
You need to make several types of changes to your application source files, both data definitions
and programs. This can be done manually, in an editor, or it can be done with automated tools.
For information on these tools, see "The Migration Plan" (p. 53).
Data Definitions
Your PDL file for RMS ISAM defined both logical objects (such as Elements) and physical storage
objects (such as Files, Records, Items and Indexes). The PDL for a relational application contains
only the logical objects and a pointer to the database. You also create a database SQL source file
containing the SQL equivalent to your File, Record, Item, and Index definitions.
Source PDL PDL Usage A

Element B Usage A
Usage A Element C
Element B Usage A Element D
Element C
Element D Database X &
Type Oracle &
File E Org Indexed Null Values Allowed &
Record E Open "X"
Item B
Item C
Index B Unique
Segment B Create Database "X";
SQL Create Table "E" (
File F "B" Char(4) Not Null,
... "C" Char(8) Not Null);
Create Unique Index "B1"

On "E" (
"B");
The PDL Database statement often includes a database user ID and password within the Open
Name.
In addition to Usage, Element, and Database statements, the PDL may also contain Application
Security Class statements. PERMIT statements cannot be applied to relational data, but ASCs may
still be used in the USERS INCLUDE options of screens, runs, and reports.
Use QSHOW to generate the initial SQL from your dictionary:
QSHOW
> SET LANGUAGE SQL
> GENERATE DATABASE E
> $RENAME QSHOSQL.TXT QSHO_E.SQL

> GENERATE DATABASE F

> $RENAME QSHOSQL.TXT QSHO_F.SQL
> GENERATE ...
This creates a series of text files, QSHO_n, which you then merge and modify to include syntax
specific to your chosen relational database. Alternatively, Axiant 4GL can convert your entire
dictionary, as described in "The Migration Plan" (p. 53).
Identifying the Database

When accessing a relational table within a PowerHouse 4GL component, use the IN clause to
identify the database as defined within your PDL. For example:
QDESIGN: FILE ORDERS IN X
QUIZ/QTP: ACCESS ORDERS IN X
Alternatives are the SET DATABASE statement (to provide the default database) and the program
parameter SUBDICT=SEARCH. If all table names are unique, then using SUBDICT means not
having to change source code.
Naming Conventions: Hyphens to Underscores

Relational databases do not permit hyphens (-) within object names. This avoids confusion with
the subtraction or minus character in operations.
The most common replacement character is an underscore (_). For example, MONTH-NAME
becomes MONTH_NAME. The change is a simple editor find-and-replace in your source files.
However, do these one by one rather than with a wildcard, to avoid making the change in code
performing a subtraction operation. Alternatively, the Axiant 4GL migration tools do this
automatically.
Naming Conventions: Sybase Case Sensitivity

Sybase is case sensitive. However, PowerHouse 4GL upshifts object names by default. Hence, a
Sybase table or column defined in mixed or lower case (for example, "Billings") is not recognized
by PowerHouse 4GL (where ACCESS Billings becomes ACCESS BILLINGS).
There are several ways to avoid this issue. The simplest method is to disable the automatic
upshifting and use the correct case in your PowerHouse 4GL programs. To disable the upshifting,
add the following to your PDL:
SYSTEM OPTIONS SHIFT NOSHIFT
Normalization
relational databases achieve their benefits by working on the basis of normalized data.
Normalization is a design process removing redundancy in your data definitions. Thus a
migration to relational requires data structure changes while moving from PDL to SQL.
Ideally, you would make a full review of your record structures and implement a fully normalized
data model. At a minimum, it is necessary to remove all non-relational features from your data
definitions. This may result in additional data objects, but the resulting application programs are
easier to understand and maintain.
The following designs are not normalized:
• item substructures
• arrays (occurring or repeating items)
• item redefinitions
• multiple record layouts (used for coded records with Select values)
Item Substructures
You can normalize substructures in the following ways:

• Remove the highest level item and use lower levels only.
Unnormalized Normalized
Item MONTH-KEY Item INITIALS
Begin Structure Item MONTH
Item INITIALS
Item MONTH
End Structure
• Remove lower levels and use the highest level only.
Item TRANS-DATE Item TRANS_DATE
Begin Structure
Item YEAR
Item MONTH
Item DAY
End Structure
The first method is useful when the end user tends to enter the subitems individually; the second
approach is useful when you commonly work with the whole structure at a time (for example, a
date field).
If you choose the first method yet you need to access the higher-level item in your applications,
you can create a concatenated item in either the application (for example, a Define) or the
database (for example, a calculated column).
Similarly, if you choose the second method yet you need to access the lower-level item in your
applications, you can extract it in either the application (for example, a Define) or the database
(for example, a calculated column).
Arrays
Some relational databases support arrays, but they must be replaced with normalized structures
for PowerHouse 4GL applications. You can normalize arrays in the following ways:
• Define individual fields for each occurrence.
Unnormalized Sales File Normalized

Item PRODUCT-NO Item PRODUCT_NO
ITEM MONTHLY-TOTALS & Item JANUARY_TOTAL
Occurs 12 Item FEBRUARY_TOTAL
... ...
• Create a detail table (relational files are called tables).
Unnormalized Sales File Normalized Tables

Item PRODUCT-NO Sales table:
ITEM MONTHLY-TOTALS &
Occurs 12 Item PRODUCT_NO
... ...
Monthly_Sales table:
Item PRODUCT_NO
Item MONTH
Item MONTHLY_TOTAL
• Define a single item as long as all the occurrences.

This solution is only available if the items are character or zoned unsigned. For example, Item
DAY-CODE Char Size 2 Occurs 7 could become Item DAY_CODE Char Size 14. You
would then use the [n:m] function in your applications to extract the desired day.

The first method is the simplest metadata change, but it is less practical if there are a large number
of occurrences, and it is not true normalization. It can result in many lines of application code. For
example, a screen cluster around one Field statement is replaced by multiple Field statements; a
procedural For loop is similarly replaced. This method might be appropriate for MONTH (12
values) but not for DAY_OF_MONTH (31 values).
The second method may be less efficient when reading, as the detail table holds one record for
each occurrence. However it can be more efficient in program processing logic, and require
simpler program changes. The I/O loss is often recovered by both the CPU savings and the easier
maintenance effort. As well, aggregate processing can be simpler and faster if you change your
logic to use SQL.
Screen Example, Unnormalized Sales File Screen Example, Normalized Tables

Screen X Screen X
File SALES File SALES In DB
File MONTHLY_SALES In DB &
Detail Occurs 12
Field PRODUCT_NO Field PRODUCT_NO
Cluster Occurs with & Cluster Occurs with &
MONTHLY_TOTAL MONTHLY_SALES
Field MONTHLY_TOTAL Field MONTHLY_TOTAL
End Cluster End Cluster
... ...
Item Redefinitions
You can normalize Redefines in the following ways:
• Remove one item and change the program logic to only use that one.
Item USERID Item USERID
Item USERIDCHAR &
Redefines USERID
• Keep separate items and maintain them in your program logic.
Item USERID Item USERID
Item USERIDCHAR & Item USERIDCHAR
Redefines USERID
Which method you use depends on the reason for the original Redefine. The second method need
not require changes to your application code if you use relational database triggers or computed
fields to automatically populate one item with the value of the other item.
Multiple Record Layouts

Multiple record layouts for a single file are usually (but not necessarily) used when creating coded
records with Select clauses. For example:
File CONTACTS
Record CONTACTS
Item RECTYPE
...
Record SUPPLIERS
Item RECTYPE SELECT "S"
...
You can normalize multiple record layouts in the following ways:
• Use one table and add views to separate the data.
• Create separate tables and merge them with a view.

If you use a single large table, you can create views that report from specific subsets of that data.
Depending on the relational database and the Select statement within the view, you may also be
able to write to the table through the view.
If you choose to use separate tables, you may be able to report from all tables at once by creating
a database view that includes the data from all the tables.
Program changes are likely necessary after removing coded records. This includes changing or
removing Select options and "Set File Open n" statements.
Primary Keys and Indexes

A primary key is a unique identifier of each record in the table. Some relational databases, such as
Sybase, require a primary key in every table definition. Regardless of the relational database, we
recommend you add a primary key and a unique index to every table if they do not already have
one. This maintains data integrity. Equally important, it allows table records to be updated or
deleted within Cursors. Cursors are a relational feature which can greatly improve performance.
Primary keys and indexes should be modified if they contain an item which was a substructure
and you have replaced the substructure with the lower-level items (p. 43). The key or index must
have its segments defined with the same items.
Some relational databases, such as Oracle, automatically generate a unique index based on the
primary key for every table. You may want to disable this database feature if you have your own
unique indexes already declared. (An alternative is to remove your own index definitions, but you
then have to also change any programs that refer to those indexes through syntax like
VIAINDEX.)
Index names must be unique within a relational database, so you may have to rename some
indexes with are currently the same within different record structures. Remember to change any
programs that reference the old index names.
Ordered Retrieval
Records in a relational table are not stored in a specific order (for example, chronological or by
unique index). Therefore, any programs that expect the data in a specific order but which have no
Sort statement need to be changed.
In the following examples, the new code is highlighted in bold:
QUICK
FILE EMPLOYEES IN TRACKING
ACCESS ORDERED &
VIA LAST_NAME USING LAST_NAME REQUEST LAST_NAME
QUIZ/QTP
ACCESS EMPLOYEES IN TRACKING
CHOOSE VIAINDEX LAST_NAME
For more information on ordering, see the Ordered, Orderby, and Viaindex clauses in the IBM
Cognos PowerHouse 4GL QDESIGN, QUIZ, and QTP Reference documents.
Null Values
Relational databases support the concept of null values by default. As this affects programming
logic and thus requires evaluation of all your program code, you may wish to disable null support
initially and investigate its benefits after your system has been fully migrated.
A null value is an unknown value. It indicates nothing, not zero or blank. Nulls model the real
world better than binary processing (True or False) does, because the real world often has missing
information.
For example, calculations containing null values evaluate to null. So Total = Supply + Labour
evaluates to null if either Supply or Labour is null. If the labour costs are unknown, the total cost
is unknown. (Compare this to binary logic, where Total = Supply if Labour has nothing in it,
because ’nothing’ is treated as a zero.)

Null support can cause conversion issues when loading your OpenVMS data into a relational
database. It can also cause logic errors in existing program code that is not expecting null
processing rules. For more information on null values in a PowerHouse context, see the IBM
Cognos PowerHouse 4GL PowerHouse Rules document, as well as the training courses, The
PowerHouse Relational Interface (Parts I and II).
Null value processing is disabled within PowerHouse 4GL by default: the PDL Database
statement has the default option of Null Values Not Allowed. This can be changed once the
migration is complete and you are ready to upgrade your programs to support nulls.
Miscellaneous Syntax
Relational tables cannot be opened with an access-type of Append, Clear, or Write (for example,
FILE x IN db OPEN APPEND). Valid types are Update (the default) and Read.
Relational tables can only be opened with an exclusivity of Share. We recommend you replace
exclusivity control with transaction control. For more information, see "The Next Step:
Relational Features" (p. 47).
The QDESIGN Lock and Unlock verbs, as well as the Lock option are generally not supported for
relational tables. The same is true for the QTP SET FILE [UN]LOCK and QUIZ SET [UN]LOCK
statements. Oracle has limited support for them, and they are ignored for other database systems.
In any case, for all relational databases, we recommend they be replaced with transaction control
statements. For more information, see "The Next Step: Relational Features" (p. 47).
The creation and maintenance of your relational database is handled by database tools rather than
PowerHouse 4GL. Thus, in QUTIL, the following syntax does not apply to relational tables, and
must be removed as follows:
CREATE|DELETE FILE x
Two PowerHouse 4GL options which behave differently in a relational application are Open
numbers (for example, FILE x Open 1) and the Close verb or option.
• Open numbers cause separate transactions to be created. We recommend they be replaced
with transaction control statements.
• The Close verb or option commits a transaction and then detaches from the database. We
recommend they be replaced with a Commit verb.
• For more information, see "The Next Step: Relational Features" (p. 47).
The Next Step: Relational Features

Once you have successfully migrated your application to a relational environment, your next step
is to take advantage of features that were not available with RMS.
Some of these features can simplify your programs, some can extend your program functionality,
and several of them can improve performance. Some of these features require changes to the
database, while others require changes to your program code.
The following are features to consider adding to the database:
• triggers (SQL code inserted in the database to take place whenever any application inserts,
modifies, or deletes data in a specified table)
• views (virtual tables, constructed in the database to merge or separate data from one or more
tables)
• computed fields (columns whose definition includes a calculation, performed at write time
once, which improves read time)
• varchars (variable character datatypes, which can be more efficient than fixed-length
character items)
The following are features to consider adding to your programs:
• SQL cursors, essentially temporary views defined for the duration of that program run
• SQL commands (Insert, Update, and Delete) that you can include within QUICK procedures
and QTP calls
• transaction control, the relational method of controlling data access
• null value support, allowing your program logic to handle real-world situations of missing
data

• stored procedures, functions defined within the database which can be explicitly called by
QUICK or QTP
For more information, see the IBM Cognos PowerHouse 4GL PowerHouse and Relational
Databases document and the training courses, The PowerHouse Relational Interface (Parts I and
II).
Migrating from RMS Files (Direct, Relative, Sequential)

A sequential file is one which can be read sequentially. New records are added to the end of the
file. Existing records cannot be updated or deleted.
A direct file is one which can be read sequentially or by record number. New records are added to
the end of the file. Existing records can be updated but not deleted.
A relative file is like a direct file except that records can also be deleted (leaving gaps in the file).
Direct and Sequential Files

UNIXIO on UNIX and Linux supports direct and sequential files. The same is true for DOS on
Windows. Hence few changes are required to your application programs.
First Record, Direct Files

The first record of a Direct file in OpenVMS is record number 1. However, on UNIX, Linux, and
Windows this is record number 0. Therefore all applications which use Direct file record numbers
must be reviewed and possibly revised. For example, a QDESIGN statement that reads the first
record in the file changes from ACCESS USING 1 to ACCESS USING 0.
This affects the following statements: ACCESS (QDESIGN, QUIZ, QTP), PUT AT and TARGET
(QDESIGN), and OUTPUT USING (QTP).
PDL
To migrate a Direct or Sequential PDL FILE statement, simply change the TYPE option (or
remove it completely, since it is optional):
OpenVMS: FILE x ORGANIZATION DIRECT|SEQUENTIAL TYPE RMS
UNIX, Linux: FILE x ORGANIZATION DIRECT|SEQUENTIAL TYPE UNIXIO
Windows: FILE x ORGANIZATION DIRECT|SEQUENTIAL TYPE DOS
The following FILE options do not apply to UNIXIO or DOS and must be removed:
CAPACITY
RECORD FORMAT
SUPERSEDE
Relative Files
UNIX, Linux, and Windows do not support relative files (which are like direct files that also allow
record deletion). To support the deletion capability, we recommend such files be migrated to an
indexed file system (C-ISAM on UNIX or DISAM on Linux and Windows).
This can be done with a simple index consisting of a one-segment sequence number.
On OpenVMS, use the following:
FILE x ORGANIZATION RELATIVE TYPE RMS
RECORD x
ITEM I1...
ITEM I2...
On UNIX, Linux, and Windows, use the following:
FILE x ORGANIZATION INDEXED TYPE CISAM|DISAM
RECORD x
ITEM I1...
ITEM I2...

ITEM SEQUENCE_NO
INDEX x1 UNIQUE
SEGMENT SEQUENCE_NO
To also populate the index value, you must modify any code that writes to the file. For example, it
could read the last record for its sequence number and then add that value plus one to the new
record. You may need to apply some locking in a concurrent-user environment.
Retrieval must be changed from a direct read (USING n) to an indexed retrieval (VIA segment
USING n).
PDL
The CAPACITY n FILE option does not apply to UNIXIO or DOS and must be removed.
Mailbox Files (MBX)

Mailbox files are unique to OpenVMS. When migrating to UNIX, Linux, or Windows, you need
to study the application your mailbox files are being used for and then design alternative logic
using other file systems.
Migrating from Relational

IBM currently supports the following relational database management systems
UNIX and Linux Windows

IBM DB2 IBM DB2
Oracle Oracle
Sybase Sybase
DataDirect ODBC to SQL Server Microsoft SQL Server (via ODBC)
We recommend the following migration paths (however a migration to any other relational
database would also be a viable option):
OpenVMS UNIX and Linux Windows

Oracle Oracle Oracle
RDB, RDB/VMS Oracle Oracle
Study the documentation on your chosen relational database and compare it to your source
relational database to identify the changes you need to make to your SQL data definition file.
Common issues are the syntax structure, functions, and datatypes supported. Depending on your
data definition changes, this may also require modifications to your PowerHouse 4GL program
logic.
Migrating from RDB/VMS

The file type RDB/VMS uses direct OSRI calls to the database. On UNIX, Linux, and Windows,
however, PowerHouse 4GL accesses all relational database management systems through its own
access method (just as the newer OpenVMS file type RDB does). What this means is that
migrating from file type RDB/VMS to a relational database on UNIX, Linux, or Windows may
result in performance changes, given the extra level of translation. We recommend you investigate
some of the features now available in your target relational database to improve performance
further.

Naming Conventions: Sybase Case Sensitivity

Sybase is case sensitive, however PowerHouse 4GL upshifts object names by default. A Sybase
table or column defined in mixed or lower case (for example, Billings) would not be recognized by
PowerHouse 4GL (as ACCESS Billings would become ACCESS BILLINGS).
There are several ways to avoid this issue. The simplest method is to disable the automatic
upshifting and use the correct case in your PowerHouse 4GL programs. To disable the upshifting,
add the following to your PDL:
SYSTEM OPTIONS SHIFT NOSHIFT
Primary Keys and Indexes

A primary key is a unique identifier of each record in the table. Some relational databases, such as
Sybase, require a primary key in every table definition. Regardless of the relational database, we
recommend you add a primary key and index to every table if they do not already have one. This
maintains data integrity. It also allows table records to be updated or deleted within Cursors, a
relational feature which can greatly improve performance.
Some relational databases, such as Oracle, automatically generate a unique index based on the
primary key for every table. You can disable this database feature if you have your own unique
indexes already declared. (An alternative is to remove your own index definitions, but you then
have to also change any programs that refer to those indexes through syntax like VIAINDEX.)
After the Migration

Once your migration is completed, study the documentation of the new relational database to
identify features that were not present on the source relational database. You may want to take
advantage of some of these by further refining your SQL and programs.
Datatype Mappings
PowerHouse 4GL makes few restrictions on datatype usage for keys and indexes. File systems, on
the other hand, are much more restrictive, so PowerHouse 4GL maps its datatypes to the best
match available when the file is generated using QUTIL. In some cases, a mapping that works well
in RMS ISAM may not work well with C-ISAM or DISAM.
If you are migrating from RMS ISAM to C-ISAM or DISAM, review your key and index datatypes
using the following table and adjust them where appropriate. If you create the files outside of
PowerHouse 4GL, ensure that the indexes you create are consistent with the PowerHouse 4GL
definitions.
Since PowerHouse 4GL does not generate relational databases using QUTIL, it makes no
assumptions about relational datatypes.
The following table compares the file system datatypes for each PowerHouse 4GL datatype:
PowerHouse 4GL RMS ISAM C-ISAM/DISAM

CHARACTER character string CHARTYPE
DATE 2-byte unsigned integer CHARTYPE
DATETIME 8-byte unsigned integer CHARTYPE
FLOAT5 not permitted FLOATTYPE (4 byte)

DOUBLETYPE (8 byte)
FREEFORM1 character string CHARTYPE
G-FLOAT
5
not permitted --

PowerHouse 4GL RMS ISAM C-ISAM/DISAM

INTEGER 2-byte signed integer INTTYPE (2 bytes)
SIGNED
2
4-byte signed integer LONGTYPE (4 bytes)
8-byte signed integer CHARTYPE (> 4 bytes)
INTEGER 2, 4, 8-byte unsigned CHARTYPE

UNSIGNED integer
INTERVAL
5
not permitted DOUBLETYPE
JDATE 2-byte unsigned integer CHARTYPE
PACKED SIGNED
3
packed CHARTYPE
PACKED packed CHARTYPE

3
UNSIGNED
PHDATE 2-byte unsigned integer CHARTYPE
VARCHAR4 character string CHARTYPE
VMSDATE 8-byte unsigned integer CHARTYPE (8 bytes)
ZDATE character string CHARTYPE
ZONED SIGNED3 character string CHARTYPE
ZONED character string CHARTYPE

3
UNSIGNED
ZONED character string CHARTYPE

NUMERIC
1
FREEFORM keys and segments do not work due to the nature of the
FREEFORM datatype.
2
CHARTYPE does not process negative numbers correctly.
3
PACKED and ZONED only work for C-ISAM and DISAM if the signs
are all the same.
4
The first two bytes which represent the size are ignored.
5
RMS ISAM allows only certain datatypes as index segments.
Moving Forward


Chapter 5: The Migration Plan
At this stage, you have evaluated the choices for both your target platform and your target file
system(s). This chapter describes the twelve-step plan to actually perform the migration. This
covers everything from identifying training needs to editing data definitions, with an emphasis on
the physical migration activities in Step 6.
The Twelve-Step Plan

1. Define the intended application.
2. Learn about the target environment and migration tools.
3. Take inventory of what you have.
4. Identify what will be migrated.
5. Develop a plan.
6. Migrate the pilot application.
7. Assemble the pilot application.
8. Assess the results of Steps 2 through 7.
9. Have users evaluate the pilot application.
10. Assess the results of Steps 2 through 9.
11. Plan the complete migration.
12. Do the complete migration.
Step 1: Define the Application

This simple step has you document exactly how much of the source application will be migrated
to the target platform and file system(s). Identify the architectures you have to create to support
the new environment. Also define how you will measure success, in terms of user acceptance and
business productivity.
An important component of this step is to identify a portion of the application that you will
initially migrate as a pilot. This can be used to evaluate your tools, processes, and understanding
of the migration issues.
As such, choose a portion which is small but which contains a variety of features, such as the
following:
• all PowerHouse 4GL components
• calls to operating system commands
• 3GL calls (if the application has many)
• data definitions that have changed significantly (for example, due to a change of the file
system and supported features)
• security
Step 2: Learn
Learn about your target platform and file system(s). If you will be using the Axiant 4GL migration
tools in step 6, learn about those as well.

53
This learning can be done by reading the appropriate documentation, discussing the issues with
knowledgeable co-workers, or taking training courses. The time and costs invested in education
will be recovered later by a smoother migration.
Relevant IBM courses include the following:
• Migrating Applications with Axiant 4GL
• The PowerHouse Relational Interface (Parts I and II)
• Axiant 4GL - Building Applications
• PowerHouse Web - Developing Applications
For information on these and other courses, see http://www.ibm.com/support.
Step 3: Take Inventory

Take an inventory on both your OpenVMS system and your target system to identify the
following:
• skills
Who knows what about PowerHouse 4GL, its relational interface, Axiant 4GL, the source
and target operating systems and file systems, the networking, the user interface, and the
applications involved? This may involve existing staff, new staff, and external consulting
services. All team members should be familiar with the key architectural features of the
various technologies in order to eliminate potential problems early in the process. We also
recommend including an application user on the migration team to get early buy-in and catch
user issues at an early stage.
• software
Identify what software is needed on both the source and the target operating systems and file
systems. This includes PowerHouse 4GL versions, editors, mail systems, possible 3GLs, batch
processing tools, security systems, and FTP tools. Axiant 4GL includes a Migration Profile
tool that identifies the programs and data used, showing them in a graphical format.
• hardware
What are the hardware requirements for your UNIX, Linux, or Windows servers (for
example, disk space, memory, and networks)?
• standards and practices
Identify day-to-day activities that may have to change due to the new environment. For
example, perhaps users were notified of software updates indirectly by having the system go
down during changes. If software updates could now be done automatically over a network,
you have to specifically plan to notify the users.
Step 4: Identify What Will Be Migrated

Determine what will be
• moved as is
Many screens, runs, and reports does not have to change, especially if the source and target
file systems are similar (for example, Oracle on OpenVMS to Oracle on UNIX, Linux, or
Windows, or RMS ISAM to C-ISAM or DISAM).
• moved with changes
For example, a move from RMS ISAM to a relational database requires replacing
substructures, arrays, and redefinitions. These, in turn, lead to changes in your programs. Any
platform-specific logic, such as command files, also falls into this category. A 3GL program
may need changing due to different compilers. A migration to a relational database allows
optional program changes to use cursors and other SQL syntax.
• replaced
Oracle Rdb databases may be replaced with new relational databases or indexed files. QUIZ
reports may be replaced by GUI tools such as ReportNet, Impromptu, and PowerPlay.
• created

You may have to create some new tables to make up for non-relational structures in RMS
ISAM files. You may also want to create new relational database objects (such as views and
triggers), which in turn affect your programs.
Step 5: Develop a Plan

A plan for the move includes a preliminary schedule. This should include time for:
• training
• design
• development
• help systems
• the actual migration
• testing (security, for example, and running the new application in parallel with the source
application)
We recommend that you meet with your IBM representative during the development of the
migration plan. They have lots of migration experience and may also be aware of recently
available tools or tips. If you are moving to a new file or database system, you should include the
vendor in the planning as well.
Through consulting programs and services, IBM and other vendors can provide skilled resources,
either directly or through a partner. For more information, see http://www.ibm.com/support.
Step 6: Migrate The Pilot Application

The pilot portion of the overall application was identified in Step 1. The actual migration
activities vary, depending on whether you are using the Axiant 4GL migration tools.
• "Migrate with the Axiant 4GL Migration Tools" (p. 55)
• "Migrate without the Axiant 4GL Migration Tools" (p. 58)
For information on this decision, see (p. 11).
Migrate with the Axiant 4GL Migration Tools

If you are moving to UNIX, Linux, or Windows and employing the Axiant 4GL migration tools
on Windows as a middle step, your migration will involve the following activities:
1. Collect your OpenVMS files (as identified in Steps 3 and 4).
2. Send your files to Windows.
3. For the pilot portion of your application, use the Axiant 4GL migration tools to convert the
PDL and component programs to formats for your target platform and file system(s).
You can also migrate your OpenVMS .SQL files into Axiant 4GL and then generate .SQL files
for the target relational database. However many people bypass this step and send the source
platform .SQL files directly to the target platform and edit them manually for the target
relational database.
4. Send your modified PDL and component programs to your target platform (UNIX, Linux, or
the appropriate Windows server).
1. Collect your OpenVMS Files

Obtain a current PDL definition of your OpenVMS application, or use QSHOW to generate one:
> SET LANGUAGE PDL
> SET SECURITY
> GENERATE ALL
;Similarly, obtain a current .SQL definition file of any OpenVMS relational databases being
migrated, or use a database utility to generate the SQL DDL.

Use QTP to transfer data into portable subfiles. Also convert any data currently in permanent
subfiles to portable subfiles for transfer to the new platform. Use QTP instead of QUIZ because of
internal differences in generating the mini dictionaries (such as the way arrays are described).
QUIZ subfile contents are also based on the items in the REPORT statement, which has a
maximum record length of 256 characters.
When writing your data to portable subfiles, you do not usually have to code ITEM statements.
For example:
QTP:
ACCESS PAY [IN database]
SUBFILE PAYSF KEEP PORTABLE INCLUDE PAY
GO
2. Send Files to Windows

On OpenVMS, we suggest you place your various application files into separate directories based
on component (for example, PDL, QUICK, QTP, QUIZ, SUBFILES, 3GLS, SQL and command
files). They can then be sent to separate corresponding folders on Windows. Use an FTP tool to
transfer all of your application files from OpenVMS to the corresponding folders in the Windows
environment.
When using FTP, ensure that you have both the .PS and .PSD files for each portable subfile. Use
the ASCII file transfer format when sending all files from OpenVMS to Windows, except for the
data file of each subfile.
It is important to send the data files for all subfiles using the BINARY transfer format of the FTP
tool (even though the data files simply contain ASCII text). If you use the ASCII transfer format, it
inserts a line feed character at the end of each record. PowerHouse 4GL subfile data files should
not have this character inserted.
3. Convert your Files

For a migration to Windows, the file extensions can be left in upper case. For a UNIX or Linux
migration, use a Command Prompt window to rename all your files to have lower case extensions.
For example:
• Move into the SUBFILES folder, then type rename *.PSD *.psd, followed by rename *.PS
*.ps.
• Use similar mv commands in the other folders (such as mv *.QKS *.qks for QUICK).
Within Axiant 4GL:
1. Create a Migration Profile defining your source and target platforms and file systems (for
example, OpenVMS and Indexed to UNIX and relational).
2. Import the data definitions:
• Use the Migration Profile to import your PDL and generate the dictionary objects (such as
Elements and Files). Import your SQL files as well if you are migrating from a relational
database and you want the database objects translated by Axiant 4GL.
If you are migrating to a target relational database, this also generates database objects
(such as tables) and makes automatic global changes to normalize the data (removing
arrays, substructures, item redefinitions, and coded records).
• Apply your own global changes to your dictionary and database objects, using the
Change Manager. This can include name changes (such as hyphens to underscores), key
and index changes, and customized solutions for normalization.
3. Import the component programs:
• Use the Migration Profile to generate Axiant 4GL program objects (such as screens, runs,
and reports) from your program source files.
You can group programs into program sets to identify the work related to only your pilot
application.
The Advice tool identifies migration issues to be aware of (such as OpenVMS-specific
code).

Name changes applied during the data definition migration are automatically applied to
your programs. You can also customize any program changes for the new platform or file
system.
4. Export the data definition source files:
• Use the Generate PDL tool to create the PDL file for your target platform and file system,
automatically removing options specific to OpenVMS and its file systems.
• Use the Maintain Databases tool to create the SQL file if you are migrating to a relational
database.
You can now edit these files for further customization, if desired.
5. Export the component program source files:
• When you imported the OpenVMS program source files into Axiant 4GL, they were
converted into Axiant 4GL objects. Compiling the application with a UNIX, Linux, or
Windows Build Profile creates *.qks, *.qts, *.qzs and other source files for your platform,
automatically removing options specific to OpenVMS and its file systems. Programs for a
relational file system also have the IN database option added.
• You can now edit these files for further customization. (For example, QDESIGN
procedural code statements with syntax specific to OpenVMS are not automatically
edited, so this is a good time to make these changes.)
• Use the Build Profile tool to identify what you want to compile, along with any compile
options.
You can specify a remote compile directly across the network to your target UNIX,
Linux, or Windows server, or you can do a local compile on your PC and save the
resulting source files, to be sent to your target platform later (using a tool like FTP for
UNIX or Linux, or a network copy for Windows). The local compile approach allows
you to separate the compile and send processes. However you must remember to set the
Keep Temporary Files flag in your Build Profile.
Axiant 4GL includes a powerful Find Object tool for making global changes to programs while
they are still Axiant 4GL objects. However you may prefer to make your edits after generating the
source files, using a UNIX, Linux, or Windows text editor. This depends on your own comfort
level with the various tools.
For target file systems like Oracle and DB2, you may wish to disable the generation of primary
keys. Oracle and DB2 automatically create a unique index for each primary key, but they only
allow one index on the primary key and you likely have your own index defined. To avoid this
conflict in Step 7, clear the Generate: primary key check box in the Migration Profile during your
data definitions import.
For a target file system that is relational, Axiant 4GL also generates foreign keys when it detects a
table whose primary key is a column in another table. Foreign keys, similar to the LOOKUP ON
syntax in QDESIGN but evaluated at write time, are a useful component of referential integrity
within a relational database.
For a migration from non-relational to relational, the subfile dictionaries (*.psd) need to have all
hyphens replaced with underscores (except for Leading or Trailing minus signs). For more
information, see "4. Send Files to Your Target Platform" (p. 57).
4. Send Files to Your Target Platform

If your target platform is a Windows server, simply copy all the files for your pilot application to
that server, ideally preserving the separate folder structures.
If your target platform is a UNIX or Linux server, follow the same FTP procedure used when
sending the original files from OpenVMS to Windows, ideally preserving the separate folder
structures. (If you are using remote compiles, you do not need to resend the program source files.)
Again ensure that all files are sent with the ASCII transfer format except for the data file of each
portable subfile (which uses the BINARY transfer format).
For a migration from a non-relational file system to a relational database, the subfile dictionaries
(*.psd) need to have all hyphens replaced with underscores (except for Leading or Trailing minus
signs). This can be done with two simple UNIX or Linux scripts:

• In an editor, create the script sub_strings.txt in the SUBFILES directory:

s/-/_g
s/"_/"-/g
• In an editor, create the script replace_hyphens.txt in the SUBFILES directory:
foreach p (‘ls *.psd‘)
sed -f sub_strings.txt $p > tempfile
mv tempfile $p
end
Note: the ls command (‘ls *.psd‘) is placed within grave marks (‘), not quotation marks.
The grave key is located above the Tab key on most full sized keyboards. It is to the left of the
space bar on many laptops.
• On UNIX or Linux, type source replace_hyphens.txt to invoke the script. On Windows,
this can be done after installing a UNIX emulation toolkit (such as MKS).
Migrate without the Axiant 4GL Migration Tools

If you are not employing the Axiant 4GL migration tools, your migration involves the following
activities:
❑ Collect your OpenVMS files (as identified in Steps 3 and 4 of the Twelve Step Plan).
❑ Send your files to your target platform.
❑ For the pilot portion of your application, convert the PDL, SQL, and component programs to
formats for your target platform and file system(s).
Collect your OpenVMS Files

Obtain a current PDL definition of your OpenVMS application, or use QSHOW to generate one:
> SET LANGUAGE PDL
> SET SECURITY
> GENERATE ALL
Use QTP to transfer the data into portable subfiles. Also convert any data currently in permanent
subfiles to portable subfiles for transfer to the new platform. Use QTP instead of QUIZ because of
internal differences in generating the mini dictionaries (such as the way arrays are described).
QUIZ subfile contents are also based on the items in the REPORT statement, which has a
maximum record length of 256 characters.
When writing your data to portable subfiles, you do not usually have to code ITEM statements.
For example:
• If you are migrating from RMS ISAM to a relational database, also run QSHOW to generate
an initial SQL definition from your dictionary. See (p. 43).
• If you are migrating from a relational database to a relational database, use a database utility
to generate the SQL DDL into a .SQL file.
Send Files to Target Platform

On OpenVMS, we suggest you place your various application files into separate directories based
on component (for example: PDL, QUICK, QTP, QUIZ, subfiles, 3GLs, SQL, and command files).
They can then be sent to separate corresponding folders on Windows. Use an FTP tool to transfer
all of your application files from OpenVMS to the corresponding folders in the Windows
environment.
When using FTP, ensure that you have both the .PS and .PSD files for each portable subfile. Use
the ASCII file transfer format when sending all files from OpenVMS to UNIX or Linux, except for
the data file of each subfile.
It is important to send the data files for all subfiles using the BINARY transfer format of the FTP
tool (even though the data files simply contain ASCII text). If you use the ASCII transfer format, it
inserts a line feed character at the end of each record. PowerHouse 4GL subfile data files should
not have this character inserted.

Convert Your Files

This section only applies to the pilot portion of your application.
First, for UNIX or Linux migrations only, rename your file extensions to be lower case. For
example
• Move into the SUBFILES folder, then type
mv *.PSD *.psd
followed by
mv *.PS *.ps.
• Use similar mv commands in the other folders (such as mv *.QKS *.qks for QUICK).
Second, optionally use some unsupported UNIX or Linux tools to identify code that needs
changing and to automatically make some of those changes. (If your target platform is Windows,
you can still use the first two of these tools if you have software emulating the UNIX environment
on Windows, such as the MKS Toolkit.) The tools are known as PowerHouse 4GL Migration
scripts, and they can be downloaded from http://www.ibm.com/support, under Documents,
PowerHouse 4GL 8.4, and Utility. Run some or all of them, depending on whether they apply to
your goals:
• phflag: This script searches program source files for platform specific syntax. An asterisk is
inserted in the first column of each lining containing non-portable syntax, and the program is
placed in the directory specified by the PHFIX environment variable. (This is a skeleton script
that may not include all platform specific syntax. You may wish to add additional search
strings to it.)
• phparse: This script parses program source files and moves programs that fail to compile into
the directory specified by the PHFIX environment variable.
• phlower: This script downshifts all characters in a set of files except for quoted strings and
comments after a semicolon. Use this if you are renaming all your data objects and file names
to lower case. Before executing this script, you must download and compile the C program
phdown, which is called from phlower.
• phfilename.csh or phfilename.sh: This script alters the case of file names. Use this, along
with phlower, if you are renaming your entire file names to lower case.
Third, edit your PDL to adapt it to your new platform and file system(s). Use the results of the
phflag and phparse scripts, as well as the appropriate earlier chapters in this guide:
• "The Target Platform: UNIX or Linux" (p. 13)
• "The Target Platform: Windows" (p. 27)
• "Indexed to Indexed" (p. 41)
• "RMS ISAM to Relational" (p. 42)
• "Migrating from Relational" (p. 49)
• "Direct and Sequential Files" (p. 48)
• "Relative Files" (p. 48)
If you are migrating from a non-relational file system to a relational database, you must also
create an SQL data definition file, as described in "Data Definitions" (p. 42).
If you are migrating from a relational database to a relational database, edit your .SQL file to
adapt it to your new relational database.
Fourth, edit your component programs to adapt them to your new platform and file system(s). As
with your data definition changes, this can be done using the results of the phflag and phparse
scripts as well as the appropriate earlier chapters in this guide.
For a migration from non-relational to relational, the subfile dictionaries (*.psd) need to have all
hyphens replaced with underscores (except for Leading or Trailing minus signs). This can be done
with two simple UNIX or Linux scripts.
• In an editor, create the script sub_strings.txt in the SUBFILES directory:
s/-/_g
s/"_/"-/g

• In an editor, create the script replace_hyphens.txt in the SUBFILES directory:

foreach p (‘ls *.psd‘)
sed -f sub_strings.txt $p > tempfile
mv tempfile $p
end
Note: the ls command (‘ls *.psd‘) is placed within grave (‘) marks, not quotation marks.
The grave key is located above the Tab key on most full sized keyboards. It is to the left of the
space bar on many laptops.
• On UNIX and Linux, type source replace_hyphens.txt to invoke the script. On
Windows, this can be done after installing a UNIX emulation toolkit (such as MKS).
Step 7: Assemble the Pilot Application

At this stage, you have all the source files (both data definitions and programs) on your target
platform and converted to work with your target file system(s). To assemble the pilot application,
use the following steps:
❑ Build the relational database (if applicable) using the migrated SQL.
❑ Build the PowerHouse dictionary using the migrated PDL.
❑ Create the indexed, sequential, and direct files using QUTIL.
❑ Load the data into the file systems using QTP and the migrated subfiles.
❑ Convert migrated command files into UNIX or Linux scripts or Windows command files, as
appropriate. For more information, see (p. 14) for UNIX and Linux or (p. 28) for Windows.
❑ Compile and test the pilot application, modifying the data definitions and programs as needed
to fit the target platform and file system(s).
❑ Modify the data definitions and programs as desired to take advantage of platform or file
system features that were not available on the original platform.
❑ Apply system, application, and data security (if part of your pilot application).
Step 8: Assess Steps 2 through 7

Assess your pilot application by asking the following questions:
• Is the application definition (Step 1) appropriate?
• Is your inventory (Step 3) complete?
• Did your plan (Step 4) omit anything?
• Did things move as expected?
This is the stage where you modify your activities in Steps 2 through 7 in order to arrive at a pilot
application that is ready for a user evaluation. It may require several cycles before proceeding to
Step 9. At this point, you may also want to consider volume testing and/or performance testing.
Step 9: Have Users Evaluate the Pilot

Testing for user acceptance on a pilot application can identify issues that will save you much effort
when it comes to migrating the full application. Among other things, ask the following questions:
• Are the expectations of the users being met?
• Are the expectations of the users realistic?
• Are your UI standards appropriate?
• Do the users need more training?
• Is the security appropriate?
As you test for user acceptance, you will probably uncover issues about user requirements and the
user interface in the new environment. Early user involvement also ensures a higher level of user
acceptance of the new application, as they have had direct involvement throughout the process.

Step 10: Assess Steps 2 through 9

Modify the activities in Steps 2 through 9 based on the feedback from your users, and also based
on what you (the migration team) have learned during the pilot migration. For example, you may
want to look at
• additional training, hardware, or software
• changes in file systems, server topology, or user interface
Step 11: Plan the Complete Migration

Now that you know what is involved in such a migration, you can make decisions about the
complete application. We recommend delaying these final decisions until this point in the process,
since they can be affected by discoveries during the pilot migration.
Step 12: Do the Complete Migration

Incorporating any planning changes made during Step 11, you are now ready to apply the 12-step
process to the migration of the complete application.
In Conclusion
The following are key decisions to make in planning your migration from OpenVMS:
• Target platform: UNIX, Linux, or Windows
• Target file systems: Relational, indexed, direct or sequential
• End-user UI: Terminal, Windows GUI (using Axiant 4GL), or Web Browser (using
PowerHouse Web)
• Migration method: using Axiant 4GL migration tools or using editors and UNIX or Linux
scripts
• Migration timing: what do you move and in what sequence?
You now have the resources to make these decisions.


Index
Numerics DO EXTERNAL
UNIX, 21
3GL locking
Windows, 35
UNIX, 22
DSC, See dictionary security classes
Windows, 35
dynamic function keys, 25, 39
A E
application security classes
education, 53
UNIX, 20
end-user UI
Windows, 33
choosing, 10, 11
arrays, 44
environment variables
ASC, See application security classes
UNIX, 14, 15
Windows, 27, 28
B execution time parameters, 38
backwards access UNIX, 20
UNIX, 25 Windows, 33
Windows, 38
Build Profile tool, 57 F
BuildExternal, 35
file extensions, 56, 59
PowerHouse on UNIX, 17
C PowerHouse on Windows, 30
case sensitivity UNIX, 14
Sybase, 43, 50 Windows, 27
UNIX, 13, 18 file names
Windows, 27 UNIX, 13
choosing Windows, 27
end-user UI, 10, 11 file systems, 41-51
file systems, 9, 10 choosing, 9, 10
platforms, 9 file transfer, 56, 57, 58
C-ISAM, 23, 25 file versioning, 16, 29
coded records, 45 files
command files, 14, 15, 28 access control, 16
Command Prompt window, 30, 34 renaming, 59
copyright, 2 Find Object tool, 57
courses, 53 first record, 48
cursors, 47 folders, Windows, 27
foreign keys, 57
FTP, 56, 57, 58
D function keys
datatype mappings, 41, 50 dynamic, 25
DCL command files, See command files
designated files
UNIX, 18
H
Windows, 31 hyphens, 43, 59
dictionary security classes
UNIX, 20 I
Windows, 33
IBM Cognos Axiant
direct files, 10, 48
Build Profile, 57
directory paths, UNIX, 13
Find Object, 57
DISAM, 37, 38
Migration Profile, 56
datatype mappings, 50
migration tools, 55
opens, 41

63
Index
indexed P
See also RMS ISAM
parameters
subfiles, 23, 37
execution time, 38
to indexed, 41
Path variable
to relational, 42
UNIX, 16
Indexed files, See RMS ISAM files
Windows, 29
indexes, 46, 50, 57
paths in file names, Windows, 30
overlapping, 41
PDL differences
interrupt control
UNIX, 19, 25
UNIX, 18
Windows, 33, 38
Windows, 31
performance, 9, 10
items
periods in file names, 13
redefinitions, 45
PHD vs. PDL
substructures, 43
UNIX, 19
Windows, 32
K phfilename, 59
keys phlower, 59
dynamic function, 25 phparse, 59
foreign, 57 planning the migration, 53-61
primary, 46, 50, 57 platforms
choosing, 9
UNIX, 13-26
L Windows, 27-39
locking portable subfiles, 55, 58
3GL, 22, 35 POW command, OpenVMS, 18, 32
QKGO, 22, 36 PowerHouse differences
relational, 47 UNIX, 17
logical names Windows, 30
UNIX environment variables, 14, 15 primary keys, 46, 50, 57
Windows environment variables, 27, 28 printer options in QUIZ
UNIX, 24
M Windows, 38
mailbox files (MBX), 49
migrating Q
choices, 9-12 QDESIGN, See QUICK
from RMS files, 48 QKGO
from RMS ISAM, 41 UNIX, 19, 22, 25
overview, 5 Windows, 32, 35, 38
planning, 53-61 QSHOW
to indexed file systems, 48 differences, UNIX, 21
to relational, 42 differences, Windows, 34
tools (UNIX), 59 generating PDL, 55, 58
twelve step plan, 53 generating SQL, 42, 58
with Axiant tools, 55 QTP differences
without Axiant tools, 58 UNIX, 23, 25
Migration Profile, 56 Windows, 36, 39
multiple record layouts, 45 QUICK differences
multi-versioning, See file versioning UNIX, 21, 25
Windows, 34, 38
N QUIZ differences
normalization, 43 UNIX, 24, 26
null values, 46 Windows, 37, 39
QUTIL differences
UNIX, 21
O Windows, 34
operating system commands
UNIX, 14 R
Windows, 28
ordered retrieval, 46 RDB/VMS, 49
overview redefined items, 45
migration, 5

Index
relational, 10 UNIX (cont'd)

cursors, 47 QUIZ differences, 24, 26
locking, 47 QUTIL differences, 21
migrating to, 42 scripts, 59
relative files, 10, 48 subfiles, 17
migrating to indexed files, 48
renaming files, 56, 59 V
RMS ISAM, 10
migrating from, 41 version of document, 2
S W
scripts Windows, 27-39
UNIX, 59 file names, 27
Windows, 28 folders, 27
security, 16, 55 PDL differences, 33, 38
UNIX, 20 QKGO, 38
Windows, 29 QSHOW differences, 34
sequential files, 10, 48 QTP differences, 36, 39
SET JOB in QTP QUICK differences, 34, 38
UNIX, 23 QUIZ differences, 37, 39
Windows, 36 QUTIL differences, 34
SET JOB in QUIZ scripts, 28
UNIX, 24 scripts or batch files, 28
Windows, 37 subfiles, 31
SQL
commands, 47
cursors, 47
generating from Axiant, 57
generating from QSHOW, 42
subfiles
indexed, 23, 37
locations, 17
portable, 55, 58
UNIX, 17, 23, 24
Windows, 31, 37
substructures, 43
supported environments, 7
T
target platforms
UNIX, 13-26
Windows, 27-39
training, 53, 55
twelve step plan, 53
U
UICs, 16
underscores, 43, 59
UNIX, 13-26
case sensitivity, 13
directory paths, 13
file names, 13
migration tools, 59
PDL differences, 19, 25
PHD vs. PDL, 19
platform differences, 13
QKGO, 25
QSHOW differences, 21
QTP differences, 23, 25
QUICK differences, 21, 25

Index

Ibm Cognos Application Development Tools Ibm Cogno Powerhouse 4Gl

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ibm Cognos Application Development Tools Ibm Cogno Powerhouse 4Gl

Uploaded by

Copyright:

Available Formats

IBM Cognos Application Development Tools

IBM Cogno PowerHouse 4GL

Version 8.4G for OpenVMS

Migration Planning Guide Migration Planning Guide

IBM Cognos PowerHouse

About this Document 5

Licensed Materials - Property of IBM

4 IBM Cogno PowerHouse 4GL for OpenVMS

Licensed Materials - Property of IBM

IBM Cognos PowerHouse 4GL Documentation Set

Get an The IBM Cognos PowerHouse 4GL Primer document provides an

IBM Cognos PowerHouse Web Documentation Set

6 IBM Cogno PowerHouse 4GL for OpenVMS

IBM Cognos Axiant 4GL Documentation Set

Migration Planning Guide 7

8 IBM Cogno PowerHouse 4GL for OpenVMS

Key Migration Decisions

Choosing the Target Platform

Licensed Materials - Property of IBM

Choosing the Target File Systems

File System Simplest Migration Other Options

RMS ISAM Indexed Relational

RMS (Direct, Direct, Sequential

RMS (Relative) Indexed (Relative is not

• cost and availability

10 IBM Cogno PowerHouse 4GL for OpenVMS

Choosing the End-User UI

Choosing the Migration Method

Migration Planning Guide 11

Choosing the Migration Timing

Scenario A: Keeping the Same File System Type

Scenario B: Changing File System Types

Scenario C: Merging File Systems

12 IBM Cogno PowerHouse 4GL for OpenVMS

Periods in File Names

Licensed Materials - Property of IBM

UNIX and Linux File Extensions

Operating System Commands

Some Common Commands

Task OpenVMS UNIX, Linux

Change working area SET DEFAULT cd

14 IBM Cogno PowerHouse 4GL for OpenVMS

Task OpenVMS UNIX, Linux

Display all or part of text files TYPE cat, more,

Determine disk usage DIRECTORY /FULL du

Search for text patterns in a file SEARCH grep, egrep,

Terminate a process or job that is running STOP /ID, kill

Rename files RENAME mv

Display current working directory SHOW DEFAULT pwd

Delete files DELETE rm

Delete directories DELETE rmdir

Shorten file names using a logical name or ASSIGN, DEFINE, setenv, =

Sort information, merge files SORT, MERGE sort

Edit text or program files EDIT/EDT vi, ed, ex

Display a list of who is logged on the system SHOW USERS who

Run an executable RUN FILE1.EXE file1

Submit a batch job at a later time SUBMIT at

Example: Logical Names

Example: A Batch Job

An OpenVMS DCL Command File, The UNIX and Linux Equivalent,

Migration Planning Guide 15

An OpenVMS DCL Command File, The UNIX and Linux Equivalent,