Preface

This document is written for database designers, developers and project managers who are new to DP4. It presents the concepts behind the DP4 system and introduces the terminology used throughout DP4 documentation.

The descriptions that follow assume that you already have some knowledge of database management systems. If you have used a database in the past, you have sufficient knowledge to start learning about DP4.

This document tells you about the functionality of DP4. It does not tell you how to use the product. Other documents are available which tell you how to install and upgrade your DP4 systems and how to use the features described in this document. An up-to-date list of DP4 documentation is available from Itim Technology Solutions Technical Support.

An example database called SALESORD based on a Sales Order entry application is used throughout this document. This application exists as a DP4 database and programs. If you want to find out more about the examples, consult the appropriate DP4 product document.


What's New in the Introduction to DP4

This page will tell you about recent changes to this manual. The most recent changes are mentioned first

New in 4.624

  • 30 Apr 2010 Information on DP4 limits updated for 4.624

New in 4.622

  • 22 Jul 2009 Correction to documentation of data type P

  • 13 Aug 2004 Information on DP4 database model and limits updated for 4.622

New in 4.620

  • 04 Oct 2003 Information on DP4 Programming updated

  • 17 Oct 2002 What's New page added

  • 17 Oct 2002 Information about DP4 Thin Client (Terminal Server) added.


DP4 Overview

DP4 is a development environment for creating database applications to run on PC workstations. DP4 is used for developing systems of all levels of complexity for business areas such as retail and banking. The core system consists of an ADE (application development environment), and a runtime environment.

The DP4 application development environment provides you with the tools for designing and implementing a database application based on the relational model. A relational database stores information in tables, and allows record selection using the keys in the table. The DP4 relational database allows you to look at and edit more than one table at a time. For example, if you have a set of customer records and a set of order records, you can look at and change both sets of information simultaneously.

DP4 supports the development of your database from entity modelling and table specification through to database distribution and maintenance. The development environment provides a complete set of tools for the creation of application programs in C/C++ (other lanaguages are supported on some platforms), and fourth-generation environments such as QA Build and Report Writer.

The DP4 runtime environment supports a client/server architecture, with the possibility to use the server machine as an additional workstation. You can configure DP4 to suit the requirements of your system. The configurations range from a simple networked system, with one server and several clients, to more complex systems that use more than one server for distributed databases. You can set up your system to ensure non-stop working of an application using the DP4 resilience scheme.

If you wish to use special-purpose devices such as scanners, receipt printers and LED displays, you can access these from within your DP4 application programs. You can view and update data stored in databases and file systems from other suppliers, and they can update DP4 databases.

The DP4 runtime environment is supplied for Microsoft Windows from Windows 3.1 right up to Windows 2000 and Windows Me, many Unix and Linux platforms including high end platforms such as the Sun Solaris and IBM RS6000, as well as legacy platforms such as MS-DOS,FlexOS OS/2 and Presentation Manager. The supported network environments are TCP/IP,IPX/SPX, NetBIOS, TCP/IP and FlexNET.

The application development environment uses all the features of the runtime environment. As a result, you can develop and test an application on one operating system, and port to another platform with little or no extra development time. You can develop an application independently from the devices and the network configuration that will be used for the delivered system.


Application Development Environment

DP4 gives you the tools to develop a database from the initial design through to the fully implemented system. This diagram shows a simplified view of the application development environment:

This section contains a brief overview of the following topics, which are covered in greater detail in other sections of this manual:

  • DP4 Database Management System
  • Data Dictionary
  • User Interface Specification
  • Device Integration
  • Network Resilience
  • Auxiliary Database Management
  • Programming Tools
  • System Code


DP4 Database Management System

The DP4 Database Management System (DP4 Database Management System (DBMS) ) is a set of tools for implementing and maintaining a relational database. The DP4 DBMS supports the development of applications that are data independent and operating-system independent and is described more fully here.


Data Dictionary

From your database design, you set up the data dictionary for the database. The data dictionary describes all the tables and fields used in your database. You create your database the database setup utility (MAKEDB). You can learn about how to design a DP4 database here.

You can use create a plan of all the tables on your database with the data dictionary planner.

DP4 automatically generates database structure information from your table definitions. The structure information includes the indexes used to find records, and the links between each table.


User Interface Specification

In DP4, maps are used to define the output from an application, and to accept input. The maps are displayed by the user interface manager at runtime, as they are requested by an application.

Maps are set up using a special editor, which you use to enter the display text and define the positions of the fields. You define maps in the same way for displaying screens and windows, and for outputting forms to a printer. Maps are stored and edited independently from application programs. If you change the text on a map, you do not need to recompile your application programs.

You can learn more about the DP4 user interface and maps here.


Device Driver Interface

Device Integration

A range of devices can be accessed in DP4 using a facility called device integration. The DP4 Operating System Device Interface package can be used to define drivers for special devices. For example, a device driver may be needed for an input device such as a scanner or a magnetic stripe reader, and an output device such as a receipt printer or an operator display. In each case, your application need not know the characteristics of the device.

Devices in DP4 are maintained separately from an application, and are accessed by their device names. If the parameters of a device change, the changes need only be made to the definition on the DP4 System Database


Network Resilience

Applications developed using DP4 run without change on a network system. DP4 provides the tools to add resilience to a system by maintaining more than one copy of a database. Although any DP4 application will run in a resilient environment there are some special considerations to be taken into account when designing an application intended for a resilient environment.

Two of the most common networked configurations of DP4 are introduced here.


Auxiliary Database Management

Using the Auxilary Database Controller pack you can add your own code to the DP4 database manager to support communications with other database systems and file systems, or to add business logic to the database.


Programming Tools

DP4 offers a range of program development environments:

The figure shows the different levels of programming tools available to the developer. In general, the higher level of the language, the less training and experience is required to produce a program and the more quickly a program can be produced.

  • QA Build is the DP4 fourth generation tool for producing application programs by answering a series of questions. Report Writer is a specialised tool for writing reports quickly. SQL is a standard command interface for querying and updating your database.

  • The DP4 C programming environment provides you with the tools to develop powerful applications. C Programming (and BASIC on the IBM 4690) are third generation environments that you use to produce a compiled executable program. As with all data processing tools, there is a trade-off between the ease of use of a programming environment, and the flexibility and ability to perform complex actions.

  • On Windows platforms you have the choice of using other application development environments and accessing DP4 databases using either a DLL based version of the DP4 database API, or SQL via ODBC.


System Code

DP4 allows system code to be developed and maintained separately from database applications. System code can be used for the following purposes:

  • Supporting a device using a special driver or OSDI

  • Handling a connection to an auxiliary database or file system

  • Managing messages between your DP4 system and a host system

  • Adding routines written in C to a QA Build program

You can use system code to add flexibility and intelligence to an application, without adding to the complexity of an application program.


Runtime Environment

The DP4 runtime environment provides a set of components that add layers of independence to your database application. A simplified view of the runtime system is shown below.

The two main DP4 components are the database manager and the user interface manager (usually known as the terminal manager). DP4 uses these components when a DP4 application is run.

This topic is divided into the following sub-topics:

  • Database Manager
  • User Interface Manager
  • Networks and Resilience


Database Manager

The calls made by your program to access the database are processed by the database manager. The database manager fulfils these functions:

  • Data Independence

    The database manager supports data independence since it provides an interface between the application program and the database. The application is insulated from the details of physical storage. Data independence ensures that provided the logic of the application program is not affected, you can change the database structure without changing your application

  • Referential Integrity

    Relationships between tables can be set up so that entries in one table (a child table) depend upon the presence of a matching entry in another table (a parent table). Referential integrity protects these relationships. For example, you can have the records in a child table deleted automatically when the matching record in a parent table is deleted. Alternatively, you can prevent the deletion of a parent record when there are matching child records on the database

  • Data Recovery

    The mechanism by which the database manager ensures that data can be recovered is transaction logging and roll-back logging . Each time information is posted to the database, the transaction log and the roll-back log are also updated. If a temporary failure occurs, the database manager uses the roll-back log to roll back the database to the state it was in before the temporary failure. If a data error occurs, then a backup of the database can be restored from disk, and the transaction log is used to roll-forward the database to the state it was in before the failure

  • Access Control

    DP4 controls access to your database. You can allocate an access level to each table on the database and each field in a table. The database manager permits users to see records that match their read access level, and to change records that match their write access level

  • Multi-user Control

    In multi-user systems, contention control is handled by the database manager to prevent two users updating the same record at the same time. DP4 supports both change verify and record locking


User Interface Manager

Whilst the database manager provides an interface between the application program and the database, the DP4 user interface manager, or terminal manager provides an interface between the application and the workstation. In this context, the workstation consists of the screen, the keyboard and the operating system on the machine.

The terminal manager insulates the application from the operating system and hardware in the following ways:

  • Keyboard Management

    When the user presses a key, the user interface manager processes the keystroke, and sends the information to the application in a standardised form. You can modify the key translation table to reassign keys, such as redefining the help key to <F1> or <Ctrl><F3>

  • Map Output

    The user interface manager reads the layout of the screen from the currently selected map at runtime. If you change the text defined by the map (for example because you want to provide a localised version to run in another country), you do not need to change or recompile your application program. The application does not need to know if it is running in a text based environment or a GUI. The application may not even be running on the same computer as the terminal manager.

  • Device Independence

    Devices are set up on the system database and are independent of the application. Your application selects a named device at runtime. The user interface manager then reads the device information and inputs from or outputs to the device. As a result, your application is device independent.

The DP4 User Interface is described in greater detail here.


Networks and Resilience

DP4 is based on a client/server architecture. You can configure your system to run over a network by setting up a server machine. The DP4 utilities and the database are installed on this machine, which can also be used as a workstation in its own right, and workstations access the database over the network.

Each workstation runs its own copy of the user interface manager, allowing different types of workstations to be used on the same system.

There are many possible configurations of DP4 networking. Two of the most important are:

  • Distributed Databases

    DP4 allows you to access more than one server over a network. This means that a program can update databases in different locations. The program does not need to know how a database is distributed. The application simply makes a call to update the database, and the database manager consults a control table to discover the location of the table.

  • Resilience

    In a resilience system, a copy of the database is maintained on more than one server. Resilience systems ensure non-stop working of an application, since a failure on one of the servers does not affect the working of the second server. If a server fails, it may be off-line temporarily, but the second server continues as normal. As soon as the failed server is back on line, it can be updated with any transactions recorded on the second server during the failure.

You can find out more about DP4 networking in Resilience and Distributed Databases.


Database Management Syste,

Database Management system

Diagram The DP4 database management system includes a set of development tools and a runtime program called the database manager. This is a component that handles the storage of data and retrieves data when it is requested by an application.

The DP4 database manager provides an interface between your application program and the database. Your application program does not need to know how the data is stored on disk in order to access and change the information on the database. It is possible to extend or even completely replace the database manager with components that access data over a network or from another database management system such as Oracle.

The following topics have more information about the core DP4 database manager:

  • Database Model
  • Physical Model
  • Security and Integrity
  • Database Administration
  • Distribution and Version Control


Database Model

The DP4 database management system is based on the relational database model. In a relational database, the entities in a system are represented as tables. A table is a two-dimensional array in which the columns define the fields in a record, and the rows represent different records.

This topic is divided into the following sub-topics:

  • Entity Modelling
  • Entity Relationships
  • Table Definition
  • Field Definition
  • Primary Key
  • Relationships Between Tables
  • Referential Integrity
  • Field Roles
  • Data Types
  • Range of Occurrences
  • Data Dictionary Plan
  • Automatic Increment of Key Values
  • Indexes
  • Record Sequence and Key Precedence


Entity Modelling

To define a database, you begin by designing a simplified model of the real-world, in which entities represent logical collections of values. For example, you may group the set of details that describe a customer into an entity, and the set of details that describe a material into another entity. The process of designing a database is known as entity modelling.

In a sales order system, entities are required to represent customers, orders and materials. At the design stage, you identify the information that is to be stored. For example, the customer information normally includes the name and address:

Jones Builders, 121 Main Road, Cambridge

A first approximation of the entities in a sales order system is shown here:


Entity Relationships

Two of the relationships between the entities in the example sales order system are:

  • Customers place orders

  • Materials are specified in orders

The first approximation of the entities is shown in Figure 6. In order to show the relationships between the entities, an entity relationship diagram is used. An entity relationship diagram shows the one-to-many relationships between the entities in a system. The design represents the relationships between the entities in third normal form.

In a sales order system, there are three main entities: CUSTOMER, ORDER and MATERIAL. However, an ORDER entity would not be in third normal form since an order for a single customer can include many materials. An order can therefore be separated into two parts, ORDER HEADER and ORDER LINE. The ORDER HEADER includes the date the order was placed, the customer number and the total value of the order. The ORDER LINE identifies each of the materials ordered. There is a one-to-many relationship between the ORDER HEADER and the ORDER LINE entities.

Once your entities are represented as tables in a DP4 database, the relationships between the tables are known as parent-child relationships. For example, in the diagram shown above, the CUSTOMER table is the parent of the ORDER HEADER table.


Table Definition

Entities are represented as tables on your database. You can have up to 32,000 tables on your database. Each instance of an entity is represented as a record in a table. A record consists of one or more fields that define the type of information that is stored in the table.

Here is an example of a table representing the details of materials in stock:

Material Code | Description | Quantity in Stock | Price
12345 | Paint | 200 | 2.56
34567 | Cement | 50 | 4.00
56789 | Hardboard | 100 | 5.00

To define a table, you first need to identify the individual items of information that are to be stored. Each item of information is represented as a field. The field definitions form the columns of the table. In the MATERIAL table above, the column headings are Material Code, Description, Quantity In Stock and Price. The names need to be modified before they can be used as unique field names in a table definition. They are changed to upper-case, and the spaces are removed.

For example, "Material Code" becomes MATERIAL_CODE. The definition of the fields in the MATERIAL table is shown in the example table plan on the right

In the example, the number 1 next to the MATERIAL_CODE field indicates that this field is a key field. The codes to the right of the field names indicate the data type and size of the fields.


Field Definition

  • For each field in the table, the type and size of the field is selected. For the fields in the MATERIAL table, these are:

    P8

    Up to 8 pseudo-numeric characters can be entered for the material code key. This field type is suitable for storing a bar code

    C20

    Up to 20 ASCII characters can be entered for the material description, in upper and lower case

    N8

    Up to 8 digits can be entered for the price field. This includes the decimal point

    I5

    Up to 5 digits of an integer, including the sign, can be entered for the quantity in stock (a number between -9999 and 30000)

  • For numeric, date and time fields you can also specify the valid range of values. Other parts of DP4 can (and do) check entered data is within range.


Primary Key

Each record in a table has a unique primary key. At the database design stage, you select the fields that identify the records. You may need to introduce new fields to ensure record uniqueness. For example, in a customer table, the customer name is not guaranteed unique, but a numeric field CUSTOMER_NUMBER can be introduced to act as the primary key.

You can define a multi-part key, composed of up to 99 fields. The ORDER_LINE table below has a two part key:

The precedence of the key fields is shown by the number on the left. In the ORDER_LINE table, ORDER_NUMBER is the first part of the key and takes precedence over the LINE key field.

The MATERIAL_CODE field is marked with an asterisk. This indicates that this field is a secondary key. Secondary keys define a link to another table.


Relationships Between Tables

DP4 derives the structure of your database from an analysis of the tables on your database. A parent-child link is derived where you include the primary key of the parent table in the child table.

For example, customers place orders, and there is a requirement to find the order record for a customer. You create a link by including the key of the CUSTOMER table, CUSTOMER_NUMBER, as a secondary key in the ORDER_HEADER table:

The database manager uses this structural information for indexing and referential integrity, and QA Build and Report Writer use it to provide predetermined access paths between records.


Referential Integrity

You can apply rules to the relationships between tables. The rules specify how an action on one table affects the other tables in the database. DP4 automatically implements the rules when the table is accessed. This can reduce the amount of development time needed for an application program.

The rules of referential integrity are:

  • Parent Check

    Check a parent record exists before inserting a child. For example, check that a customer exists before an order can be created for the customer

  • Update

    Maintain an index link to another table. For example, make sure DP4 updates the link between order lines and materials when a change is made

  • Prevent Change

    Ensure the key fields that identify the parent table cannot be changed. For example, make sure the customer for an existing order cannot be changed

  • Orphan Check

    Do not allow a parent record to be deleted if there are children. For example, do not allow the deletion of a customer for which orders exist

  • Child Delete

    Delete all the child records of a deleted parent. For example, when a customer is deleted, delete all their outstanding orders (order header and order line records)

  • Parent Verify

    Check whether a parent record has been updated since it was last read. For example, make sure the material price is still the same before updating an order line


Field Roles

You can specify a role for a field in a table where you wish to store the same type of information as an existing field. For example, on the MATERIAL table, we want to ensure that a material is reordered when there is a specific number left in stock. This means adding another field:

QUANTITY_IN_STOCK | I5
REORDER_LEVEL | I5

In both cases, the type of information is the same. A better way of identifying the fields is to use the same field name with different roles:

QUANTITY (IN_STOCK) | I5
QUANTITY (REORDER_LEVEL) | I5

Both fields are QUANTITY fields, and so share the same size and type checking, and the same upper and lower limits.

You can use the role facility to specify two links to a parent table. For example, the MATERIAL table includes two links to the SUPPLIER table:

SUPPLIER_NUMBER (PRINCIPAL)

SUPPLIER_NUMBER (ALTERNATIVE)

In this example, if the principal supplier cannot supply a material, the alternative supplier record is retrieved.


Data Types

The standard data types supported by DP4 are:

Type | Code | Description
Character | C | A string of ASCII characters
Date | D | A field used to store the year, month and day
Integer | I | Standard 2-byte signed integer, with the low-order byte first
Long integer | L | A 4-byte signed integer with the low word first. This is the format used by most compilers which support 32-bit integers
Mixed case | M | A field like the C character type, except that this type is not case sensitive in indexes, and so "SMITH" and "smith" appear next to each other in an index
Number | N | DP4 implements this type according to the language format you choose for your database. For example, for the Microsoft C programming language, the IEEE real number system is used
Pseudo numeric | P | A character field composed only of the characters '0..9'
Time | T | A field composed of hours, minutes, seconds and hundredths of seconds
Boolean (Yes/No) | Y | A field for which only two values are allowed, for example "Yes" and "No"
Upper case | U | A character field suited for use as a key field. You can change the collate sequence of U type characters. This facility is used for national language support and to indicate the precedence of non-alphabetic characters such as @ and #

You can change the way each field type is entered and displayed on your database. Although the fields are always stored in the same way, the entry and display is user-specific. For example, for the date field, you can specify the order of the day, month and year parts, and whether the month is shown as a name or a number.


Range of Occurrences

Fields in DP4 can have up to 99 occurrences. The use of occurrences allows lines of data and lists of numbers to be treated as a single field. For example, for an address field, you may allow four lines for an address:

13 Cherry Lane
Wheathampstead
Hertfordshire
AL10 6BP

The address field is defined as a multi-occurs field with four occurrences.

Numeric multi-occurs fields can be thought of as an array or list of numbers. If you wish to store 12 values representing the budget for each month of a year, you define a field BUDGET with 12 occurrences. To reference the budget for March, the programmer writes:

BUDGET[3]


Data Dictionary Plan

The DP4 data dictionary planner (TABLEPLN) or can be used to print out a table plan of the tables on the database:

In the example, the lines are drawn to show the relationship between the tables. DP4 automatically shows the data type and size of each field in a table. Key fields are marked with a number to indicate the key precedence, or an asterisk (*) to indicate a secondary key that indexes another table.


Automatic Increment of Key Values

If the primary key field has the data type 'Number', this key can be automatically incremented by the DP4 system. A multi-part key can also be incremented in this way, provided that the last part of the key is a number. If you use this feature, then each time a user enters a new record, DP4 supplies the next number in the sequence. For example, for the CUSTOMER table in the example Sales Order database, the customer number is allocated automatically.

In a multi-user system, the numbers remain contiguous, even if users abandon half-completed transactions.


Indexes

Records in a table are indexed by the primary key of the table. For example, a customer record is indexed by the key CUSTOMER_NUMBER. As a rule, the customers are displayed in the order of the key field.

Records can also be indexed by tables higher in the table structure. For example, the CUSTOMER_NUMBER is included as a secondary key in the ORDER_HEADER table. This allows order records to be indexed in customer sequence.

If you want to index the records in a table by a key other than the primary key of the table, you define an index-only table that uses the desired key as its primary key. It is not necessary to do this where one of the other data tables already uses this key.

For example, to view the records on the CUSTOMER table in order of the customer name, an index-only table can be used. This table defines CUSTOMER_NAME as the key field on the table:

The index-only table is a parent table of the CUSTOMER table, and allows the customer records to be viewed in name order.


Record Sequence and Key Precedence

If an index has more than one key field, the precedence of the key fields is significant. For example, order lines have the key fields ORDER_NUMBER and LINE. The records can be indexed in two sequences: ORDER_NUMBER/LINE or LINE/ORDER_NUMBER.

DP4 asks you what you want the key sequence to be. Here, there is a natural precedence: ORDER_NUMBER comes before MATERIAL_CODE. Where there is no natural precedence, it does not matter which precedence you choose, but you have the option to control the choice. If you wish to use both indexes, you can do this by defining an index only table with the alternative key sequence.


Physical Model

A DP4 database is stored in these files:

  • The Data (.DAT) file contains all the records stored on the database. From release 4.622 the Data file may be stored in a compressed format.
  • The Data Compression Information (.DCI) file, introduced in release 4.622, contains vital information needed to decode data stored in compressed data files.
  • The Index (.IND) file contains all the indexes for all the records on the database.
  • The Pointer (.PTR) file, introduced in release 4.622, used with databases using a new more space efficient index structure, stores a cross reference between record numbers and the location of the corresponding record in the data file.
  • The transaction log (.LOG) or temporary transaction log (.RLL) is used to safely store new transactions in the database until such time as the database stored on disk is fully updated.
  • The rollback (.RLB) file is used to safely recover the database after a system failure.

In addition there are various other files associated with the DP4 system. All these files are described in more detail in the following topics:

  • Data and Index Files
  • Roll-back and Transaction Logs
  • Other Files
  • DP4 Runtime Files
  • Base Dictionary
  • Location of Database Files


Data and Index Files

As a minimum, your database has a data file and an index file. The data file contains the tables in your database, and all the records stored in them. As well as application data, it contains the data dictionary, the maps and messages used in your database, and any programs written with QA Build, Report Writer or Importer.

The index file provides the access mechanism for data retrieval. This file contains the keys together with pointers to the records in the data file. The index file is structured as a B-Tree.

When a record is deleted, a hole the size of the deleted record is left in the data file. DP4 dynamically re-uses the space. When a new record is added to the database, the database manager places it in the next available free space that is larger than the record.

You can use the status and integrity checking utility to find out what percentage of the data file is being used to store data. The Database Reorganisation utility removes any holes when it compresses the data file.

From release 4.622 databases may also have a Data compression information (DCI) file, and a Data Pointer (PTR) file. The DCI file is used to store information that allows the data file to be compressed more effectively. The (PTR) file contains information about where each record is in the data file. This information used to be in the index file, but storing it separately enables the index to be smaller overall, and speeds up certain database operations.


B-Trees

The index of a DP4 database is organised as a dynamic B-Tree structure. A B-Tree is a balanced multiway tree, in which the parent nodes contain several records and pointers to the child nodes below.

To locate a key, the database manager starts with the root node and compares the key it is searching for with the keys in the nodes following the pointers down through the tree until the correct node is found. A new key is inserted into the tree by moving to the correct point in the tree, moving the existing nodes to the right and putting in the new key and pointer.

A B-Tree provides one of the most efficient ways of organising an index.


Roll-Back and Transaction Logs

The transaction and roll-back log files are used in database recovery. You can specify whether you want DP4 to maintain either or both of these logs. The roll-back file is only maintained on the disk whilst the database is being used, and is deleted when programs terminate normally. The transaction log is normally saved to a removable disk each time you take a backup of your database, and is then cleared from your hard disk.

The transaction log records each database transaction. The log records the transaction data, the nature of the change and the date and time the record is changed. This information can be viewed on screen for testing and audit purposes, and the roll- forward recovery process uses this information to update an earlier version of a database.

The roll-back log stores images of data before changes are made. If a power failure or system crash occurs, the roll-back log can be applied to the database to return the database to the state it was in before the changes were made.

A temporary log is used to improve performance if you do not use a transaction log.


Utility Files

Other Files

As well as the files that make up a database, there are various other files that are associated with your database, or DP4 more generally. These are:

  • Backup files

    Backup files are (or should be!) created periodically, and are normally stored on tape or other backup media.

  • Work files

    DP4 creates various work files when you run a program

  • Spooler files

    Spooler files are created for some operating systems for background printing

  • Console log

    This log records all uses of the DP4 programs, including user name, the time and date, the name of the programs run, and any DP4 errors

  • Extract files

    Extract files are temporary files created during report printing

  • Print files

    Print files are created when you select the option to send printer output to a file. They contain the text of the report or form that has been printed


DP4 Runtime Files

The DP4 runtime system uses these files in addition to your database:

  • System database data and index files

    The system database contains information that is shared across a set of application databases. It contains all the images, help and error messages for the DP4 standard utilities. The list of user names and encrypted passwords with their access levels and language selection is stored on the system database. A set of preferences for display colours, the date and time format, and other setup information is stored for each user.

    The input and output devices available on the system are also defined on the system database. This ensures that application databases are device-independent, and that there is only one set of device definitions to maintain. For example, when a report is ready for output, the application may prompt the user to select a printer from a list of those set up on the system database. The output is formatted according to the parameters set up for the printer on the system. The application need not know whether the selected printer is a dot matrix printer, an inkjet or a laser printer.

  • Licence file

    The licence file is a small file that defines your DP4 licence number and name. This file provides a measure of security against the unauthorised copying of DP4 programs, since it can only be installed from a distribution disk. This file also defines the location of DP4 files, and the console and transaction log settings, as defined during the DP4 setup procedure.

  • Userdata file

    The userdata file defines the characteristics of the workstation you are using. The information in this file tells the DP4 user interface manager if your workstation can display colour, and how the keys on your keyboard are to be translated into ASCII values. This file also stores the default configuration for the colour and preferences on your system.


Base Dictionary

The base dictionary database defines the underlying structure for the data dictionary. An application database is initialised by making a copy of the empty base dictionary.

Each time you add a table or field specification to your database, the information is added to the base dictionary on your application database. Report Writer and QA Build programs are also stored in the base dictionary. Normally, there is no reason for you to know how your database is implemented, and so this information is hidden. However, you can access the underlying database by specifying a command tail to the DP4 utility programs.


Location of Database Files

You can configure your system to store the files in any location you wish. Each of the database file and other file types can be kept in different locations, on local or remote disks. (On some operating systems, such as Windows NT, there are security restrictions imposed by the operating system which make it difficult to store a database on a remote drive.)

For performance reasons, you should always store databases locally if possible. It is a serious error to try to use network directories for storing database files as a means of achieving multi-user operation, and it does not work. You should always use DP4 networking components for this.


Security and Integrity

This topic is divided into the following sub-topics:

  • Data Integrity
  • Change Verify
  • Record Locking


Data Integrity

The security and integrity of a database is a very important concern in database management. If one data item is invalid, the entire database can be affected. If all the data values are correct, then there is data integrity.

These are some of the safeguards used by DP4 to preserve data integrity:

  • Transaction Logging

    The transaction log records each database transaction. The log is used in roll-forward recovery to update an earlier version of a database where the current version is no longer valid.

  • Roll-Back Logging

    The roll-back log stores images of data before changes are made to your database. If you experience a temporary failure such as the loss of power, you can apply the roll-back log to the database, to return the database to the state it was in before the changes were made.

  • Automatic Data Validation

    When the user changes the value of a field, the value is checked against the type defined on the database, and the upper and lower bounds. See (field definition). The validation is applied automatically, independently of any validation carried out by your program.

  • Referential Integrity

    Each time you add or amend a record, the referential integrity rules defined for a table are checked. If the rules are violated, a message is returned.

  • Contention Control

    Where two users attempt to update the same record at the same time, the DP4 change verify mechanism ensures that an appropriate action is taken, and that one of the users is given priority over the other.

  • Backup Facilities

    Facilities are included to back up the database and the transaction log. The user is prompted to take a backup at the intervals you specify (usually once a day)

  • Database Integrity Checking

    A periodic check can be run to ensure that database integrity is maintained. The system user is prompted to run this utility at the intervals specified in the configuration.

  • Access Control

    When users log on, the database manager only allows them to see fields and records that match their read access level, and to change records that match their write access level. Access control can also be applied to the entire database, or to individual programs and menus.

  • User Logging

    A user log records the activities of each user.


Change Verify

In a multi-user system, it is always possible that two users may attempt to update the same record at the same time. In the DP4 system, this type of contention is handled by a change verify process. This procedure allows each user to read the same record from the database. The first user to request an update will be able to do so, and the second will have their commit rejected. If a commit fails, the application may re-read the record and request the update again, after making any necessary adjustments. This type of contention control is also known as optimistic contention control. It is very efficient in systems where there is little contention, as it avoids the overhead of record locking.

In the figure on the right, user A and B read the material record at the same time. User A completes the transaction first and changes the value of the 'Quantity In Stock' field to 401. The record is updated on the database. User B still has 421 as the 'Quantity In Stock' value, and so if user B were allowed to update the database, the new value would not reflect the updates made by user A.

In DP4, if user B attempts to change the record, the attempt to commit the transaction returns an update failure message to the application, to indicate that the record has been updated since user B read it from the database. Normally, user B will re-read the record and modify the changed version of the record. As a developer, you have the choice of whether to make this process automatic, or to leave it to the user.


Record Locking

In addition to change verify, record locking is supported in DP4 as a control that you can apply in your application program. You can specify record locking in your program to ensure that the first user to read a record has the exclusive right to update the record. Other users are not allowed to update the record until the first user has completed the update.

Record locking differs from change verify since the locking is done to the record when it is read by the first user. If the user is slow in completing the transaction, the record may be locked for some time, which can cause problems to other users, or even cause dead-lock (where two users each want to lock a record that the other has already locked and will not unlock the record they already ahve locked). The change verify procedure gives priority to the first of the users to attempt an update. Of the two methods, change verify gives the better performance when the incidence of contention is low.

You are recommended to use record locking sparingly.


Database Administration

The administration of a database includes taking a regular backup of the database, and adding new users to the system. When a new printer is added to the set of devices, you should add a definition of the printer to the system database so that it can be accessed by all DP4 applications. If you upgrade your workstation, and wish to start using a colour monitor, you will need to select the new screen type. DP4 provides a set of utilities to help you carry out these tasks.

This topic is divided into the following sub-topics:

  • Backing up the Database
  • Running Integrity Checks
  • Changes to the Database Structure
  • Adding Users to a System
  • Adding Printers to a System


Backing up the Database

DP4 prompts you to take a backup at the interval specified in your preferences, and also warns you when the transaction log is approaching its maximum size. You can backup your database to disks or to tape.

To backup the database, first make sure you have a supply of backup media, and then run the backup utility. For diskettes, or other removable media, the utility writes the database in a special file format that can be spread over several disks. The backup utility prompts you to label each disk with the name of the database (for example, "SALESORD") and the number of the disk (for example "1 of 3").

The normal practice when backing up a database is to close the database to make sure no-one is using the database. However, DP4 also provides you with the facility to take a dynamic backup while the users are still logged on. This facility is useful in banking and retail situations where a database is in constant use. A recently added feature of this program enables you to back up the database in the normal database format making it possible to check the integrity of the database at the time the backup is taken. This program is the preferred means of backing up the database if you have enough room on your database disk for a complete second copy of the database.


Running Integrity Checks

Loss of data integrity is not always apparent when it first occurs. One item of data may be corrupt, but it may be some time before that item is read and an error message displayed. At this point, you normally restore a database from a backup, and apply the transaction log. However, if there is also a problem with the backup, then a lot of time could be lost. The preferred backup mechanism checks the integreity of the database at the same time as doing the backup, thus eliminating the possibity of creating a bad backup.

To make sure that a corruption does not go unnoticed, DP4 provides a utility to check the records in the database, and report the status of the data and the indexes. DP4 prompts you to perform an integrity check at the intervals specified in the setup. This ensures that you are notified if a corruption has occurred, and you can take corrective action.


Changes to the Database Structure

You can change the structure of a database on a live system without affecting the data on the database. However, if you modify the key field of a table that contains data, DP4 prompts you to reorganise the database.

Other typical structural changes are:

  • Add a new field

  • Modify the data type of a field

  • Modify the size of a character field or the precision of a number field

If you make any structural changes such as these, DP4 increments the generation number of the database. DP4 checks this number before reading or writing a record. Each record on the database, and each application program, also has a generation number.

For Report Writer programs and programs written in third generation languages such as C, DP4 invokes data independence to ensure that records can be accessed and updated correctly, even if the program has a different generation number. QA Build programs need to be recompiled to give them the same generation number as your database.

DP4 implements data independence by recording the mappings of earlier structures as well as the data dictionary information for the current structure. Each time a program reads or writes a record to the database, the generation number is checked. If the generation numbers are different, the database manager translates the record into the current structure.

You should check whether changes to the database structure will affect the logic of your program. For example, the customer name field is changed from 6 characters to 5, and a program name contains a statement like this one:

REPEAT <some actions> UNTIL CUSTOMER NAME = 'ABCDEF'

With this syntax, all customer names would be presented to the program with blank as the last character, so the test can never succeed.

The data independence facility ensures that provided the logic of your program is not affected, you can change the database structure without changing your application programs.


Adding Users to a System

A list of the users of a system is held on the DP4 system database. The information relating to each user includes their password, access levels, language and user defaults.

Users are prompted to log on when they run the DP4 menu system. Alternative menu pages can be displayed that are tailored to the requirements of the user. You can also set up your application program to prompt the user to log on. The log on facility is useful for three reasons:

  • For controlling access to an application

  • To use the DP4 language switching facility

  • To allow the individual preferences for a user to take precedence over the system preferences

These are the details that are entered for each user:

User Information Description

Password

The user is prompted for a password when logging on to DP4. This consists of a word eight characters long

Access levels

The read and write access levels determine what tables and fields the user can view and update, and what programs the user can run

Language

The language selects the set of maps that are to be displayed for this user. This facility can be used to distinguish between a text for beginners and text for advanced users of a system, as well as between different national languages

Menu page

A special menu can be displayed for a user when the menu program is run

You can also:

  • Supply a default database for a user

  • Define formatting and display information for each of the data types for individual users

  • Select colour preferences


Adding Printers to a System

In addition to the keyboard and the screen, you define other devices for use by your DP4 application. As a minimum, if you wish to print from your application, you need to define a printer. All the information about the devices on a system is stored on the system database. Once you have defined the printers and devices used in your system, your application programs simply select the device that is to be used.

In DP4, an output device is defined in two parts:

  • Device group description

    This defines the device and all the possible control information that is required to operate it. For example, you may define all the useful commands that can be sent to a printer, including the commands to change to use the fonts available on a printer

  • Parameterized output device configuration

    This selects the parameters that you wish to use. For example, you may select the control string that chooses the Times Roman font (though this is unlikely to be necessary on a Windows based system).

    Your DP4 application can select a specific output device by name, either in a program, or when the user runs a program. The selection includes any special parameters that are to be sent to the printer.

In the same way, you can access other devices such as a non standard display devices like customer and operator displays, scientific apparatus, bar code readers and magnetic stripe readers in your application. For some devices, you may need to provide a Device Interface (known as an OSDI). An OSDI consists of specialised code written in C. The DP4 OSDI pack ensures that device specific code is independent of your application programs. Your program can access an output device by name, and send the output in exactly the same way as if the device is a printer. Input devices are also specified by name, and the input is presented to the application in the same way as input from the keyboard.


Distribution and Version Control

This topic is divided into the following sub-topics:

  • Distribution Method
  • Distribution to a New User
  • Upgrading an Existing System
  • Upgrading Several User Sites
  • Security of the Installed System


Distribution Method

A database issued as part of a system built with DP4 is normally distributed to users on the CD ROM used to install the application, or alternatively as a backup file spread over several disks. A database distributed in this way includes any Report Writer and QA Build programs you have created. In the latter case the database is restored at the user site by running the utility to restore a database.

If any executable programs associated with the system use an operating system different from your development system, you need to convert the programs before they are distributed.On 16 bit systems, provided that you follow the guidelines for producing operating system-independent programs, no re-compilation is necessary. In 32 bit environments recompilation is required, but it normally straight forward, provided you use only the DP4 APIs or ANSI APIs for C/C++.


Distribution to a New User

If you are distributing an application developed using DP4 to a new user, you also need to include the DP4 licence file, the DP4 system database, and the standard DP4 runtime programs:

The runtime programs include the database manager, the user interface manager, the DP4 setup and database backup utilities. Depending on the configuration of the user system, you may include the DP4 network runtime programs, and any special device drivers required for the user system.


Upgrading an Existing System

For an existing user, you distribute the application and any executable programs:

If you wish to update the list of users of a system, or the set of devices on the user's system, you have two options:

  • You can distribute your system database with the application database

  • You can export the information to an ASCII file with DFSETUP (printers), or MENUEDIT or MENUUSER (user information). This is then imported to the system database using the DP4 utility for posting maps (MAPPOST).


Upgrading Several User Sites

If you make changes to the database structure, and you wish to upgrade several user sites, you can use the DP4 Software Release and Data Distribution (SRDD) utility.

When you have completed the changes to an application, you can use this utility to take a "snapshot" of the database. The utility allocates a new version number to the application database and produces a file of changes, for sending to each of the user sites. At the user site, an automatic mechanism is used to update the user application and report on the success of the operation.

For QA Build development, you can make use of the split database facility. A database can be split into two parts:

  • Program database

  • Application data database

The QA Build programs are run against the data in the application data database. This facility enables you to update the programs on a remote site by simply copying a new program database, leaving the application database undisturbed.


Security of the Installed System

These are the security measures provided for your DP4 application:

  • Data Encryption

    You can specify that you want the data in a table to be encrypted, to make sure that the information cannot be easily read except under the control of DP4. The encryption algorithm is designed for speed rather than ultimate security. It protects against the casual hacker, but not against professional assault. (If you are concerned about this aspect of security, then from 4.622, you should also use Enhanced Data Compression, as the data is then stored in a format which would be extremely difficult for other software to decode.)

  • Table and Field Access Control

    You can restrict user access to the database, at table and field level using the DP4 access control facility. To hide a table or a field from a user, you give it an access level higher than that of the user (or group of users). Alternatively, you can allow a user to see a table, but not to change it, by changing the write access level. Users have read and write access levels between 0 and 99

  • Program Access

    You can assign read and write access levels to a menu option to restrict access to a program. You can assign access levels to your QA Build Programs to restrict access from the menu or the command line

  • Conceal Program Code

    You can ensure that users cannot change QA Build programs by using a 'Conceal' option that hides the program code


User Interface

The DP4 user interface manager provides an interface between the application and the terminal, or workstation. The user interface manager handles all the calls to the keyboard, screen and printers, Using this interface brings a number of benefits:

  • The DP4 user interface manager promotes a consistent way of displaying information and has conveneient functions for entering and checking data to be added to the database. The keystrokes to select an item, move around the screen, and exit the current screen are always the same in programs designed using DP4 making it easy to learn how to use new programs, or a new version of a system that has been ported to a different operating system.

  • DP4 has a user interface which is logically independent of the operating system, so that your application can run both on Microsoft Windows, and other GUI environments, and in text based environments. An application designed for a text based environment subsequently ported to a GUI will automatically support the use of a mouse to select controls, and elements such as Icons, and buttons can be added to the application maps without the need for alterations to program code.

  • A program written using the DP4 user interface can automatically be run using the DP4 Thin Clinent configuration.

  • DP4 helps you to design programs for users with different levels of experience:

    • New users: The on-line help facility can display context-sensitive help for all the fields and menu items in a program.
    • Experienced users: The type-ahead facility allows the experienced user to go directly to a specific point in the program; the display of intervening menus and screens is suppressed.

    • All users: For a screen containing many fields, the user can short-cut to the next screen, and accept default values for the remaining fields.

  • Well-written DP4 programs do not contain "locale" sensitive data (such as message text), so it is easy to translate the system to work in another language. It is even easy to run a single installation in several languages at once.

More information on the user interface is contained in the following topics:

  • DP4 Standard User Interface
  • Text and GUI operation
  • Maps
  • Keyboard Layout
  • Printing
  • User Management
  • Help System
  • National Language Support
  • DP4 Thin Client


DP4 Standard User Interface

All the information that appears on the screen of your DP4 application, or that is printed uses maps.

You can create many different types of map, for example:

  • Dialogs

    Dialogs or data entry maps are used to change the data on a database or to select such things as file names. Typically dialogs will contain a range of controls such as edit boxes, check boxes,radio buttons, and push buttons. Edit boxes are also known as fields.

  • Pull-down menus

    You can define pull-down menus that appear on a menu bar at the top of the screen. When the user selects an item on the menu bar, the menu drops down

  • Popup windows

    A popup window overlays what is on the screen already. You can use popup windows to offer the user a choice of records for selection. Where not all items of information will fit onto the window, your application can (very easily) allow the user to scroll through the records.

  • Error and Warning Messages

    Your application will most likely need to display error messages if there is a problem with the data a user is entering, or some other error condition.

  • Function Keys

    You can set up accelerators, known as hot keys in QAB, that allow a user to access a particular screen with a function key. You can use a special map that the user can switch on and off to display which hot keys are available.

  • Help messages

    You can set up help messages for each of the data entry screens and menus in your application program. Help can be specified for each field.

Although there are various types of map, there are very few restrictions on the types of control you can place in each type of map. For example you can (at any rate from DP4 C) populate a pull down menu by displaying data from the database.


Text and GUI Operation

Applications using the text based version of DP4 (4.5xx) can make use of GUI elements such as window borders and title bars, buttons and checkboxes in the same way as GUI applications. If the system is subsequently converted to work with the GUI version of DP4 (4.6xx) the maps will automatically be converted to GUI format, and will look perfectly respectable.

Screen shots of DP4 programs
Click the picture to see text and GUI versions of DP4. QAB is shown running on Linux and Windows.

Unfortunately there is currently no facility for conversion in the opposite direction. However it is perfectly possible to create a set of 4.5xx maps if a GUI application is required to be ported back to a text based platform. Where it is known in advance that both will be required it may be best to rely on the automatic conversion forward, and to use the Map Editor to make any desired enhancements. This is the method adopted for maintaining the 4.5xx and 4.6xx DP4 system databases in parallel.

The text based version of DP4 is available on all supported platforms (it is sometimes useful on Windows platforms as it allows you to run DP4 programs using TelNet). The 4.6xx version is currently only available on Windows platforms. However some GUI features are available even in 4.5xx versions on some platforms, as detailed here.


Operating Systems

DP4 supports output to a graphics monitor under several operating systems:

  • Microsoft Windows

    DP4 for Windows makes use of the graphical environment to support push buttons, radio buttons, check boxes, edit controls and list boxes. You can add title bars, borders and icons to maps. DP4 also supports copying and pasting between applications and the use of the Windows Print Manager.

  • MS-DOS (in graphics mode)

    Running in graphics mode for the MS-DOS operating system, DP4 supports the display of bitmap graphics. In addition, you can display double-height, double-width characters anywhere on the screen. The double-size character is also available on some FlexOS and OS/2 platforms. A Microsoft Windows like implementation is also available for MS-DOS

  • X Windows

    A prototype X Windows version of the user interface manager is available on Linux. Currently this supports check boxes and push buttons, and a few standard icons.


Maps

In DP4, maps are used to define how information is displayed and printed by your application. Maps are usually designed with the Map Editor, which you use to enter the display text and to define the positions of the fields. You define maps in the same way for displaying screens and windows, and for outputting forms to a printer.

Maps are stored independently from an application. If you change the text on a map, you do not need to recompile your application programs. Maps are organised in mapsets in tables in the base dictionary of the database.

All the screens used by DP4 are defined as maps, and these are held on the system database. You can look at and edit these maps in exactly the same way as the maps on your application database, though you need to be careful what you do.

Applications that build their user interface with DP4 maps gain all the benefits of the DP4 user interface.

Map Display

On the screen, maps are displayed in layers. The most recently displayed maps overlay what is on the screen already:

Your application can have up to 50 maps to the screen at any one time (and there is no limit in 4.6xx versions of DP4). Maps can be positioned in in two ways:

  • Automatic (or free) positioning

    With this method the user interface manager is allowed to select a position for the map, taking accounts of various hints passed with the API. This method allows the interface manager to make best use of the available space on the screen, (which may be variable especially on a Windows based system).

  • Attached positioning

    You can display a map with reference to a field that is on the screen already. This is called the attach map method.


Keyboard Layout

The keyboard layout is stored in a key translation table in the user file. The table can be modified to redefine keys without affecting the application program (using the DFSETUP). You can use this feature to support different types of keyboard:

Unusual Keyboards
If you have the keyboard on the left, it is probably time to buy a new computer!

You can also select between a number of standard keying conventions:

  • The original DP4 keying convention will be familiar to users with a UNIX or minicomputer background, and is often preferred by computer operators

  • The SAA convention conforms to IBM recommendations and is generally similar to the conventions used by Microsoft Windows

  • A Windows keying convention is also supported, though not recommended for use with the DP4 development environment as some help messages may be misleading.

You select a set of keying conventions when you run the USERDATA program, by specifying a commant tail of -saa or -windows to select those conventions, or no command tail for the traditional keying convention.


Printing

In DP4 the term printing refers to far more than simply output to a printer. Output is formatted using maps, exactly as when interacting with the user. However, when printing, maps are commonly referred to as forms. Your DP4 program can control the destination of printed output in the following ways:

  • Program Selection

    Your program can pre-select output to any combination of the screen, printer (including devices integrated with the OSDI) or file

  • User Selection

    You can give the user the option to select an output destination at runtime

  • Printer Initialisation

    You can send initialisation strings to select the paper type, font and other printer control information, or control an OSDI

  • Printing from Windows

    In the Windows environment, DP4 can use the Windows Print Manager. Printing this way enables you to print using images, colour, and multiple fonts. DP4 does not then need any information about the actual device being used.

  • Multiple Devices

    Your QA Build and C programs can output to several devices. You can use this facility to manage complex devices such as those used for a POS workstation


User Management

This topic is divided into the following sub-topics:

  • Log On Facility
  • User Preferences
  • User Language
  • User Menu


Log On Facility

The DP4 log on facility prompts for a user name and password:

DP4 checks the user name and password against the system user table. If the user is valid, DP4 reads the user information from the system database.


User Preferences

When a user logs on, the user preferences are read from the system database. The preferences include the following information:

  • Number Format

    The number format for a user determines how fields are justified, how separators and signs are displayed and other formatting information

  • Date and Time Format

    The date and time formats for a user determine the way dates and times are displayed

  • Colour Preferences

    These preferences determine the colour of each portion of the screen display


User Language

For the user language, you can specify any language you have set up on the user table on the system database. The language is used to select a set of maps, also the words used for 'Yes' and 'No', the decimal point character and the date format.

When the user logs on, the user interface manager selects the set of maps for the user's language. In a multi-user system, you might have a number of users logged on, each using your application in a different language. Read the section on National Language Support for more information on how DP4 handles languages.


User Menu

DP4 provides a menu building utility that lets you create a user menu. This is the menu that is displayed when the user logs on to the DP4 menu. The default menu that appears is shown in DP4 Menu.

For each option you add to a user menu, one of several actions can be taken:

  • A sub-menu is displayed

  • A DP4 program is executed

  • A non-DP4 program is executed

  • An operating system command is executed

  • A user-menu command, such as LOGON, is executed

  • The menu program is terminated

An example user menu is shown in the section User Menu Editor.


User Menu Editor

DP4 supplies a menu editor for creating user menus to access your application programs. You can use the menu editor to build a popup menu that gives the user access to the programs provided with your application.

When a user logs on to the DP4 menu utility, the user menu is displayed. The options on a menu are not restricted to DP4 programs - you can call any program you wish, provided that there is sufficient memory. Where necessary, the user can be prompted for the command line parameters to a program.


Help System

The DP4 help system is designed around the concept of field sensitive help. Help text is displayed for each field on a map and for each option on a menu.

The user can toggle the help display on and off by pressing the <Help> key (usually <F10>, <F1> or <Ctrl+J>). To see how help works, run any DP4 utility, and press the <Help> key to get help for the current field. As you move the mouse or cursor around the screen, you will see the help display change to refer to the current field.

To add help to your application, you have two options:

  • Add help for a field when you set it up using the map editor

  • Run the help authoring utility to define the help text interactively whilst the application is running

The DP4 help authoring utility is the most productive way to add field sensitive help to your application. You load this utility into memory, and then run your application program. To add a help screen to your program, you simply press the help authoring key (usually <F9>), and you will be prompted for the help text for each field. Unfortunately this utility is not supported with the latest version of DP4 for Windows, but it will be reintroduced shortly.

Your program does not need to position the help popup map. The user interface manager displays help in the clearest part of the screen.


National Language Support

This topic is divided into the following sub-topics:

  • Using More Than One Language
  • Error Messages
  • Database Text
  • Development Language
  • Oriental Languages


Using More Than One Language

DP4 provides a facility to enable your application to display text in the national language of the user. You set up the languages on your system in the language table using the MENUEDIT utility.

To make your application support more than one language, you add each language to the language table, and define the words for 'yes' and 'no', and the date format for the language. Text that is output by your application can be translated into a new language by editing the maps. When the user logs on, the user interface manager automatically selects the maps that are in the user's language.

Maps can be modified using the DP4 map editor, or they can be exported to a text file. Using the export option, you can translate the maps using your favourite editor or word processor, and post them back to the database.

For a multi-language application, you can copy the original set of maps, and translate the maps to each of the other supported languages. The positions of the fields usually remain the same for all languages.


Error Messages

When an error occurs, DP4 outputs an error message. For example, if there is insufficient memory to run a program, DP4 informs the user with a message. If a parent check on a table reveals that there is no customer record for an order, a message such as "Customer does not exist" is displayed.

DP4 error messages are stored as maps on the system database. To translate these error messages, you can export them to a file and translate them in the same way as for the maps of your application.


Database Text

Whilst maps can be translated with ease, there are other language issues which may affect your application. If you are storing text on the database, you will need to add an extra key to each textual record. This allows the record to be linked to the user's nationality. For example, in a retail system, you may store item descriptions in English, German and French. To do this, you construct a two-part key that includes the language code:

To display records from the table, your program supplies the language code, and this code is used in combination with the item code to display an item description.

QAB programs can use special maps, known as word strings, to avoid the need for hard-coded language specific text, and a similar facility is available to C programmers.


Development Language

DP4 gives you the option to change the language that is used for development. In particular, you can specify table and field names in the language of the developer. For example, for French and German speaking developers, you can specify the name of the CUSTOMER table as CLIENT and KUNDE in those languages.

When the developer logs onto the system, the words for 'yes' and 'no' and the date format will automatically be selected from the language table. You have the option to translate the maps used by the DP4 system into the developer's language. If you do translate the system maps, it is recommended that you do not change the fields on the maps in any way.


Oriental Languages

Alternative versions of the DP4 user interface manager are available for oriental languages. The following oriental languages are currently supported:

  • Kanji

  • Hangul

  • Chinese

    For example, the DFSETUP main menu looks like this in Kanji:


DP4 Thin Client (Terminal Server)

Introduction

Typical DP4 components For many years DP4 has had an extremely well modularised and portable structure which lends itself to distributed processing. Until recently this has primarily been used to create applications with a typical client/server architecture with a database distributed between one or more servers, and perhaps also held locally on each client to provide resilience. The typical DP4 components are shown in the diagram on the left.

With the decreased cost and increasing power of PC based servers, as well as the increasing complexity and cost of deployment of PC based software a new type of solution has become popular - "Thin Client", or "Ultra Thin". In this architecture the absolute minimum of software is deployed on client PCs and applications run primarily on the server with the client computer acting more or less solely as a terminal (possibly a very sophisticated one).

In fact this largely represents a return to the typical model of computer systems before the invention of the PC. Thin Client solutions should offer cost savings through reduced cost of deployment and administration, and savings on hardware costs through reuse of legacy hardware for clients and reduced cost of new hardware.

From version 4.523/4.619 DP4 can run in this type of configuration. Existing applications are able to run with little or no modification using the new DP4 Terminal Server.

Existing Thin Client Technologies Compared with DP4 Terminal Server

The original thin client software was probably Telnet - this allowed any computer to act as a dumb terminal to any other computer running as a Telnet server to which it could connect. Telnet is still a very useful program - its primary disadvantage is that it can only run text based programs. Later on the Unix X Windows system allowed GUI based programs to run in a similar fashion, though this does not seem to have become very commonly used as yet (at least in the commercial environment).

In recent years two more types of technology have emerged:

  • Windows Terminal Servers - the various Citrix products, the Terminal Server Edition of Windows NT, and latterly the Terminal Services built into Windows 2000.
  • Web based architectures such as Java, ASP etc.

DP4 systems can already be deployed using most, if not all, of these technologies. However the DP4 Terminal Server architecture has unique advantages over all of them. Before going into this in more detail a few terms will be defined:

  • The Application Host is the server class computer where programs executed with the DP4 Terminal Server run.
  • An MS Architecture Terminal Server is a server that runs as a Windows Terminal Server using one of the products mentioned above.
  • The Client Machine is the computer where an application executed with the DP4 Terminal Server interacts with the user and the operating system - i.e. where screen output is displayed and keyboard and other input is captured. Normally printing will be done and non database files accessed on this computer though this will be configurable at the system, per client and application level.

Here then are the advantages of the DP4 Terminal Server Architecture:

  • Cross Platform Portability

    The DP4 Terminal Server will be based around the existing DP4 API. As such an application might be running on a Unix or Linux based Server, but the client machine might be running Windows 9x,Windows CE (or even Windows 3.1). To the user on such a device the application will appear exactly like an ordinary Windows application. In due course GUI execution on Linux will be supported. Text based execution is also be supported - a major strength of the DP4 API is that is almost completely indifferent to the type of display device in use. Thus an existing text based Unix based QAB system will automatically use the mouse correctly when run with a GUI DP4 Terminal Server.

  • Cost

    The Application Host will need to be sufficiently powerful to run the expected maximum number of DP4 programs simultaneously. However typically a machine previously acting as a DP4 server in a client server architecture will already be sufficiently powerful to run as the application host, though possibly some extra RAM will be required, particularly if a large number of different executables are used. Typically the additional processing required for running the application programs on the server will be largely offset by reduced network traffic, though this will of course depend on the application to some extent. An important point to note is that no special operating system version will be required for running as a DP4 Application Host - in particular there will be no need for the machine to run Windows NT/2000 Server rather than workstation (unless it is felt that additional CPUs are required beyond the two supported by NT Workstation). If desired the Application Host can run one of the MS Architecture terminal server operating systems so that a mix of client architectures can be used. Deploying an application using the DP4 Terminal Server will offer the benefits in terms of reduced cost of deployment typical of Thin Client Solutions. In particular upgrading a system and making database changes should be much easier in a Terminal Server environment.

    Any PC capable of running DP4 in client server mode can be used as a client. An absolute minimum spec would be a 386 DOS PC with FTP TCP/IP protocol, or a Windows 3.1 PC with Microsoft TCP/IP. Any higher spec will be sufficient. Non PC hardware such as Winterms will not be supported, though these can of course be used if the Application Host is also an MS Architecture Terminal Server.

  • Extensibility and device support

    With most existing Thin Client architectures programs typically have no access to devices on the client. For example in the Telnet client there is no facility to save a file from the server to the client and the FTP program must be used instead. Access to specialised hardware such as retail devices is out of the question. In Web Based architectures it may be possible to gain access to the local machine, but typically there are difficult security issues to be addressed, and unpleasant cross language software has to be written - for example to bridge from Java classes to an existing device driver with a C/C++ interface. In some cases even if access to devices is possible existing devices drivers may have to be completely rewritten.

    With the DP4 Terminal Server is possible to use an existing OSDI more or less unchanged, as the OSDI is an interface between the DP4 terminal manager and the hardware, and not between the application and the hardware.

  • Performance

    The DP4 Terminal Server architecture should offer improved performance compared with Remote Display Protocol type servers (X Servers and MS Terminal Servers). This is because the DP4 API is much more abstract than most RDP architectures. For example when a user is selecting options from a menu an MS Terminal Server will typically have to send many messages across the network for the client to to tell the application server where the mouse is, and from the server to the client to repaint the display. In the DP4 architecture this will be accomplished by a single API executed entirely on the client, with a one time transfer of the text in the various menus from the database on the server. In this respect the DP4 architecture is more like a Web architecture where client side processing reduces the load on the server. On the other hand the DP4 architecture does not suffer from the high round trip cost for going back to the server inherent in current web based architectures. The vast majority of processing is carried out on the most appropriate computer - display, editing and device handling on the client, database and business logic on the server.

Architecture

To understand the DP4 Terminal Server Architecture it is only really necessary to understand the basics of the regular DP4 architecture.

A pure DP4 application program never interacts with any devices on the computer directly. All such interaction is done via one of two interfaces - the DP4 database interface, and the DP4 terminal interface. The DP4 database interface implements the calls necessary to access and update a DP4 database. The DP4 terminal interface implements a set of APIs which is sufficient for all typical application needs - it contains calls to display screens, collect data from the user, access and create non database files, and print to regular or special printers or files. Specialised hardware is via the terminal interface accessed using abstract devices.

The word interface was used advisedly above. It is common to speak of a program "calling" the database manager, but this is not strictly accurate, it is an interface that is called, and the components that implement that interface can be extremely varied - anything from a standalone DP4 database residing locally through to a mixture of DP4 and non DP4 databases residing on different servers running different operating systems on different and incompatible processor architectures and accessed through differing network protocols. The application need not care about the implementation of the DP4 database at all.

Internally this is achieved by defining a simple protocol which is common to all calls to the database interface. This protocol is completely independent of the operating system and hardware used by the program. All calls to the DP4 database interface work by constructing a simple parameter block which describes the function to be called and the data to be passed in and out of the function. In the simplest case calling the interface will send some kind of message directly to the DP4 database manager. In a more complicated set up the same message may be picked up and passed through one or more ADC components and then passed into one of the DP4 network requesters. This then communicates with a DP4 network manager (receiver) running on another server and transfers to it the parameter and data associated with the call. The call can then be handed on to the DP4 database interface on that server. From the point of view of whatever is implementing the DP4 interface on the server computer the call is more or less identical to one made by a DP4 application running locally - so the same process may be repeated to pass the call through several more layers. Eventually (usually almost instantaneously) the destination will be reached, the call will be processed and the answer will be returned to the calling application, which will have no idea where or what actually did the processing. The DP4 networking components function much like software equivalents of electrical extension cables and adapters that convert British to Continental plugs or vice versa. (A slightly better analogy might be with surge protector type adapters or UPS as the DP4 networking software also contains logic to deal with network problems of various types)

Diagram of DP4 Terminal Server architecture The DP4 terminal interface is logically identical to the DP4 database interface. In exactly the same way a parameter block is constructed to describe the function to be called and its input and output data. Indeed the format of the parameter block is compatible, and in principle exactly the same network components can be used to transfer a call from one machine to another. (The same interface is now also used for calling the DP4 SQL Engine and will be used for any future interface components). The implementation of the DP4 terminal server, shown in the diagram on the right, is almost as simple as replacing the regular DP4 terminal manager component with the existing network requester and making the existing DP4 network receiver accept and pass on Terminal Interface calls as well as Database Interface calls.

In fact things are not quite as simple as this as there do need to be some additional "components" and there are some minor changes required to the regular DP4 network architecture. For example the client machine has to have some program running that is capable of starting an application on a remote server, and at the same time creating an instance of the "terminal receiver" that will execute its client side code. Whereas the regular DP4 network requester is completely single threaded a separate "terminal requester" is created for each application (since otherwise all the applications on the server could be blocked if a remote user went to lunch with a DP4 program sitting in a data entry screen). The regular DP4 Network Receiver is used as the program which processes requests from clients to launch applications. Each application is supplied with an environment variable that tells its terminal requester which client machine to connect to.

The diagram shows the networking components as using TCP/IP protocol. In principle there is no reason why other protocols could not be supported.

Implementation

The Terminal Requester is built into the regular DP4 Terminal Manager. An application will automatically select whether to use the regular terminal manager code, or the requester version. Thus there is no problem with running DP4 applications locally on the application host.

No additional components are required on the application host. On the client side you can choose either to install a simple client configuration (which comfortably fits on a single diskette) without installing any other DP4 components, or you can install the client as an additional package. This might be convenient where you want to deploy some, but not all of an application locally. You can run almost any mix of local,client-server, and DP4 terminal server applications all at once, connecting to as many servers as you want!

The two special components for the client side are :

  • The program to launch applications on the application host. This is a simple command line utility which can easily be replaced by a customised version - you can launch applications yourself by directly calling the same API that TSRUN uses.

  • The terminal receiver program TSTCPx. This is the program that communicates with the remotely running application. An initial copy of this program must be loaded as part of the DP4 service, (which will be started automatically when a request to start a DP4 program is made).

In addition to this a skeleton DP4 installation is required - the install program for the client will do this automatically. For example on Linux the files tcp3,trm3 and userdata.sys are required. On Windows a few additional DLLs are also required and the DP4 service program srvw32.exe . The OSDI must be installed on the clients if required.


DP4 Programming Tools

DP4 provides the programming tools to help you produce application programs quickly and easily. If you are new to programming, the fourth generation program development tools will help you to start producing useful programs quickly. If you are an experienced programmer, DP4 provides third and fourth generation tools for you to construct complex applications.

DP4 offers several programming environments:

  • QA Build

    QA Build, or QAB for short, is the DP4 environment for producing application programs quickly. The QA Build program editor consists of a series of menus and questions which determine how each part of your program is to work. Your responses are used to generate a program that is analysed as partially compiled with the QA Build compiler, and then executed, either with the standard QA Build Interpreter (PROGRUN), or a version of the Interpreter that you have extended by adding to it your own C functions called from QAB, or which contains C functions that call QAB programs.

  • Report Writer

    Report Writer is one of a number of specialised tools for creating specific types of prograsm. Report Writer helps you construct report programs, and one or two other related types of program. Reports output information from your database in a table format. Report Writer uses a similar question-and-answer technique to QA Build. On Microsoft Windows platforms you may want to use third part Report utilities instead. A tool related to Report Writer is Importer, which helps you import data from flat files into a DP4 database.

  • SQL

    SQL is an industry-standard language that you can use to interrogate and update the database. You can enter SQL commands interactively, or you can define a file of commands that are interpreted as a batch process. On Microsoft Windows platforms you can use SQL commands via ODBC or ADO to access a DP4 database from any program that supports them. The various ways of using SQL with DP4 are described here.

    Programming with C/C++ and other Languages

    The DP4 Programming Environment provides a library of functions that you incorporate into your program. DP4 programming with C is available on any platform where DP4 is supported, and many other languages are, or can be, supported on most platforms (On Microsoft Windows platforms you can use the native DP4 database APIs from any tool that supports the use of DLLs, including Visual Basic and Borland Delphi). With this type of program you have the highest degree of control over how the database is accessed and what the user interface is like. See the DP4 C Programming Environment for further details.

DP4 gives you the flexibility to combine QA Build and C/C++ in your application program. A function written in C or C++ can be called from a QA Build program, and a QA Build program can be called from a C or C++ program.


QA Build

The term QA Build can be interpreted as Question and Answer Builder or Quick Application Build. The QA Build programming environment is designed to help you write database application programs quickly and easily. It also contains tools that help system integrators perform such tasks as distributing changes to QAB programs, locating problems caused by changes to the database, and reconciling conflicting changes from programmers working on different revisions of a database.

QA Build is suited to applications that process a group of transactions. A transaction represents a logical group of actions such as the sale of a group of items to a customer or the crediting of an account with the sum of a set of figures. For example, the user (the cashier or operator) enters one or more item codes, the program retrieves the cost of the items, calculates the total and outputs the information to the display and to the printer.

Application programs developed in QA Build can range from simple data entry programs to complex retail and banking programs.

This topic is divided into the following sub-topics:

  • QA Build Programs
  • Components of a QA Build Program
  • Components of a Procedure Body
  • Accessing the Database
  • Running a QA Build Program
  • Automatic Program Generation
  • QA Build Program Debugging
  • QA Build Program Documentation


QA Build Programs

As a QA Build developer, you create a program by selecting options and answering the series of questions posed by the QA Build setup program. Once you have set up the program, you compile it using the program compilation utility. The program compilation utility checks the syntax of your program, and warns you of any errors that affect the program. It also checks the tables and fields specified in your program against the database tables and fields, to make sure they match.

The compiled program is interpreted at runtime by the PROGRUN utility. All the validation checks included in your database are carried out as well as those you have specified in your program. QA Build automatically handles the majority of error conditions that arise. If an error does occur, such as two users attempting to update the database at the same time, DP4 will display an error message.

QA Build programs are stored in tables as a part of your database. They are not accessed directly since they are stored in the hidden part of the database known as the base dictionary. Since they are stored with the database, they are easy to distribute, and can be ported across the supported operating systems with no need for re-compilation.


Components of a QA Build Program

A QA Build program consists of a program header and a procedure tree:

  • The program header defines the type of access to the database, and the initial output destination of your program

  • The procedure tree defines the sequence in which tasks are executed in the program, and is defined recursievly using one or more procedures.

A procedure tree is represented in the QA Build system by a program flow diagram, a (rather old) example of which is shown below.

The order of execution is top to bottom, left to right. The MAIN_MENU procedure marked with an M offers the user a number of options. The options are shown as subsidiary procedures. Conditional procedures, such as RETURN_TO_DOS are shown with question marks (?). Repeated procedures, such as ORDER_ENTRY are shown with an asterisk (*). Further options to the right are indicated by the >> symbol.

The procedures in the example program flow diagram above are executed in this sequence (the | symbol is used to separate menu options):

HEADING, MAIN_MENU,[RETURN_TO_DOS | ORDER_ENTRY, ORDER_LINES | STOCK_REVIEW ..]

Each procedure has a corresponding procedure body.

Each procedure body performs one logical task, such as updating a specific table on a database, or prompting the user for input. The distinction between a procedure and a procedure body is that a procedure defines the structure of your program, and a procedure body defines the task to be performed.


Components of a Procedure Body

Each procedure body has the following components:

  • Procedure Body Overview

    The procedure body overview defines the type of processing to be carried out, and the conditions to enter and repeat the program

  • Table Processing

    You use table processing to define the tables that are used, and how they are accessed

  • Screen Layout Definition

    As with all output from DP4, you define the screen layout and output formatting using maps

  • Field Processing

    You initialise, validate and perform calculations using the field processing part of a QA Build procedure. The fields need not be database fields - you can also define and process fields that are local to your QA Build program

You can also add conditions and formulas at specific points in your program:

  • Conditions

    To test one or more values you include a condition in your program. You can make the execution of a procedure conditional, and you can use conditions to validate the user's entry

  • Formulas

    To assign a value to a field, you include a formula. A formula can include operators such as IF THEN ELSE, functions such as TODAY to obtain the current date, and functions that you define in C


Accessing the Database

For procedure bodies that perform some action on the database, you specify a main table. For the main table of the procedure, you can indicate whether the user can add, delete or amend records, and whether the key field is automatically incremented. You can also offer the user a choice of records in a popup window.

If the main table defines fields that link to parent tables, then these tables are automatically defined in your program. For example, on an order entry screen the customer details can be displayed and modified at the same time as the order details, since the CUSTOMER table is a parent table of the ORDER_HEADER table. Records on the parent table can be added or amended, but not deleted or auto-incremented. To access the full set of database actions, you define the table as the main table in the procedure body.


Running a QA Build Program

QA Build programs are interpreted. The user runs the QA Build interpreter and enters the name of the program. If the program name is not known, the user selects the program from a popup list of programs on the database.

You can run the QA Build interpreter with a command tail to select a specific program on the database. The instruction to run a program can be included in a batch file or a user menu.


Automatic Program Generation

The DP4 automatic program generator (AUTOQAB) can automatically create a QA Build program for you to access and update one or all of the tables on your database. If more than one table is accessed, DP4 will create a menu giving access to each of the tables by name.

This is an example data entry screen generated by the automatic program generator:


QA Build Program Debugging

The QA Build Debug utility gives you precise information about your program. You can set breakpoints at specific points in a program, or run a program in trace mode. In trace mode, QA Build will report on every significant action, or on selected actions such as database accesses or field processing.

The QA Build Debug utility displays the name of the procedure, the procedure body, and the maps, fields and tables used by the program. You can inspect and change database fields and local variables whilst the program is running.


QA Build Program Documentation

QA Build includes the following documentation features:

  • Summary

    QA Build prompts you to enter a program, procedure and procedure body summary. The summary is displayed for the current selection from a popup list of existing programs or procedures

  • Documentation

    You can use the text editor to enter up to 4,000 characters as documentation for each program, procedure and procedure body

  • Formula Comments

    You use the {} symbols to include comments in formulas

  • Program Print Utility

    This utility (PROGPRN) prints out the definition of a program, including the program flow diagram, the tables accessed, the maps and the field processing used in the program

  • Search Utility

    This search utility (in QABUTIL) allows you to find and print out information such as programs or procedures that use particular table,field,maps or procedures. The same program also contains an Impact Analysis utility which can be used to find parts of QAB programs that are affected by database changes


The DP4 C Programming Environment

The DP4 C programming environment allows you to develop executable programs to access your database. The C language gives you the flexibility to manipulate data in any way you wish, but the more your program is based round the DP4 API, the more more portable and future-proofed it will be.

DP4 C is easy to learn, and baseically the same DP4 functions are available on all supported platforms, and sometimes in other languages, thus simplifying migration.

Your DP4 C program can be compiled using one of the supported compilers:

  • Microsoft C

    All versions are supported from 16 bit versions through to Visual Studio 6 and beyond. Itim Technology Solutions are committed to supporting new versions of this compiler as they become available.

  • Metaware C

    The small, medium, big and large memory models are supported for programming on Legacy operating systems (including MS-DOS,FlexOS and OS/2)

  • UNIX Native C

    The appropriate native compiler for each supported platform is used. Typically you will be able to use other C compilers if desired (the GNU compiler is supported on almost all platforms, even if it is not our preferred compiler), as there are common standards for object files and use of processor registers.

See An Introduction to DP4 Programming in the DP4 C/C++ Programmers reference for a more detailed introduction to DP4 programming using C or another language.


Combining C Code with QA Build

You can combine C code with QA Build in three ways:

  • Call a QA Build program from C

    You can call a QA Build program from a C program. You might want to do this if you are writing a high-level selection program to behave in ways that QA Build cannot achieve. The QA Build program cannot access the data of the C program

  • Write QA Build procedure bodies in C

    You can define a QA Build procedure body in C. These are called in exactly the same way as QA Build procedure bodies. Your C code can access all the data of the QA Build program

  • Write C functions for use in QA Build formulas and conditions

    You can add your own functions, written in C, to the QA Build library. They are then called in exactly the same way as predefined functions from formulas and conditions in QA Build. Parameters can be passed to the function, and a single value returned

    To combine your C and QA Build programs, you link your C code with the QA Build object modules.

The third option is particularly useful as it allows you to build a pwoerful customised versions of the QA Build interprete. This is described in more detail in Incorporating C Functions in QA Build.


Incorporating C Functions in QA Build

When you are developing C functions for inclusion into a QA Build program, you must perform the following tasks:

  • Define the C function in QA Build (name, description and parameters)

  • Include the function in your QA Build program

  • Write the C source code

  • Compile your QA Build program and generate the C function interface

  • Compile and link the source files

The following is an example C function that is called whenever a QA Build program uses the function unittoword():

void f_unittoword(word,number1,number2)
/* Function to convert a numeral to a character word */
char *word;
double *number1, *number2;
{
  int i;

  static char *word_for_nr[] =
  {
    "Zero","One","Two","Three","Four",
    "Five","Six","Seven","Eight","Nine"
  };

  strcpy(word,word_for_nr[(int) *number1]);

  /* Tell QA Build the return string is 5 characters long */
  set_occurs(5);
}


Report Writer

This topic is divided into the following sub-topics:

  • What Report Writer Does
  • Report Program
  • Export Program
  • Delete Program
  • Program Definition
  • Running a Report Writer Program
  • Automatic Report Generation


What Report Writer Does

You can use the DP4 Report Writer utility to write a program to process the information on your database. Programs produced using Report Writer are suited to defining tasks that require infrequent user interaction. For example, you might use this facility to print the names and addresses of all the customers on the database to a file, for use in a mail merge. Some users prefer to use QAB for reporting purposes, as this gives more control over program flow and allows you to print graphics or use multiple fonts. On Windows platforms you may choose to use third party software and ODBC to create reports.

Report Writer provides automatic access to parent tables. This means that you can produce a report that includes information from a selection of tables, provided that they are linked by common keys. For example, you can print out the order details for each customer by including fields from the CUSTOMER, ORDER_HEADER and ORDER_LINE tables in the report.

You can specify a condition for the selection of records, and include formulas for calculation. For example, you can set up a report to print out the names of all customers who have ordered goods over a specified value in the last six months.

Report Writer gives you detailed control over the format of the report. You can specify the size and spacing of the fields and the location of columns on the page. You can set up subtotal fields that are calculated at runtime, and specify whether records are sorted in ascending or descending order.

Report Writer can be used for developing three types of programs:

  • Report program

    A report program outputs information from your database in the specified layout, usually a tabular format

  • Export program

    An export program produces a file of data that can be used to update another database

  • Delete program

    A delete program deletes records from your database according to a set of criteria


Report Program

You can create a report program to extract and print fields on the database in the format you specify. In this example, a report is printed showing the customer details for each region.

Sales Order Example Reports    SALESORD TOTALS  14 Feb 1993 18:10  Page 10

Summary report printing sub-totals for one or more categories

Region Running Customer                           Order      Order
Code   Count   name                               Number     Value

SEE     53     Amps W T                              5        3.12
        54     Bellerose Capt D P                   23      226.55
        55     Friodé N                             64      727.94
        56     Perry G                              33       72.65
        57     Weller C                             39       75.25
        58     Kennedy R P                          43     1094.75
        59     Keown T                              44      625.57
        60     Richmond P                           45     2054.34
        61     Cuthburt I                           47      100.00
        62     The Hair Company                     57      204.72

STATISTICS FOR South East England

        Total number of orders:            10
        Average order value is:           518.49
        Total value of orders is:        5184.89


Export Program

You can create a program to produce an export file in a format like this one (although you can also specify non-delimited fields, and delimiters other than commas):

  0,"M.Miggins                ","M","C",03 Mar 1955
  1,"John Brown               ","M","B",29 Jan 1982
  2,"M. Holmes                ","M","A",01 Jun 1964
  3,"A. Jones                 ","M","B",06 Mar 1945
  4,"A. N. Other              ","F","A",04 May 1965
  5,"A. McTavish              ","M","B",04 Dec 1965
  6,"A. White                 ","F","C",05 Nov 1965
  7,"S. Holmes                ","M","B",05 Nov 1972
  8,"M. Fitzpatric            ","M","B",16 Feb 1960
  9,"P. Fitzmaurice           ","M","C",17 Mar 1961
 10,"F. Richmond              ","F","B",25 Dec 1959
 11,"B. Black                 ","F","C",22 Nov 1963
 12,"F. Red                   ","F","B",23 Jul 1962


Delete Program

You can specify a delete program to delete the records on the table that comply with a condition. For example, you might create a delete program to remove records of orders completed before a certain date.


Program Definition

The Report setup utility REPSETUP will prompt you to make a series of selections:

  • Tables

    You specify the lowest table in your table plan that you wish to access. The parent tables are automatically accessed through the keys on the table

    In the SALESORD table plan (See Data Dictionary Plan), the lowest table is the ORDER_LINE table. However, if your report is only concerned with customers and orders, such as a report on the balance of each customer, then you specify the ORDER_HEADER table

  • Fields

    You can specify fields on the database, fields that are calculated at runtime, and fields that are entered by the user

    Fields are displayed in a column format. Report Writer will use the size of the field to automatically supply the position of the columns. Where there are too many fields to fit on the page, you can indicate where the output is to fold onto the next line

  • Condition

    You can specify a condition to select records for reporting, exporting or deleting

  • Totals

    For a report program, you can specify totals to be calculated for any numeric field

  • Report Heading, Column Heading

    You can specify a heading that is displayed at the front of the report. DP4 automatically supplies the column headings using the field definition information on the database. The headings are printed with the date, time and page number at the top of each page of a report

  • Sort

    You can sort the records by one or more fields. When sorting by multiple fields, you must choose their sort precedence

  • Output Devices

    You can specify the default output devices for the program


Running a Report Writer Program

Report Writer programs are run in the same way as QA Build programs. The user runs the Report Writer report printer utility and enters the name of the program. If the program name is not known, the user selects the program from a popup list of programs on the database:

Figure 40 Report Writer Popup Program List:

You can run the Report Writer printer utility with a command tail to select a specific program on the database. The instruction to run a program can be included in a batch file, a user menu, and a QA Build or C program.


Automatic Report Generation

DP4 can automatically generate a Report Writer program for you to produce a report or an export file from the data on your database. An automatically generated report program will print out all the records on a table in report format. The fields will be listed in the sequence in which they are specified in the table, and the headings will be taken from the table definition. If the page width exceeds the width specified, some fields may be wrapped onto the next line. No totals or conditions are included in the automatic generation.

An automatically generated export program will print each of the fields on the table to a file, in the sequence they are specified in the table.


SQL

In common with most other databases, a Structured Query Language (SQL) interface is available for DP4. There are three main ways of using the DP4 SQL interface:

  • Interactive

    You can run the DP4 SQL Interpreter to interrogate your DP4 database interactively. This method is useful for trying out SQL that you will use one of the other ways

  • Batch

    You can also run the DP4 SQL Interpreter using with statements supplied from a file of input statements with the results also written to a file.

  • ODBC

    You can use the Microsoft ODBC interface to develop an application. This is a standard interface for developing applications that can be run against any database management system that supports ODBC, including DP4. The ODBC interface can also be used to access DP4 databases running on the Linux operating system.

More information on SQL is contained in the following topics:

  • SQL Interface
  • SQL Commands
  • ODBC Database Manager


SQL Interface

The DP4 SQL interface supports queries and updates in the SQL language. You can enter the commands interactively, or as text files.

You use the SQL to specify the conditions under which records are extracted. Where records are extracted from more than one table, SQL 'joins' the records from the tables.

To update the database in SQL, you can define an input file and specify a cursor that indicates the next record to be read. Records can be inserted into the database, and amended or deleted according to a condition.


SQL Commands

You use the SQL commands to specify the tables and records you wish to extract or update. The main commands are:

Extract Records

SELECT <expression> FROM <table> WHERE <condition> GROUP BY <fields> HAVING <condition>
ORDER BY <fields>;

Update Records

DECLARE <name> CURSOR FOR <select statement>
FOR UPDATE OF <column names>;
UPDATE <table>;
DELETE FROM <table>;

Fetch the Next Record

FETCH FIRST/LAST/PRIOR/NEXT;

Insert a Record

INSERT INTO <table fields>;

Manage Updates

COMMIT WORK;
ROLLBACK WORK;

Date and Time

DATE(); TIME(); DAY(); MONTH(); YEAR(); HOUR(); MINUTE(); SECOND(); DAYS();

Below is an example SQL program excerpt to print out a list of the customers assigned to each employee by region:

select    employee.employee_number,
          employee.name,
          customer.customer_number
          customer.name
          customer.address

from      employee,
          region,
          customer

where     employee.employee_number = region.employee_number
and       region.region_code = customer.region_code

order by  employee_number,
          customer_number;


ODBC Database Manager

ODBC Interface

DP4 provides an ODBC-compatible interface for executing SQL statements. The Microsoft ODBC standard Application Program Interface (API) offers portability across different database management systems.

The ODBC interface defines a standard set of functions for connecting to and logging onto a database management system and for sending and retrieving values to and from an application. The DP4 interface supports all the core functions and level 1 of the ODBC standard, and many of the level 2 ODBC functions.

On Windows, the ODBC interface will enable your to access your DP4 database using a wide range of third party software. You can also use ODBC commands as an alternative to the native DP4 APIs in languages such as C++.

The DP4 ODBC interface allows DP4 databases to be accessed over the Web using ADO. You can also use ADO as a means of accessing DP4 databases from C++ programs.

Using third party ODBC drivers and the ODBC Gateway ADC you can access other databases using the DP4 API's.


DP4 Support Tools

  • Data Entry and Enquiry
  • Data Import and Export
  • DP4 Menu
  • Text Editor
  • File Viewer
  • Map Editor
  • Menu Editing
  • Help Authoring
  • Test and Demonstration Setup
  • Transaction Log Auditor
  • Application Documentation
  • Version Control


Data Entry and Enquiry

DP4 provides a data entry and enquiry utility, known as BROWSER. You can use this utility to enter data into the tables on your database, and see the records that have already been entered.

DP4 prompts you to enter the name of a table on the database. If you do not know the name, you can select a table from the popup list. The field headings are displayed in the left column, and the input fields on the right:

If the fields of the table do not fit on the screen, you can use the cursor keys to scroll up and down through the record.

The functions provided by BROWSER are:

  • Scan records
  • View records
  • Add records
  • Modify records
  • Delete records
  • Print records

You can use the QA Build automatic program generator to create an application program with a similar data entry and enquiry functionality. A program generated in this way provides a menu of all the tables on the database. For any table the user can scan through the records, and update the records. You can customise the generated QA Build program as you wish.


Data Import and Export

You can import data from a file to your database, and export data from your database to a file. This facility allows data to be transferred from different environments, and is useful when facilities such as the DP4 ODBC interface are not available.

You can find This topic is divided into the following sub-topics:

  • Import Data
  • Export Data
  • Automatic Program Generation


Import Data

You import data to your database using the DP4 import utility. The import setup utility is used to define the format of an import file.

The details for each import filed are stored as an Importer program or parameter set on the database. To import a file, you call the Import utility specifying the appropriate parameter set, which then postd the records in the file onto the database.

A parameter set contains the following types of information:

  • Fixed length

    You can specify whether fields and lines are of a fixed length

  • Delimiters

    You can specify the characters used to delimit the fields and records (or lines) in the file

  • Line definition

    You specify additional lines if a record is spread over more than one line in the file, or the file contains multiple lien types with data for different tables.

  • Database fields

    You can select the destination fields on the database

For any import file, the fields conform to a fixed length, or they are separated by a common delimiter, such as this one:

  0,"M.Miggins","M","C",03 Mar 1955
  1,"John Brown","M","B",29 Jan 1982
  2,"M. Holmes","M","A",01 Jun 1964
  3,"A. Jones","M","B",06 Mar 1945
  4,"A. N. Other","F","A",04 May 1965
  5,"A. McTavish","M","B",04 Dec 1965
  6,"A. White","F","C",05 Nov 1965
  7,"S. Holmes","M","B",05 Nov 1972
  8,"M. Fitzpatric","M","B",16 Feb 1960
  9,"P. Fitzmaurice","M","C",17 Mar 1961
 10,"F. Richmond","F","B",25 Dec 1959
 11,"B. Black","F","C",22 Nov 1963
 12,"F. Red","F","B",23 Jul 1962


Export Data

You export data from your database to a file using the DP4 Report Writer utility. As for a report, you set up a program that defines the table, fields, and conditions used to determine the output. These parameters are used to output information from your database to a file. If the information from the CUSTOMER table is exported using fixed length fields, it will appear in the format shown in Import Data.

For transferring data between two slightly different DP4 databases you may orefer to use the database unload and load utilities which use a simple, but private, text file format to describe the data in the file.


Automatic Program Generation

DP4 can automatically generate the programs to export data from and import data to the tables on your DP4 database. This facility assumes that fields are stored in fixed lengths in the file. You can use the facility to transfer information between DP4 databases.

To create an export program, you run the Report Writer automatic generation utility, and enter the name of the table. The generated program will export all the fields on the table to the file named at runtime.

The export program generated in this way is used as a basis for generating the import parameter sets. You run the importer setup utility, and select the export program from the popup list of those on the database. The generated parameters define how a file of data is posted to a table on the database.


DP4 Menu

When a user logs on to the DP4 menu system, the menu page selected for the user is displayed. If you do not set up a menu page as descibed in Using the Menu Editor, the default menu is the system menu, which gives the user access to the DP4 utilities.

The DP4 menu utility includes the system menu which provides access to the DP4 database development utilities:

The top-level system menu options provide access to the DP4 utilities as follows:

Configuration Options

System setup, user setup and maintenance, user preferences and password, keyboard lock up

Database Management

Database setup and modification, index link definition, database dictionary printing, table planning, database structure extract and transfer, database reorganisation

Backup/Recovery

Database backup, roll-back recovery, database restoration, integrity checking and transaction log auditing

QAB Facilities

QA Build program setup, compilation and interpreting, program printing, transfer and debugging, automatic program generation

Other Facilities

Data entry and enquiry, data import and export, report setup and printing, menu setup, map editing and maintenance, help authoring and text file editing

Run Program

Run a program as from the operating system command prompt

Log Out

End your DP4 session and return to the operating system

Exit

Return to the operating system without logging out


Text Editor

The DP4 text editor (DP4ED) is an editor that allows you to enter and store text in a file. The text editor provides the following functionality:

  • Word wrap

    You specify the maximum length of a line before DP4 wraps the text onto the next line

  • Copying and moving text

    You can copy or move blocks of text to a new place in the file, or to a new file

  • Select text colour

    You can change the ink and paper colour for text

  • Box drawing

    You can draw boxes on the screen and around text

  • Print

    You can print the file to any output destination you have set on your system

  • Save to a file

    You can save the text in a file, or you can specify that the file is stored in an alternative format defined on your system

Although not as powerful as a proper word processing program, the editor can be useful if you are working in an unfamiliar environment


File Viewer

The DP4 file viewer displays the contents of a file on the screen. The file viewer displays the text in colour, if the DP4 painting options have been used on the file. It is quite often useful for displaying a report that has been printed to a file.

The file viewer provides the options to print a file.

In the 4.6xx version of DP4 this program is less frequently used, as the DP4 print manager program provides superior facilities for viewing a report. However, it is still useful for viewing files created in plain-text format for use by other software.


Map Editor

You use the DP4 map editor to define all the screens and forms in your database application. Maps are stored on your application database, and are displayed or printed by your application programs.

The map editor utility lets you manage the maps on your database. A powerful feature of the DP4 map architecture is that you can store a separate set of maps on your database for each language your application must support. This allows applications to be completely independent of the country or locale they are running in.

You organise your maps into named mapsets, that store the different types of maps on your database. For example, you might store all the message maps used by your database application in a mapset called MESSAGE, and all the maps for a customer enquiry program in a customer enquiry (CUST_ENQ) mapset:

As well as using the Map Editor described below you can export maps to a file, and make full use of the text editing facilities of your editor or word processor. (This is particulary useful in the text based version of DP4 as the format used is very simple.) When the changes are completed, the maps are posted back to the database.

Editing Maps, Map and Control Properties

The details of the Map Editor program vary according to whether you are using a text based (4.5xx), or GUI version (4.6xx), of DP4 , as does the structure of and details held in map information. (An upgrade program will automatically create 4.6xx GUI maps from 4.5xx ones). In both cases you can specify the following information.

  • Text and field layout: You can position the text, edit fields and other controls such as buttons and icons on the screen

  • Cosmetic Attributes: You can draw boxes and lines on a map, or in 4.6xx define frame styles for each field or control. You can choose the text colour (or `ink') and the background colour (or `paper'). In 4.6xx you can assign colours for each part of objects such as buttons, and select the font to be used for each control.

  • Control Properties:You can specify a range of other properties which reduce the amount of code required in a program:

    • Validation: You can specify a field definition from the database which can eb used to validate a number or date is within a certain range. In 4.6xx you can also specify a custom validation on a field by field basis.
    • Security: You can enter read and write access levels for a field on a map
    • Data formatting:You can specify how the value in a field is to be formatted for display purposes (for example whether and how to separate thousands in a numer) . It is even possible to use a completely different type of control, for example a set of radio buttons instead of a numeric entry field, without the need for application changes.
    • You can define things such as the Tab order of the fields in a dialog or mnemonic or short cut keys for menus.

  • Copying and pasting: You can copy an entire map, and you can copy a part of a map to another point in the map

  • As well as editing maps you are likely to need to perform various Map Management tasks, which MAPEDIT and associated utilities also handle.


Map Management

The map editor helps you to manage the maps on your database. You can use the map editor to review the organisation of the maps, and add, copy and delete maps.

The map editor, or an associated utility called MAPMAKE (in 4.6xx), provides several additional facilities:

  • Export maps

    This option lets you export the maps to a text file. You can use the maps in the production of user documentation. You can also edit the maps using your favourite word processor or editor, and post the maps back to the database when you have finished

  • Documentation

    You can print out your maps to a text file or printer in a format useful for producing documents such as user manuals

  • Create a change file

    You may have more than one copy of a database during the development process. You can ask the map editor to print out all the maps that differ between the two versions of a database. This can be very useful when you need to translate maps into several languages.


Menu Editing

The DP4 menu editor enables you to enter a specialised map that is displayed as a popup menu. The options can do either of the following:

  • Run an executable program

    You can specify the command to run a DP4 application program, written in C, QA Build, Report Writer or SQL, one of the DP4 utilities, or any other program installed on the computer.

    Execute a DP4 menu command

    You can select from a range of DP4 commands to log on, log off, lock up the screen until the user returns, change the user preferences and return to the operating system, or move to an another page of the menu.

For each menu option, you can specify a set of parameters. You can also popup an entry window to prompt the user to enter parameters, such as the name of the file to edit.

For example, to run a QA Build program, you would enter the database name and the name of the program in this format:

PROGRUN -DB <database name> -PROG <program name>

You can specify a default option that is highlighted when the user returns to the menu.


Help Authoring

To help you add context-sensitive help to your programs, DP4 provides a help authoring utility. The help author is a utility that you load into memory, and invoke when your program is running.

To enter a help message for a field, you move to the field and press the author key. The help editor will overlay what is on the screen to allow you to enter and edit the help text. When you have completed the message, you exit the help editor, and continue through your program. You can use this method to add a complete set of help messages to your program.

The help editor is based very closely on the DP4 text editor. You can copy and move text, draw boxes, and colour the help text. You can also specify whether a beep sounds when the help message is displayed. The help messages can be output to a printer or a file destination.


Test and Demonstration Setup

The DP4 redirect tool is a utility designed to help you construct test sequences and demonstrations for your database application. Redirect records your keystrokes as you execute a DP4 program. The record of keystrokes stored in a file can be played back to perform the same set of actions. DP4 responds as if you had typed the commands on the keyboard.

To record a set of keystrokes, you load redirect into memory, and specify the DP4 program that you wish to run. You can select any DP4 program, such as a QA Build program or a DP4 menu. As you select options and enter text, redirect will write the keystrokes to a file.

Demonstration of a Program

To create a demonstration, you run your application program and record the keystrokes in a redirect file. You can enter messages that are displayed when your keystrokes are played back, and you can select points at which the playback pauses. Pauses and messages can be used to slow down the playback, and draw the user's attention to what is happening on the screen.

You run the demonstration by telling DP4 to apply your redirect file to the named program. During playback, the <+> and <−> keys can be used to control the speed of the demonstration.

Testing a Program

You create a redirect test by running your application program and recording the keystrokes. Redirect files can be used for specific tests:

  • You can set up a redirect test to achieve an expected result. The test can be used to determine whether the changes made to an application have affected the functionality of a program

  • You can set up a batch file to repeat a set of actions on a system. The test will reveal if any different responses occur over a period of time. This type of test is important for resilient systems, where non-stop working must be maintained


Transaction Log Auditor

The transaction log auditor lets you view the records that are stored in the database log file. This facility is very useful for debugging programs, and for auditing purposes, as it shows you exactly what changes have been made to the database.

Auditor shows you which tables have been updated and the date and time each update was made:


Application Documentation

DP4 provides a range of utilities to help you document your application:

Data Dictionary Report

The data dictionary report utility (PRINTDB) prints out the complete details of each table on the database, including the table size, field types and field lexicon

Data Dictionary Planner

The table plan or data dictionary planner utility helps you to build a plan that shows the fields and keys in each table. You can use the plan to show the links between the tables on the database. An example data dictionary plan is shown in Data Dictionary Plan.

QA Build Program Printer

The program printer utility prints out the details of a QA Build program, including the program flow diagram, tables used by the program, and the maps used in the program


Version Control

There are two version marking tools. For an executable program and almost any other DP4 file, you use can KENTCURS to enter version information into the file header. PROGDATE displays the version information. KENTCURS can also set up the version information reported by Windows executables.

Marking an application with version information has two benefits:

  • When users consult you with questions, you can check which version of your application they are using

  • If you are working in a team, the version information helps ensure that developers use compatible versions of the database and program files


Resilience and Distributed Databases

The DP4 Database Management System is based on a client/server architecture. Application programs are clients that issue requests, and a server processes the requests:

The communications between the client and the server are transparent to your application. Your application issues a request, and the database manager processes the request. The application does not need to know whether the data is held on the workstation or on a server on the network.

The following sections outline the possible DP4 configurations from simple standalone configurations through to DP4 Resilience, and list the network protocols supported by DP4.

  • Standalone System
  • Networked System
  • Multiple Servers
  • Distributed Databases
  • DP4 Resilience
  • Supported Networks


Standalone System

A typical standalone system consists of a workstation with the following components:

  • A screen for viewing data

  • A hard disk drive containing the DP4 programs and database

  • Sufficient memory for loading programs

  • A diskette or tape drive for backing up the database and transferring data

  • A keyboard for entering data

A workstation need not be an ordinary PC. A POS terminal can be a workstation, provided it uses a standard operating system such as Windows, Unix/Linux, DOS or FlexOS.

In a single-user configuration, all requests are passed to the database manager from the client program on the same machine:

The capabilities of a standalone workstation can be used to good effect in more complex configurations. In one resilience scheme, if there is a break in the connection to the network, the workstation can continue to operate as a standalone system. The copy of the database on the workstation is used until the connection is re-established.

In a distributed database setup, some database tables can be located on the workstation. The tables on the workstation are likely to have a more rapid response time than those on the network server. This configuration is described in more detail in Distributed Databases.

Stand-alone DP4 often provides an alternative to using DP4 networking on Unix servers. Typically rather tahn connecting with DP4 networking components you can use programs such as TelNet to run DP4 programs in remotely on the server. This can provide a big performance improvement. However currently this restricts you to using a text based version of DP4.


Networked System

A networked system consists of a server machine and several client workstations.

In a networked system, the database is held in one central location. Unlike a standalone system, each user can view and update the same set of information. Networks are essential for multi-user systems such as an airline booking system, where information on flight seat availability is shared data, accessed by all the users of a system.

The client/server architecture of DP4 means that applications developed with DP4 can be run in any network environment with no change.


Server Machine

A server machine manages and stores the shared data in an application. In a networked system, this includes the database, the system database and the DP4 utilities.

Any workstation can act as a server. There are no special characteristics, other than that the machine is connected to the network and has sufficient disk space for the system and database files.

The server machine can be configured as a dedicated server, or as a workstation that runs the server in the background. As a dedicated server, the display can show you which users are logged onto the system.


Client Workstation

A client requests data from the server and sends data to the server. A client can be a workstation with or without standalone capabilities. A client can also be a POS terminal.

If the server machine is also configured as a workstation, the workstation element of the server is treated as another client.


Multiple Servers

In a standalone system, the client and server programs run on the same machine. In a networked system, there is one server machine, and several client workstations. DP4 also supports configurations that use multiple servers. This facility is used for two types of application:

  • You can set up a resilience scheme, to ensure the non-stop working of your application. Resilience is very important in retail and banking applications where a network failure can otherwise mean a halt in trading

  • You can set up a distributed database, in which database tables reside on different machines. For example, you may locate frequently used tables on the workstation, and the remaining tables on the server machine

The following sections explain how DP4 is set up on a standalone machine, and on a simple network. Make sure you understand how these environments work before you consider the alternative ways of setting up your system. These standalone and networked systems are used as the basis for the more complex systems that use resilience and database distribution.


DP4 Resilience

If the network connection is broken, the user will lose the transaction, and the application will halt. For applications in retail or banking, this can mean an expensive break in trading:

Resilience is the mechanism used to ensure non-stop working of your application. To accomplish this, two or more copies of your database are maintained at the same time. If the network connection to one of the databases is broken, operation continues with only one database.

A resilience scheme requires either the presence of at least two servers, or keeping a local database on each workstation on your system. DP4 offers you the flexibility to decide on a scheme which best meets your requirements:

  • Your scheme can make use of the standalone capabilities of the workstations, or you can use a dedicated server machine

  • The workstations may be standard PCs or POS terminals and you can mix workstations with standalone capacity with terminals that have no standalone capacity

  • There are various possible schemes for automatically maintaining "duplex" databases, that are intended to contain exactly the same data. However, in practice, it is most effective to use collector programs to retrieve transaction data from workstations' local databases. These allow a meaure of load balancing, and help to eliminate the possibility of contention errors from the database, by delegating tasks such as maintaining stock totals (which is especially likely to cause contention), to a single process.

  • You can combine resilience with the distributed database feature, so that the more commonly accessed tables are read from the local database on the workstation to ensure better performance

You can decide on your own scheme, or you can use one of the several pre-defined resilience schemes offered by DP4.


Distributed Databases

A distributed database is held on two or more machines on the network. This facility allows you to spread the components of your database physically across the network. For example, you might decide to put branch tables on the workstations, and master tables on the Head Office server.

A common way of distributing a database is to hold the base dictionary on the workstation, and the database tables on the DP4 server. The base dictionary is accessed by DP4 in the course of executing your application. In general, it is best to put commonly accessed tables on the local machine, to decrease the traffic over the network.


Supported Network Environments

The DP4 Network and Resilience programs are supplied for the following transport protocols:

  • TCP/IP
  • NetBIOS
  • IPX
  • FlexNET

Using one of these protocols, DP4 can be run on most networks in common use, over both Local and Wide Area networks (including the Internet). TCP/IP is our preferred protocol.


DP4 Connection Tools

DP4 provides four tools for handling connections:

  • Open System Driver Interface Pack

    The OSDI is a tool to help you integrate devices such as scanners and journal printers into your database system

  • Auxiliary Database Controller

    The Auxiliary Database Controller pack is is a tool to let you add extra features to the database manager. For example, you can add code to re-direct updates to a non-DP4 database or file system

  • Connection to other SQL Database Systems

    Various ADC components are available which allow you to access non-DP4 database systems such as Oracle and Microsoft Access as though they were DP4 databases.

  • Message Manager

    Message Manager is a tool to format data for sending to and receiving from a host system. For example, your application may read customer information from a host computer

All of these tools help you to make full use of the resources on your system by adding extra layers of functionality to your application. You can use these tools to integrate code that is developed and tested independently from your application programs. This method helps you develop your application in three ways:

  • When you develop your application program, you need not have any specialised knowledge of the OSDI pack or auxiliary database manager

  • Your application database and programs remain operating system and device independent

  • Your device driver, database system and message manager code can be tested separately from the application


Open System Driver Interface

The Open System Driver Interface (OSDI) package included with DP4 provides an application program interface as C code that you can modify to handle devices. You can add the commands for controlling your own devices to this code. The device driver code is loaded into memory, and is executed whenever an application sends data to an output device, or receives data from an input device.

The ability to integrate devices is very important in an environment where specialised devices are used. For example, a POS terminal may use several devices. The input devices might include the keyboard, bar code reader, and magnetic stripe reader. The output devices could include an operator display, customer display and a receipt printer.

The OSDI gives you the means to access a range of devices from an application, in as flexible a manner as possible.

You can find out more in the following pages:

  • Role of the OSDI
  • Device Definition
  • Access Within an Application
  • Writing a Device Interface


Role of the OSDI

The OSDI developer's pack provides skeleton or example code for creating a Device Interface or OSDI, which provides the DP4 terminal manager with a standard means of controlling specialised hardware. The OSDI handles the devices used by an application:

An OSDI may support:

  • Management of specialised input and output devices

  • Input from more than one device at the same time (for example, a keyboard and scanner)

  • Synchronous and asynchronous printing, depending on the operating system

  • Software devices (such as key press counters)

  • Error notification to the user application

  • Device-independent applications that are portable across different systems


Device Definition

A device definition consists of the logical name of a device such as LASER_PRINTER or SCANNER, and the commands DP4 needs to communicate with the device.

You set up a device definition using the DP4 utility DFSETUP.

DP4 gives you two levels of definition for output devices:

  • Device Groups

    At this level, you define the set of parameters that relate to the device. For example, for a laser printer, you might define the printer commands to change the paper orientation and the font. A device group can in fact refer to a whole collection of devices, defined as Component Output Devices (CODs).

  • Logical Devices

    A DP4 application accesses a device using what is, perhaps unfortunately, known as a POD, which stands for parameterised output device. This is best though of, and used, as a "logical device". A POD selects a specific combination of device group and parameters that you want to use for a particular task. For example a system might be set up different PODs for differing types of reports (e.g. Sales Reports, or Management Reports), and you might set these to use the same or different actual printers depending on the actual installation . A POD can be reconfigured to use a completely different device without the application being affected in any way.

Input devices

The input device definition lets you specify multiple input devices. This means that more than one input device may be active at any one time in an application. For example, a POS terminal can have both a keyboard and a scanner attached. The cashier is free to use either or both devices for the input of a product code. Most DP4 systems use the same definitions for input devices


Access Within an Application

The concept of device integration means that your application does not need to know how a device is defined. Even if the underlying definition of the device is changed, you do not have to make any changes to your application.

Your application program accesses a device by name. When your application "prints" a map, the control information is sent by the user interface manager to the currently selected output device. The output device need not be a printer, it can be any of the output devices set up on your system database. If the device has an associated device driver, this is loaded into memory. DP4 then takes the map, formats the fields, and sends the resulting text to the device driver.

Input to your application program is sent to the current input field on the map. Where more than one input device is used, your application can check which input device returned the data.


Writing an OSDI (device interface)

The OSDI (device integration) pack includes a template device driver C module, which you modify for your device. The template code provides empty functions for each of the actions to be taken, such as initialise the device, start input and send output.

For example, you might write a device driver for a special video display. You might include instructions to write data to a specific address in memory, or call a device specific DLL. When the application "prints" to the display, the data is passed to your function, and is in turn output to the device.


The Auxiliary Database Controller

The database manager processes all the database calls made by your application program. You can use the DP4 auxiliary database controller (ADC) to write database system code in C that is executed before the database manager code.

The Auxiliary Database Controller processes all the Controller (ADC) database calls made by your application program. It is a skeleton program, into which you can add whatever code you want to be executed as a "plug-in" before the database manager code.

You can write database system code to:

  • Use a non-DP4 database or file system

  • Add "intelligence" to the database manager without modifying your application programs

  • Access communications services

    You can find out more about writing ADCs here.


Non-DP4 Database and File Systems

The DP4 auxiliary database manager allows you to run DP4 application programs or DP4 utilities against the data stored in a non-DP4 system.

For example, if some of the data in the system is stored in a non-DP4 database, you can add your own functions to read the records from the alternative source. Whenever the database manager implements the function to fetch a record, your database system code is processed. Your database system code can filter those records that are processed by your code from those that are processed by DP4.

DP4 supply pre-defined database management code for accessing data from non-DP4 environments. For example, DP4 supply an auxiliary database controller program called AUXWODBC, that allows you to access data in an ODBC compliant database. See Connection to Other SQL Database Systems.


Adding Intelligence to the Database Manager

You can write code to perform any of a range of functions:

  • Calculate values at runtime

    For example, you might include database system code to read the current exchange rate and convert a total amount into another currency

  • Implement additional integrity constraints

    For example, you can add code to ensure that a replacement is in stock before a material is deleted

  • Implement views of the data

    For example, you might define an empty table named OVERDUE_ORDERS. At read time, your exit code would read the main orders table and return the records with overdue accounts

  • Implement a sophisticated security system

    For example, you might make a table accessible to specific people at different times of the day

  • Log database usage

    For example, you might maintain a file logging all reads of sensitive data


Accessing Communications Services

The ADC can be used for integrating a DP4 application into a communications service to a remote computer. This may be a remote mainframe providing transaction services or perhaps a card validation service. Using this method, you create tables on the database that represent the communications service. Application accesses to these tables do not store data in the tables, but instead your own ADC processing invokes the communications services. This approach enables you to model the communications system as a set of tables, allowing the application programmer to remain largely unaware of the technicalities of the communications service. It also allows application development to continue without a communications link by using the tables directly to simulate dialog.

For example, you could create two tables called SEND_TX_REQ and TX_RESP which represent the actions of sending a transaction request and reading the response. They contain fields that you wish to send and receive from the communications service. Application programmers would write records into SEND_TX_REQ and read records from TX_RESP to invoke communications. Your ADC code would intercept accesses to these two tables, turning writes on SEND_TX_REQ into message transmits and reads on TX_RESP into a wait for response.


Writing a Database System Function

DP4 provides template versions of the standard DP4 database manager functions. You can modify these functions in order to intercept the calls, and then pass the function onto the database manager, or indicate that your code performs the required action.

For example, to intercept the message to fetch the primary key of a record, ftch_prm(), you supply your database system code version of the message, u_ftchprm(), as shown in Figure 58.

int u_ftchprm(flags, data_record, index_record, role, keys)

struct DATAREC *datarec;

{
   if (datarec->typenr==_CUSTOMER)
   {
   customer = (struct CUSTOMER *) datarec;
   ....<Your_code_goes_here>....
   return 0;  /* Record to be read by non-DP4 system */
   }
   return 1;    /* DP4 to read the record */
}

Your code can make full use of the DP4 database access functions. If you are writing code that is native to one operating system, you can use the standard file functions of your operating system. If you are writing object-code portable programs, you should not use functions that are specific to one operating system.

DP4 provides a special function, user_auxdbms(), that lets you communicate with database system code from an application.


Connection to Other SQL Database Systems

The DP4 SQL environment is described earlier in the manual.

DP4 provides additional tools to access non-DP4 database systems such as Oracle and Sybase through the SQL language. Further information on these tools is contained in the following topics:

  • ODBC Gateway ADC
  • SQL Utilities


Open Database Connectivity

ODBC Gateway ADC

The Windows version of DP4 is suppled with an ADC called AUXWODBC, known as the ODBC Gateway. Using this ADC you can access any third party database that supports the ODBC interface as though it were a native DP4 database,once you have created a small DP4 database to describe the data dictionary. (The ADC comes with a utility to simplify this process). This will enable you to use standard DP4 utilities such as QA Build against the database.

For each table in your application, you can specify whether the data is located on the DP4 database or in the foreign database, enabling you to mix and match to achieve best performance. If your application requests information that is on another database system, the auxiliary program redirects the request. The DP4 query is translated into SQL statements, and is sent to the other SQL database system.

This facility, combined with the ODBC interface that allows other ODBC client software to access DP4 databases nmeans that you can use almost any mix of DP4 and non DP4 programs and databases in a system. It should also make it much easier to transfer data between systems.

Specialised replacements for the Gateway ADC are available for accessing Oracle and Sybase databases. These use the native API for these databases, enabling improved performance and use of special facilities.


SQL Utilities

DP4 provides the following utilities for SQL data structure transfer:

SQLMake

This utility creates an SQL database from a DP4 database. It does this by creating a file of SQL DDL (Data Definition Language) commands which can be executed using an SQL product from another supplier

SQL2DP4.EXE

This utility creates a DP4 database from a file of SQL DDL commands such as CREATE TABLE and CREATE INDEX


Message Manager

The DP4 message manager is a tool for composing and decomposing messages that are sent to and received from a host system or other applications. The messages consist of data such as records and variables, in a format that can be understood by the receiving system.

For example, you may have a branch application program which needs to look up customer information on a central computer. The central computer is designed to update a terminal, and sends all the data to update the screen display, including the customer details you require. However, your computer is not a terminal at all, it is an intelligent workstation. Before your application can use the data, the customer details must be extracted as distinct fields, in a format that your application program can understand. Message manager provides you with the mechanism for decomposing the message, which you can process in your DP4 application.

The message manager tool comprises the libraries for inclusion in your application program, and the utilities for setting up and testing a message definition. The message manager environment is shown in the diagram on the right.

The definition of the message formats are held on the database. Because the application programs read the format from the database, you can modify the message format without having to change the application code.

You can find out more about how to use Message Manager in the following topics:

  • Message Setup
  • Including Message Manager in the Application


Message Setup

To set up a message, you run the MSGSETUP utility, and define the fields that compose the message. This specifies the mapping and conversion between the internal and external representations. You can define the following setup features:

  • You can include database and local fields and fixed strings of characters in your message

  • Fields can be fixed length or variable length. If variable length fields are used, you can specify the delimiter to identify the end of the data in the field

  • You can specify character fields, number fields, and date and time field types, in ASCII, EBCDIC or Binary formats

Once you have completed the message setup, you compile the parameters. Your message definition is stored as a parameter set in the base dictionary of the database. You can test the parameters, and export them to other databases using the message utility MSGUTIL.


Including Message Manager in the Application

DP4 provides message manager libraries for C and QA Build. In both cases, a source module supplies you with the data structure and functions you need to call the message manager.

In C, you run the message manager code generation utility MSGMAKE. MSGMAKE reads your compiled parameters and generates a C source module. The C source module defines the data structure for storing messages in the format you specify. The source module defines the functions, including:

init_msg() | Initialise and test the parameter set
compose() | Translate the data into the message structure
decompose() | Translate the message structure into the component parts

C Application Programs

When you wish to translate a record in your C program, you call the compose() function. You pass the identification number of the message parameter, and a pointer to the block in memory that is to store the message.

You call decompose() when you wish to translate a message, and read the values into fields. You pass the identification number of the message parameter, and a pointer to the start of the message in memory.

QA Build Application Programs

In QA Build, you incorporate message manager as a C Exit. To do this, you link the message manager library with the QA Build module. In your QA Build program, you set up a message table that references the message parameter you are using.

All the messages sent and received by your program are stored in the message table. To compose or decompose a message, you set up a procedure that executes the msg_comp() or msg_decomp() functions.


Appendix A: DP4 Program Reference

This Appendix lists the DP4 programs that are described in this document, in seven sections:

  • Database Management System
  • User Interface Tools
  • System Configuration Tools
  • Programming Tools
  • Support Tools
  • Network and Resilience Programs
  • Programs for Connection to External Device and Systems


Database Management System

Program/Utility | Executable | Description
Database Backup | DBBACKUP DYNABACK | Database backup utilities
Database Copy and Transfer | COPYDB RECASTDB | Database structure copying and transfer
Data Dictionary Definition | MAKEDB | Database setup and modification
Database Integrity Checking | DBCHECK DYNACHEK | Data integrity checking
Database Manager | SRVx or DP4SRVR.W32 | (x denotes the operating system) manages the data in a database
Table Link Generation | MAKELINK | Generate the links between tables in the data dictionary
Reorganise a Database | REORGDB | Reorganise or rebuild a database after you make changes to the structure
Roll-Back Recovery | DBRECOV | Recover the database after a system crash
Roll-Forward Recovery | DBRESTOR | Restore a database from backups, with the option to apply the transaction log for roll-forward recovery
Set Table Link Attributes | SETLINK | Set up the rules on the indexes between tables, such as 'child delete', 'parent check' and 'prevent change'


User Interface Tools

Program/Utility | Executable | Description
User Interface Manager | TRMx | (x denotes the operating system) Provides the parts of the standard DP4 application program interface that manage the screen, printer and devices
Menu Definition | MENUEDIT | Set up a user menu
Map Definition | MAPEDIT | Set up a map for formatting text and fields


System Configuration Tools

Program/Utility | Executable | Description
System Setup Program | DFSETUP | Configure your system for the location of files, console logging, user preferences, keyboard layout and printer definition
User Setup | MENUUSER | Set up the password, language and access levels for a user
User Terminal Type | USERDATA | Select the user settings for your workstation


Programming Tools

Program/Utility | Executable | Description
C Program Development | LIBMAKE | Generate a data definition file for a C source file. LIBMAKE also supports C++,Delphi and Visual Basic.
QA Build Program Development | PROGMAKE PROGCOMP QABUTIL PROGRUN PROGRUND | Set up a QA Build program. Compile a program, transfer and test programs, run programs and debug programs
Report Writer Program Development | REPSETUP REPPRINT | Set up report programs and print reports
SQL Program Development | SQL SQLMAKE SQL2DP4 | Query the database using SQL commands, create compatible SQL and DP4 databases


Support Tools

Program/Utility | Executable | Description
Audit Transaction Log | AUDITOR | Examine the database transaction log
Automatic Program Generation | AUTOQAB | Generate a data entry application for your database
Data Entry and Enquiry | BROWSER | Enter and examine database records
Help Authoring | MAPEDIT AUTHOR | Add help text to each of the fields on your database
Import Data | IMPSETUP IMPPOST | Set up the parameters to import records from an ASCII file to the tables on the database
Map Editing | MAPEDIT | Create, amend and delete maps
Map Management | MAPEDIT MAPPOST MAPMAKE | Manage maps in different languages, copy maps and export maps to and from an ASCII file
Menu Editor | MENUEDIT | Set up user menus and manage the user and language tables
Menu Program | DP4 | Display the standard DP4 menu or user menu set up with the Menu Editor
Software Release & Data Distribution | SRDD SRDDUTIL POSTSRDD | Release software upgrades to customers, maintain database of changes
Text Editing & Viewing | DP4ED VIEW | Use full-screen editing facilities for producing text files


Network and Resilience Programs

Program/Utility | Executable | Description
Client Agent | TCPMGR NTBMGR FLXMGR IPXMGR | Receive messages and send to the database manager
Network Copy | NETCOPY | Copy files over the network
Network Router | TCPx FLXx NTBx IPXx | Route database requests over the network
Resilience | AUXDISTR | Distribute data requests, specify the location of tables, re-synchronise databases


Programs for Connection to External Device and Systems

Program/Utility | Executable | Description
Auxiliary Database Management | Object files (source-code product) | Modify template and link object files to create an ADC
Connection to SQL Systems | AUXORACL AUXSYBAS AUXWODBC SQL2DP4 SQLMAKE | Communicate with database systems from other vendors
Device Integration | OSDI (source-code product) | Produce OSDI to load into memory to manage integrated devices
Message Management | MSGMAKE MSGSETUP MSGUTIL | Create parameter sets, extract and test parameters, create source module for linking with application
Open Database Connectivity | ODBCLIBx | Provide ODBC standard API for accessing DP4 databases


DP4 Limits

Operating System and Network software may impose limits of its own.

For example Unix limits the amount of memory a single process can have and the number of files it can open (sometimes to as little as 64). You need to make sure you have configured appropriate limits for the kernel. SRV3 will open one file for every user, as well as all the regular database files. TCPMGR will "fork" another process for every connection.

Database Manager

Maximum database data file size | 4096 MB (up to 4.622). From release 4.622 there are no file size limits other than those imposed by the underlying operating system
Maximum number of tables on a database | 32K
Maximum number of records per table | Limited only by max data file size
Maximum record size | 4K
Maximum field size | 4K-12 bytes
Maximum number of key fields per table | 99
Aggregate key size | 200 bytes
Maximum length of table and field names | 16 charcters
Maximum number of indexes per table | 32767

Maximum Number of Connections

DP4 limits the number of connections that a server can accept (there is one connection per client machine, if multiple programs run on on a client there is only one connection) to 256. Individual implementations of TCP/IP may limit this figure further. A client can connect to 99 servers simultaneously using AUXDISTR, but individual tables can only use 32 of these.

The maximum number of connections supported by the network manager depends on the platform.

For both 16- and 32-bit Windows DP4 limits this value to 127 (or 256 in 4.623). If a Windows client is running two DP4 programs that is only one connection but two user processes. Again this may be further limited by the underlying software layers. (The 16 bit Windows TCPMGR is obsolete. It probably won't accept more than about 6 connections, because of memory constraints)

On UNIX servers the limit is the smaller of 256 and the defined value of FD_SETSIZE. This is defined in the system header files. There is only one connection per client machine.

The DOS network manager can accept up to 128 connections. (The DOS network manager is not available since release 4.520. It certainly won't accept 128 connections if it is reinstated)

Networks

Maximum number of servers | 99
Maximum number of databases open | 48. In 4.623 up to 1024 databases may be opened
Maximum number of DP4 programs per server | 414 - Likely to be limited further by number of connections

Notes

The lists above shows the current limits of the DP4 system.

However, the practical limits may be affected by performance issues.

QAB and User Interface Limits

Prior to release 4.520/4.616 there was a limit on the number of QAB procedures of 32767. Now you can raise this limit to 65533 by making some changes to the base dictionary. See release notes for details.

QAB Programs can access a maximum of 128 database tables per program.

Each QAB procedure can process at most 99 input and output fields.You can have additional fields that are neither input nor displayed.

In 4.5xx DP4 programs can display a maximum of 50 maps on screen at the same time. There is no limit in 4.6xx.

Prior to release 4.624 the maximum size of a compiled QAB program is 64K code+data. In 16 bit versions of DP4 the maximum size is 42000, but this can be increased if you link your own version of PROGRUN. In 4.624 the maximum size of a QAB program is limited only by the maximum size of a characer array in a 32-bit program. The default maximum program size is 4MB, but you can increase this is you link your own version of PROGRUN.

Minimum processor requirements

From release 4.521 the minimum processor requirement for all 16 bit versions of DP4 is an 80386 (previously the English MS-DOS version worked on 80286).

32-bit DP4 will work on any 32-bit x86 style processor. DP4 is tested on machines with Intel Pentium 4 class processors, but there are no known compatibility issues with older processors, or with AMD processors.

64-bit DP4 is currently only available for "X64" style processors. The Itanium processor is not supported.


Access Control

User access to programs and data in DP4 can be controlled by allocating appropriate read and write access levels


ADE

Application Development Environment - the tools for developing an application


Application

The database and associated programs which meet the requirements of a system


Asynchronous Resilience

A type of duplex resilience, where commits are made to one server before processing continues. Within a short space of time, the same update is made to the second server


Attach Map

A map that is displayed at the coordinates of a specified field that is already on the screen


Auxiliary Database Controller

The Auxiliary Database Controller processes all the Controller (ADC) database calls made by your application program. It is a skeleton program, into which you can add whatever code you want executed before the database manager code


Base Dictionary

The base dictionary is a component of the DP4 environment. It defines the underlying structure for the data dictionary. An application database is initialised by making a copy of the empty base dictionary


BASIC Programming

BASIC is one of the supported, third generation development environments in DP4. The development environment provides a set of tools to develop powerful database applications


C Programming

C programming is one of the supported, third generation development environments in DP4. The development environment provides all the facilities necessary to develop powerful database applications


Change Verify

A contention control method that ensures that the first application program to update a record will be successful, and that other programs will not be allowed to update the record until they have read the new version. This method is perhaps better known as optimistic contention control.


Child Table

A table that includes the key fields of a parent table


Client

An application program running on a workstation that issues requests to a server


Client/Server Architecture

An architecture in which a program (the client) issues requests to a master program (the server) which can reside on a separate machine


Composing

In message manager this means translating the data into the message structure you have specified


Contention Control

A scheme to ensure that data integrity is preserved when two users attempt to update the database at the same time


Context-Sensitive Help

Specific information on the currently selected field or option on the screen


Data Dictionary

The set of table and field definitions (including names, types, roles and relationships) that define the database


Data File

A DP4 database comprises at least a data file (.DAT) and an index file (.IND). The data file contains all the tables in your database and all their records


Data Independence

A scheme to ensure that the program accessing data does not need to know the physical details of data storage


Data Integrity

The correctness of data values on the database


Data Recovery

This is the mechanism by which the database ensures that data can be recovered. The DBRECOV utility can be used to recover the database after a system crash, if roll-back logging is turned on


Database

A file of structured data that can be accessed for different purposes by a range of programs


Database Manager

A component that manages the database, and ensures that data can be accessed concurrently and is protected from corruption


DDI

A term sometimes used as the name for a device interface built using the OSDI package. The term DIP is also commonly used.


Decomposing

In message manager this means translating the message structure into the component parts


Dedicated Server

A server machine that runs the DP4 network software in the foreground


Device

An object attached to the workstation that inputs information to or outputs information from the application


Device Independence

A scheme to ensure that changes to the devices on a system do not affect the application


Device Integration

A mechanism to allow devices such as bar code readers and customer displays to be accessed by an application without the use of device or system dependent code


DIP

An old name for the the DP4 product that provides the application program interface for device handling in DP4. (The name stands for Device Integration Pack). This is now known as the OSDI. Device interfaces built with the OSDI are still commonly referred to as DIPs.


Distributed Database

A distributed database is one that is held on two or more machines on the network. This allows you, for example, to put branch tables on the workstations, and master tables on the Head Office server


DP4 Database Management System (DBMS)

The DP4 Database Management System is a set of tools for implementing and maintaining a relational database


DP4 Menu Program

A menu program named DP4 is provided to run the menus set up for each DP4 user


Dynamic Backup

The process of backing up the database whilst it is being accessed by other programs


Entity

A significant business object with properties that are modelled, stored and manipulated in the database system


Entity Modelling

The process of identifying objects in the real world that are to be represented in the database


Entity Relationship Diagram

The Entity Relationship Diagram shows boxes representing entities, linked by lines that show the relationships (such as: one-to-many, many-to-one) between the entities


Export Data

The mechanism of outputting information from the database in a format that can be read by another application, such as an ASCII file


Field

A single item of data in a record


Field-Sensitive Help

Help for each field and option within DP4


Field Role

A role that is applied to distinguish a field from another field of the same type


Generation Number

DP4 uses generation numbers to keep track of modifications made to the application database, records on the database, application programs and Report Writer programs. For example, if you make structural changes to the database, its generation number is incremented. Each time a program accesses the database, the generation number of the application program is compared with that of the database. If they are different, the database manager translates the record correctly


Glossary

This glossary provides brief definitions for many of the terms used in this document. The definitions are restricted to their use in the context of DP4.Not all these terms are the same as ones commonly used actually by DP4 developers and users!

• Access Control | • Entity | • Parent Table
• ADE | • Entity Modelling | • Performance
• Application | • Entity Relationship Diagram | • Point of Sale
• Asynchronous Resilience |  | • Popup Window
• Attach Map | • Export Data | • POS Terminal
• Auxiliary Database Controller | • Field | • Post
• Base Dictionary | • Field Role | • Primary Key
• BASIC Programming | • Field-Sensitive Help | • QA Build
• C Programming |  | • Record
 | • Generation Number | • Record Locking
• Change Verify |  | • Referential Integrity
• Child Table |  | • Relational Database
• Client | • Help Authoring | • Report Writer
• Client/Server Architecture | • Import Data | • Resilience
 | • Index | • Resilience Scheme
• Composing | • Index File | • Roll-Back Log
• Contention Control | • Index-Only Table | • Runtime Environment
• Context-Sensitive Help | • Indexed Records | • Secondary Key
• DDI | • Key Translation Table | • Server
• Database | • Keyboard Management |
• Database Manager | • Language Table | • SQL
• Data Dictionary | • Licence File | • SRDD
• Data File | • Licence Number | • Standalone System
• Data Independence | • Logical Device | • Synchronous Resilience
• Data Integrity | • Map | • System Database
• Data Recovery | • Mapsets | • System Menu
• DP4 Database Management System (DBMS) | • Message Manager | • Table
• Decomposing | • Multi-Occurs Field | • Table Link
• Dedicated Server | • Multi-Part Key | • Third Normal Form
• Device | • Multi-User | • Transaction
• Device Independence | • Multiple Language | • Transaction Log
• Device Integration | • National Language Support | • User Code
• DIP | • ODBC Driver | • User File
• Distributed Database | • ODBC (Open Database Connectivity) | • User Interface Manager
• DP4 Menu | • Object-Code Portable | • User Menu
• Dynamic Backup | • Operating System Portability | • Workstation
 | • Output Destination |


Help Authoring

The DP4 authoring utility allows you to add context-sensitive help to your application programs. This utility is pre-loaded into memory and can be invoked from within your application program


Import Data

The mechanism of reading information into the database in a format that can be generated by another application, such as an ASCII file


Index

A retrieval mechanism that allows data to be retrieved in a particular sequence


Index-Only Table

An index-only table is inhibited from having data entered into it, and is used to create secondary indexes for its child tables


Index File

A DP4 database comprises at least a data file (.DAT) and an index file (.IND). The index file provides the access mechanism for data retrieval. It contains the keys together with pointers to the records in the data file


Indexed Records

Records in a table are indexed by the primary key, and any secondary keys in the table


Key Translation Table

A table that defines the message that is sent to the application when a key is pressed


Keyboard Management

The User Interface Manager (UIM) manages the keyboard


Language Table

This table allows you to set up mapsets for different languages that are appropriately displayed depending on the user's login name


Licence File

The DP4 licence file, DATAFIT.SYS, holds your DP4 licence number and name, as well as defining the location of the DP4 files, and console/transaction settings. DATAFIT.SYS is provided with the distribution disks


Licence Number

The DP4 licence number is stored in the licence file, DATAFIT.SYS, and uniquely identifies each installation


Logical Device

A representation of a device on the system database which consists of a name and the currently selected parameters for the device


Map

A definition of the layout of text and fields that is used for displaying and printing information


Mapsets

A mapset is a collection of maps under a mapset name. Mapsets are stored on the application database


Message Manager

The DP4 Message Manager is a tool for composing and decomposing messages that are sent between it and a host system or other application


Multi-Occurs Field

Fields may have multiple occurrences. For example, an address field with 3 occurrences can hold a three-line address


Multi-Part Key

A multi-part key is one that is composed of several fields to select table records


Multi-User

A system that can be accessed by many users at the same time


Multiple Language

The facility to display text in more than one language


National Language Support

The facilities in DP4 that support the development and creation of applications in other national languages


Object-Code Portable

The term used for executable programs that can run on several operating systems without modification


ODBC (Open Database Connectivity)

A standard interface for developing applications that can be run against any database management system that supports ODBC, including DP4


ODBC Driver

A set of functions that comply with the Open Database Connectivity (ODBC) standard


Operating System Portability

The ability to transfer applications with no modification


Output Destination

The screen, printer or file selection to which the application sends data


Parent Table

A table which has a one-to-many relationship with another table (a child table)


Performance

The combination of factors relating to the speed and efficiency of a system, including the time to retrieve a record from the disk and the rate at which transactions are processed


Point of Sale

An application that processes sales and other transactions on a POS terminal


Popup Window

A map that temporarily overlays part of the main screen


POS Terminal

A type of Workstation with devices such as an operator display, keyboard, cash drawer and receipt printer used at point of sale


Post

To send information to the database


Primary Key

One or more fields that are used to select the records in a table


QA Build

A fourth generation programming environment for use with DP4 applications


Record

A single set of information, including the key fields and data fields that is stored in a table. A record is represented as a 'row' in a two-dimensional table


Record Locking

The contention control mechanism that ensures an application program cannot access a record that is currently being processed by another program


Referential Integrity

The facility to include rules in the database to ensure that data integrity is maintained


Relational Database

A database system that organises data in tables, and allows record selection using the keys in a table


Report Writer

A report writing environment for defining and running reports on the data in a DP4 database


Resilience

The ability of a DP4 system to continue operating with data integrity in the event of the failure of part of it


Resilience Scheme

DP4 offers two basic resilience schemes, which may be used separately or combined:

  • Local database resilience, where a local database exists as well as the central database. This covers the following failures: entire network fails; link to the server or the client fails; server crashes

  • Duplex server resilience, where there are two servers, each with an identical copy of the central database. The following failures are handled: link to one of the servers fails; one of the servers crashes


Roll-Back Log

This stores the images of the data before changes are made to the database


Runtime Environment

The set of programs required to run the DP4 end-user application. Important amongst these are the User Interface Manager and the Database Manager


Secondary Key

A key other than the primary key that is used for indexing purposes


Server

The DP4 environment supports a client/server architecture. The server is the machine on which the database server resides


SQL

A query language common to many relational database management systems


SRDD

The DP4 Software Release and Data Distribution (SRDD) product is a management control system for the incremental release of data from a master site to its remote sites


Standalone System

A computer system in which client and server programs run on the same machine


Synchronous Resilience

A type of duplex resilience, where any updates are committed to two servers before other processing is carried out


System Database

The System Database is a component of the DP4 environment. It contains information for the application databases, the list of users and their passwords, and the set of printers and devices


System Menu

A standard menu that provides access to all the DP4 utilities. This is the default menu, if you do not set up a menu page for a user


Table

A two-dimensional representation of data, in which fields comprise the columns and records comprise the rows


Table Link

The inclusion of the fields of one table in the second table


Third Normal Form

The stage of normalisation of an entity in which the key (such as a customer number) uniquely identifies all the other fields of a record (such as the name and address)


Transaction

A set of changes to the database that are processed as a single unit


Transaction Log

A log that records all the modifications to the database since the last backup


User Code

User-supplied C code incorporated into the DP4 runtime system. For example, you can use the DP4 ADC to write database system code in C that is executed before the database manager code


User File

The DP4 user file, USERDATA.SYS, holds information defining a user's terminal


User Interface Manager

A component that manages the screen, keyboard and printer and communicates with the operating system. In fact this component is generally known as the terminal manager.


User Menu Display

A menu that is displayed when the user logs on to the system


Workstation

The client machine, including the operating system, screen (not necessarily a full size monitor) and keyboard used by the application