OSI/FTAM Programming Guide

Introduction to NonStop OSI/FTAM
HP NonStop OSI/FTAM Programming Guide—528612-001
1-6
FTAM in Online Transaction Processing Applications
defined by the Guardian disk process; how to use the FTAM API procedures and
files of predefined data structures; and what types of errors your application can
receive through the FTAM API. Section 3, NonStop FTAM Programming covers
those topics.
•
Programming concepts of the NonStop operating system, and features and
operation of the NonStop C or TAL compiler and development tools. See the
preface for a list of manuals on those topics.
•
Appropriate sequences of calls for accomplishing common operations with FTAM,
including how to create and manipulate local files compatible with FTAM document
types. Section 4, Using FTM Procedure Calls provides some guidance in
performing common operations. Section 3, NonStop FTAM Programming provides
some information about Guardian files, but you will also need to consult the
ENSCRIBE Programmer’s Guide for concepts and the Enscribe Programming
Reference Manual for procedure calling sequences.
•
Characteristics of the remote FTAM responder and how it implements the FTAM
standard. The vendor from whom you purchased the responder should provide this
information to you.
FTAM in Online Transaction Processing
Applications
Most HP NonStop customers develop their online transaction processing applications
using the Pathway online transaction processing system. It is possible to integrate your
FTAM application with Pathway if you remember several important facts. A Pathway
application consists of two types of processes: requesters, which usually accept
requests from users at terminals or workstations, and servers, which do the requested
work, normally database operations. The relationship between a requesting program
and a server is expected to be context free: that is, multiple requests from the same
program are independent and therefore need not be handled by the same server
process. When the server responds to the requester, the requested work, such as a
series of database updates, can be assumed to be complete.
The FTAM API and initiator work very differently. The application makes a series of
related requests; the requests are all handled by the same server (the FTAM initiator)
within the context of an association. The relationship is context sensitive. Furthermore,
all requests pertaining to an association normally come from the same application
process. Finally, because FTAM applications operate across a heterogeneous network
with uncertain performance characteristics, many applications are designed so that,
when the application receives a notification of I/O completion, the action it requested is
not necessarily complete.