Pathmaker Programming Guide

Defining Data for a Pathmaker Project
Preparing for Pathmaker Application Development
2–24 067868 Tandem Computers Incorporated
Defining Data for a
Pathmaker Project
An application built with the Pathmaker product is capable of accessing data in either
an Enscribe or NonStop SQL database, or both. The type of database accessed causes
some differences in the data definition methods. This subsection discusses the data
definition tasks that you perform for a Pathmaker project.
To define data for a Pathmaker application, complete the following tasks:
Document the design of the application data, including the database and other
application data structures (such as an interprocess communication (IPC)
messages and screen fields not found in the database).
Create a physical database for testing. (For Pathmaker applications that access
Enscribe files, the Enscribe files do not have to exist until the application is ready
for testing. For Pathmaker applications that access NonStop SQL tables and
views, the tables and views must exist before the Pathmaker product can be used
to create the application.)
Describe the data to the Pathmaker project:
Load the project’s DDL dictionary by compiling a schema describing the data.
(This step is optional for NonStop SQL tables.)
Create programming language data definitions for use by application
developers by compiling the schema describing the data. (This step is
optional.)
For applications accessing a NonStop SQL database, register the tables and
views.
For applications accessing a NonStop SQL database, define additional access
paths for the tables and views. (This step is optional.)
Some of these tasks require the use of the Pathmaker full screen interface, which is
introduced in “How to Operate the Full Screen Interface” in Section 3.
Note The Pathmaker product requires DEFs and RECORDs used in C services to be compiled by DDL with the
CFIELDALIGN_MATCHED2 command. Doing so ensures that the request and reply IPC elements are
compatible with their counterparts in COBOL services and SCREEN COBOL requesters. As a
consequence of this requirement, field alignment of existing DEFs and RECORDs could change when
they are recompiled with the CFIELDALIGN_MATCHED2 command, making them incompatible with
services, clients, requesters, and database files that use old versions of the DEFs and RECORDs.