03 UG Solutions Guide

sgpubb.
book Page 1 Friday, April 14, 2000 11:08 AM
Issue 3a, May 2000
Micro Focus
®
Net Express
Solutions Guide
sgpubb.book Page 2 Friday, April 14, 2000 11:08 AM
Copyright © 2000 MERANT International Limited.

All rights reserved. Printed in the U.S.A.
MERANT has made every effort to ensure that this book is correct and accurate, but
reserves the right to make changes without notice at its sole discretion at any time.
The software described in this document is supplied under a license and may be used
or copied only in accordance with the terms of such license, and in particular any
warranty of fitness of MERANT software products for any particular purpose is
expressly excluded and in no event will MERANT be liable for any consequential loss.
Micro Focus®, Animator® and Forms-2® are registered trademarks, and AAI™,
Analyzer™, Animator Version 2™, Application to Application Interface™, AppTrack™,
CCI™, Co-Writer Builder™, Co-Writer Designer™, Co-Writer™, Co-Writer Report™,
Dialog System™, Directory Facility™, Forms™, LEVEL II COBOL™, LEVEL II COBOL/ET™,
Micro Focus COBOL™, Micro Focus COBOL/2™, Object COBOL™, Operating System
Extensions™, OSX™, Panels™, Panels Version 2™, Professional COBOL™, RTE™,
Screens™, Session Recorder™, Structure Animator™, Toolbox™, VS COBOL™,
Workbench™, Xilerator™, XM™ and MERANT™, are trademarks of MERANT. All
other trademarks are the property of their respective owners.
No part of this publication, with the exception of the software product user
documentation contained on a CD-ROM, may be copied, photocopied, reproduced,
transmitted, transcribed, or reduced to any electronic medium or machine-readable
form without prior written consent of MERANT.
Licensees may duplicate the software product user documentation contained on a CD-
ROM, but only to the extent necessary to support the users authorized access to the
software under the license agreement. Any reproduction of the documentation,
regardless of whether the documentation is reproduced in whole or in part, must be
accompanied by this copyright statement in its entirety, without modification.
U.S. GOVERNMENT RESTRICTED RIGHTS. It is acknowledged that the Software and the
Documentation were developed at private expense, that no part is in the public
domain, and that the Software and Documentation are Commercial Computer
Software provided with RESTRICTED RIGHTS under Federal Acquisition Regulations
and agency supplements to them. Use, duplication or disclosure by the U.S.
Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of The
Rights in Technical Data and Computer Software clause at DFAR 252.227-7013 et. seq.
or subparagraphs (c)(1) and (2) of the Commercial Computer Software Restricted
Rights at FAR 52.227-19, as applicable. Contractor is MERANT, 701 East Middlefield
Road, Mountain View, California 94043. Rights are reserved under copyright laws of
the United States with respect to unpublished portions of the Software.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Purpose of this Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Example Scenarios . . . ...... ...... ....... ...... ....... . 6
1.2.1 Gas Services . . . . ...... ...... ....... ...... ....... . 6
1.2.1.1 Phase 1 . . . ...... ...... ....... ...... ....... . 6
1.2.1.2 Phase 2 . . . ...... ...... ....... ...... ....... . 7
1.2.1.3 Phase 3 . . . ...... ...... ....... ...... ....... . 7
1.2.1.4 Phase 4 . . . ...... ...... ....... ...... ....... . 7
2 Developing Client/Server Applications . . . . . . . . . . 9

2.1 Client/Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.1 What is a Client/Server Application? . . . . . . . . . . . . . . . . . 9
2.1.2 Client/Server Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Suggested Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 Separating Program Logic . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Supported Platforms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3 Client/Server on the Web . . . . . . . . . . . . . . . . . . . . . 17

3.1 Introduction to the World Wide Web . . . . . . . . . . . . . . . . . . . . . 17
3.2 What Does a Web Application Look Like? . . . . . . . . . . . . . . . . . 20
3.2.1 Execution Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Challenge: Creating a User Interface . . . . . . . . . . . . . . . . . . . . . 21

3.3.1 Solution: HTML Form Using Cross-platform Output or
Dynamic HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.2 2 Adding an Event Handler . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Challenge: Migrating or Updating an Existing User Interface . 27

3.4.1 Solution: Internet Application Wizard . . . . . . . . . . . . . . . 27
Solutions Guide
3.5 Challenge: Web Server-side Program . . . ....... ...... ...... 28

3.5.1 Solution 1: CGI Program . . . . . . . . ....... ...... ...... 30
3.5.1.1 Pros and Cons . . . . . . . . . . . . ....... ...... ...... 31
3.5.1.2 Practical Considerations . . . . ....... ...... ...... 31
3.5.1.3 Example . . . . . . . . . . . . . . . . . ....... ...... ...... 32
3.5.2 Solution 2: ISAPI Program . . . . . . . ....... ...... ...... 36
3.5.2.1 Pros and Cons . . . . . . . . . . . . ....... ...... ...... 37
3.5.3 Solution 3: NSAPI Program . . . . . . ....... ...... ...... 37
3.5.3.1 Pros and Cons . . . . . . . . . . . . ....... ...... ...... 38
4 Data Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1 Challenge: Accessing an RDBMS . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Solution: OpenESQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1.1 Practical Considerations . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.1.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.2 Solution: Internet Application Wizard . . . . . . . . . . . . . . . . 61
4.1.2.1 Practical Considerations . . . . . . . . . . . . . . . . . . . . . . . 62
Solutions Guide
1 Introduction
This chapter explains the purpose of this book, who should read it, and
how it fits into the rest of the Net Express documentation. It also
explains the imaginary organization and scenarios that are used for the
examples in the rest of the book.
1.1 Purpose of this Book

This book is aimed at programmers who are developing complete
client/server solutions, and who need a practical understanding of the
technologies and issues involved in creating real-world COBOL
applications with Net Express.
It concentrates on key concepts and practical examples of some of the

main technologies supported by Net Express, illustrating typical
challenges in designing, programming and deploying field-strength
client/server COBOL applications. Its aim is to provide a choice of
possible solutions, enabling you to make informed decisions, and
giving you the key technical, implementation and rollout details you
need. Realistic examples of the techniques described are provided
where appropriate.
This book is designed to be used in conjunction with the other online

books, which give more detailed information about using the features
available in Net Express, and with the Net Express online help system,
which provides comprehensive reference and step-by-step task
information. References in the text indicate where we suggest you look
at specific topics in the online books or help system.
We want this book to be kept right up-to-date with the latest

techniques available in Net Express. If you have any ideas or
suggestions that you would like us to explore, or if you find a better
way of doing something shown in this book, please let us know and
share the benefit with other COBOL programmers.
Solutions Guide
6 Chapter 1 Introduction
1.2 Example Scenarios

Many of the solutions outlined in this book use code from applications
designed around imaginary scenarios to illustrate their application in a
real-world situation. These scenarios, detailed below, are designed to
illustrate specific applications as realistically as possible, without making
the code too complicated to follow. For example, they incorporate some
features that would be essential in a real application (such as data
validation), but they are not always implemented in a fully realistic
environment (for example, using a transaction processing system in
conjunction with a database). We suggest you read the general
introduction to get a flavour of the scenario, then refer back to the
specific phases of implementation as required later in the book.
1.2.1 Gas Services

Gas Services Incorporated is a utility company that supplies gas to
domestic customers. It currently services only the Eastern State area, but
is in an advanced state of negotiations with competitor WestGas
Corporation with a view to a merger and expansion to service the entire
state. Each house in the service area has a gas meter that is read by a
Gas Services employee at regular intervals, immediately before the
customer’s gas invoice for the billing period is produced. If the
employee cannot read the meter for any reason, the gas consumption
for the period is estimated, and the estimated figure is used to produce
the customer’s invoice. If the customer doesn’t agree with the estimated
figure, they can read their own meter and supply a figure which is used
to produce a revised invoice.
1.2.1.1 Phase 1
Gas Services customers can currently supply their own meter reading by
using Gas Services’ telephone Helpline. There is a requirement,
however, for customers to be able to connect to a page on the World
Wide Web, and update their meter reading using a Web application.
The server-side program will be run on the existing Gas Services
Windows NT Web server.
Solutions Guide
1.2 Example Scenarios 7
1.2.1.2 Phase 2
Gas Services require a client/server system to support their Helpline
operators in dealing with customer enquiries. Customers can call the
Helpline to give their own meter reading, to change their choice of gas
tariff, to make enquiries about their invoices, or to make general
enquiries. The Helpline operators need a system to provide the
necessary customer data from the operational database system, and to
accept changes they make to the data. The Helpline supervisor
additionally requires the system to generate follow-up letters at the
end of each working day to customers who have requested a change in
their gas supply tariff.
The system will be deployed on a Windows NT server at the Helpline

Center. The Gas Services data is held in an Oracle relational database
on a UNIX server. The Helpline application server is linked to the
database by a wide area network. The Helpline operators use Windows
95 machines that are connected by a local area network. Each operator
must be able to deal with up to four customer enquiries at a time.
1.2.1.3 Phase 3
The merger with WestGas is complete.
Before the merger, Gas Services and WestGas each operated a

telephone Helpline and had independent operating databases. The
former WestGas database is held in COBOL files on a mainframe. Since
the merger, the Helplines have been combined into a single Helpline
Center, but the databases for each area are still separate.
1.2.1.4 Phase 4
Gas Services offers twelve standard gas tariffs. Due to difficult market
conditions, however, the corporation has had to introduce a special
tariff that can be tailored to the customer’s individual circumstances. A
telephone Helpline operator can find out how much gas a customer
has used over the last twelve months and, using this to represent a
typical year’s consumption, explore how the charges vary as the tariff
variables are adjusted.
Solutions Guide
8 Chapter 1 Introduction
Solutions Guide
2 Developing Client/Server
Applications
This chapter introduces some of the basic principles of client/server

applications and explains their advantages over the more traditional
monolithic architecture. It also suggests how to divide your application
into modules that make the most of client/server architecture, and
outlines the platforms on which Net Express applications can be
deployed.
2.1 Client/Server Architecture

Despite a rapid increase in the deployment of client/server applications,
there is still a certain amount of mystique surrounding the term
’client/server’, especially as the same term is often used to describe a
number of different concepts.
2.1.1 What is a Client/Server

Application?
In principle, a client/server application consists of a client program that
consumes services provided by a server program. The client requests
services from the server by calling functions in the server application. In
a distributed computing environment, where the client program and
the server program execute on different machines and possibly even on
different platforms, the client and server communicate through a
communications layer that is often called middleware.
Solutions Guide
10 Chapter 2 Developing Client/Server Applications
Figure 2-1. Basic client/server architecture
Although applications that are running on different machines obviously

require those machines to be physically connected in some way - usually
by a network (LAN, WAN or Internet) - it is important to distinguish
between the network architecture and the client/server application
architecture. The client application might run on a network client or a
network server. The client and server applications might run on the
same machine, which could be a network client or a network server, or
neither! A client/server application is described as such solely because of
its own architecture, without reference to how it is deployed on a
network. For example, the X system used for graphical front-ends on
many UNIX systems is a client/server application. However, the server
part of the application often runs on the network client machine, with
the client part of the application running on the network server! The
easiest way to remember which is the client part of an application is to
remember that the client is always the requestor of services.
The following are typical features of a client/server application:
• A client program can request services from multiple server programs
• A client program does not need to be aware of the actual

subprograms that provide a service
• Multiple subprograms can work together to provide the service
• Multiple client programs can request services from a single server

program
• A server program can provide multiple services
• Typically, the server program runs on a machine that is remote from

the machine running the client program
COBOL applications request services by using the CALL statement. The

request for a service is actually a call to a function implemented in a
procedure. Although CALL statements are usually associated with local
functions - that is, procedures that execute on the same machine as the
Solutions Guide
2.1 Client/Server Architecture 11
calling program - they can equally be associated with remote functions

that execute on a different machine. When a CALL is used in this way, it
is often referred to as a remote procedure call, or RPC. A key
requirement for the rapid development of client/server applications is
that remote procedure calls should be handled independently of the
network protocol in use; this enables you to concentrate on coding
your application rather than handling the underlying network. Net
Express is supplied with a simple RPC mechanism called client/server
binding, which provides a straightforward network-independent
communications layer between client and server programs.
2.1.2 Client/Server Benefits

Most of the benefits of using client/server architecture for enterprise
applications relate to flexibility of deployment and relative ease of
maintenance. For example, using client/server architecture you can
typically:
• Re-use existing legacy code for the business logic
• Run each functional layer of the application on the platform most

suited to the task
• Distribute the processing and network loads
• Quickly and easily change business logic procedures without

changing the client program or user interface
• Provide simple and convenient delivery of the application and any

updates to end-users
• Provide alternative client user interfaces to the same server-side

program
• Use development tools that are designed to work together
To maximize the potential value of using a client/server architecture,

you should adhere to some basic design guidelines. These are outlined
below.
Solutions Guide
2.2 Suggested Approach
2.2.1 Separating Program Logic

To gain the most benefit from using a client/server architecture for new
applications or as a conversion exercise when updating existing
applications, it is essential to logically (and often, physically) separate
the different layers of functionality in the application so that they are
not indiscriminately mixed together. A typical approach is to split the
logical functions of the application into three:
• User interface logic (screen handling)
• Business logic (data processing)
• Data access logic (file or database handling)
Conceptually, each of these three areas of functionality - or layers - are

handled by separate programs. The user interface logic is always
handled by the client application. If the client application handles only
the user interface logic, it is called a thin client. Sometimes some, or
even all, of the business logic is also handled by the client application;
this is called a thick client.
When you create a client/server application, it makes a lot of sense to

apply this conceptual division of functionality to the actual program
code, so that you create physically separate programs for handling each
of the three layers. In a distributed computing environment, each of
these programs might run on different machines - but they would work
equally well if they were all running on the same machine.
A Web application is the ultimate thin client. The user interface is

handled entirely by the user’s Web browser. Although the definition of
the interface is provided as an HTML form which resides on the Web
server, it is downloaded temporarily under the control of the Web
browser.
Solutions Guide
2.2 Suggested Approach 13
2.2.2 Supported Platforms

Net Express is designed to enable you to create 32-bit Web-based and
network-based client/server applications that can be deployed on the
following platforms:
• Operating systems supported directly:
• Windows NT V4.0 with Service Pack 3, 4 or 5
• Windows 2000
• Windows 98
• Windows 95
• Operating systems supported in conjunction with Object COBOL for

UNIX V4.1 and/or Server Express:
• Most SVR4-based UNIX systems, including:
• SCO
• AIX
• HP/UX
• Sun Solaris
(Applications created with Internet Application Wizard are not
suitable for deploying on UNIX)
• Network protocols supported:
• TCP/IP
• Microsoft Network
• IPX (Novell NetWare)
• NetBEUI
Solutions Guide
We have tested the following platforms and believe them to be

generally compatible with Net Express Web applications:
• Web servers:
• Microsoft Information Server V4.0
• Microsoft Personal Web Server (as supplied with Windows NT

V4.0 Option Pack)
• Netscape FastTrack Server V2.01
• Netscape Enterprise Server
• Apache web server (on UNIX)
• Web browsers:
• Microsoft Internet Explorer V5
• Netscape Communicator V4.7
• HTML Painters:
• Microsoft FrontPage 97
• NetObjects Fusion
• Sausage Software HotDog
• Softquad HotMetal Pro
• Middleware:
• IONA Technologies Orbix V2.3c
• Microsoft Transaction Server
• Oracle Pro*Cobol V1.8 and V8.0.4 database precompiler
• Sybase Open Client Embedded SQL/COBOL precompiler V11.5
• XDB ExpressLane V2.0
• Databases:
• Oracle V7 and V8
• Sybase V11.0.1
• Informix V9.x
Solutions Guide
2.2 Suggested Approach 15
• Microsoft SQL Server V7.0
• Microsoft Access 2000
• IBM DB2 V6.1 for Windows NT
• Source code control systems:
• MERANT PVCS Version Manager V5.3 and V6.0
• Microsoft Visual SourceSafe V6.0
• VisualAge TeamConnection
As Web applications created by Net Express conform to the relevant

international, platform-independent standards, it is highly likely that
they will work correctly when deployed on other TCP/IP-capable client
platforms with appropriate Web browsers. However, as each
application has individual requirements, we advise you to test your
application thoroughly on all target systems before deployment.
Solutions Guide
Solutions Guide
17
3 Client/Server on the Web
This chapter introduces the basic concepts of a Web application,

explaining the roles of forms and server-side programs. It explains how
the availability of various Web browsers influences the way you create
your forms, and explains in which circumstances you might need event
handlers for your form. It also introduces the different types of server-
side program, and explains the differences between them.
3.1 Introduction to the World Wide Web

The World Wide Web ("the Web" for short) is a popular mechanism for
communicating across the global Internet or across an organization’s
internal intranet. The Web is made up of many interlinked documents
that can be accessed and displayed using a Web browser, such as
Microsoft Internet Explorer or Netscape Navigator. Most of these
documents are made up of pages of information consisting of text and
graphics with hotspots - just like the Net Express help system. Clicking
on a hotspot takes you to another page, where you can click on further
hotspots, following the subjects that interest you at the time. The Web
browser knows where each hotspot should link to because each is
associated with a uniform resource locator, or URL. A URL is simply a
way of specifying a delivery mechanism (called a scheme) and an
address for the document in a standard format - for example:
http://www.merant.com/training/index.asp
In this example, the scheme is http: and the address is
//www.merant.com/training/index.asp
Solutions Guide
18 Chapter 3 Client/Server on the Web
Technical: Internet and intranet

The Internet is a worldwide network of computer networks. There are
estimated to be over four million computers connected to it, running
just about every conceivable operating system. The Internet is not
owned by any one organization or country, but works because each
individual computer connected to it uses the same communications
protocol, TCP/IP, to communicate with all the other computers. TCP/IP
support is provided with both Windows 95 and Windows NT.
Information is passed over the Internet in small, self-contained chunks
or packets, each of which contain their destination address. The
packets travel by ’hopping’ from one computer to another, with each
computer forwarding the packet on according to its destination
address. The initial ’hop’ from your computer or network onto the
Internet must be made via an Internet service provider, who provides
the service by means of a leased line or a dial-up telephone
connection.
To connect to the Internet, your network must be capable of
communicating using the TCP/IP protocol. This means that your
internal network can work just like the Internet, passing packets of
information around the computers that are attached to it. When a
network is set up like this, enabling standard Internet applications
(such as a Web browser) to be used over an internal network, it is
called an intranet.
If your network is set up to access the global Internet, it is
automatically capable of working as an intranet - you get the intranet
capability ’for free’. This is one reason why intranets have become so
important for corporate communications.
A Web document does not have to consist of text and graphics,

however. It could be a directory of files available for download, an
animation, a movie, or a piece of audio. As you click on each link, the
appropriate file for the document you selected is downloaded to your
computer’s Web browser, which then either displays it or calls a helper
application to run or play the file.
The Web browser knows what to do with all the many types of
document because the documents are all coded using a standard
language, Hypertext Markup Language, or HTML. HTML is a simple text
markup language, consisting of plain text surrounded by tags that mark
the beginning and end of meaningful constructions in the file. A sample
Solutions Guide
3.1 Introduction to the World Wide Web 19
HTML file and the result as it would appear if opened in a Web browser
are shown below.
<html>
<head>
<title>A Sample Web Page</title>
</head>
<body>
<h1>HTML Sample</h1>
<img src="nxbkcovr.gif">
<p>
This is an example of a simple Web page containing a graphic
and a paragraph of text.
</p>
</body>
</html>
Figure 3-1. How the sample HTML page looks in a Web browser
Solutions Guide
3.2 What Does a Web Application Look Like?

One type of Web document is called a form. This is a standard HTML
page that can be displayed in a Web browser. It differs from a page of
text and graphics, however, because it can contain the types of control
used in graphical user interfaces: for example, entry fields, radio
buttons, and check boxes. This means that it provides a means for user
interaction, enabling the user to enter data and make selections that
can be passed back to an application that runs on the Web server. An
example of an HTML form is shown below.
The user of a Web application - an application that runs across the

Internet or your own intranet - sees it as a set of HTML pages and forms
displayed on a Web browser. Clicking on a link on one page starts a
program running on the Web server. The program downloads an HTML
form, with which the user interacts.
Figure 3-2. How a Web application appears in a Web browser
A Web application therefore has the following components:
• An HTML page with a link to a URL that starts the server-side

program
• A form for the end-user to enter queries and updates, and for
display of data
• A server-side program.
Solutions Guide
3.3 Challenge: Creating a User Interface 21
More complex applications consist of a number of smaller applications,

linked together by URLs on HTML forms.
3.2.1 Execution Flow

A typical Web application works like this:
1 A user requests the application from a Web server, usually by

accessing a Web page using their Web browser, then clicking on a
hotspot.
2 The application starts running on the server, and sends back an

HTML form for the application.
3 The user fills out the form and clicks the ’Submit’ button.
4 The server-side program performs the data processing - perhaps

fetching data from files or a database - and returns the results to
the user’s browser. The results can be displayed on the same form
that provided the input, or output as a new form or HTML page.
One of the great advantages of Web applications to the programmer is

that there is no middleware or communications protocols to worry
about. It’s already built into your existing internet infrastructure! This
ensures that Web applications are relatively quick and easy to develop
and deploy.
3.3 Challenge: Creating a User Interface

As explained above, the user interface for a Web application consists of
an HTML form, which contains controls similar to those used in
Windows applications.
The Web browser takes care of how the controls on the form actually
work. For example, it ensures that only one radio button in each set
can be selected at a time; it automatically populates a listbox with the
data that you supply, and so on. When the user has entered all the
required data on the form, they click a ’Submit’ button, and the
information they entered is sent back to the Web server.
Solutions Guide
Once the server-side program has processed the data sent in a form, it
can return any type of document supported by a Web browser. For
example, it could return an ordinary Web page containing the results,
or another HTML form requesting further information. If you have used
systems like CICS and IMS, you will immediately see the similarity
between them and a Web application. They all use a batch, or
transaction, processing system, where data is sent to and received from
the user interface in discrete chunks, and there is no communication
between the client and server except when a chunk of data is being
passed between them.
Creating the user interface for a Web application is very easy - you can
just paint the forms you require in Form Designer. Form Designer
creates the HTML files containing the markup for your forms, and also
the copyfiles that contain the data definitions you need in your
program to access the data from your forms. If you have an existing
application, use the Internet Application Wizard to create a simple
HTML form from it, then change the form to make it look how you
want using Form Designer. If you are creating a Web application from
scratch, use Form Designer directly to create your new form.
As well as HTML form controls, you can add ActiveX controls and Java
applets to your HTML forms. These are both different ways of adding
more interactivity to a form. For more information see the chapter
Forms and HTML in the Internet Applications online book.
You can use Form Designer to create two different types of output for
forms:
• Cross-platform HTML
• Dynamic HTML
Cross-platform HTML forms work with a wider variety of Web browsers.

Although cross-platform HTML enables you to specify the order and
approximate positioning of the controls and their labels, you cannot
specify the exact appearance of the form, which is controlled by the
Web browser. Dynamic HTML offers more exact positioning, but is only
supported by Internet Explorer 4.0 or later.
Solutions Guide
3.3.1 Solution: HTML Form Using Cross-

platform Output or Dynamic HTML
Use Form Designer to paint a graphical user interface for your Web
application and automatically generate corresponding skeleton code
for the server-side program. Once you’ve painted your interface, you
can add event handlers to perform any client-end processing that you
may need. (See the section Adding an Event Handler below for more
information.)
If you specify Cross-platform HTML, Form Designer creates an HTML

form that can be displayed by any modern Web browser. If you specify
Dynamic HTML, Form Designer creates an HTML form that can only be
displayed by Internet Explorer 4.0 or later.
Overview of steps:
• Create a Form-based project
• Complete the HTML Page Wizard
• Design form: add controls, labels, change properties
• Save form
• Set up event handler for any control that needs it
• Save form
• Close Form Designer
• Generate a skeleton server-side program using Internet Application

Wizard
• Change project settings as appropriate
• Add your business logic to the server-side program
• Debug
Solutions Guide
3.3.1.1 Example
Phase 1 of the Gas Services scenario (see the section Example Scenarios
in the chapter Introduction for more details) provides an example of a
Web application that uses a server-side CGI program. This application
consists of a form that the user can access using the World Wide Web.
The form has fields that enable the user to enter their account number
and a new meter reading. When the user clicks the ’Submit’ button, the
meter reading is updated in the Gas Services database, and a
confirmation page is sent back to the user. A prototype of the input
form for this application is shown below.
Figure 3-3. A prototype input form for the Gas Services Web
application
This is how we used Form Designer to create the form shown:
1 We created a new project. In the New Project dialog box, we chose

an Empty Project.
Solutions Guide
2 We created a new HTML Form. We chose Cross-platform (table

output) rather than Dynamic HTML positioned form because this
application is intended to be used by Gas Services’ customers, and
we cannot be sure that they will all have Internet Explorer 4.0 or
later.
3 In Form Designer, we designed the input form. To add each control,

we clicked on the appropriate icon on the bar at the top, then
clicked on the form at the position where we wanted the control.
Then we filled in the properties of the control in the pane at
bottom-right. This is how it looked in Form Designer:
Figure 3-4. Designing the Gas Services input form in Form Designer
4 We saved the form. When we clicked Save, Form Designer updated

the form in our project.
Solutions Guide
3.3.2 2 Adding an Event Handler

An event handler is a piece of program code that runs on the client and
processes an event (such as a mouse click) on the form. It performs a
similar task to the message loop in a Win32 API application, or to the
event manager in an Object COBOL or Panels V2 application. In Net
Express applications, event handlers for a form are written in JavaScript.
You don’t necessarily need to learn any JavaScript because Form
Designer comes with a Script Assistant that can generate the code for
many simple requirements, but you will need to learn some JavaScript
for more advanced client-side processing.
Question: Do I need any event handlers?

In a Web application, there is no communication between client and
server apart from when chunks of data (consisting of entire forms or
HTML documents) are passed between them. You do not need any
event handlers if you are writing a standard forms-based application
where the complete form is handled as one unit. This applies to
applications created with the Internet Application Wizard - which uses
Embedded HTML - and to manually-coded Web applications, which
can use either Embedded HTML or the enhanced ACCEPT and DISPLAY
syntax.
You do need event handlers if you want to process any part of an
HTML form on its own. Such processing must be done locally, at the
client end. For example, if you want to validate data as it is entered
on the form (for example, to check that a number in an edit field is
within a certain range), you need to do this in an event handler.
Similarly, if you want to gray part of the form when the user selects a
particular check box, you need to set up an event handler. The
interactivity required for this type of processing is made possible by
the event handler.
To add an event handler to a control, use the Script Assistant in Form

Designer. The Script Assistant enables you to specify what action to take
when a certain event (such as a pushbutton being clicked) occurs on
your form. For more information on using the Script Assistant, see the
chapter Client-side Programming in the Internet Applications online
book.
Solutions Guide
3.4 Challenge: Migrating or Updating an Existing User Interface 27
3.4 Challenge: Migrating or Updating an

Existing User Interface
3.4.1 Solution: Internet Application

Wizard
Use Internet Application Wizard to create Web applications from your
existing legacy applications, without changing or recompiling the
original applications. The Internet Application Wizard generates the
forms that you need. You can create forms for any application that
contains an appropriate data definition in the linkage section. In
practice this includes most existing client/server applications that
separate the user interface from the business logic - for example, CICS
and IMS programs, most programs that use the Screen Section, and
even applications that have a Visual Basic user interface.
Because the original application is unchanged, you can roll out the new
interface gradually, allowing users to choose either interface during
the transition period. Or, you can try out the new interface with a small
group of users on a live production application - it won’t affect other
users, who can still use the original interface.
Overview of steps:
• Create a project
• Build the project for the legacy application
• Open the Internet Application Wizard
• Select the .cbl file you want to generate the form from
• Set control properties: label, type of control, direction of dataflow
• Generate the form
Once you have created a form using the Internet Application Wizard,
you can import it into Form Designer to make final adjustments to its
appearence.
Solutions Guide
For detailed information on using the Internet Application Wizard in

this way, see the chapter Reusing Legacy Code in the Internet
Applications online book.
3.5 Challenge: Web Server-side Program

The server-side program in a Web application is where most of the
processing is carried out. Typically, the server application handles all of
the data processing from the client, and might interface with a
datastore such as COBOL files or a relational database, as well as
communicating with the Web server. As a COBOL programmer, you are
probably already familiar with handling business logic and interfacing
to data. The part that might be new to you is interfacing to the Web
server. This is easily achieved in practice, using one of the three main
interface definitions:
• CGI (Common Gateway Interface)
• ISAPI (Internet Server Application Programming Interface)
• NSAPI (Netscape Server Application Programming Interface)
These three interface standards are explained in more detail later in this
chapter, and in the chapter CGI, ISAPI and NSAPI Programs in the
Internet Applications online book. All three standards achieve a similar
end result, but the method of achieving it is different in each case. Net
Express enables you to easily create a server-side program that conforms
to any of these interface types just by changing a few build options.
A simple COBOL Web application has three components:
• An HTML input form
Entry fields and controls for entering data. Clicking the submit
button posts the data to the Web server and starts the server-side
program.
• The COBOL server-side program
Uses an ACCEPT statement to receive the data from the form, and a
DISPLAY statement to send back the output page. Two new clauses
enable you to tie group data items to HTML forms and pages, and
Solutions Guide
3.5 Challenge: Web Server-side Program 29
elementary data items to named parameters on HTML forms and

pages.
• An output page
An HTML page with replaceable parameters as placeholders for

data from the server-side program.
Most Web applications begin by an end-user clicking a control on an

HTML form. The control might be a pushbutton labeled OK, or it might
look like an HTML hyperlink. If you don’t know what a Web application
looks like, run the sample session in your Getting Started.
When the end-user submits the form, all the information entered onto
it is packaged into a single stream, and sent back to the Web server
with an instruction to run the server-side program. The server-side
program unpacks the stream and processes the user input, before
returning a result. The diagram below shows the way a Web
application is executed.
Figure 3-5. The role of the server-side program in a Web application
Solutions Guide
1 The end-user fills in an HTML form and clicks a Submit Form button.
The information in the fields on the form is bundled into a single
stream of data, and sent to the Web server, which interprets it as a
request to run the server-side program.
2 The Web server starts the requested server-side program, and sends
it the data stream.
3 The server-side program runs, returns an HTML page to the Web

browser and exits.
With most languages you need to write (or find) code to parse the data
stream into the server-side program. Net Express has server-side support
built in, using the familiar ACCEPT and DISPLAY verbs. A Net Express
COBOL server-side program can ACCEPT an input form, and DISPLAY an
output form.
3.5.1 Solution 1: CGI Program

The Common Gateway Interface (CGI) is a standardized interface
between a server-side program and a Web server initiated by the
National Center for Supercomputing Applications (NCSA). It enables you
to build a server-side program that, by means of a Web server, can
receive data from, and send data to, Web pages on the client Web
browser. It can also communicate with external datastores such as
COBOL data files or relational databases. The CGI interface is the most
commonly used interface for server-side programs on the Web today.
Solutions Guide
Technical: CGI implementation

When the user clicks on a hotspot in a Web page, an associated URL
request is sent to the Web server. If the requested URL is for a file in a
special, preconfigured, directory (usually called cgi-bin), the Web
server interprets it as a command to run the file as a server-side
program - in this case, a CGI program. The CGI program is executed
as if from the command-line, in its own process. The Web server
passes data to the CGI program using environment variables which it
sets up in the environment of the CGI program’s process. The output
of the CGI program is sent back to the Web server using the standard
output stream, stdout, in the form of an HTTP data stream (HTTP is
simply the standard encoding scheme understood by Web browsers).
The Web server then returns this data stream to the user’s browser,
where it is displayed as an HTML document.
For more information, see:
http://www.merant.com/ads/docs/nx/links.htm#cgi1
3.5.1.1 Pros and Cons

Pros Cons
Supported by all Web servers Inefficient use of server resources
Protection faults do not affect Limited communication with
Web server Web server
Portable Each instance can handle only one
client request
3.5.1.2 Practical Considerations

For more details on writing CGI server-side programs, see the chapter
Server-side Programming in the Internet Applications online book
Solutions Guide
3.5.1.3 Example
Phase 1 of the Gas Services scenario (see the section Example Scenarios
for more details) provides an example of a Web application that uses a
server-side CGI program. See the example in the section HTML Form for
details of how we used Form Designer to create the input form.
When the user has submitted the form, and the database has been
updated, a confirmation page is returned to the user. It looks like this:
Figure 3-6. A prototype HTML output page for the Gas Services Web
application
This application is an asymmetric application, because the form that is

returned by the application is not the same as the form used for input -
in fact, it isn’t even a form, but an ordinary HTML page. (For an
explanation of the difference between a symmetric and an asymmetric
application, see the section More Complex Applications in the Internet
Applications online book). It is very important to decide whether you
are creating a symmetric or an asymmetric application before you start
coding, as you need to make different choices in the Internet
Application Wizard for each type of application. The code that you add
Solutions Guide
to the skeleton that the Internet Application Wizard produces is also

different in each case.
We created a prototype of this application as follows:
1 With our project open, we created a new HTML page called gas1,
choosing Blank form and Cross-platform (table output).
2 In Form Designer we designed the output page. We entered the

text, and where we wanted to display data output from the CGI
program, we created text input controls (these are set by the CGI
program, rather than input by the end-user). We used the
following Name and COBOLPicture properties:
Name COBOLPicture
ACNumber X(4)
Outputdate X(10)
MeterReading X(5)
An alternative method is to design the page using any HTML

editor, then just use Form Designer to add the text controls.
3 We clicked New on the File menu and clicked Internet Application.
4 We clicked Server Program to create a new CGI program from the

HTML pages we have already created.
5 We entered a name (mycgi.cbl) for the server-side program and

specified the form we designed earlier as the input form and the
page we have just designed as the output form.
When we clicked Finish on the wizard, the CGI program was

generated and added to our project.
6 We opened the skeleton server-side program, mycgi.cbl, that the

Internet Application Wizard had generated for us.
Solutions Guide
7 We removed the comment characters from the code that checks

whether the Submit button on the form has been pressed:
*>---------------------------------------------------------
*> If the CGI uses the same form for both input and output
*> it is necessary to handle the ’initial load’ case. The
*> simplest way of doing this is shown below.
*> A more sophisticated approach would be to use a hidden
*> field
*>
*> You can determine if the CGI is running for the first
*> time by testing the submit button (default name is
*> ssubmit) for spaces. If the form has been returned by
the
*> Browser, then the submit button will return its caption.
*> Remove comments as necessary.
*>
perform process-form-input-data
perform convert-input
if ssubmit = spaces
*> Add code to initialize an ’empty’ form
perform HTMLForm-cvt
perform HTMLForm-out
else
perform process-business-logic
perform HTMLForm-out
end-if
exit program
stop run.
To understand why this is necessary, remember that this CGI

program is executed twice each time a Gas Services’ customer uses
it. It is run the first time when a user clicks on a link that points to
the /cgi-bin/ directory on the Web server. At this stage, all it needs
to do is initialize the input form and send it to the browser. Then
the user fills out the form, and clicks the Submit button. The CGI
program is then run again, but this time it must do its data
processing before returning the output page to the browser.
When the user clicks on the Submit button, the browser returns a
data item called ssubmit that contains the text of the caption that
appears on the Submit button. If, when we test this data item, it
consists entirely of spaces, we know that the user has not clicked the
Submit button. So the program must have been started by the Web
server, and we need to display the input form. If ssubmit contains
the text of the button caption (that is, it does not consist entirely of
Solutions Guide
spaces), we know that the user has clicked the Submit button, so
we must query the database and send back the output form.
8 We edited the section of the program where the output form is

displayed so that it would display our output page instead:
perform process-business-logic
exec HTML
copy "gas1.htm".
end-exec
end-if
exit program
stop run.
9 We added a call to the module containing our business logic.
In this case, it consists of an SQL statement that updates a table

with the information the user enters, followed by a query that
returns this information to the program in data items called f-
ACNumber, Outputdate and f-MeterReading. Because we used
these names for text input fields in our output HTML page, there is
no need to move the data into them. (For more details of the
business logic used here, see the chapter Data Access).
*>--------------------------------------------------------
process-business-logic Section.
*> Add application business logic here. It is recommended

*> that you place the business logic in a separate module
*> and call it from this CGI, possibly as follows
*> call "metersql" using FormFields
*> using the ’cpy’ copybook for this CGI in the linkage
*> section of your business logic module
*>
*> The benefits are:
*> - business processing and presentation logic are kept
*> separate
*> - they can therefore be worked on independently
*> - the business logic can be Animated if the
*> application is moved to a Unix server
call "metersql" using FormFields
exit.
10 We clicked Rebuild all on the Project menu.
Solutions Guide
3.5.2 Solution 2: ISAPI Program

The Internet Server Application Programming Interface (ISAPI) is a
Microsoft-originated standardized call interface between a server-side
program and Microsoft Internet Server for Windows NT. It enables you
to build a dynamically-loadable program that effectively customizes the
Web server so that it can respond interactively to requests from the
HTML client, as well as being able to communicate with other
applications such as logging or security systems, databases or
transaction processing systems. You can also use it to write filters and
encryption systems for the HTTP data stream used in World Wide Web
applications.
Technical: ISAPI implementation

program - in this case, an ISAPI program. The ISAPI program is built as
a dynamic link library (DLL). When a request to run it is received, the
Web server loads the DLL into memory and calls it at a standard entry
point. The ISAPI program can perform whatever functions are
required, obtaining data from and returning data to the Web server
through a standardized data structure called an extension control
block, or ECB, and a callback function. Because it is a dynamic link
library, it runs in the same process as the Web server, and only a single
copy is required in memory to service any number of concurrent client
requests.
Because ISAPI applications are implemented as dynamic link libraries,
they must be written to be reentrant and thread-safe. This can easily
be achieved in Net Express using simple programming and building
techniques.
http://www.merant.com/ads/docs/nx/links.htm#isapi1
Solutions Guide

Pros Cons
Resource-efficient Only supported by MS Internet
Server on Windows NT
Fast response time Care must be taken to avoid
protection violations
Copes well with heavy loading Less portable than CGI
applications
More flexible than CGI
applications

Because it is more difficult to debug a dynamic link library that is under
the control of another application (in this case, Microsoft Internet
Server), we advise you to create and debug your server-side program as
a CGI program before changing the build settings to create the final
ISAPI dynamic link library. For further information on the build changes
you need to make, see the chapter CGI, ISAPI and NSAPI Programs in
the Internet Applications online book.
You can, however, use the Net Express Internet Application Wizard to
create an ISAPI application, in which case all of the build settings are
automatically created for you.
3.5.3 Solution 3: NSAPI Program

The Netscape Server Application Programming Interface (NSAPI) is a
Netscape-originated standardized call interface between a server-side
program and a Netscape web server. It enables you to create ’plug-ins’
in the form of dynamically-loadable programs that can extensively
customize the behavior of the Web server, as well as responding
interactively to client requests from a browser, and interfacing with
database, logging or security systems. Unlike an ISAPI program, an
NSAPI program can call functions in the Web server, as well as allowing
itself to be called by the Web server. This is an advantage if you would
like to change some aspect of the fundamental behavior of the Web
server.
Solutions Guide
Technical: NSAPI implementation

program - in this case, an NSAPI program. The NSAPI program is built
as a dynamic link library. When a request to run it is received, the Web
server loads the DLL into memory and calls it at a standard entry
point. The NSAPI program can perform whatever functions are
required, obtaining data from and returning data to the Web server
through a standardized call interface (API). Because it is a dynamic
link library, it runs in the same process as the Web server, and only a
single copy is required in memory to service any number of concurrent
client requests.
Because NSAPI applications are implemented as dynamic link libraries,
they must be written to be reentrant and thread-safe. This can easily
be achieved in Net Express using simple programming and building
techniques.
http://www.merant.com/ads/docs/nx/links.htm#nsapi1

Pros Cons
Resource-efficient Only supported by Netscape-
compliant Web servers
Fast response time Care must be taken to avoid
protection violations and memory
leaks
Copes well with heavy loading Less portable than CGI applications
More flexible than CGI and ISAPI
applications
Can be used to change behavior
of Web server
Supported on more platforms
than ISAPI
Solutions Guide

Because it is more difficult to debug a dynamic link library that is under
the control of another application (in this case, a Netscape Web server),
we advise you to create and debug your server-side program as a CGI
program before changing the build settings to create the final NSAPI
dynamic link library. For further information on the build changes you
need to make, see the chapter CGI, ISAPI and NSAPI Programs in the
Internet Applications online book
If you want the server to call functions in your DLL, you need to create
an import library for the Netsite server. If you want to access server
functions, you need to link the server import library to your DLL.
Solutions Guide
Solutions Guide
41
4 Data Access
Applications written in COBOL are traditionally heavily data-driven,

relying on substantial joint file processing or relational database
management system (RDBMS) access. This chapter explains how to use
the enhanced data access features available in Net Express.
4.1 Challenge: Accessing an RDBMS

There can be many areas of difficulty in accessing a relational database
from a COBOL program in a client/server application architecture.
Perhaps the most direct and flexible technique is to use the Open
Database Connectivity (ODBC) drivers provided by the database
vendor. But calling these directly means understanding how to
translate your query into API calls, how to format data and how to
adhere to the calling conventions used. Fortunately, you can avoid all
these issues by using the powerful data access features provided in Net
Express.
The recommended way of accessing relational data from a COBOL

program is to use Open Embedded SQL, which enables you to embed
Structured Query Language (SQL) statements within EXEC and END-
EXEC statements directly in your program. The embedded statements
are preprocessed by an SQL preprocessor, and converted to calls to your
Open Database Connectivity (ODBC) device driver.
4.1.1 Solution: OpenESQL

Open Embedded SQL is a mechanism used in Net Express that enables
you to write standard SQL statements and embed them between EXEC
and END-EXEC statements in your COBOL programs. Communication
between your program and the database is established using ODBC, a
de facto industry-standard call interface that has been embraced and
promoted by Microsoft for databases. Because your program
Solutions Guide
42 Chapter 4 Data Access
communicates only with the ODBC driver, it does not have to be aware
of the nature of the database, and so a database connected through an
ODBC driver is usually referred to as an ODBC data source.
Technical: OpenESQL implementation

The SQL statements embedded in the EXEC SQL / END-EXEC statement
in your program are processed by the OpenESQL preprocessor. The
preprocessor handles the passing of data items (host variables) and
converts the SQL into corresponding calls to the ODBC interface,
implemented by means of an ODBC device driver. The ODBC driver for
a particular database is normally supplied by the RDBMS vendor with
their database, although third-party drivers are also available. The
driver acts as an interpreter, translating standard ODBC calls into the
native API calls required for the database. Because the vendor writes
the driver, it might not implement the full ODBC standard, or it might
use proprietary extensions to ODBC syntax in addition to the standard
syntax. There are three ODBC API compliance levels and three ODBC
SQL grammar compliance levels. Not all drivers, particularly those for
desktop data sources, support advanced SQL features. The range of
data types supported, and their names, also differs from driver to
driver. All ODBC drivers should implement a minimum subset of
functionality, but you should check the documentation for the target
ODBC driver before you code your SQL program.

OpenESQL provides a powerful and extremely simple way of
communicating with an RDBMS. However, there are a number of
practical considerations that you need take into account for an
application to work effectively.
Devising the SQL statements you need

You don’t need to understand SQL to use the OpenESQL capabilities of
Net Express. Net Express can generate the SQL needed for many
applications using either OpenESQL Assistant or the Internet
Application Wizard. Use the Internet Application Wizard to create the
framework of an application for browsing and updating a database
without writing any COBOL yourself. Use OpenESQL Assistant to add
SQL statements to your own COBOL programs. For more information on
OpenESQL Assistant, see the chapter Open ESQL Assistant in your
Database Access online book.
Solutions Guide
4.1 Challenge: Accessing an RDBMS 43
Of course, you can also write your own SQL statements or modify those
produced by OpenESQL Assistant. Most vendors provide SQL Reference
documentation with their ODBC driver software.You can find more
information about the supported statements, including their full
syntax, in this documentation. There are a number of useful sources of
SQL information on the Web. You can find these by entering SQL as the
search string in your favorite Web search engine - for example, Yahoo!
or Alta Vista. To get you started, try
http://www.merant.com/ads/docs/nx/links.htm#sql1
We advise you to use only a single SQL statement in each EXEC SQL /
END-EXEC statement. For example, if you want to define a cursor and
fetch multiple rows from a database, we advise you to use several EXEC
SQL statements, as follows:
EXEC SQL
DECLARE mycursor CURSOR
FOR SELECT mycolumn_NAME FROM mytable
END-EXEC
EXEC SQL
OPEN mycursor
END-EXEC
EXEC SQL
FETCH mycursor INTO :myfirstname
END-EXEC
EXEC SQL
FETCH mycursor INTO :mysecondname
END-EXEC
EXEC SQL
CLOSE mycursor
END-EXEC
Some ODBC drivers enforce this recommendation by not accepting API

calls that result from more than one SQL statement per EXEC SQL /
END-EXEC statement.
Solutions Guide
Connecting to the database

Before your program can access data in an ODBC data source, it must
make a connection to the database. There are two methods you can use
to connect to a database:
• Implicit connection.
Use this in the simple case where your program connects to only one
database, and always uses the same username. You need to know
the name of the ODBC data source, the username and the password
at the time you build your program. You can specify these
parameters using the SQL compiler directive - for example:
SQL(DBMAN=ODBC,INIT,DB=gasops,PASS=public.meters)
Alternatively, you can enter the parameters in a dialog box by

clicking the Advanced pushbutton on the Compile tab of the Build
Settings for your .cbl program file.
• Explicit connection.
If your program needs to connect to more than one database, or

needs to connect using more than one username, you should make
an explicit connection using the CONNECT statement in your ESQL.
For example:
EXEC SQL
CONNECT TO "gasops" USER "public.meters"
END-EXEC
When your program has finished working with a database, it should

disconnect from the database. If you are using implicit connection,
OpenESQL automatically disconnects from the data source when the
program terminates. If you are using explicit connection, you should
disconnect using the DISCONNECT statement in your ESQL:
Host variables
Host variables are data items defined in a COBOL program and used as
variable parameters in the ESQL section of the program. They are used
to pass values to and receive values from an ODBC data source. Host
variables can be defined in the File Section, Working-Storage Section,
Local-Storage Section or Linkage Section of your COBOL program and
have any level number between 1 and 48. Level 49 is reserved for data
items of the SQL data type varchar. When a host variable name is used
within an ESQL statement, the data item name must begin with a colon
Solutions Guide
(:) to enable the Compiler to distinguish between host variables and

tables or columns with the same name. Host variables can be used in
ESQL statements wherever ODBC allows a parameter marker (indicated
in your ODBC driver documentation by a question mark, ?). To avoid
potential problems with some ODBC drivers, we recommend that you
restrict the length of data-names of host variables to 26 characters or
less.
Note: If you design your input form in Form Designer and generate a
skeleton CGI program using the Internet Application Wizard, host
variables are automatically created to contain the data from any entry
fields on the form. The host variable name is the same as the name that
appears in the tree view of controls in Form Designer. You can control
the data type of the host variable by setting the COBOLPicture
property of the appropriate control.
Date and time formats

COBOL has no predefined date or time data types that correspond to
types such as datetime or timestamp that are typically found in SQL
databases. For this reason, OpenESQL converts these formats to their
character representations using a pic x(n) data item. The ODBC
standard defines the character format of dates and times as yyyy-mm-
dd for a date, and hh:mm:ss for a time. Note that these might not
correspond to the native date/time formats for the data source in use.
COBOL does not allow the use of the characters "-" and ":" in an
edited field, so they must be defined using a group data item.
However, the ODBC standard requires that group data items are
expanded into their constituent parts when passed to the database. It
is therefore necessary to redefine the group item to create a single
data item. For example:
01 mydate.
03 myyear pic x(4).
03 filler pic x value "-".
03 mymonth pic x(2).
03 myday pic x(2).
01 SQLmydate redefines mydate pic x(10).
The Gas Services example later in this chapter shows how you can
ACCEPT a date and pass it to the database in the correct form.
Solutions Guide
Varchar data type

The SQL varchar data type consists of a character string of variable
length. There are two ways of defining a COBOL equivalent:
• Define a fixed-length character data item pic x(n). where n is the

maximum length of the string.
• Define a group item with usage comp or comp-5, where the first
item contains the length of the string and the second item contains
the string itself. Both items must have a level number of 49. For
example:
01 varchar1.
49 varchar1-len pic 9(4) comp-5.
49 varchar1-data pic x(200).
01 Longvarchar1.
49 Longvarchar1-len pic 9(4) comp.
49 Longvarchar1-data pic x(30000).
If the data being copied to an SQL char, varchar or long varchar data
type is longer than the defined length, the data is truncated and the
sqlwarn1 flag in the sqlca data structure is set. If the data is smaller than
the defined length, a receiving char data type might be padded with
blanks.
Error handling
If an SQL statement fails to complete, an error code is returned to your
program. You should check for an SQL error after each SQL statement.
The ODBC driver returns the error information in a data block called the
SQL communications area, or sqlca. The sqlca contains two variables
(sqlcode and sqlstate) plus a number of warning flags that indicate
whether an error has occurred in the most recently executed SQL
statement. For more detailed information on the SQL communications
area (sqlca) and the sqlstate variable, look up sqlcode and sqlstate in the
help index.
Solutions Guide
Testing the value of sqlcode is the most common way of determining

the success or failure of an embedded SQL statement. The possible
values for sqlcode are:
Value Meaning
0 The statement ran without error.
1 The statement ran, but a warning was generated.
The values of the sqlwarn flags should be checked to
determine the type of error.
100 Data matching the query was not found or the end
of the results set was reached. No rows were
processed.
< 0 (negative) The statement did not run due to an application,
database, system, or network error.
To include the sqlca data block in your program, use the EXEC SQL
INCLUDE SQLCA END-EXEC statement in the data division, as in the
following example:
working-storage section.
...
EXEC SQL INCLUDE SQLCA END-EXEC
procedure division.
EXEC SQL
SELECT company, city INTO :pcompany, :pcity
FROM customer
WHERE custid = :pcustid
END-EXEC
if sqlcode not = 0
if sqlcode = 100
display "No customer found"
else
display sqlcode
display sqlerrmc
end-if
else
display "Company for " pcustid " is " pcompany
display "City for " pcustid " is " pcity
end-if
Explicitly checking the value of sqlcode or sqlstate after each

embedded SQL statement can involve writing a lot of code. An
alternative is to check the status of the SQL statement by using a
Solutions Guide
WHENEVER statement in your program. The WHENEVER statement is

not an executable statement; it is simply a way of saving you typing by
directing the Compiler to automatically generate code to handle errors
after each executable embedded SQL statement.
A further refinement is to declare a data item called

MFSQLMESSAGETEXT. If this data item exists, it is updated with a
description of the exception condition whenever sqlcode is non-zero.
MFSQLMESSAGETEXT must be declared as a character data item, pic
x(n), where n can be any legal value. This is particularly useful as ODBC
error messages often exceed the 70-byte sqlca message field. Note that
you do not need to declare sqlca, sqlcode, sqlstate or
MFSQLMESSAGETEXT as host variables:
01 MFSQLMESSAGETEXT pic x(512).
EXEC SQL INCLUDE SQLCA END-EXEC
procedure division.
EXEC SQL WHENEVER SQLERROR PERFORM ERROR-PROC END-EXEC
EXEC SQL
...
END-EXEC
stop run.
error-proc.
display "SQL Error"
display "SQLCODE = " sqlcode
display "SQLERRMC = " sqlerrmc
display "MFSQLMESSAGETEXT = "
display mfsqlmessagetext.
Porting to UNIX
If you are developing a program that will be ported to a UNIX server, we
recommend that you code and debug using Net Express on Windows,
and recompile the finished program on UNIX using the RDBMS vendor’s
COBOL ESQL precompiler for the target database. You need to ensure
that you use only SQL statements and data types that are supported by
the target database. In practise, most precompilers support ANSI SQL92
syntax, but you should be particularly careful in the following areas:
• CONNECT and DISCONNECT statements
• COMMIT and ROLLBACK statements
Solutions Guide
• Functions such as MAX or AVERAGE.
You must also take care to use COBOL data types that are portable to
UNIX. In particular, be careful when using COBOL data items with
usage comp-5. These data items might not port as you expect, because
of the different default byte-ordering between the two platforms. Use
comp-x (or display) instead.
4.1.1.2 Example
The Web application for Phase 1 of the Gas Services scenario (see the
section Example Scenarios for more details) provides a simple example
of an OpenESQL query embedded in a COBOL server-side program. In
this case, the application updates an SQL database with data entered
by the user on an HTML form; then it queries the database to return
the updated information back to the user. The query is not necessary to
obtain the information, but is used to provide reliable confirmation
that the database was updated correctly.
The database, which has the ODBC data source name gasops, is
updated by adding a row to a table called transact. This table has one
row for each gas transaction, and consists of the following columns:
Column name Data type Purpose

ACC_TRANS_NO integer A unique number that
identifies each transaction
ACCOUNT_NO integer The customer account
number involved in the
transaction
TRANS_TYPE integer A code for the type of
transaction
TRANS_TEXT char(80) A text description of the
transaction
TRANS_UNITS decimal(11,2) The number of items
involved in the transaction
TRANS_RATE decimal(8,2) The value per unit - if any -
of the transaction
TRANS_VALUE decimal(8,2) The total value of the
transaction
Solutions Guide
Column name Data type Purpose

TRANS_TAX_RATE char(1) A code for the rate of tax to
be applied
TRANS_POST_DATE datetime The date and time the
transaction was entered
TRANS_EFFECT_DATE datetime The date and time the
transaction takes effect
For the purposes of this example, we have made the following

assumptions about the database:
• The unique transaction number for each row of the table must be
calculated by the COBOL program (that is, the database does not
create this number automatically)
• Date columns do not default to the current date
The entry is confirmed to the user by querying the table for the latest
meter reading on the specified account number.
4.1.1.2.1 Program structure

In order to keep the user interface logic (contained in the CGI program)
and the business logic separate, we created a separate module to
handle the interaction with the database. The tasks performed by this
module are as follows:
1 Connect to the database.
2 Get a new transaction number.
3 Update the database with the customer’s new meter reading.
4 Read the database to check that the update has been correctly
made.
5 Disconnect from the database.
Solutions Guide
With this in mind, we wrote the skeleton of a new program,

metersql.cbl, as follows:
data division.
linkage section.
copy "mycgi.cpy".
01 Outputdate pic x(10).
procedure division using FormFields,

Outputdate.
perform dbconnect
perform dbgettrans
perform dbupdate
perform dbread
perform dbdisconnect
exit program.
stop run.
dbconnect section.
dbgettrans section.
dbupdate section.
dbread section.
dbdisconnect section.
This program will be called from the CGI program and will return its
results to the CGI program. The only data items in which the CGI
program knows about when it is first generated are those that are
represented on the input form. These are defined in the copyfile
mycgi.cpy that was automatically generated when the form was
created. We can obtain access to these data items simply by including
the copyfile in the linkage section of our new program. However, there
is a further data item that we want to return to our HTML output page
that is not represented on the form: the current date. We can arrange
to pass this back to our CGI program by defining it in the working-
storage section of the CGI program, and using it as one of the calling
parameters of metersql.cbl. This means that it must be declared in the
linkage section of metersql.cbl.
Solutions Guide
Adding the SQL statements

We used OpenESQL Assistant to add the necessary SQL statements to
our skeleton program.
We decided to add the ESQL statements first. The procedure was

basically the same for all of them. For example, we added the INSERT
statement as follows:
1 We clicked under the line in our program that says dbupdate

section.
2 We clicked OpenESQL Assistant on the View menu of Net Express.
3 We double-clicked on our ODBC data source in the left-hand pane.
4 We selected the correct data source name when the ODBC Select
Data Source dialog box appeared.
5 We entered our userid and password on the SQL Server Login dialog
box to gain access to the data source.
6 We double-clicked on the table called transact.
7 We chose INSERT on the Select Type of Query dialog box because we

wanted to add a new row to the database. (The Select Type of
Query dialog box tells you what each type of statement does when
you click on it).
8 We right-clicked on the table transact in the left-hand pane, then

clicked Select All Columns on the popup menu.
9 We clicked the icon to add the SQL statement to our program.
Solutions Guide
Figure 4-1. Adding the INSERT statement using OpenESQL Assistant
There were also two SELECT statements to add to our program: one to
get the last transaction number and one to read back the data added
to the database by our program.
The first of these was added to the dbgettrans section:
1 We chose a SELECT (Singleton) query type, because we wanted to

retrieve a single row of data.
2 We double-clicked the column A.ACC_TRANS_NO in the left-hand

pane.
However, the SELECT statement as generated retrieves all transaction

numbers from the database table, and we only want the most recent.
The most recent number will also be the highest number, so we
modified the SQL statement to read:
EXEC SQL
SELECT
MAX(A.ACC_TRANS_NO)
INTO
:transact-ACC-TRANS-NO
FROM transact A
END-EXEC
Solutions Guide
Although most data sources support a MAX function, the syntax used
depends on the RDBMS. The syntax shown above is correct for our
target system, Microsoft SQLServer.
The second SELECT statement we needed belongs in the dbread section

of our program:
1 We chose a SELECT (Singleton) query type, because we wanted to

retrieve a single row of data.
2 We double-clicked A.TRANS_UNITS in the left-hand pane.
3 We needed to narrow down the number of rows returned, so we

clicked the Search Criteria tab.
4 In the Column list, we chose A.ACCOUNT_NO.
5 In the Target Value entry field, we typed :Input1
6 We clicked the > button to add this expression to the search criteria
listbox.
7 In the Column list, we chose A.TRANS_TYPE.
8 We changed the Target Type to Literal.
9 In Target Value, we typed the number 9 (because 9 is the transaction

type code for a customer meter reading in the Gas Services system).
10 We clicked the > button to add this criterion to the listbox.
11 We clicked the Query tab, then we clicked the icon to add the
SQL statement to our program.
The SQL statement that was added looked like this:

EXEC SQL
SELECT
A.TRANS_UNITS
INTO
:transact-TRANS-UNITS
FROM transact A
WHERE ( A.ACCOUNT_NO = :Input1 )
AND ( A.TRANS_TYPE = 9 )
END-EXEC
This query looks up the rows in the table transact where the account
number corresponds to the user’s account number, and the transaction
type code is 9 (customer meter reading). In practise, a customer might
Solutions Guide
have several rows of customer meter readings in the database (all

taken at different times). So at this point the results set could consist of
several rows. To filter the result down to the one row we want, we
ordered the rows by descending transaction number, which also
corresponds to their reverse chronological order. The results set could
still be several (ordered) rows, but the SELECT keyword only ever
returns a single row - the first row in the set, which in this case
corresponds to the most recent customer meter reading. So we edited
the generated SQL statement as follows:
EXEC SQL
SELECT
A.TRANS_UNITS
INTO
FROM transact A
ORDER BY A.ACC_TRANS_NO DESC
END-EXEC
Host variables and form variables

OpenESQL Assistant makes it very simple to add the correct host
variables to a program, and automatically ensures that the COBOL data
types are correct for each column in the database table.
To add host variables to our program, we did the following:
1 We clicked under the line working-storage section.
2 We clicked the Auxiliary Code tab in OpenESQL Assistant.
3 We clicked the Host Variable Declarations radio button.
OpenESQL Assistant added a copyfile, transact.cpy to our program,

containing host variable declarations for each column in the table.
The host variables that correspond to columns in the database have the
same names as the columns (with underscores translated to hyphens),
but are prefixed by the table name. So, for example, the column
ACC_TRANS_NO has a corresponding host variable, transact-ACC-
TRANS-NO. The table-name prefix is an option that you can change by
clicking Embedded SQL on the Options menu of Net Express.
Solutions Guide
The other variables used in this example are Input1, Input2 and
Outputdate. These are all related to the input form and output page of
the CGI program rather than with accessing the database, but as they
are used to pass data between the two programs we had to ensure the
data types were compatible.
Outputdate is a data item defined in the linkage section of metersql.cbl

and the working-storage section of mycgi.cbl. It is used to pass the
current date back to the CGI program. It can simply be defined as a pic
x(10), the same as SQLtoday.
Input1 holds data entered in the first entry field of the input form. It
contains the customer’s account number, and corresponds to the
ACCOUNT_NO column in the database. Input2 holds data entered in the
second entry field of the input form. It contains the customer’s meter
reading, and corresponds to the column TRANS_UNITS.
The data declaration for columns in the transact table is contained in

the copyfile transact.cpy, which was created by OpenESQL Assistant:
************************************************************
* COBOL DECLARATION FOR TABLE transact *
************************************************************
01 DCLtransact.
03 transact-ACC-TRANS-NO PIC S9(09) COMP-5.
03 transact-ACCOUNT-NO PIC S9(09) COMP-5.
03 transact-TRANS-TYPE PIC S9(09) COMP-5.
03 transact-TRANS-TEXT PIC X(80).
03 transact-TRANS-UNITS PIC S9(09)V9(02) COMP-3.
03 transact-TRANS-RATE PIC S9(06)V9(02) COMP-3.
03 transact-TRANS-VALUE PIC S9(06)V9(02) COMP-3.
03 transact-TRANS-TAX-RATE PIC X(1).
03 transact-TRANS-POST-DATE PIC X(26).
03 transact-TRANS-EFFECT-DATE PIC X(26).
From this, you can see that we needed to define Input1 as a pic s9(9)
comp-5 and Input2 as a pic s9(9)v9(2) comp-3.
However, the variables Input1 and Input2 were defined by Form

Designer when we painted the input form. Their definitions have been
added to the COBOL program in the copyfile gascgi.cpy as follows:
01 FormFields.
03 Input1 PIC X(15).
03 Input2 PIC X(15).
Solutions Guide
You should not change the data definitions in this copyfile, as it is

overwritten by any changes that you make to the form in Form
Designer. Instead, you should open the form in Form Designer and
change the COBOLPicture property for the relevant controls to
correspond to their SQL data type equivalents. For example, we made
the following change to the COBOLPicture property for the Input2 edit
field:
Figure 4-2. Changing the COBOLPicture property in Form Designer
Similarly, we changed the COBOLPicture property of the ACNumber

edit field to pic s9(9) comp-5.
Each control for which you specify a COBOLPicture has a corresponding

data item that is used to communicate with the form. This data item is
created automatically by Form Designer in the skeleton CGI program. It
is always a pic x item, regardless of the data type you use in your
program, and has the same name as the control, but with the prefix f-.
For example, the second entry field in the Gas Services form has two
related data items defined in the skeleton CGI program:
• 01 MeterReading pic s9(9)v9(2) comp-3.(defined in the

copyfile gascgi.cpy)
Solutions Guide
• 01 f-MeterReading pic x(13). (defined in the copyfile

gascgi.cpf)
The size of this data item is calculated from the COBOLPicture property -
in our example, ACNumber is equivalent in size to a pic x(10), and
MeterReading is equivalent in size to a pic x(13) data item.
Because HTML consists of plain text, the pic x data item is the only one
that can be displayed by the browser. Data conversion routines in the
skeleton CGI program move the data from f-MeterReading to
MeterReading when the input form is submitted; and from
MeterReading to f-MeterReading when the output form is displayed.
Note that this means that if you create one of the forms outside of Form
Designer (as we have done, because we wanted an HTML page for the
output instead of a form), you must remember to use the correct data
name (the one with the f- prefix) as a placeholder in the HTML.
The final program

The following listing shows the completed program for our prototype,
with some added explanatory comments.
data division.
EXEC SQL INCLUDE transact END-EXEC
01 transno pic x(4) comp-x.

01 today.
03 thisyear pic x(4).
03 thismonth pic x(2).
03 thisday pic x(2).
01 SQLtoday redefines today pic x(10).
01 acceptdate pic x(8).
01 dateparts redefines acceptdate.
03 yearpart pic x(4).
03 monthpart pic x(2).
03 daypart pic x(2).
01 textnote.
03 fixedtext pic x(19) value "Customer reading - ".
03 mreading pic x(9).
*> SQLtextnote is needed to concatenate literal text (which
*> in ESQL must be specified in single quotes) and the host
*> variable data (which cannot be in quotes because it is a
*> variable)
01 SQLtextnote redefines textnote pic x(28).
Solutions Guide
01 tempint pic 9(9).
linkage section.
*> This is the copyfile that was generated when we created
*> the input form
copy "mycgi.cpy".
01 Outputdate pic x(10).
procedure division using FormFields, Outputdate.

accept acceptdate from date yyyymmdd
move yearpart to thisyear
move monthpart to thismonth
move daypart to thisday
perform dbconnect
perform dbgettrans
perform dbupdate
perform dbread
perform dbdisconnect
move SQLtoday to Outputdate
exit program.
stop run.
dbconnect section.
EXEC SQL
CONNECT TO ’boxtest’ USER ’rjh.rtfm’
END-EXEC
.
dbgettrans section.
EXEC SQL
SELECT
MAX(A.ACC_TRANS_NO)
INTO
:transact-ACC-TRANS-NO
FROM transact A
END-EXEC
add 1 to transact-ACC-TRANS-NO
move function integer-part(Input2) to tempint
move tempint to mreading
.
dbupdate section.
move ACNumber to transact-ACCOUNT-NO
move 9 to transact-TRANS-TYPE
move SQLtextnote to transact-TRANS-TEXT
move MeterReading to transact-TRANS-UNITS
move SQLtoday to transact-TRANS-POST-DATE,
transact-TRANS-EFFECT-DATE
*> We have replaced three of the host variables in the
*> following statement with literals, because they are
Solutions Guide
*> always the same in this program

EXEC SQL
INSERT INTO transact
(ACC_TRANS_NO
,ACCOUNT_NO
,TRANS_TYPE
,TRANS_TEXT
,TRANS_UNITS
,TRANS_RATE
,TRANS_VALUE
,TRANS_TAX_RATE
,TRANS_POST_DATE
,TRANS_EFFECT_DATE
) VALUES
(:transact-ACC-TRANS-NO
,:transact-ACCOUNT-NO
,:transact-TRANS-TYPE
,:transact-TRANS-TEXT
,:transact-TRANS-UNITS
,0
,0
,’N’
,:transact-TRANS-POST-DATE
,:transact-TRANS-EFFECT-DATE
)
END-EXEC
.
dbread section.
initialize Input2
EXEC SQL
SELECT
A.TRANS_UNITS
INTO
FROM transact A
ORDER BY A.ACC_TRANS_NO DESC
END-EXEC
move transact-TRANS-UNITS to Input2
.
dbdisconnect section.
EXEC SQL
DISCONNECT CURRENT
END-EXEC
.
Solutions Guide
Building the application

Before we build the application, we had to enable OpenESQL support
for the data handling module by setting the SQL Compiler directive.
We did this by clicking the Advanced pushbutton on the Compile tab
of the Build Settings for metersql.cbl. We made the following
selections on the dialog box:
Figure 4-3. Adding the SQL Compiler directive using the Advanced
Directives dialog box
When we clicked OK, the SQL Compiler directive (with appropriate

parameters) was added to the list on the Compile tab of the Build
Settings. These settings apply to this COBOL file only. An alternative
way of achieving the same thing would be to add the following line of
code to the program:
$set SQL(DBMAN=ODBC,AUTOCOMMIT,TARGETDB=MSSQLSERVER)
4.1.2 Solution: Internet Application

Wizard
Internet Application Wizard provides a simple way of automatically
generating an application for browsing and updating an ODBC data
source. It takes you step by step through the process, asking questions
Solutions Guide
to find out your requirements, then generates the HTML forms and CGI
programs needed to run the application.
Technical: Internet Application Wizard implementation

Internet Application Wizard generates CGI programs that can read
and write to an ODBC data source. It uses Embedded SQL to
communicate with the data source, and one step of the wizard uses a
version of OpenESQL Assistant to generate the SQL statements
needed. You can modify the generated CGI code and HTML forms to
suit your application. Look up CGI code generation in the online help
Index for further information.

For each application that you want to create, you should consider
whether it would be best to generate a program using Internet
Application Wizard or to write your own program and use OpenESQL
Assistant to generate the SQL. In general terms, Internet Application
Wizard is most suitable for applications of the following types:
• Symmetric, form-based applications
• Applications whose main purpose is to browse and update complete

records
• Applications that allow access to an entire data source
OpenESQL Assistant would be more suited to the following types of

applications:
• Asymmetric or non-form-based applications
• Applications whose main purpose is to manipulate the results of

queries
• Applications that allow access only to a filtered version of the data

source
For more information on Internet Application Wizard, see the chapter

Data Access Applications in your Internet Applications online book, or
look up Internet Application Wizard in the online help Index.
Solutions Guide
63
Index
A Connection
explicit 44
implicit 44
Access 13 Copyfile
Accessing an RDBMS 41 automatically generated 56
ActiveX control 22 host variables 56
Advanced Directives dialog box 61 Cross-platform HTML 22
AIX 13 Cursor in SQL 43
Apache web server 13
Application
client/server 9
Architecture
client/server 9
D
Data
exchanging with a relational database
B 44
Data access 41
Data type
Benefits of client/server architecture 11 varchar 46
Building the example application 61 Dates in SQL 45
DB2 13
Deployment 13
Disconnecting from relational database 44
C Dynamic HTML 22
CGI program 30
Client
thick 12 E
thin 12
Client/server Error handling 46
application 9, 12 Errors in SQL 46
architecture 9 Event handler 26
benefits 11 Example scenario 6
Common gateway interface 30 Gas Services 6
Connecting to a relational database 44 Explicit connection 44
Solutions Guide
64
F J
Form 20 Java applet 22
HTML 23 JavaScript 26
Form Designer 23
M
G
Message loop 26
Gas Services 6 mfsqlmessagetext 46
Phase 1 32, 49 Microsoft 13
H N
Host variables 44 Navigator 13
in copyfile 56 NetBEUI 13
HTML 18, 22 Netscape 13
HTML form 23 Netscape Server API 37
Hypertext markup language 18 Novell NetWare 13
NSAPI program 37
I
O
Implicit connection 44
Informix 13 ODBC 41
Internet 17 Open Database Connectivity 41
Internet Application Wizard 27, 61 OpenESQL 41
ISAPI applications 37 OpenESQL Assistant 52, 62
Internet Explorer 13 Oracle 13
Internet Server API 36
Intranet 17
IPX 13
ISAPI program 36 P
Platforms supported by Net Express 13
Program
CGI 30
ISAPI 36
NSAPI 37
Solutions Guide
65
server-side 28
PVCS 13
U
Uniform resource locator 17
UNIX 13
R porting OpenESQL program 48
URL 17
User interface
RDBMS 41
Web application 21
Relational data 41
Remote procedure call 9
RPC 9
V
S Varchar data type 46
Visual SourceSafe 13
Scenario 6
SCO 13
Script Assistant 26
Server-side program 28
W
Service provider 9
Service requestor 9 Web application 20
Spyglass web server 13 flow of execution 21
SQL communications area 46 user interface 21
SQL Compiler directive 61 WHENEVER statement 46
SQL error 46 Windows 13
SQL Server 13 World Wide Web 17
SQL statements 42 WWW 17
sqlcode 46
sqlstate 46
Supported platforms 13
Sybase 13
T
TCP/IP 13
Thick client 12
Thin client 12
Time in SQL 45
Solutions Guide
66
Solutions Guide

03 UG Solutions Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

03 UG Solutions Guide

Uploaded by

Copyright:

Available Formats

sgpubb.

book Page 1 Friday, April 14, 2000 11:08 AM

Issue 3a, May 2000

Copyright © 2000 MERANT International Limited.

2 Developing Client/Server Applications . . . . . . . . . . 9

2.2 Suggested Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Client/Server on the Web . . . . . . . . . . . . . . . . . . . . . 17

3.3 Challenge: Creating a User Interface . . . . . . . . . . . . . . . . . . . . . 21

3.4 Challenge: Migrating or Updating an Existing User Interface . 27

3.5 Challenge: Web Server-side Program . . . ....... ...... ...... 28

1.1 Purpose of this Book

It concentrates on key concepts and practical examples of some of the

This book is designed to be used in conjunction with the other online

We want this book to be kept right up-to-date with the latest

1.2 Example Scenarios

1.2.1 Gas Services

1.2 Example Scenarios 7

The system will be deployed on a Windows NT server at the Helpline

Before the merger, Gas Services and WestGas each operated a

This chapter introduces some of the basic principles of client/server

2.1 Client/Server Architecture

2.1.1 What is a Client/Server

10 Chapter 2 Developing Client/Server Applications

Figure 2-1. Basic client/server architecture

Although applications that are running on different machines obviously

The following are typical features of a client/server application:

• A client program can request services from multiple server programs

• A client program does not need to be aware of the actual

• Multiple subprograms can work together to provide the service

• Multiple client programs can request services from a single server

• A server program can provide multiple services

• Typically, the server program runs on a machine that is remote from

COBOL applications request services by using the CALL statement. The

2.1 Client/Server Architecture 11

calling program - they can equally be associated with remote functions

2.1.2 Client/Server Benefits

• Re-use existing legacy code for the business logic

• Run each functional layer of the application on the platform most

• Distribute the processing and network loads

• Quickly and easily change business logic procedures without

• Provide simple and convenient delivery of the application and any

• Provide alternative client user interfaces to the same server-side

• Use development tools that are designed to work together

To maximize the potential value of using a client/server architecture,

12 Chapter 2 Developing Client/Server Applications

2.2 Suggested Approach

2.2.1 Separating Program Logic

• User interface logic (screen handling)

• Business logic (data processing)

• Data access logic (file or database handling)

Conceptually, each of these three areas of functionality - or layers - are

When you create a client/server application, it makes a lot of sense to

A Web application is the ultimate thin client. The user interface is

2.2 Suggested Approach 13

2.2.2 Supported Platforms

• Operating systems supported directly:

• Windows NT V4.0 with Service Pack 3, 4 or 5

• Operating systems supported in conjunction with Object COBOL for

• Most SVR4-based UNIX systems, including:

• Network protocols supported:

• IPX (Novell NetWare)

14 Chapter 2 Developing Client/Server Applications

We have tested the following platforms and believe them to be

• Microsoft Information Server V4.0