tds - atossupport.bull.com/ols/product/system/gcos7/gcos7-com/g7-dps7000/… · chapter 1 presents...

TDS

Concepts

DPS

7000/XTA

NO

VASC

ALE

7000

Transaction Processing: General

REFERENCE47 A2 26UT 00

DPS7000/XTANOVASCALE 7000

TDSConcepts

Transaction Processing: General

March 1993B.P.20845

49008 ANGERS CEDEX 01

FRANCE

REFERENCE47 A2 26UT 00

The following copyright notice protects this book under Copyright laws which prohibit such actions as, but notlimited to, copying, distributing, modifying, and making derivative works.

Copyright Bull SAS 1993

Printed in France

Suggestions and criticisms concerning the form, content, and presentation of thisbook are invited. A form is provided at the end of this book for this purpose.

To order additional copies of this book or other Bull Technical Publications, youare invited to use the Ordering Form also provided at the end of this book.

Trademarks and Acknowledgements

We acknowledge the right of proprietors of trademarks mentioned in this book.

Intel® and Itanium® are registered trademarks of Intel Corporation.

Windows® and Microsoft® software are registered trademarks of Microsoft Corporation.

UNIX® is a registered trademark in the United States of America and other countries licensed exclusively throughthe Open Group.

Linux® is a registered trademark of Linus Torvalds.

The information in this document is subject to change without notice. Bull will not be liable for errors containedherein, or for incidental or consequential damages in connection with the use of this material.

47 A2 26UT Rev00 iii

Preface

INTENDED AUDIENCE

This document is intended for anyone interested in learning about Transactional DrivenSubsystems (TDS). This can be users, programmers, operators, or systemadministrators who work with or need to be familiar with TDS applications.

SCOPE AND OBJECTIVES

This document explains the basic concepts of TDS and its place within GCOS 7. Moredetailed information for developing, using and managing a TDS is found in these TDSdocuments:

TDS Administrator's Guide...............................................................................47 A2 20UTTDS C Language Programmer's Manual .........................................................47 A2 07UTTDS COBOL Programmer's Manual ................................................................47 A2 21UTTDS Quick Reference Handbook.....................................................................47 A2 24UTTransactional IntercommunicationUsing XCP1 Protocol User's Guide..................................................................47 A2 11UTCPI-C/XCP2 User's Guide ...............................................................................47 A2 14UTHigh Availability Concepts................................................................................47 A2 22UTHigh Availability Administrator's Guide.............................................................47 A2 23UT

TDS Concepts

iv 47 A2 26UT Rev00

STRUCTURE OF THIS DOCUMENT

Chapter 1 presents an overview of TDS and transaction processing.This section explains how TDS is different from other typesof processing, and how TDS interacts with GCOS 7 andother products. Also included is a summary of the types ofusers of a TDS application.

Chapter 2 defines the basic concepts of TDS and is relevant for alllevels of users: TDS Administrators, Programmers, MasterOperators, and End-users. This chapter includesexplanations of how data and resources are handled, howdata is protected and recovered, and how data is organized.

Section 3 explains how a TDS application is created and then run.The preparation and generation of the application ispresented. This chapter includes descriptions of the roles ofeach type of user.

Section 4 describes how the TDS application is designed andoptimized. This chapter presents the more complexconcepts that must be considered by the TDS Administratorand the TDS Programmer.

A glossary of TDS terms is provided at the end of this document.

Preface

47 A2 26UT Rev00 v

RELATED DOCUMENTS

The following documents provide detailed information about topics that affect TDS.

For generating the DPS 7 network:

Network Overview and Generation ................................................................. 47 A2 71UCTerminal Management .................................................................................... 39 A2 24DN

Installing, optimizing, and managing the system:

System Installation Configuration and Updating Guide ...................................47 A2 17USSystem Administrator's Manual........................................................................47 A2 10USSystem Behavior Reporter User's Guide .........................................................47 A2 03USTILS User's Guide............................................................................................47 A2 04US

Creating and managing FORMS using the MAINTAIN_FORM utility:

IOF Programmer's Manual ............................................................................... 47 A2 05UJ

Generating the GTWriter Network:

Generalized Terminal Writer User's Guide ..................................................... 47 A2 05UU

COBOL syntax and use:

COBOL 85 Reference Manual .........................................................................47 A2 05ULCOBOL 85 User's Guide..................................................................................47 A2 06UL

File access and data management:

IDS/II Administrator's Guide ............................................................................ 47 A2 13UDUFAS-EXTENDED User's Guide .....................................................................47 A2 04UFData Security Facilities User's Guide...............................................................47 A2 09UF

Main Operator tasks:

GCOS 7-V6 Network Operations Reference Manual...................................... 47 A2 72UCDOF 7-PO User's Guide ................................................................................. 47 A2 80UCSystem Operator's Guide................................................................................ 47 A2 60UU

Concurrency control:

General Access Control (GAC-EXTENDED) User's Guide .............................47 A2 12UF

TDS Concepts

vi 47 A2 26UT Rev00

For GCL commands:

IOF Terminal User's Reference Manual

Part 1 Introduction to IOF................................................................................. 47 A2 31UJPart 2 GCL Commands.................................................................................... 47 A2 32UJPart 3 Processors' Commands ........................................................................ 47 A2 33UJPart 4 Appendices............................................................................................ 47 A2 34UJ

Using IQS under TDS:

IQS-V4/TDS User's Guide .............................................................................. 47 A2 81UR

For using ORACLE under TDS:

ORACLE-V6/TDS User's Guide...................................................................... 47 A2 05UR

For Affinity:

Installation & Configuration Guide...................................................................40 A2 07WA

For OTM:

Administrator's Guide .......................................................................................86 A2 24SK

For CTP:

CPI-C Programmer's Guide ............................................................................. 86 A2 45SL

For IMAGEWorks:

TDS -IMAGEWorks Link User's Guide.............................................................47 A2 25UT

47 A2 26UT Rev00 vii

Table of Contents

1. Overview of TDS .................................................................................................. 1-1

1.1 WHAT IS A TDS APPLICATION? .............................................................................. 1-2

1.1.1 How is TDS Different from Other Modes of Processing? ..................................... 1-31.1.2 What are the Advantages of TDS ............................................................................. 1-5

1.2 WHERE IS TDS SITUATED IN GCOS 7? .................................................................. 1-6

1.2.1 Who Uses TDS? ........................................................................................................ 1-91.2.2 How to Use the TDS Documentation ....................................................................... 1-10

2. Basic Concepts and Terms ............................................................................ 2-1

2.1 WHAT IS A TRANSA CTION? .................................................................................... 2-2

2.1.1 Types of Transactions in TDS .................................................................................. 2-22.1.2 What is a Transaction Composed of? ..................................................................... 2-32.1.2.1 What is an Exchange? ................................................................................................ 2-42.1.2.2 What is a TPR?........................................................................................................... 2-52.1.2.3 What is a Conversation? ............................................................................................. 2-5

2.2 HOW TDS HANDLES DATA AND RESOURCES ...................................................... 2-7

2.2.1 Commitment Unit ...................................................................................................... 2-72.2.2 Commitment Point .................................................................................................... 2-82.2.3 Types of Commitment .............................................................................................. 2-9

TDS Concepts

viii 47 A2 26UT Rev00

2.3 PROTECTION OF DATA AND RECOVERY FROM INCIDENTS .............................. 2-11

2.3.1 Use of Journalization to Protect Data ..................................................................... 2-112.3.1.1 Before Journal ............................................................................................................. 2-132.3.1.2 After Journal ................................................................................................................ 2-132.3.1.3 User Journal ................................................................................................................ 2-132.3.1.4 Journal Utilities ............................................................................................................ 2-13

2.3.2 Recovery Techniques ............................................................................................... 2-142.3.2.1 Deferred Updates........................................................................................................ 2-142.3.2.2 Rolling Back a Commitment Unit ................................................................................ 2-15

2.3.3 Rolling Forward a Commitment Unit ....................................................................... 2-16

2.4 TYPE OF FILES IN A TDS APPLICATION ................................................................ 2-17

2.4.1 TDS-Controlled Files ................................................................................................. 2-172.4.2 Non-Controlled File ................................................................................................... 2-182.4.3 On-Line and Off-Line Files ....................................................................................... 2-19

3. The Tasks Involved in Creating a TDS Application .............................. 3-1

3.1 OVERVIEW OF THE STEPS FOR SETTING UP AN APPLICATION ....................... 3-2

3.2 DESIGNING AND BUILDING A TDS ......................................................................... 3-3

3.2.1 TDS Administrator Duties ......................................................................................... 3-33.2.1.1 Preparing On-Line and Off-Line Files ......................................................................... 3-33.2.1.2 Writing the TDS Source Program ............................................................................... 3-33.2.1.3 Generating the TDS Application.................................................................................. 3-43.2.1.4 Cataloging the TDS Authority Codes .......................................................................... 3-43.2.1.5 Generating the Network .............................................................................................. 3-53.2.1.6 Optimizing a TDS Application...................................................................................... 3-7

3.2.2 TDS Programmer Duties ........................................................................................... 3-73.2.2.1 Writing TPRs............................................................................................................... 3-83.2.2.2 Placing TPRs in a Sharable Module Library................................................................ 3-103.2.2.3 Testing and Debugging TPRs ..................................................................................... 3-123.2.2.4 Defining Special-Purpose Transactions ...................................................................... 3-123.2.2.5 Creating the Application Storage Areas ...................................................................... 3-143.2.2.6 Displaying Information on a Terminal.......................................................................... 3-153.2.2.7 Handling Reports......................................................................................................... 3-17

3.2.3 Fitting the Pieces of the Application Together ....................................................... 3-183.2.4 Later Modifications to a TDS Application ............................................................... 3-20

Table of Contents

47 A2 26UT Rev00 ix

3.3 RUNNING A TDS APPLICATION ............................................................................... 3-21

3.3.1 Master Operator Duties ............................................................................................ 3-213.3.1.1 Starting a TDS Application .......................................................................................... 3-223.3.1.2 Using the Programmed Operator to Control a TDS .................................................... 3-243.3.1.3 File Opening and Closing ............................................................................................ 3-253.3.1.4 Restarting After Failure ............................................................................................... 3-253.3.1.5 Stopping a TDS Application ........................................................................................ 3-25

3.3.2 End-User Duties ........................................................................................................ 3-263.3.2.1 Starting an End-User Session..................................................................................... 3-263.3.2.2 Starting Transactions .................................................................................................. 3-263.3.2.3 Terminating an End-User Session .............................................................................. 3-27

4. Designing and Optimizing a TDS Application ........................................ 4-1

4.1 CONTROLLING THE RATE AND AMOUNT OF DATA PROCESSED ..................... 4-2

4.1.1 Simultaneous Transactions ..................................................................................... 4-34.1.2 Non-concurrent Transactions .................................................................................. 4-44.1.3 Mapping and Unmapping Resources ...................................................................... 4-7

4.2 COMMUNICATION BETWEEN CORRESPONDENTS, APPLICATIONS,AND OTHER GCOS 7 PRODUCTS ........................................................................... 4-10

4.2.1 Correspondents ........................................................................................................ 4-114.2.2 Spawning New Tasks from within a Transaction .................................................. 4-124.2.3 Protocols for Communication between Correspondents ..................................... 4-144.2.3.1 The TM Protocol.......................................................................................................... 4-144.2.3.2 TCAM and TDS Pass-Thru capabilities ...................................................................... 4-154.2.3.3 The XCP1 Protocol ..................................................................................................... 4-164.2.3.4 The XCP2 Protocol ..................................................................................................... 4-18

4.3 INTERACTION WITH UNIX WORLD ......................................................................... 4-20

4.4 ACCESS AND ORGANIZATION OF DATA IN TDS .................................................. 4-22

4.4.1 IDS/II and TDS ............................................................................................................ 4-224.4.2 Using IQS with TDS ................................................................................................... 4-224.4.3 ORACLE and TDS ...................................................................................................... 4-23

4.5 PRODUCTS USED WITH TDS TO PROVIDE ADDED INTEGRITY & SECURITY .. 4-24

4.5.1 TDS-HA ....................................................................................................................... 4-244.5.2 Mirror Disks ............................................................................................................... 4-254.5.3 Protecting Databases with RDDF7 .......................................................................... 4-254.5.4 SECUR'ACCESS ........................................................................................................ 4-26

TDS Concepts

x 47 A2 26UT Rev00

Table of Contents

47 A2 26UT Rev00 xi

Illustrations

Figures

1-1 The TDS Environment in GCOS 7 .............................................................................. 1-31-2 The TDS Monitor within the TDS Environment ........................................................... 1-41-3 TDS, ORACLE, and IDS/II .......................................................................................... 1-61-4 TDS and FEPS............................................................................................................ 1-71-5 TDS and CNP 7........................................................................................................... 1-82-1 The Components of a Transaction.............................................................................. 2-32-2 Two Types of Exchanges............................................................................................ 2-42-3 A Conversation............................................................................................................ 2-52-4 Comparison of Explicit and Implicit Commitments...................................................... 2-102-5 TDS Journalization ...................................................................................................... 2-122-6 Example of a Rollback ................................................................................................ 2-152-7 Example of a Rollforward ............................................................................................ 2-163-1 The Steps in Building a TDS Application..................................................................... 3-23-2 TDS Terminals on a Network...................................................................................... 3-63-3 The Relationship Between TPRs and Transactions.................................................... 3-83-4 Compiling TPRs .......................................................................................................... 3-103-5 Code and Data Segments of a TPR............................................................................ 3-113-6 Linking TPRs............................................................................................................... 3-113-7 Special-Purpose Transactions .................................................................................... 3-133-8 An Example of a Form ................................................................................................ 3-163-9 Using TDS with IMAGEWorks .................................................................................... 3-173-10 Assembly TDS............................................................................................................. 3-193-11 Different Types of Sessions ........................................................................................ 3-223-12 End-User Terminal as Master Operator...................................................................... 3-233-13 System Console or IOF Terminal as Master Mailbox.................................................. 3-243-14 Sequence of Events when a Transaction is Submitted............................................... 3-284-1 Simultaneity Level of One ........................................................................................... 4-34-2 Transactions Specified as Non-Concurrent ................................................................ 4-54-3 Commitment Units of Non-Concurrent Transaction.................................................... 4-64-4 Unmapping versus No Automatic Unmapping ............................................................ 4-84-5 Spawning Transactions............................................................................................... 4-134-6 Using Pass-Thru to Connect to Remote Applications................................................. 4-154-7 An XCP1 Communications Session............................................................................ 4-164-8 An XCP2 Communications Session............................................................................ 4-184-9 TDS in the UNIX World ............................................................................................... 4-21

TDS Concepts

xii 47 A2 26UT Rev00

47 A2 26UT Rev00 1-1

1. Overview of TDS

This chapter explains what TDS is and includes:

• examples of TDS applications

• a description of how TDS is different from other modes of processing

• an explanation of the advantages of TDS

• an overview of how TDS interacts with GCOS and other products

• a summary of the typical users of a TDS application

• a diagram of the related documentation.

The Transaction Driven Subsystem, or TDS, is a GCOS 7 environment based ontransactions or real-time processing. That is, a TDS application accepts a request froman end-user, processes the request, and then sends a response back to the user'sterminal. This type of system is called transaction driven because processing isdetermined by the transaction specified by a user. (The term "transaction " as it is usedhere, indicates an interaction between the end-user and the data stored in the computersystem.)

TDS applications allow many users to access files or databases simultaneously whilemaintaining the integrity of the data. Several users can even submit the sametransaction at the same time. TDS applications provide short response times, reducethe time applications are unavailable after an incident, and ensure security andconfidentiality of data.

The names of the commands given in this manual are these applicable to GCOS 7 V6.

TDS Concepts

1-2 47 A2 26UT Rev00

1.1 WHAT IS A TDS APPLICATION?

A TDS application is an application designed to execute transactions. Bull provides theTDS software which both acts as a monitor of TDS applications and is used to generatethe customer's TDS applications. The TDS Administrator and TDS Programmer createthe customer's TDS applications using the Bull supplied TDS software. This is thereferred to as creating a TDS.

TDS applications are those where many users need to access informationsimultaneously or process continuous business activities. There are many differentkinds of customized TDS applications. Transactional applications are suitable for orderprocessing, inventory control, manufacturing, scheduling, billing, retail banking, andaccounting where many different operators or end-users use the same programs at thesame time on different terminals.

Examples of TDS Applications:

For example, travel agents are linked via terminals to a computer. Each travel agent canaccess flight records stored in a central location and make reservations for particularflights.

Another example of a transaction is a bank customer's interaction with an automatedteller machine. When the customer withdraws money from an automatic teller machine,several things happen during the processing of the transaction requested (withdrawal ofmoney from an account): the customer's account is read to determine whether there isenough money to cover the withdrawal, the account is updated in the bank's database,the amount of money requested is delivered, and a receipt is printed.

Overview of TDS

47 A2 26UT Rev00 1-3

1.1.1 How is TDS Different from Other Modes of Processing?

TDS, like IOF and batch processing, is an environment in GCOS 7. As with IOF or batchprocessing, several TDS applications can exist in the TDS environment. Figure 1-1shows this relationship.

IOFENVIRONMENT

BATCHENVIRONMENT

TDSENVIRONMENT

G COS 7

Figure 1-1. The TDS Environment in GCOS 7

TDS satisfies customers information needs rapidly. The amount of time it takes for theTDS application to respond to a request for service made by an "end-user" is themeasure of its effectiveness. This interval is called "response time ". When using aTDS application, a user can expect a response to a request immediately (1 or 2seconds).

In batch or IOF processing, the data needed to update a master file is collected beforethe file is updated. The time needed to prepare data before final processing can be long.Furthermore, a master file can be used by only one program at a time. Other programshave to wait for the file to be released.

When using a TDS application, users can enter data for immediate processing and canaccess updated data any time. An airline reservation system is an example of this real-time processing. When a passenger purchases a ticket, the reservation can be madeimmediately, and the system updates information about available seats automatically. Inaddition, TDS applications are designed to respond to multiple information processingrequests.

TDS Concepts

1-4 47 A2 26UT Rev00

TDS is an inquiry/response type of application. Inquiry means that you can only retrieveinformation from files, but you cannot modify the contents of these files. Responsemeans that a TDS application returns the appropriate information to a request.

The following scenario illustrates the usefulness of TDS processing:

If a user wants to check the status of the accounts for the business' customers and thecompany uses batch mode, a job stream must be set up, jobs must be scheduled, andresults printed and distributed; a process which can take several hours. In the TDSenvironment, the user logs on to the system, enters a transaction and sees a menu offunctions displayed on the screen. By selecting a function and entering the accountcodes, the information is available in seconds.

In a TDS application, the transaction is executed as it occurs. In a batch/IOFenvironment, jobs are scheduled over an interval of time and then executed.

Within GCOS 7, resources (the TDS environment) which contain information to beshared by TDS applications are available. The software that provides centralized controland orders the processing of transactions (requested by users at the terminals) is knownas the TDS Monitor. Figure 1-2 shows the relationship of the TDS Monitor to TDSapplications.

TDSENVIRONMENT

TD S M onito r

TD S A p p lica tions

Figure 1-2. The TDS Monitor within the TDS Environment

Overview of TDS

47 A2 26UT Rev00 1-5

1.1.2 What are the Advantages of TDS

Transaction Driven Subsystems provide applications with security, integrity, and flexibilityusing its own mechanisms, and standard GCOS 7 mechanisms.

In a TDS application, the confidentiality of data is assured by TDS authority codes,GCOS 7 access rights, and can be protected by SECUR'ACCESS (the Bull softwaresecurity product). Users can be granted or refused the right to execute a giventransaction.

TDS allows for simultaneous processing. A TDS can run up to 124 processes perapplication. The file integrity and coherence is maintained by TDS non-concurrencyfacilities, GAC-EXTENDED, and the protected read mechanisms. The TDS recoverymechanism and GCOS 7 journals provide the means of saving data and restarting afterabort.

TDS offers flexible programming. Transaction Processing Routines (the basic units oftransactions) can be written in COBOL, C language, or GPL, and can integrate IQSprocedures (IQS is the Bull Relational Information System).

TDS recovery mechanism, along with GCOS 7 system journals ensure that applicationare available . Warm start recovery in case of an incident, restarts of interruptedtransactions and dynamic recovery of errors are offered by TDS. Furthermore, usingTDS with these GCOS 7 High Availability products improves protection of applicationsand reduces the time that the application cannot be used:

• TDS-HA improves the availability of applications (local system backup)

• Mirror Disks improves the availability of data

• RDDF7 improves the availability of databases (remote system backup).

TDS Concepts

1-6 47 A2 26UT Rev00

1.2 WHERE IS TDS SITUATED IN GCOS 7?

TDS and Databases:

Figure 1-3 shows TDS in relation to the ORACLE and IDS/II products.

ID S /IID atab ase

O R A C LED atab ase

G C O S 7

O R A C L E

TD S M onito r

ID S /II TDS

Application

Figure 1-3. TDS, ORACLE, and IDS/II

Overview of TDS

47 A2 26UT Rev00 1-7

TDS and FEPS:

Figure 1-4 shows TDS in relation to the FEPS (and VCAM).

D P S 7 000

TD S A pp lica tio n

V C A M

F E P S

D ata net

Figure 1-4. TDS and FEPS

TDS Concepts

1-8 47 A2 26UT Rev00

TDS and CNP 7:

Figure 1-5 shows TDS in relation to CNP 7 (and VCAM).

D P S 700 0

TD S A p p lica tion

V C A M

TN S

C N P 7

Figure 1-5. TDS and CNP 7

Overview of TDS

47 A2 26UT Rev00 1-9

1.2.1 Who Uses TDS?

There are four types of users who work on TDS applications: TDS Administrator, TDSProgrammer, master operator, and end-user.

• The TDS Administrator is responsible for determining the requirements of theapplication and customizing it to meet these needs. The system administratorprepares and generates the application, and then manages the sizing and optimizingof a running application.

• The TDS Programmer writes the transactions (or TPRs) of the application followingthe outline determined by the system administrator.

• The master operator is responsible for supervising a TDS session. The operatorstarts and terminates the application, opens and closes files, and restarts theapplication when an incident occurs.

• The end-user is the person at a terminal connected to a TDS application who runstransactions.

TDS Concepts

1-10 47 A2 26UT Rev00

1.2.2 How to Use the TDS Documentation

There are several different documents which explain various aspects of TDS. The typeof document you consult depends on what your role is in TDS. This list presents anoverview of the documents that should be consulted by the four different type of users ofTDS. The documents you consult depend on the specific products on your site. Thedocuments in brackets are optional.

End-User TDS Concepts

Main Operator TDS ConceptsTDS Administrator's Guide (subset "Master OperatorCommands")

TDS Programmer TDS ConceptsTDS COBOL or C Language Programmer's GuideTransactional Intercommunication Using XCP1 ProtocolUser's Guide or CPI-C/XCP2 User's GuideTDS Quick Reference Handbook- [IQS-V4/TDS User's Guide]- [ORACLE-V6/TDS User's Guide]

TDS Administrator TDS ConceptsTDS Quick Reference HandbookTDS Administrator's Guide- [High Availability Administrator's Guide]

The TDS Programmer may also read the TDS Administrator's Guide or at least somechapters of it. Similarly, the TDS Administrator should be familiar with some of thecontents of the manuals destined for the TDS Programmer.

For a more thorough list of related documents and the document numbers of those listedhere, refer to the Preface of this book.

47 A2 26UT Rev00 2-1

2. Basic Concepts and Terms

To understand TDS, there are several concepts that need to be defined. Theseconcepts are explained in this chapter:

• Transactions and the elements that make up a transaction:

TPRsExchangesConversations.

• The handling of data and resources by using:

Commitment UnitsCommitment Points.

• Journalization and recovery techniques:

Deferred UpdatesRollbacksRollforwards.

• The files in a TDS application:

TDS-controlledNon-controlled files.

TDS Concepts

2-2 47 A2 26UT Rev00

2.1 WHAT IS A TRANSACTION?

In TDS, a transaction is a sequence of activities designed to accomplish a user-definedtask. There can be up to 2000 transactions in a TDS application. A transaction, or Tx, isnamed by a specific message identifier code, or message-id. This code is provided bythe TDS Administrator or displayed in a menu.

A transaction is executed or processed when a user starts a transaction by issuing aspecific message-id. The transaction is terminated when all of the task is performed.When the TDS Monitor receives a message-id from a terminal, it loads the first TPR ofthe transaction. A transaction can be made up of one or several TPRs. If all of the workof a transaction is not completed by the first TPR, other TPRs are started.

Only one message-id can be entered at one time, at a given terminal. When thetransaction is successfully executed, the user can enter the next message-id.

2.1.1 Types of Transactions in TDS

There are three main types of transactions in TDS.

• The FOR INQUIRY transaction is a request for information. This transaction answersthe user's question by "asking" the database about the current status of data. Thistransaction does not modify any files.

• The UPDATE transaction is a modification of files or databases. This transactionperforms the user's request by adding or removing the requested data. Thistransaction does updates files.

• The FOR DEBUG can be considered a temporary transaction. This type oftransaction is used by the programmer trying to correct a problem or optimize a TDSapplication.

In addition there are several types of special transactions available to the TDSprogrammer. For more information on these special transactions, see "TDSProgrammer Duties" in the chapter "The Tasks Involved in Setting Up a TDSApplication".

Basic Concepts and Terms

47 A2 26UT Rev00 2-3

2.1.2 What is a Transaction Composed of?

A transaction is composed of:

• Exchanges• TPRs• Conversations.

Figure 2-1 shows the relationship of these elements.

E x cha ng e

C on v e rs atio n

C om m itm e ntU nit

A c tiv atio n m essag e

D isp lay f orm

Fo rm fillin g

R e sp o nse

TR A N S A C TIO NTP R 1

TP R 2

R E C E IV E

TP R 3

S E N D

C O M M IT

N E XT -TP R = T P R2

N E XT -TP R = T P R3

N E XT -TP R = sp ace s

R E C E IV E

S E N DC O M M IT

Figure 2-1. The Components of a Transaction

A transaction is a sequence of exchanges and conversations. A transaction consists ofat least one exchange , each of which include one or more TPRs. However, atransaction may or may not include a conversation. The processing of a transaction isperformed by TPRs during an exchange, and the operator reply takes place during theconversation.

TDS Concepts

2-4 47 A2 26UT Rev00

2.1.2.1 What is an Exchange?

Each exchange is comprised of an input message, processing, and an output message.The processing that occurs during the exchange is performed by one or more TPRs(Transaction Processing Routines).

An exchange starts at the transmission of a message from the terminal operator andends at the reply sent back to this operator. An exchange is the sequence of:

• a request keyed in by the user (INPUT)

• processing performed by the transaction

• response sent to the user's terminal (OUTPUT).

An exchange contains at least one TPR. However, one exchange can include severalTPRs chained to one another. Figure 2-2 shows these possibilities.

O n eE xch an geTP R 1

T P R 1

T P R 2

T P R n

R ece iv e In pu t

P rocess in g

S en d O utpu t

R e ce iv e In pu t

P roce ss in g

S end O utput

Figure 2-2. Two Types of Exchanges

When a transaction is started, the TDS Monitor loads the first TPR. The processing ofthe TPR, that is the input and output, is an exchange. If the transaction is interactive,that is, if an end-user must respond to an on-screen message, a conversation is started.When the reply from the terminal operator arrives, the next TPR is loaded and executed.

When an exchange is completed, control is returned to the terminal. The end of theexchange is signalled either by the response to operator input, or by the default reply,"READY" when the transaction ends without a write to the screen. After you enterinformation, you must wait for this response from the transaction before entering a newmessage.


47 A2 26UT Rev00 2-5

2.1.2.2 What is a TPR?

A TPR is a Transaction Processing Routine written in either COBOL, C, or GPLprogramming language. TPRs are the programs that perform the individual steps of atransaction. A transaction consists of one or several related TPRs. TPRs are used toaccept input, to process it, and then to issue the reply.

A TPR usually chains to another TPR. When a TPR does not chain to another TPR, itmeans that it is the last TPR of the transaction.

The TDS Programmer writes and compiles the TPRs, then stores them in sharablemodule libraries. TPRs are brought into main memory to be executed when required.Several transactions can share the same TPR, in any sequence (that is, order ofexecution) with other TPRs. In any TDS application, several different TPRs can runsimultaneously.

A system can have up to 40,000 TPRs. Each TDS application can have as many as25,200 TPRs.

2.1.2.3 What is a Conversation?

In TDS, a conversation is defined as the period of time between two exchanges of thesame transaction. A conversation is the time that the user takes between receiving anoutput message and sending an input message. That is, the period starting when theresponse is sent by a transaction to the terminal, the time the user spends thinking (orthinktime), and when the next piece of information entered by the user is received.

Figure 2-3 illustrates a conversation.

E nd o f E xcha ng e - Tran sac tion send s o u tp u t m e ssa ge

N ew E xcha ng e - Tran sac tion rece iv e s in pu t m e ssa ge

C onv e rsa tio n

The E nd -u ser:- rea ds ou tp u t m essag e- m a ke s a dec is ion- e n ters a re p ly

Figure 2-3. A Conversation

TDS Concepts

2-6 47 A2 26UT Rev00

A conversation relates to an exchange as follows:

• A transaction does not necessarily include a conversation.

• A conversation includes the "thinktime" between the output message and theresponse. This period can be long, particularly if the user must do something, or if thetransaction involves two people (for example a sales clerk and a customer).

A conversation requires more time than the processing of an exchange as it requireshuman intervention. Other functions can be performed by a TDS application while theuser is reacting, a factor which is important for the TDS Programmer to consider whendesigning the TPRs.


47 A2 26UT Rev00 2-7

2.2 HOW TDS HANDLES DATA AND RESOURCES

A transaction does not have unique access to the data that its TPRs access. If atransaction holds all of the data (or resources) that it accesses, other transactionscannot access the same data until the first transaction terminates.

At a given point in processing, a transaction must "save" the modifications made to thedata. This save is called "taking a commitment". The place in the transaction where thecommitment is taken is called a commitment point.

2.2.1 Commitment Unit

A commitment unit, or CU, is a unit of processing in a transaction. It encompasses allthe processing from the last commitment point (or from the beginning of the transactionif it is the first commitment unit) to the current commitment point (or to the end of thetransaction if it is the last commitment unit). All writes, deletes, reads, or updates to filesare performed according to this unit of processing. When a commitment is taken, themodifications made during the commitment unit are permanent. A commitment allowsother transactions (started by other users) to access the same data. Commitmentsreduce long queues of transactions waiting for resources to become available, andreduce response times. Well placed commitments allow data to be processed faster,more efficiently, and in a more secure way.

The TDS programmer decides where a commitment should be taken within atransaction. As each commitment unit ends successfully, modifications to files ordatabases are committed. Once the data is committed, the resources are available tobe used by other transactions.

TDS Concepts

2-8 47 A2 26UT Rev00

2.2.2 Commitment Point

A commitment point is the point, or place, in the execution of a transaction where acommitment is taken. A transaction is always between two commitment points; theprevious and the current. At a commitment point:

• All previous processing is completed and cannot be cancelled. Processing includesoperations on files, messages, or requests to submit a job.

• Data and files are in a consistent state from the user's point of view.

• Transactions can be restarted if a software or hardware failure occurs. This meansthat when an incident occurs, all data before the last commitment point is valid.

In addition, the beginning of a transaction is, by default, a commitment point.

At a commitment point, TDS releases resources allocated to the transaction. (During theprocessing of a transaction, data is transferred from disks to main memory. This data isstored in objects called buffers and pages.)

Commitment points resolve conflicts between TPRs that request the same resources.When a transaction cannot continue processing because of a conflict for resources, thetransaction is aborted, then restarted at the previous commitment point. In themeantime, the TPR that had the resource will have released it at its commitment point.


47 A2 26UT Rev00 2-9

2.2.3 Types of Commitment

There are two types of commitments: explicit commitments controlled by the TDSprogrammer, and implicit commitment (controlled by TDS). In the generation of the TDSapplication, the TDS Administrator declares which type of commitment is to be used foreach transaction.

Implicit Commitment:

When the administrator specifies an implicit commitment for a transaction, TDSautomatically takes a commitment:

• at every conversation

• at the end of the transaction

• at the end of a TPR when the TDS programmer specifies a maximum number ofseconds that can elapse between the completion of the TPR and the start of a newTPR (this is known as the wait-time value).

There are commands that allow the programmer to override all implicit commitments,except for those at the end of the transaction.

Explicit Commitment:

Explicit commitments are controlled by the programmer. For every commitment in atransaction, the programmer must add a statement in the TPR program to call acommitment. The commitment will take place at the end of the current TPR.

The four columns in Figure 2-4 compare implicit and explicit commitments, and showhow the programmer can change the automatic (implicit or explicit) commitment.

TDS Concepts

2-10 47 A2 26UT Rev00

A utom a tic P rog ra m m e rA ction

Imp licit Co mm itm ents Explicit Com m itm en ts

A utom atic P rog ram m e rA ction

co nv e rsa tion

com m itm ent

con v ersation

c onv ersatio n

co m m itm en t

co nv e rsa tion

co m m itm en t

conv ersa tion

com m itm e nt

co m m itm en t

c onv ersatio n

co m m itm en t

c onv ersatio n

co m m itm en t

co m m itm en tco m m itm en t

com m itm ent com m itm e nt

com m itm e nt

E n d o f TxEn d o f Tx

E nd o f Tx E n d of Tx

c onv ersatio n

TP R TP RN o C om m it C a ll

TP R TP R

TP R TP R

TP RTP R

TP RTP R

TP R TP RFo rce C o m m it C a ll

TP RTP R

TP R TP RF orce C om m it

TP RTP R

Figure 2-4. Comparison of Explicit and Implicit Commitments

Modifications to files or databases by a TPR are effective only when the TPRscommitment unit is processed.


47 A2 26UT Rev00 2-11

2.3 PROTECTION OF DATA AND RECOVERY FROM INCIDENTS

TDS provides several mechanisms to protect data from the effects of hardware orsoftware incidents. The Journalization mechanisms and the associated recoverymechanisms maintain the integrity of data in the event of a transaction abort, TDS abort,or GCOS 7 system crash. The integrity procedures and recovery techniques varyaccording to the type of failure and the level of protection required.

For example, if a system crashes during the execution of transaction that withdrawsmoney from one account and puts it in another account, the "updated" data isinconsistent and possibly incomplete. When an incident occurs, the reliability of updateddata depends on whether or not a commitment is taken. The TDS journalization andrecovery mechanisms are used to save commitment units and thus handle this type ofsituation.

2.3.1 Use of Journalization to Protect Data

Journalization is the use of the Journals to maintain data integrity. There are two GCOS7 Journals that protect data, and another TDS Journal file that can be customized andused for statistics or debugging. The three journals are:

• Before Journal.• After Journal.• User Journal.

The Before and After Journals are not specific to TDS, they are GCOS 7 facilities. TheUser Journal is a TDS facility.

In Journalization, two copies are made of the data being processed. The copies arereferred to as "images". The first image of the data is made before the data is updated.This is known as the before image . The second image of the data, or after image , ismade after the data is updated. These images are saved, or journalized, in the TDSJournals; in the Before Journal and the After Journal, respectively.

The Before Journal allows files to be recovered when updates are incomplete due tosoftware failure. The After Journal protects files against any type of destruction,including physical destruction of the file media.

The TDS Administrator determines the level of protection for each application. Thejournal used depends on whether the file is protected against hardware failure, softwarefailure, or both. Journal protection for a file can be specified either when the file isprocessed, or in the catalog description cataloged file.

Figure 2-5 shows where the Before and After Journals intervene in a transaction with twoexchanges and a file update.

TDS Concepts

2-12 47 A2 26UT Rev00

D a ta bas e

com m itm e nt po in t

TPR1

TPR2

TP R 3(w rite o pera tion)

TPR4

Tran sa c tion en tered by u ser

co m m itm en t p o in t

B efo reJo urna l

A fte rJo urna l

e nd o f tran s ac tion

com m itm e nt p o in t

Figure 2-5. TDS Journalization


47 A2 26UT Rev00 2-13

2.3.1.1 Before Journal

The Before Journal protects files from software incidents. This journal does not protectfiles against physical destruction due to hardware failure. The Before Journal is used torecover files when updates in progress are aborted.

The Before Journal stores an image of the file to be updated. The images stored in theBefore Journal are used to return files to the most recent valid state; that is, to thebeginning of the last commitment unit. The images in the Before Journal are madebefore the updating begins, while the commitment unit is in process. When thecommitment unit is terminated, the before images are released.

The Before Journal must be used for files shared between a TDS application and batchprograms. This Journal can be used by itself or in conjunction with the After Journal.

2.3.1.2 After Journal

The After Journal protects data from hardware or software incidents. This journal isused to save modifications to a file when an incident occurs after an update iscommitted, but before it is written to the file.

When a commitment unit is updating a file, the system keeps an image of each recordafter it is updated, and writes each "after image" to the After Journal. If an incidentoccurs, it is possible to reconstruct the file by using a previously saved version of the file,and then overwriting each updated record with the after image.

File saving and restoring are not automatic in TDS. The master operator oradministrator must perform these tasks using the data management utilities.

2.3.1.3 User Journal

A third journal exists in TDS which allows users to record certain statistics of a TDSapplication. A user can decide to log input and output messages, as well as informationabout transactions in the TDS User Journal.

The User Journal is located in the After Journal. The TDS User Journal is not a fileprotection mechanism, but is explained here because of its location. However, theinformation in the User Journal can be transferred to a special file when required, andused for debugging.

2.3.1.4 Journal Utilities

There are other utilities associated with the After Journal. These utilities can only beused by the TDS Administrator:

• The ROLLFWD utility uses the After Journal to reset from 1 to 25 user files to thestate they were in at a specified date and time.

• The DUMPJRNL utility takes the data in the User Journal and writes it to a sequentialoutput file.

• The After Journal Recovery Utility, JRU, restores the After Journal to a coherent statewhen it is corrupted because TDS cannot supply the list of aborted commitment units.

TDS Concepts

2-14 47 A2 26UT Rev00

2.3.2 Recovery Techniques

The TDS recovery techniques reconstruct the data so that it is in the same state as itwas at the time of the incident. The recovery mechanisms must perform these tasks in arapid and effortless way so that transactions in progress can resume processing.

Three recovery mechanisms are used in TDS:

• deferred updates• rollbacks• rollforwards.

These mechanisms are used with the Journals.

2.3.2.1 Deferred Updates

The deferred update mechanism works with the After Journal. If a deferred update isrequested for a file, the WRITE or REWRITE statement in the TPR is not physicallyexecuted until after the commitment unit is successfully terminated. During theprocessing of the commitment unit, the output record is placed in a buffer in the AfterJournal. If the commitment unit does not terminate successfully, the modifications areignored.

The WRITES to files are made according to these conditions:

• If a commitment unit is aborted, the system erases the contents of the buffer and theafter images. No changes are made to the files.

• If a commitment is validated, the contents of the buffer is transferred to the files.

Deferred updates means that updates to files are accepted but are not actually written todisk until the commitment point is reached. If a commitment unit fails, it does not effectthe TDS data.


47 A2 26UT Rev00 2-15

2.3.2.2 Rolling Back a Commitment Unit

When an incident occurs during the processing of a commitment unit, the commitmentunit must be restarted. This is accomplished using "rollback" processing. A rollbackreturns the journalized files to their valid state at the beginning of the last commitmentunit.

To perform a rollback, the before images are copied back to the corresponding files,restoring them to their previous state. That is, if a commitment is not taken, data isrestored to its original state by applying its before image. The transaction can berestarted, and process same data as if it were accessed for the first time.

A rollback is shown in Figure 2-6. In this example, the first commitment unit terminatessuccessfully. The abort occurs during the second commitment unit (CU2). When arollback is processed, the files are return to the state they were in at the end of the firstcommitment unit.

C om m itm e nt U n it-1 C om m itm e nt U n it-2

ABORT

Tra ns a ctio n b ein g p ro ces sed

R o llba ck to la st com m itm e nt p o int

Figure 2-6. Example of a Rollback

TDS Concepts

2-16 47 A2 26UT Rev00

2.3.3 Rolling Forward a Commitment Unit

When an incident occurs after a commitment is taken, but before the data is written tothe file, the I/O transfer to the file must be restarted. (The operator is notified when theupdate to the file terminates abnormally). In this type of incident, a rollforward uses theafter images to update the file.

If the incident is caused by a hardware problem, the problem must be solved before theafter image can be applied to update the file.

A rollforward updates the journalized files to their valid state as determined by the lastcommitment unit as shown in Figure 2-7. In this example, the first commitment unitterminates successfully but the transfer of these modifications to the file aborts.Because the updates are committed, a rollback can be applied to the file.

ABORT

Transac tion b e ing proce sse d

T im eC om m itm ent p o int

W rite m od if icatio n to f ile

A fterJ ournal F ile

Figure 2-7. Example of a Rollforward


47 A2 26UT Rev00 2-17

2.4 TYPE OF FILES IN A TDS APPLICATION

In a TDS application, there are two types of files: TDS-controlled and non-controlledfiles. The basic difference between these files is the way that access conflicts areresolved. Both types of files are UFAS-EXTENDED. However, each type of file hascertain restrictions.

When an access conflict occurs for a TDS-controlled file, the conflict is resolved by theTDS Monitor. When a non-controlled file is accessed, it is "locked" (but only during the"access" time) so that other transactions cannot use it.

2.4.1 TDS-Controlled Files

The TDS Administrator can declare a UFAS-EXTENDED file to be TDS-controlled. Thisfile can be either a relative or indexed sequential file. When a file is TDS-controlled,simultaneous access to records in the file is controlled by the TDS Monitor.

When a transaction accesses records in a file, a part of the file is locked for the durationof the commitment unit. Locked records cannot be accessed by other transactions.This is where the TDS-controlled files comes in, any access conflicts are resolved by theTDS Monitor.

For example, two airline ticket agents may try to simultaneously assign the same seat ona flight to two different passengers. If the file containing the seating information is TDS-controlled, the concurrent access to the files is resolved. The identical data requestedsimultaneously by the two users can be accessed in a controlled way.

The concurrency control mechanism, known as GAC-EXTENDED (General AccessControl), allows a TDS-controlled file to be shared concurrently between a transactionand the following:

• another transaction in the same TDS application• another TDS application• a batch program• an IQS application.

The areas of an IDS/II database must be declared TDS-controlled. Under GAC-EXTENDED, TDS-controlled files and IDS/II areas can be assigned exclusively or not tothe TDS job. Exclusive access means that access may be given only to the TPRrequesting it.

The use of GAC-EXTENDED is specified when the files are assigned. GAC-EXTENDED applies to cataloged or non-cataloged files. In the latter case, the use ofGAC-EXTENDED can be defined in the JCL statements that run the TDS job.

Furthermore, TDS-controlled files can be protected by full Journalization facilities.

TDS Concepts

2-18 47 A2 26UT Rev00

2.4.2 Non-Controlled File

TDS non-controlled files are also UFAS-EXTENDED files. Non-controlled file can beprotected by the Before Journal, but not by the After Journal. This type of file is notprotected by GAC-EXTENDED. Therefore access conflicts can occur, for example,between two TPRs of the same TDS application.

Unlike TDS-controlled files, the protection of non-controlled files requires the interventionof the TDS Programmer. The programmer must ensure that when a non-controlled fileis accessed, it cannot be accessed at the same time by another transaction in the sameor in another TDS application.

There are several ways of protecting a non-controlled files. The programmer can

• Assign the file exclusively to a TDS application.

• Make transactions that are accessing the same file execute non-concurrently.

• Protect non-controlled files by an indirect locking mechanism based on user-definedidentification. The form of identification may be letters or numbers. Users can sharenon-controlled files by associating a file with a given name and then locking the name.This technique must be programmed in the TPRs. Locking and unlocking TPRsallows users to temporarily protect other transactions from concurrently writing to orreading from a file. When the user finishes using the file, the name corresponding tothe locked file is unlocked. Because this type of locking mechanism is indirect (that is,the actual files themselves are locked via the use of numbers or letters), no guaranteecan be given that the locking/unlocking functions are always effective.

Another way of locking files can be performed by the master operator. The masteroperator can prevent a specific transaction or class of transactions from being started.


47 A2 26UT Rev00 2-19

2.4.3 On-Line and Off-Line Files

On-line and off-line files are the files used to generate and operate the TDS application.These files can be considered TDS "system files". They are not user data files thatmake up the database of an application. A summary of how to use these files ispresented in the chapter "The Tasks Involved in Setting Up a TDS Application". Forinformation about individual files, see the TDS Administrator's Guide.

Off-line files:

Off-line files are needed to generate, compile and link TDS. These files are not neededat run time. The TDS off-line files are:

<tdsname>.SLLIB is a source language library that contains the TDS sourcegeneration and Linker commands

<tdsname>.COBOL is a source language library that contains the filedescriptions and storage areas defined at the generation.

<tdsname>.SMLIB is a sharable module library that contains the linked units ofTPRs

<tdsname>.LMLIB is a library that contains the TDS generation load module

<tdsname>.EDITION is a work file that contains the report produced by the TDSgeneration program

TDS Concepts

2-20 47 A2 26UT Rev00

On-line files:

On-line files are required for processing transactions. Therefore, these files need to beon-line, or accessible, while the application is running. The TDS on-line files are:

<tdsname>.SWAP is the internal TDS journal file that contains restartinformation relevant to each terminal logged on to TDS

<tdsname>.CTLM is a file (controlled by GAC-EXTENDED) that containscontrol information at generation time and updates thisinformation while the application is running

<tdsname>.CTLN is a file (not controlled by GAC-EXTENDED) that containscontrol information at generation time and updates thisinformation while the application is running

<tdsname>.RECOV is a file that contains information for rollback and dynamicrollforward of TDS-controlled files.

<tdsname>.DEBUG is a file that contains the results of the trace options.

<tdsname>.PPCLOG is a file used by the XCP2 service and contains the currentstate of the pools.

<tdsname>.GMEM is a file that contains a description of IQS objects.

<tdsname>.H_MMS is a file that contains information that allows IMAGEWorksto be used.

47 A2 26UT Rev00 3-1

3. The Tasks Involved in Creating a TDSApplication

Creating an operational TDS application involves many different procedures. Theseresponsibilities are handled by the TDS Administrator, the TDS Programmer, the MasterOperator, and the End-User.

This chapter explains the tasks that must be carried out, and shows where theresponsibilities of each type of user come in during the preparation.

TDS Concepts

3-2 47 A2 26UT Rev00

3.1 OVERVIEW OF THE STEPS FOR SETTING UP AN APPLICATION

The TDS environment and generation program is delivered as a standard package. TheTDS administrator and programmer must customize the application(s) according to sitespecifications. Figure 3-1 shows the basic steps that must be performed to customize aTDS application. Next to each step is the type of user responsible for the action.

TD S A dm in is tra to r

TD S P rog ram m er

M a ste r O p era tor

E nd -U se r




P rep are TD S E nv iron m ent(TP 7P R E P )

W rite TP R s

C reate the TD S S ou rceP rog ram (S TD S )

G e nera te the A p p lica tio n(TP 7G E N )

G enera te the N e tw ork(C R N E TG E N )

S tart O p era to r S ess io n

R un Tran sac tions

Figure 3-1. The Steps in Building a TDS Application

The Tasks Involved in Creating a TDS Application

47 A2 26UT Rev00 3-3

3.2 DESIGNING AND BUILDING A TDS

The design and creation of a TDS application is handled by the TDS Administrator andthe TDS Programmer. After the administrator and programmer set up the application,the Master Operator can start the TDS and End-User can begin running transactions.

3.2.1 TDS Administrator Duties

The TDS Administrator is responsible for planning and defining the application, setting itup, and then overseeing the management of a running application. The administratorcreates an application to site specifications by declaring the files, the transactions to beused, the storage structures, and the correspondents that can access the application.

3.2.1.1 Preparing On-Line and Off-Line Files

The on-line and off-line files are the "system files" of a TDS application. They are usedto create the TDS environment and to process transactions. These files are not used tohandle user data of an application.

The TDS administrator uses the JCL utility, TP7PREP, to create the on-line and off-linefiles. The TP7PREP utility is a software tool that helps the administrator build theapplication by providing ready-made files. In this utility, the administrator defines,allocates, and specifies the size of the files as well as the media and device type. If thedefault file-sizes are not suitable, the administrator can specify other sizes.

3.2.1.2 Writing the TDS Source Program

The TDS Source Program, or STDS, is the program used in the generation of theapplication. In the STDS, the administrator defines the application. When the programis written, the administrator saves it in the off-line file <tdsname>.SLLIB.

The STDS contains three sections:

• TDS Section.• INPUT-OUTPUT Section.• TRANSACTION Section.

In the TDS Section, the administrator specifies the overall constraints of the TDS. In theINPUT-OUTPUT Section, the administrator specifies information about how files areaccessed, including file descriptions, file processing modes, file protection, and databaseschema references. In the TRANSACTION Section, the administrator provides detailsof all transactions that can be accessed by users, the resources available totransactions, and the restrictions to be observed.

The administrator must arrange the statements of the STDS in the order in which theyappear in the TDS Administrator's Guide. For information on the statements used in theSTDS, see the TDS Administrator's Guide.

TDS Concepts

3-4 47 A2 26UT Rev00

3.2.1.3 Generating the TDS Application

After the administrator allocates the required files and stores the source program(STDS) in the off-line file <tdsname>.SLLIB, the TDS Generation program must be run.The TDS Generation program, or TDSGEN, is executed by running the JCL utilityTP7GEN.

This utility formats and initializes the TDS "system files", compiles the STDS (SourceTDS generation program), and prepares the command files used to link the TPRs. Italso creates the members (in <tdsname>.COBOL) that are copied into the TPRs.

3.2.1.4 Cataloging the TDS Authority Codes

The TDS administrator must declare information about users in the Site Catalog. Thesite catalog contains a list of TDS users associated to projects. Each project is assigneda list of authority codes. The authority codes determine whether or not a project canaccess a particular set of transactions.

By establishing authority codes, the administrator determines the set of transactions thateach operator is allowed to perform, thus eliminating the risk of unauthorized access.For example, if the TDS administrator gives a transaction the authority code of 10 only,to use the transaction the operator must be assigned to a project that has the authoritycode 10.


47 A2 26UT Rev00 3-5

3.2.1.5 Generating the Network

In a TDS, terminals often communicate with the application between different physicalsites. The communications software necessary for the transmission of data across anetwork must be described independently of TDS. The purpose of the networkdescription is to reflect the number of users and the types of correspondents declared atTDSGEN.

If the communications network is not already declared, then the administrator mustgenerate it after TDSGEN is executed, and the transactions are compiled and linked.The Network generation, or NETGEN, is processed using the CRNETGEN utility (CreateNetwork Generation). In the NETGEN, the administrator defines the networkconfiguration and declares the number of TDS users and correspondent types.

Figure 3-2 shows a TDS application on a network.

TDS Concepts

3-6 47 A2 26UT Rev00

DPS 7000

THE NETWORK

Figure 3-2. TDS Terminals on a Network

Once the network is generated, the communications session and then the TDS sessioncan be started.


47 A2 26UT Rev00 3-7

3.2.1.6 Optimizing a TDS Application

The TDS Administrator can use these two facilities for measuring performance andoptimizing system resources:

• TILS• SBR.

The System Behavior Reporter (SBR) is a tool used to analyze the workload and usageof the hardware and software resources of a DPS 7000 installation. It can be used tomeasure the efficiency of TPRs, as well as the behavior of a TDS and GAC-EXTENDED. For more information, see the SBR User's Guide.

The Transaction and Interactive Load Simulator (TILS) is designed to simulate a TDSworkload. TILS can be used on the same system as the application, or on a remotesystem. TILS is useful for testing applications under modification or in development.For more information, see the TILS User's Guide.

3.2.2 TDS Programmer Duties

The TDS programmer is responsible for:

• writing the Transaction Processing Routines• writing the special-purpose transactions• declaring TDS storage areas• determining how information is displayed on the screen• handling reports• testing and debugging TPRs and applications.

TDS Concepts

3-8 47 A2 26UT Rev00

3.2.2.1 Writing TPRs

The TDS programmer can start writing the source code for TPRs before the TDSadministrator generates the application. Transaction Processing Routines, or TPRs, arethe user-defined programs written for an application. TPRs can be written in COBOL, CLanguage, or GPL. TPRs perform these tasks:

• read files• process data• update files• dialog with the end-user who started the transaction.

For more information on TPRs, see the section "What is a TPR?" in the chapter "BasicOperating Concepts".

Figure 3-3 shows the relationship of TPRs to a transaction. TPR1 through TPR4 arefunctionally dependent on transaction 2 (Tx2). In this example these TPRs cannot beused by either transactions 1 or 3 (Tx1 and Tx3). However, in an actual application,TPRs are shared by many different transactions.

TP R 1

TP R 2 TP R 3

TP R 4

Tx2

Tx 1Tx3TD S G E N

Figure 3-3. The Relationship Between TPRs and Transactions


47 A2 26UT Rev00 3-9

The TDS programmer must decide which transactions are needed in an application, andthen write the TPRs for the transactions. The task of writing TPRs includes coding,editing, compiling, linking, and testing of the TPRs.

The TDS programmer must design and write TPRs to optimize response times.Resources should not be held while waiting for a reply from the terminal operator.Efficient TPRs use and then release resources. Functions must be allocated amongdifferent TPRs. If a TPR handles too many tasks, response times are increased,resources are held, and conflicts occur.

The most common TDS design mistake is using one TPR to do everything that needs tobe done in a transaction. For example, a TPR can be used to update several records ina restricted set of files. However, a TPR that reads or updates a few dozen records isnot efficient. TPRs designed this way conflict with other transactions that need to accessthese records, or occupy the TDS for a long period, causing delays for other users.

The TDS Monitor provides procedures for managing TPRs, telecommunications, anddata.

The TDS programmer can describe files, transactions storages, in the TDS generationprogram and have the TPRs copy the descriptions by using the COPY function inCOBOL. This feature helps to create a consistent structure to a TDS application; it alsoreduces the time spent coding TPRs, and prevents errors.

Hints for Writing TPRs:

• Design transactions to correspond to a basic unit of processing.

• Write small and compact TPRs.

• Decide which operations are indivisible.

• Make each indivisible operation into a single commitment unit.

• Free resources at the start of a conversation. A conversation requires more time thanthe time needed to process an exchange.

• Use an outline to write TPRs. Writing individual TPRs can lead to errors andinconsistencies.

• Create special TPRs to handle the processing of "exceptional" items; such as error-handling TPRs.

TDS Concepts

3-10 47 A2 26UT Rev00

3.2.2.2 Placing TPRs in a Sharable Module Library

The TDS programmer compiles all TPRs separately, and then links them by running theLINKER utility. This utility creates references between the compile units and sets up thelinks to TDS procedures. When the TPRs are linked, they are stored in a sharablemodule library (SMLIB).

When the Source TPRs are compiled, compile units are produced containing the TPRcode and data segments as shown in Figures 3-4 and 3-5.

TD S G E NInfo rm atio n

C om p ile r

S ou rceTP R s

C om p ileU n its

Figure 3-4. Compiling TPRs


47 A2 26UT Rev00 3-11

Each TPR is composed of code and data segments as shown in Figure 3-5.

C o m pile U nit

C od eS eg m ents

D a taS eg m ents

ca n b e sha re dam on g se v eralins tan ces of a TP Rsim u ltan eous ly

e ac h ins tanc eo f a TP Rh as its ow n da ta

Figure 3-5. Code and Data Segments of a TPR

When the LINKER utility is run, each compiled TPR is stored in a sharable module asshown in Figure 3-6.

C om pileU n its

S ha rab leM odu les

LIN K E R

Lin k erC om m an ds

Figure 3-6. Linking TPRs

TPRs are sharable entities. This means that several transactions can use the sameTPR at the same time. If a new transaction is activated that requires a TPR currentlyexecuting, TDS creates data segments of the TPR in their original state for this newtransaction. The code segments need not be duplicated because they are sharable.

TDS Concepts

3-12 47 A2 26UT Rev00

3.2.2.3 Testing and Debugging TPRs

There are several ways to test and debug TPRs and TDS applications:

• Use the TRACE command to debug TPRs. This command accepts a subset of theProgram Checkout Facility (PCF) commands.

• Specify the DEBUG mode in the TDS generation program. When transactions areexecuted in DEBUG mode, file updates are cancelled. This means that TPRs can berun and tested without permanently modifying any data.

• Simulate an Operational TDS Application. A special program, known as the TDSBatch Interface, can simulate a fully operational TDS environment without having touse terminals. TDS Batch Interface programs can be written by the programmer, inCOBOL, and used to simulate terminal operator functions.

• The batch program can be logged on as a terminal to send and receive messages.The TDS application thinks that a terminal is connected, but does not have the real-time constraints of a terminal.

• Use the Real Time Statistics to display detailed information and general statisticsabout correspondents and files of a running TDS. This procedure allows theprogrammer to identify problem areas (blocked users, whether files are open orclosed, etc.) and to make the necessary corrections.

3.2.2.4 Defining Special-Purpose Transactions

There are seven default special-purpose transactions used to control a TDS application:

• STARTUP• LOGON• RESTART• BREAK• DISCNCT (for DISCONNECT)• LOGOUT• SHUTDOWN.

Figure 3-7 shows where these special-transactions are in the context of an application.

In a TDS session, there is only one startup and shutdown.

However, during a user session, there may be several logons. For example, if a user isdisconnected and subsequently logs on again.

The user can decide to cause a BREAK (for example, by pressing a BREAK key).Thisinterrupts the transaction in progress and starts the BREAK transaction.


47 A2 26UT Rev00 3-13

TR A N S A C TIO NP R O C E S S IN G LOGOUT S H U T D O W N

B R E A K D IS C N C T

TD S S ess ion

U se r S ess ion

S TA R T U P L O G O N R ES T A R T

Figure 3-7. Special-Purpose Transactions

The TDS programmer can substitute customized special-purpose transactions for thedefault transactions. Writing customized transactions is important if the defaulttransactions are inappropriate for a given site or application. For more information onthese transactions, see the TDS Programmer's Manual.

TDS Concepts

3-14 47 A2 26UT Rev00

3.2.2.5 Creating the Application Storage Areas

There are several storage areas in a TDS which allow TPRs to communicate with otherTPRs or with TDS. These storage areas allow transactions to access and communicatedata:

TDS-STORAGE A communication area used to pass information betweenTDS and TPRs.

TRANSACTION-STORAGEThe area that allows one TPRs to pass information to thefollowing TPR within the same transaction.

COMMON-STORAGE An area shared among all transactions of a TDS, that allowsone TPRs to pass information to the following TPR withinthe same or different transactions.

CONTROLLEDCOMMON-STORAGE A communication area, controlled by the GAC-EXTENDED

mechanism, that can be rolled back when an incidentoccurs.

SHARED-STORAGE User storage areas shared between two or moretransactions.

CONSTANT-STORAGE An area that contains communications control characters.

PRIVATE-STORAGE A part of the TRANSACTION-STORAGE section that isallocated to one user from logon to logout.

WORKING-STORAGE An optional storage section used by a TPR in the samemanner as in a standard COBOL program.


47 A2 26UT Rev00 3-15

3.2.2.6 Displaying Information on a Terminal

The TDS programmer can decide to display data on the screen in one of four ways:

• In Normal, or line mode where commands are entered after the READY prompt orafter messages sent by a transaction.

• In Format mode, where data is entered on screen-based forms or menus.

• In windowing mode using FORMS.

• Using IMAGEWorks (multimedia product) on a PC (Personal Computer).

In addition, the Terminal Adapter facility allows the TDS Programmer to modify a userprofile. When the Terminal Adapter is used, external messages can be sent to an activeform, or to the status line (the bottom line of the screen). To use this facility, theprogrammer must add the TA procedures to TPRs, and the administrator must modifythe TDS Generation Program. For more information on the Terminal Adapter, see theTDS Administrator's Guide and the TDS COBOL Programmer's Guide.

Regardless of the mode selected, an end-user can issue commands or starttransactions from a terminal.

When issuing commands, the user enters each command after the "READY" prompt.Commands available to an end-user include displaying the list of message identifiers, re-displaying the last message, or connecting to another TDS application. The charactersused to perform these actions must be defined by the TDS administrator.

When transactions are running, the user can only communicate with the transaction.When the transaction is completed, the user can issue another transaction, or acommand. The user terminal is notified when a transaction ends normally when eitherthe last message sent, or the service message "READY" is displayed.

Normal mode:

The TDS programmer prepares Normal mode by writing SEND and RECEIVE verbs inTPRs. In Normal mode, end-users can enter commands after the "READY" (or a sitespecific prompt), or after messages sent by the transaction being executed. (Theprogrammer can modify the "READY" prompt according to site specifications). In thismode, data is entered one line at a time.

TDS Concepts

3-16 47 A2 26UT Rev00

Format mode:

In format mode, a form or menu appears on the screen. A form is a set of text blockswith blank spaces, or input fields, where the end-user enter information at the screen.The TDS programmer uses the FORMS facility to create and add forms to anapplication.

A TDS application accepts data via forms, processes the forms, accesses and updatesthe database, and output reports in the same manner as data entered in Normal mode.A transaction activates a form, processes it, and then returns an updated form to theterminal. The output form may be either an update to the input form, or it may be anentirely new form.

When forms are used in a application, the accuracy of data entered can be checked todetermine whether the data is within the allowed parameters. This is usually theminimum and maximum values allowed for the given transaction. Forms can alsosupply help and error messages (for example, indicating that an incorrect value isentered) for each input field.

Figure 3-8 shows a simple customer form.

STOCK PURCHASE

CUSTOMER NUMBER : #######

STOCK QUANTITY DESCRIPTION PRICE TOTAL##### ######## # # # # # # # # # ####

CONFIRMATION: #

Figure 3-8. An Example of a Form


47 A2 26UT Rev00 3-17

IMAGEWorks Windowing mode:

On a system with IMAGEWorks, an end-user can access multimedia services fromwithin the TDS application. IMAGEWorks emulates a TDS terminal in a window on PC.A TPR can open other windows through IMAGEWorks, to display lists or documents.

D P S 700 0 D P X /2

TD S IM A G E W orks

A ff in ity O p e nTeam

Figure 3-9. Using TDS with IMAGEWorks

When IMAGEWorks is used, the application can be displayed in either Normal or Formatmode. IMAGEWorks allows a TDS application to interact with a DPX so that an end-user can get information from either system.

3.2.2.7 Handling Reports

The Generalized Terminal Writer (GTWriter) allows any hardcopy terminal in acommunications network to be used as a printer. Any TDS user can request thatoutputs or files be printed at any terminal known to GTWriter.

To use this utility, the TDS Programmer must add the GTWriter procedures to TPRs.For more information on these procedures, see the TDS COBOL Programmer's Guide,or the Generalized Terminal Writer User's Guide.

TDS Concepts

3-18 47 A2 26UT Rev00

3.2.3 Fitting the Pieces of the Application Together

The TDS Administrator puts the different parts of the TDS together by first generatingthe network, running the TP7PREP utility to produce the TDS files, then running theTP7GEN utility to create the TDS load module.

The TDS Programmer compiles the source TPR code segments (producing the compileunits), and then links them (see Figure 3-10).

Using the SYSMAINT utility, the TDS administrator loads all sharable modules intobacking store.

When the TDS is running and transactions are activated, code segments are swappedinto main memory from these sharable modules when required. In other words TDSfinds the desired TPR in backing store and brings it into main memory for execution.


47 A2 26UT Rev00 3-19

G e ne ra te N etw o rkan d lo ad in

B ack ing S tore(C R N E TG E N )

P re pare f ile s(TP 7P R E P U tility)

W rite S ourceP rog ra m(S TD S )

TD SF iles

G e ne ra te TD S(TP 7 G E N U tility)

C O B O LTP R s

TD S loa dm odu le s

C om pilethe TP R s

O p era tio na lTD S A pp lic a tio n

B ack in gS tore

R un S YS M AIN TU ti lity

S h arab lem od ule

(S M )

R un L IN K E RU ti lity

C om p ileU n its(C U s)

Figure 3-10. Assembly TDS

TDS Concepts

3-20 47 A2 26UT Rev00

Figure 3-10 shows how the TDS must be assembled. The steps to be followed are givenin the order, though steps 4 and 5 can be done simultaneously.

1. The TDS Administrator or System Administrator generates the network using theCRNETGEN utility.

2. The TDS Administrator allocates the TDS files by running the TP7PREP utility.

3. The TDS Administrator writes the source program (STDS).

4. The TDS Administrator executes the TDS Generation Program by running theTP7GEN utility. This utility produces: LINKER command files for linking TPRs, andthe TDS load module.

5. The TDS Programmer writes TPRs and stores them in a source library.

6. The TDS Programmer compiles the source TPRs. The input library(<tdsname>.COBOL) contains the file definitions and storage areas described inthe Generation Program.

7. The TDS Programmer stores the compile units in the CULIB library.

8. The LINKER, using the command file produced at TDS generation, links the TPRs.

9. The LINKER stores the resulting linked units in a TPR sharable module (SM)library. There can be several TPR SMs in the same library.

10. The TDS Administrator uses the SYSMAINT utility to load the TPR sharablemodules into backing store.

The TDS application is ready to be used.

3.2.4 Later Modifications to a TDS Application

Once the application is running, the administrator or the programmer may need to makemodifications or updates to the TDS due to errors, changing requirements, or newdevelopements.

A TDS application that is properly implemented will need fewer modifications than onethat is poorly implemented. Depending on the nature of the revisions, the programmeror administrator can make changes at two levels:

• Clauses in the TDS generation program can be changed at any time. The onlyrequirement is to that the TP7GEN utility must be re-run for the clauses to becomepermanent. Be aware that changing or inserting a clause in the TDS generationprogram can require that other changes be made. Any TPRs affected by new clausesmust be recompiled, relinked, and reloaded into backing store.

• TPRs can be modified and then recompiled, relinked, and reloaded. The TDSGeneration Program (the TP7GEN utility) does not need to be re-executed whenTPRs are modified.


47 A2 26UT Rev00 3-21

3.3 RUNNING A TDS APPLICATION

After the Administrator and Programmer create the application, the Master Operator canstart the TDS, and then End-Users can log on to the application.

3.3.1 Master Operator Duties

The master operator is the user that is responsible for controlling a running TDSapplication. Once the master terminal operator logs on to the TDS application, end-users can connect to the application. Furthermore, the master operator is responsiblefor these tasks:

• starting the TDS application• opening and closing files• performing restarts after failures• stopping the TDS application.

In addition, the master operator can use a special set of commands known as themaster commands which allow this operator to control a running TDS application.Master commands can be used to modify or display information about the application.For more information on these commands, see the TDS Administrator's Guide.

TDS Concepts

3-22 47 A2 26UT Rev00

3.3.1.1 Starting a TDS Application

A session is the duration of an activity. A GCOS 7 session starts when the system isloaded (the GCOS READY message appears). The communications session startswhen the Main Console operator enters the required command. Finally, a TDS sessioncan be started by the master operator from the system console or any terminal. Therecan be up to 5000 connected (end-user) sessions on any TDS. These different sessionsare all required in running a transactional application.

Figure 3-11 shows the relationship of the different types of sessions.

G C O S 7 S ess ion

Te lecom m unica tio ns S ess ion

TD S S ess ion

T im e

U ser S ess ion 1 U ser S ess ion X ...

Figure 3-11. Different Types of Sessions

To start a TDS application, the master operator by enters the GCL commandENTER_JOB_REQUEST (EJR) specifying the name of the TDS application. The JCLfor activating a TDS job is described in the TDS Administrator's Guide.

Once a TDS session is started, TDS operations are under control of the masteroperator, who can issue privileged (master) commands. Any terminal in the network canact as the master as long as the master operator is connected to it. All other terminals inthe network are known as user terminals. User terminals must log on in order to starttransactions.

Associated with the concept of master operator is the idea of a mailbox. In TDS, amailbox is a data structure reserved for the user who controls the TDS session.

• If the master mailbox is defined by the TDS administrator when the TDS is generated,then the first terminal with the correct access rights in the network to connect tothis master mailbox becomes the master operator. No other user can log on to thatTDS application until the master operator is logged on.

• If a master mailbox is not defined by the TDS administrator, the user who submitsthe TDS job automatically becomes master.

For example, when the TDS job is submitted from any user terminal and a mastermailbox is not defined by the administrator, the first terminal that logs on becomes themaster operator as shown in Figure 3-12.


47 A2 26UT Rev00 3-23

LO G O N

M aster O p era tor(M aster C om m ands)

LO G O N LO G O N

S yste m or IO FC on so le

(G C L com m ands)

TD S A pp lica tio n

G C O S 7

Figure 3-12. End-User Terminal as Master Operator

TDS Concepts

3-24 47 A2 26UT Rev00

However, if the TDS job is submitted from the System Console or an IOF terminal, theconsole or terminal becomes the master mailbox as shown in Figure 3-13.

+(M a ste r C om m an ds)

S ta rt TD S S ystem or IO FC o nso le

(G C L com m and s)

TD S A pp lic a tio n

G C O S 7

Figure 3-13. System Console or IOF Terminal as Master Mailbox

3.3.1.2 Using the Programmed Operator to Control a TDS

A program can be written using the Distributed Operator Facility (DOF 7-PO) whichallows a TDS application to be automatically controlled by a Programmed Operator. AProgrammed Operator can control several TDS applications simultaneously.

This facility manages exchanges, responses, or unsolicited messages using servicessuch as data enqueuing and addressee notification. For more information on theProgrammed Operator, see the DOF 7-PO User's Guide.


47 A2 26UT Rev00 3-25

3.3.1.3 File Opening and Closing

After a TDS session is started, all files defined in the TDS Generation Program areautomatically opened. However, the files can be closed and re-opened dynamically bythe master operator using the master commands. At the end of a TDS session, all filesare automatically closed.

3.3.1.4 Restarting After Failure

The master operator must intervene when an incident occurs that prevents an end-userfrom successfully executing transactions.

If a user session is abnormally interrupted without the user having entered BYE (loggedoff), the user is "frozen" and cannot enter any commands. Interruption can be causedby:

• disconnected terminals• system crashes• abort of the TDS (due to a system failure or by master operator command)• incident on communications network.

The master operator must determine why the incident occurred and then restart theTDS.

3.3.1.5 Stopping a TDS Application

The master operator can log off without affecting end-users who remain logged on to theTDS application. However, the master operator can stop a TDS application, by issuingthe TERMINATE_TDS command and specifying whether other users are to be loggedoff or not.

In normal operations, the master operator allows current users to log off when they havefinished the transactions in progress. This message is displayed on the end-userterminals:

tdsname SHUTDOWN

When the master operator performs an immediate shutdown (the STRONG option isspecified in the TERMINATE_TDS command), all user transactions in progress areaborted.

TDS Concepts

3-26 47 A2 26UT Rev00

3.3.2 End-User Duties

The end-user session starts when the terminal operator logs on via a terminal to theTDS application. An end-user session is all activities performed by a given user,including the TDS responses, from the time the user logs on until the user logs off aspecific TDS application. An end-user can have several sessions during any one TDSsession.

3.3.2.1 Starting an End-User Session

To log on to a TDS application, a user enters the following at a terminal:

$*$ CN <Name of a TDS application>

When a TDS user logs on to TDS, the system verifies whether or not the user is allowedto log on to TDS by checking that the user is listed under a project that can access theapplication. When the logon is successful, the "READY" prompt (or the application'sequivalent) appears on the screen. At the logon, unknown users, duplicate users (thatis, users who are already logged on), or users with incorrect passwords are rejected.The TDS administrator can also set up an automatic logon facility that allows a terminalto be automatically logged on to a TDS application as soon as the terminal operator logson to GCOS.

3.3.2.2 Starting Transactions

An end-user connected to a TDS application can enter a transaction code (message-id)to activate a transaction and thus start application processing. The message-id must beone of those defined by the TDS administrator when the application is prepared. Amessage-id can be up to eight characters long, can be followed by a space, and caninclude the parameters expected by the transaction.

If a user enters a message-id that is not valid in the TDS application, "UNKNOWNTRANSACTION" is displayed at the terminal. End-users can activate only thosetransactions which the TDS administrator has authorized them to use.

In Transaction mode, an end-user can interrupt a transaction that is currently executingby pressing the BREAK key or by entering $*$BRK. The resulting actions depend onhow the TDS administrator has set up the TDS application. Usually, sending a BREAKin command mode has no impact other than the sending of a "READY" message.However, if a BREAK command is sent from a passive terminal, the terminal is reset toactive. For more information on active and passive terminals, see the section"Correspondents" in the chapter "Designing and Optimizing a TDS Application".


47 A2 26UT Rev00 3-27

3.3.2.3 Terminating an End-User Session

When a transaction completes execution, it returns a status to the terminal. The user istold when the transaction is completed, but remains logged on to the TDS application.The user can either start another transaction or log off from the terminal.

When all his/her TDS activities are finished, the end-user can terminate the session byissuing the BYE command. The BYE command prevents other end-users from loggingon to someone else's end-user session. In addition, the master operator can force anend-user to log off.

Figure 3-14 shows the sequence of events of an end-user session.

TDS Concepts

3-28 47 A2 26UT Rev00

m essage -id

rep lyG C O S 7

TD S

rea dw rite

com m itsen d

.

.

.

N etwork

T ransaction is p rocessed

Figure 3-14. Sequence of Events when a Transaction is Submitted

47 A2 26UT Rev00 4-1

4. Designing and Optimizing a TDSApplication

This section focuses on concepts that the TDS Administrator must be familiar with todesign an efficient application.

• simultaneity• non-concurrency• spawning• mapping• correspondents• communications protocols• security functions.

TDS Concepts

4-2 47 A2 26UT Rev00

4.1 CONTROLLING THE RATE AND AMOUNT OF DATA PROCESSED

In GCOS 7-V6, a TDS application can have up to 2000 transactions. TDS applications,such as those used in banking, airlines, or inventory control, must support a high volumeof transactions. In large applications, many transactions run simultaneously.

In applications where many transactions run simultaneously and files are accessible toall users, concurrent access to the files must be controlled. Controlling access to filesensures that data remains logically consistent. The TDS administrator controls accessto files and resources by specifying the SIMULTANEITY, NON-CONCURRENT, andUNMAPPING clauses in the generation of the application.

• The simultaneity level determines the maximum number of TPRs that can beexecuted simultaneously.

• Non-concurrency prevents specified transactions from being run simultaneously. Thisis used to avoid resource conflicts and prevents concurrent access to non-controlledfiles.

• Unmapping releases resources held by transactions being processed.

Designing and Optimizing a TDS Application

47 A2 26UT Rev00 4-3

4.1.1 Simultaneous Transactions

The TDS Administrator can control the number of simultaneous transactions byspecifying a simultaneity level in the TDS Generation Program. This clause allows theadministrator to specify the maximum number of processes available to handle TPRs,and thus defines the maximum number of TPRs that can execute concurrently. In V6,the maximum number of TPRs that can be executed concurrently is 140.

A simultaneity level of 1 does not protect files from concurrent access. Although onlyone TPR can be processed at a time, several transactions can be active, and theirrespective TPRs are simultaneous.

Figure 4-1 shows that two TPRs of two transactions are active and try to access thesame resource.

Transaction - A Transaction - B

TPR A 1R E AD R

TPR A2W R ITE R

TPR B1R EAD RW R ITE R

T im e

Figure 4-1. Simultaneity Level of One

Even though the level of simultaneity is 1, TPRA1 can read a record, then TPRB1 canread and rewrite the same record before the record is written by TPRA2. The filereflects only the update performed by Transaction A.

To prevent this type of problem, the TDS Administrator can specify that certaintransactions be non-concurrent, as described below.

TDS Concepts

4-4 47 A2 26UT Rev00

4.1.2 Non-concurrent Transactions

The TDS Administrator can declare transactions as non-concurrent with (a list of) othertransactions at the TDS generation. By specifying transactions as non-concurrent, theTDS Administrator:

• avoids resource conflicts which reduce system performance• prevents concurrent access to (TDS) non-controlled files.

In a TDS application, many tasks are independent and can be performed at the sametime (or concurrently) by separate transactions. For example, several users canconcurrently read or update data in a TDS application. However, sometimes it isadvantageous to complete tasks one step at a time. This is done by declaringtransactions to be non-concurrent, or specifying non-concurrency.

Non-concurrency prevents the commitment units of TPRs from being run simultaneouslywhen there is a risk of resource conflicts or even deadlocks. Non-concurrency allowsTDS to handle these conflicts automatically, but at the expense of system performance.As far as performance is concerned, it is more efficient not to declare file non-concurrent, but to use TDS-controlled files protected by GAC-EXTENDED.

The non-concurrency feature can be controlled automatically or manually depending onthe choice made in the TDS Generation Program.

• If the non-concurrency control is automatic, TDS automatically locks out the non-concurrent transactions at the commitment unit level. That is, as soon as a non-concurrent transaction starts to execute, any transactions declared non-concurrentwith the initial transaction are not permitted to execute until the end of the commitmentunit.

• If the non-concurrency is manual, the TDS Programmer can decide when and wherenon-concurrent transactions occur by switching the protection on and off.

Running a transaction non-concurrently with one or more other transactions is requiredto prevent concurrent access to non-controlled files. When transactions are allowedconcurrent access (that is, not declared non-concurrent), the way a resource conflict ishandled depends on whether the file is controlled by TDS or not. On TDS-controlled file,if two TPRs try to update the same record, the commitment unit can be aborted. In thecase of non-controlled files, one of the updates can be lost.

Figure 4-2 shows Transaction-1 and Transaction-2 competing for access to Record-R.While Transaction-1 is accessing Record-R, it has complete control over the record.Meanwhile, Transaction-2 is also trying to gain control of the record. Transaction-2 isactivated just after Transaction-1, but cannot start executing until the commitment unit inTransaction-1 ends.

When the administrator specifies non-concurrency, each commitment unit of thetransaction is executed non-concurrently. That is, Record R-is accessed first by thecommitment unit of Transaction1 and then by the commitment unit of Transaction 2.


47 A2 26UT Rev00 4-5

activ a tion

Transa c tio n-1 Transac tion -2

ac tiv a tion

w aiting

wait ing

C om m itm entU n it

Tx1 accessesR ecord-R

Tx2 accessesR ecord-R

Tx1 accessesR ecord-R C om m itm ent

U n it

C om m itm ent U n it

C om m itm entp o in t

T im e


Figure 4-2. Transactions Specified as Non-Concurrent

TDS Concepts

4-6 47 A2 26UT Rev00

Even when a commitment unit corresponds to several TPRs, as shown in Figure 4-3,there is no danger of corrupting files because all processing performed by the firsttransaction is completed before the second transaction can access the record.


TP R A 1

TP R A 2

TP R A 3

TP R B 1

Transac tion - A Transa ctio n - B

T im e

W aitin g

Figure 4-3. Commitment Units of Non-Concurrent Transaction

In this example, TPRA1 reads a non-controlled file and TPRA2 rewrites updated data toit. After this modification is made, TPRB1 can read and rewrite the same file.


47 A2 26UT Rev00 4-7

4.1.3 Mapping and Unmapping Resources

In a TDS application, there are general-purpose control tasks used simultaneously byseveral transactions. (A task is a set of system resources necessary for executing asequence of code). These tasks correspond to physical "processes" in the GCOS7meaning of the term, and are the processes used to execute TPRs.

To process a transaction, TDS allocates one of these control tasks to a TPR and thenexecutes the TPR. The allocation of a control task to a TPR is called mapping . At theend of the TPR, TDS determines whether a commitment is to be taken and whether thecontrol task is released. When the control task is released, the TPR is unmapped andthe control task can be used by another TPR. Note that mapping is done at thebeginning of a TPR and unmapping is done at the end of a TPR.

When a TPR is unmapped, its context (or information about the TPR and its currentstate of execution) in the session is saved so that it can be restored later to be used bythe next TPR. The context of a TPR is saved in a swap file. If the following TPR needsto read the context of the preceding TPR, it accesses and then reads the swap file.

Figure 4-4 shows two transactions. The TPRs of the first transaction are unmapped, inthe second transaction the resources are not unmapped, or are declared as having "NOAUTOMATIC UNMAPPING".

TDS Concepts

4-8 47 A2 26UT Rev00

TP R a TP R x

P ro cess 1 P rocess 2 P roce ss 3

TP R b TP R y

after - TP Rw rite to S w ap

befo re - TP Rread from S w ap

after - TP R

b e fore - TP R

A U TO M A TIC U N M A PP IN G N O A U TO M A TIC U N M A P P IN G

S w a pfi le

Figure 4-4. Unmapping versus No Automatic Unmapping

The use of the swap file (in unmapping) increases the number of input/output operations.However, when TPRs are not unmapped, response time can be increased due toqueues of TPRs waiting for tasks.


47 A2 26UT Rev00 4-9

Unmapped transactions occupy a control task only when a TPR is executing. The TPRreleases the task when a conversation is started. Unmapping allows a few control tasksto serve a large number of transactions, running almost in parallel.

The TDS Administrator can specify that unmapping occur systematically at the end ofeach TPR, or that automatic unmapping is suppressed. When TPRs are not unmapped,the I/O overhead is reduced because there is no need for saving the transaction contextbetween TPRs. This is particularly significant for transactions composed of many TPRs.Although specifying "NO AUTOMATIC UNMAPPING" improves the performance ofcertain transactions, this clause can reduce the overall performance of a system.

TDS Concepts

4-10 47 A2 26UT Rev00

4.2 COMMUNICATION BETWEEN CORRESPONDENTS, APPLICATIONS,AND OTHER GCOS 7 PRODUCTS

TDS applications can exchange information with applications and users of other TDSapplications.

This section explains:

• Types of Correspondents.

• Spawning.

• Communication protocols used for dialogs inside the same TDS and/or between TDSand IBM, or IBM-compatible applications, and the protocols used for transactionprocessing on UNIX.


47 A2 26UT Rev00 4-11

4.2.1 Correspondents

Definition of Correspondent:

A correspondent is simply an "object" that a TDS application can "talk to". The "object"can be a terminal (or the end-user logged onto it), a "virtual" correspondent, a "dummy"correspondent, or even an application. Correspondents must be defined in the TDSGeneration Program so that TDS can establish the necessary connections. However,correspondents that initiates a connection to TDS, as a terminal does, do not need to bedeclared at TDSGEN.

Terminal Correspondent:

In general, correspondents (terminals) are linked to TDS when the correspondent logson. However, certain correspondents such as printers can be automatically assigned.Applications are connected to TDS when requested by the master operator.

The master operator is the correspondent in charge of the TDS application. Like anyother user, the master operator correspondent can start transactions.

Correspondents which are terminals can operate in either active or passive mode.

• A terminal in active mode can initiate transactions and can use a wide range offunctions.

• A terminal in passive mode cannot be used to start transactions. Messages can besent to the terminal, or transactions can be activated for it from elsewhere. A passiveterminal can take part in conversations but is not set input mode when the transactionterminates.

A passive terminal is often a terminal without a keyboard, but can also be an activeterminal set to passive by the TDS programmer. The programmer can set a terminalwith a keyboard to passive mode by sending a specific TPR.

Application Correspondent:

Access to a correspondent which is an application requires the use of a communicationsprotocol (see the paragraph "Protocols for Communication between Correspondents" inthis chapter).

TDS Concepts

4-12 47 A2 26UT Rev00

4.2.2 Spawning New Tasks from within a Transaction

Starting a new transaction from within a transaction is called spawning . In spawning,one correspondent starts a transaction on behalf of another correspondent from anactive transaction. The transaction that activates the operation is known as thespawning transaction and the transaction that is started is known as the spawnedtransaction.

Once a transaction is spawned, its execution is independent of the transaction thatactivated the spawning. Spawned transactions are placed in queues and activated whenthe correspondent on which the spawned transaction is directed, becomes idle. Aspawned transaction is validated when the commitment unit in which the spawning isperformed ends normally.

Spawning can be used when a transaction needs access to facilities (such as printers)which the transaction cannot start. Spawning can also be used to start a transaction at aspecified time in the future, or to run a transaction using different priorities than the onesinitially requested. A transaction spawned to a dummy correspondent can only retrievetransaction parameters; it cannot send information to the dummy correspondent.

Figure 4-5 shows a simple example of spawning. In this example, Transaction-Aspawns Transaction-B to user X. Transaction-B can be executed immediately, after aspecified time interval, or at a specified time of day depending on the requirements ofTransaction-A.

The CALL "SPAWN" statement is executed at time t2, but is not validated until time t3.Transaction-B remains in the spawning queue between time t3 and time t10. During thisperiod, Transaction-0 (TX0) is executed for user X. At time t10, Transaction-B isexecuted for user X.

The starting time of Transaction-B is not dependent on the finishing time of Transaction-A, unless the correspondent of Transaction-A is the same as the correspondentassociated with Transaction-B.


47 A2 26UT Rev00 4-13

Tim e

t10

U S E R AM E S S AG E-ID

C A LL "S P A W N "(Tra nsaction B ,

u se r X )

S PA W N IN G Q U E U E

B

TX 0

TX B

TX 0

C om m itm ent

TR A N S A C TIO N B U S ER X

t0

t1

t2

t3

t4.....

TR AN SA C TIO N A

P R O C E SS IN G

Figure 4-5. Spawning Transactions

TDS Concepts

4-14 47 A2 26UT Rev00

4.2.3 Protocols for Communication between Correspondents

Users communicate with TDS or with an application during a communications session ,which is a structured dialog. Applications can also communicate with each other. Apredefined structure is necessary so that these dialogs are standardized. Protocols arethe set of communication rules between two correspondents of a communicationsessions that provide this standardization.

TDS can use these communication protocols:

• the Terminal Manager (TM) Protocol• the Pass Through (PT) facility• the Extended Communication Protocol XCP1• the Extended Communication Protocol XCP2.

4.2.3.1 The TM Protocol

The Terminal Manager (TM) protocol is a facility used to manage the communicationbetween a terminal or group of terminals and a correspondent. (A correspondent can beanother terminal or an application with which the session is established.) The TMtranslates application data to the format defined for the terminal.

There must be a logical connection between the TM and the correspondent. Theinformation necessary for this connection is declared by the administrator during thegeneration of the communication network.


47 A2 26UT Rev00 4-15

4.2.3.2 TCAM and TDS Pass-Thru capabilities

The TDS Pass-Thru facility allows a TDS end-user to log on to remote applicationwithout requiring the user to log off the active TDS host session. (A host session is theinitial TDS application to which the user logged on.) The remote application can beanother TDS application (in the same room or on another site), or IOF.

The TDS Communications Access Method (TCAM) opens the TDS Pass-Thru session,or logical link, between the user and the application. TDS creates this link at the time ofthe connection. Figure 4-6 shows a user with two sessions: the principal session andthe TDS Pass-Thru session. Only one TDS Pass-Thru session can be open at a time.

After issuing the TDS Pass-Thru command, the user begins works directly under theremote application(s) to which he or she is connected, not under the initial TDSapplication. To return to the initial TDS application, the user must log off from theremote TDS application.

Figure 4-6 shows a TDS Pass-Thru (PT) session.

E nd -U ser

P T

TD S Y

IO F

B YE

P T TD S Z

Loca lTD S

R em ote A p p lica tion s

B YE

P T

P ass-ThruS ess ion

Figure 4-6. Using Pass-Thru to Connect to Remote Applications

TDS Concepts

4-16 47 A2 26UT Rev00

4.2.3.3 The XCP1 Protocol

The Extended Communications Protocol (XCP) family of protocols that allow users tolink to other applications for inquiry and modification. The applications do not have torun on GCOS 7, but can be on any operating system as long as XCP1 is supported.

XCP1 provides compatibility with IBM's LU0 (CICS) and LUP (IMS) protocol. The XCP1protocol allows applications to exchange messages with these other applications. TDSimplements XCP1 and can therefore communicate with other applications that supportthis protocol.

XCP1 allows data to travel back and forth between applications running on either local orremote systems. ("Remote" means either in the same room, or at another site).Cooperation takes place at application level and not at correspondent level. In otherwords, a correspondent can run several applications cooperating through the XCP1protocol.

When TDS dialogs with an IBM-compatible application, TDS functions as the front-endapplication, and IBM as the back-end application. That is, a GCOS 7 transaction canstart the IBM application, but the IBM application cannot start a GCOS 7 transaction.

L oca lTD S

TD S 1 TD S 2

TD S 3

IM S

G C O S 7

Figure 4-7. An XCP1 Communications Session


47 A2 26UT Rev00 4-17

Figure 4-7 shows how a TDS application using the XCP1 protocol communicates withanother application over the communications session. A transaction started by the end-user and executed in the user's local TDS application works with transactions in fourdifferent applications:

• TDS1• TDS2• TDS3 (on a remote site)• an IMS application in an IBM environment.

When two correspondents dialog over an XCP1 session, one is the primarycorrespondent and the other is the secondary correspondent.

To use the XCP1 protocol in a TDS application, the TDS programmer must designtransactions the XCP1 CALL statements. Then the TDS Administrator must modify theTDS environment during the preparation of the application. For more information onTDS and XCP1, see the Transactional Intercommunication Using XCP1 Protocol User'sGuide.

TDS Concepts

4-18 47 A2 26UT Rev00

4.2.3.4 The XCP2 Protocol

The XCP2 protocol, is part of the Extended Communications Protocol (XCP) family ofprotocols which allow application to application communication.

In the case of XCP2, this communication permits the management of distributedtransactions and the exchange of messages.

The support by TDS of the XCP2 protocol enables a TDS application to dialog with thefollowing:

• another TDS on the same system or another system,

• an IBM application using the IBM System Network Architecture (SNA) Logical Unittype 6.2,

• any platform where a "transactional like" subsystem using an XCP2 protocol exists(for example, a Bull DPX system with the CPI/C-OSI product).

Figure 4-8 shows an XCP2 Communications session.

loca l TD S

TD S 1 TD S 2

TD S 3

C P I-C /O S IA p p lica tion

G C O S 7

LU 6 .2A p p lica tion

R em ote G C O S 7

IB M S yste m

D P X S ys tem

C IC S

Figure 4-8. An XCP2 Communications Session


47 A2 26UT Rev00 4-19

In the transactions, the TDS programmer uses either the X/Open CPI-C programminginterface, or the Bull PPC-PI programming interface. The TDS Administrator has to setup a specific TDS environment for CPI-C/XCP2. For more information on XCP2, see theCPI-C/XCP2 User's Guide.

An interesting feature of XCP2 is that any of the partners (applications) can initiate aremote transaction.

TDS Concepts

4-20 47 A2 26UT Rev00

4.3 INTERACTION WITH UNIX WORLD

2LTP (Two Level Transaction Processing):

It is possible to connect to a TDS application from an MS-DOS application or a UNIXworkstation. TDS sees the application as a terminal. See the Affinity and OTMdocumentation.

CTP (Cooperative Transaction Protocol):

The CPI-C application programmatic interface ("API") supports the XCP2 protocol (at"confirm" level) and allows communication between a TDS application and a BOS/TPapplication. See the CPI-C Programmer's Guide.

HOST 7 is a function based on CPI-C which allows you to invoke a TDS transactionthrough the normal BOS/TP "API". This feature is available only after Technical Status6152.


47 A2 26UT Rev00 4-21

IMAGEWorks:

There is an "API" which enables a TDS transaction to manipulate an IMAGEWorksdocument. See the TDS-IMAGEWorks Link User's Guide.

Figure 4-9 shows TDS in the UNIX world.

TD S

C P I-C c f

2 L TP C TP

G C O S 7

U N IX S e rv e r

B O S /TP

C P I-C c f

O TM

C TP =2L TP =

c f =ss =

O TM =

C o -o p erativ e Tra ns ac tion P ro ce ssingT w o L ev e l T ra ns ac tio n P ro ces s ingC o nfi rm S e tS ta rte r S etO p en Te rm in al M an ag er

A pp lica tio n P rog ra m m a tic Inte rfa ce}

/H O S T 7

C P I-C ss

/H O S T 7

Figure 4-9. TDS in the UNIX World

TDS Concepts

4-22 47 A2 26UT Rev00

4.4 ACCESS AND ORGANIZATION OF DATA IN TDS

A TDS application can simultaneously access ORACLE data, IDS/II databases, andUFAS files. A TPR can update either an ORACLE database, or IDS/II and UFAS data.

The data used in a TDS application can be organized in any of these databases:

• IDS/II• IQS• ORACLE

4.4.1 IDS/II and TDS

Transactions within TDS can access IDS/II databases. The IDS/II areas have to bedeclared in the source of the TDS Generation. Schemas and sub-schemas can be used.Areas of IDS/II are UFAS controlled files and follow the usual integrity rules. See theparagraph on "TDS Controlled Files" in chapter 2 and the IDS/II documentation.

4.4.2 Using IQS with TDS

IQS queries can be executed in a TDS environment. Such queries can access IDS/IIand UFAS-EXTENDED databases for which IQS schemas and/or views have beendefined.

IQS queries can use object macros, forms, formats, and reports under TDS, just asunder IOF. These can be loaded explicitly by the master operator for use by all users, orimplicitly by IQS when used by a query (and thus are private to the user).

After the IQS queries are compiled, they are linked to create an object TPR. Atransaction can consist of a mixture of COBOL TPRs and IQS queries. However, nodata can be passed between TPRs and queries.

After the queries are written by the TDS Programmer, the TDS Administrator mustdeclare IQS views, schemas, files, and areas in the TDS Generation Program. Inaddition, the administrator must specify the <tdsname>.GMEM file in the TDSpreparation. For more information on using IQS with TDS, see the IQS-V4/TDS User'sGuide.


47 A2 26UT Rev00 4-23

4.4.3 ORACLE and TDS

ORACLE databases can be used with TDS. Several TDS applications can share anORACLE database, and can access the database simultaneously. The database mayreside on the same (local), system or on a remote GCOS 7 system

In ORACLE/TDS, the TDS programmer writes COBOL TPRs which contain embeddedSQL statements that access ORACLE databases. TPRs written in C Language are notsupported.

The ORACLE server runs independently of the TDS application. ORACLE databaseshave their own log file and rollback segments, and all maintenance is handled byORACLE tools.

The TDS Administrator must declare the database in the TDS Generation Program. Forinformation on using ORACLE databases with TDS, see ORACLE-V6/TDS User'sGuide.

TDS Concepts

4-24 47 A2 26UT Rev00

4.5 PRODUCTS USED WITH TDS TO PROVIDE ADDED INTEGRITY &SECURITY

Several GCOS 7 products, offered as options, can be used in a TDS environment toimprove system security. Using this products minimizes the impacts of hardwareincidents, software failures, or unauthorized access attempts. These GCOS 7 optionsare:

• TDS-HA• Mirror Disks• RDDF7• SECUR'ACCESS.

4.5.1 TDS-HA

The purpose of High Availability, or HA, is to increase the time that applications areavailable, and reduce the impact of incidents on applications. TDS-HA is the GCOS 7product that provides TDS users with this continuous service. TDS-HA increases theavailability of TDS applications when hardware or software incidents occur. TDS-HA canbe implemented on one or more TDS applications on a site (with 2 systems); thus TDS-HA can co-exist with non-HA applications such as TDS or IOF. TDS-HA can useORACLE and UFAS/IDS/II databases.

The TDS-HA product:

• reduces restart time after a crash• restarts all transactions from the last commitment point• provides a backup system in case of incidents• performs system recovery and reconnection simultaneously• reconnects all users connected before the incident• is based on coupled systems• supports Mirror Disks• recovers journalization files.

During operation, a TDS application is tracked by a back-up TDS operating on aseparate processor. If a failure occurs, the system switches processing from the activeto the back-up TDS. The back-up TDS takes over the session and continues normalprocessing.

For more information on high availability, see the High Availability Concepts and the HighAvailability Administrator's Guide.


47 A2 26UT Rev00 4-25

4.5.2 Mirror Disks

Mirror Disks is a GCOS 7 product that offers high availability of data stored on disks. Byincreasing the availability of disk based data, Mirror Disks provides continuous service ofdata to applications.

Mirror Disks can provide this availability by maintaining two copies of data; each copy isstored on a separate disks. Each disk has a disk which is its mirror image, or copy.Every write operation generates two write, one to each copy. If one copy is lost, theother copy is still available. When a failure that effects disks or controllers occur, MirrorDisks allows application to continue normal processing using the other copy.

Mirror Disks can be used on mono or coupled systems, and on systems running TDS-HA. This option can be applied to selected disks, or all disks on a system. Mirror Disksrequires additional disks. Every disk declared as a Mirror Disk must have an identicalback-up copy.

For more information on data availability, see the Mirror Disks User's Guide.

4.5.3 Protecting Databases with RDDF7

The Remote Database Duplication Facility, RDDF7, allows a backup machine tomaintain a copy of ORACLE databases on GCOS 7. RDDF7 can be used with TDS,IOF, or batch transactions.

While a TDS application is running and the database is updated, RDDF7 transfers AfterJournal images to the backup machine. The after images are applied to a duplicatecopy of the database. The duplication of updates is deferred on the remote site. TheRDDF7 software ensure the consistency of data between the two sites.

If the main machine fails, TDS can be started up on the backup machine using theduplicate database. When the main machine is restarted, the after images can betransferred to the restored system.

For more information on improving the availability of databases, see the RDDF7/RTOUser's Guide.

TDS Concepts

4-26 47 A2 26UT Rev00

4.5.4 SECUR'ACCESS

SECUR'ACCESS is a logical access control software that can be used to protect atransactional application. This software identifies, authenticates, and then authorizesuser to connect or re-connect to the application. These controls can also beprogrammed to verify user access at any moment during a work session.

For more information about using SECUR'ACCESS with TDS, see these documents:

• SECUR'ACCESS Security Administrator's Guide• SECUR'ACCESS Delegate Administrator's Guide• SECUR'ACCESS User's Guide• SECUR'ACCESS Programming and Implementation Guide.

47 A2 26UT Rev00 g-1

Glossary

Any words appearing in bold in the text of a definition are explained in the glossary.

Access rights:

A list of codes declared for each GCOS 7 project which allow (or prevent) users toaccess disks, applications, environments, or stations. These access rights are declaredat the site level and should not be confused with TDS authority codes which concern theaccess of a TDS transaction.

Administrator:

see TDS Administrator.

After image:

The copy of an update to a file, recorded on an After Journal, used to recover files in thecase of a rollfoward .

After Journal:

A GCOS 7 function that protects against hardware failure. This journal is used to storeupdates (after images) to be written to a file or a database.

Authority codes:

A list of codes which allow or prevent users from executing a given transaction withinTDS. As in other GCOS 7 applications, all users belong to one or more projectsdeclared in the site catalog. Authority codes are also declared in the site catalog andallocated to projects. Thus, through the authority codes associated with the projects,users have access to transactions.

TDS Concepts

g-2 47 A2 26UT Rev00

Batch interface:

This is an interface which allows you to establish a session and dialog between a batchprogram and a TDS application.

It can be used as a program debugging facility. A batch program simulates a terminal,allowing the program to be logged on as a terminal to send and receive messages.

Before image:

A copy of the file containing the data in the state prior to an update. Before images arerecorded sequentially in the Before Journal, and are used in case of a rollback.

Before Journal:

A GCOS 7 function that protects against software failure. When a record is processed,a copy of the original record is written (as a Before images) to this journal.

Commitment:

The action taken periodically by TDS after the normal end of processing. It is a pointwithin a transaction where:

• TDS saves all processing of the transaction up to that instant: the processing isdefinite and cannot be lost or cancelled

• the transaction may be restarted after a software or hardware failure

• all resources allocated to the transaction are released

• resource conflicts can be resolved.

Commitment unit:

All of the processing completed since the last commitment (or from the beginning of thetransaction if it is the first commitment unit) to the current commitment (or to the end ofthe transaction if it is the last commitment unit). This is sometimes referred to as a CU.

Conversation:

A conversation is the interval between two exchanges of the same transaction . Thatis, the time between the transmission of the transaction's first input message and thereception that transaction's next input message of a given user.

A conversation has a different meaning in an XCP2 context.

Glossary

47 A2 26UT Rev00 g-3

Correspondent:

An application, a user logged on at a terminal, or a "virtual" correspondent that interactswith a TDS application. A correspondent uses a protocol to dialog with a TDS. It can be aTM (PT, Batch Interface), XCP1, XCP2 or virtual session.

Coupled system:

Two DPS 7000s using the Coupled System product and sharing one or more diskvolumes.

CRNETGEN:

The facility used to generate the network and also to define correspondents.

Deadlock:

A conflict between one or more commitment units for system resources.

Deferred Updates:

An updating method in which the modification is not made to the file until thecommitment unit is completed. If a transaction aborts before the end of thecommitment unit, the update is not made. The principle of deferred updates is used bythe rollforward utility. This mechanism improves performance but it needs memoryresources (UFAS buffers).

Dirty read:

The access and reading of a file while it is being updated. The information from a dirtyread is or is not correct depending on whether the read was before or after thecommitment point of the TPR updating the file.

Dummy correspondent:

A "virtual" correspondent, that is, a correspondent that is not real but seen only by TDS.It allows parallel processing to be coded through the spawn mechanism.

End-user:

A user who interacts with a TDS application via a terminal. In terms of this document, anend-user is anyone who logs on to TDS to run transactions. An end-user is notconcerned with the development or administration of the TDS application.

TDS Concepts

g-4 47 A2 26UT Rev00

Exchange:

A sequence which includes the input message, the processing by the application, andthe output message. A TPR results in one exchange, but an exchange may bedispersed over any number of TPRs. A transaction may include several exchanges.

Exclusive Read:

A type of access to a file in which the record is locked while being read. Only one TPRcan access the record at a time; access to the file is "exclusive".

FORMS:

An on-screen form with blanks, or fields, to be filled in by the user.

GAC-EXTENDED:

A file sharing facility that allows several concurrent users in various processingenvironments to read and write to the same file.

GCL:

GCOS 7 Command Language.

GTWriter:

A GCOS 7 facility that allows information to be asynchronously spooled and printed onthe specified hardcopy terminal.

High Availability:

A GCOS 7 software product designed to increase the availability of applications. This isalso referred to as HA.

IDS/II:

A hierarchical networked database fully integrated with TDS. It is based on UFAS files.

IOF:

Interactive Operation Facility. A GCOS 7 facility that allows users to access information(files, databases, applications, programs, or facilities) and submit requests.

Glossary

47 A2 26UT Rev00 g-5

JCL:

Job Control Language.

Journalization:

The selection of one or both of the GCOS 7 journals (Before and/or After) to protect files.

Library:

A file that can contain objects of various types known as members . A library isfunctionally divided into subfiles.

Linked unit:

A COBOL TPR compile unit that has been linked. The Static Linker forms linked unitsand stores them in a sharable module on a SM library.

Mailbox:

A string of 8 alphanumeric characters external address that identifies an endpoint, eithera user, correspondent, terminal, or printer.

The Master mailbox identifies the Master Operator.

Mapping:

The process of allocating a process or a task to a transaction.

Master commands:

Commands available to the Master Operator, used to control TDS.

Master file:

A file that contains the user data of the application. This file can be thought of as part ofthe data base. A master file is frequently used and always kept up-to-date.

Master mailbox:

A mailbox name (a string of 8 alphanumeric characters) cataloged as an application inthe site catalog with at least authority code 0. The Master mailbox identifies the MasterOperator.

TDS Concepts

g-6 47 A2 26UT Rev00

Master operator:

The correspondent in charge of managing the TDS session. The Master Operator mustcomplete the start-up dialog with TDS before other users can log on.

Member:

A subfile of a library .

Message-id:

The name used to identify a transaction. When a user types in the MESSAGE or selectsit from a menu, the transaction is executed.

MTGEN:

The V3/V5 JCL utility used to generate the TDS application. The corresponding V6 utilityis TP7GEN.

MTPREP:

The V3/V5 JCL utility used to prepare the TDS application by allocating file space forTDS files. The corresponding V6 utility is TP7PREP.

NETGEN:

see CRNETGEN.

Non-concurrency:

The prevention of activating simultaneously, tasks belonging to different transactions. Atransaction may be declared as non-concurrent with other transactions (or with itself) atTDS generation.

Non-controlled file:

A UFAS-EXTENDED (or UFAS) file which is not affected by the access control providedby TDS.

Off-line files:

Files used to generate, compile and link TDS. These files are not required at run-time.

Glossary

47 A2 26UT Rev00 g-7

On-line files:

Files used to process transactions. These files need to be available (or on-line) at runtime.

ORACLE:

A Relational Database Management System. ORACLE can be used with TDS, but ismanaged by independent software.

Pool:

A set of parallel sessions having common characteristics. They may have the samesynchronization level or security options. A pool must contain at least one session. Amaximum number of sessions is defined for each pool.

Rollback:

The process of restoring a file to an earlier state by discarding all the work done sincethe last commitment point. The Before image replaces the updated record.

Rollforward:

A process of recovering files in the event of a TDS abort or system crash. The mostrecent state of the files is achieved by replacing records with the valid modificationssaved as After images.

Session:

A logical connection that allows a succession of transmissions between two-endpoints,called mailboxes .

Sharable Module library:

A library where compiled and linked TPRs are stored.

Shared read:

A type of access to a file in which the record can be read by multiple TPRs. A sharedread is only used to read the file. If the TPR wishes to write to the file, it must wait until ithas an exclusive read .

TDS Concepts

g-8 47 A2 26UT Rev00

Simultaneity:

The level of multitasking permitted in a TDS application. That is the maximum numberof tasks that can be executed at any one time. Simultaneity is specified at TDSgeneration.

Spawning:

The activation of a transaction from within another transaction.

Special-Purpose transactions:

Transactions written by the programmer and called by TDS in the case of a TDS startupor shutdown, user log-on or log-off, when TDS is disconnected or restarted, or when aBreak is sent.

Statistical read:

A read of a file in which transactions can access data (for a read, but not a write) that isbeing updated by other commitments.

STDS:

The Source TDS, or program used to generate the TDS application.

TDS Monitor:

The software that controls the execution of application programs during transactionprocessing. This is sometimes referred to as the TDS Executive.

TDS-controlled file:

A UFAS or UFAS-EXTENDED relative or indexed sequential file, or an IDS/II database,controlled by TDS during generation. This type of file has concurrent access control.

TDS Administrator:

The person who performs the administrative functions in TDS including theconfiguration, optimization, and implementation of a TDS application.

TDSGEN:

The TDS Generation Program is used to define the environment in which transactionprocessing applications are to be run.

Glossary

47 A2 26UT Rev00 g-9

Terminal Manager:

A protocol used to exchange data between a TDS application and a terminal.

Terminal Operator:

see End-user.

TPR:

Transaction Processing Routine. A program unit written in either COBOL, C language,or GPL by the TDS programmer, and designed to execute in the TDS environment. Oneor more of these program units form a transaction. TPRs are stored in sharablemodules.

TP7GEN:

The V6 JCL utility used to generate the TDS application.

TP7PREP:

The V6 JCL utility used to prepare the TDS application by allocating file space for TDSfiles.

Transaction:

A unit of processing defined by the TDS programmer. Each transaction consists of oneor more Transaction Program Routines (TPRs). An example of a transaction is theupdating of a customer's bank account after a payment is made using a credit card. Thetransaction includes accessing the customer file, the dialog with the Operator, and themodification to the file.

User:

see End-user.

User Journal:

A private journal that allows a user(or a programmer) to record messages, statistics, orany user information.

Windowing:

The ability to overlay or superimpose one form or window on another.

TDS Concepts

g-10 47 A2 26UT Rev00

XCP1:

(eXtended Cooperative Protocol Level 1) A standard application-to-applicationcommunications protocol.

XCP2:

(eXtended Cooperative Protocol Level 2) A standard application-to-applicationcommunications protocol.

47 A2 26UT Rev00 i-1

Index

A

Access control 4-26Access rights 3-4Accessing data 4-22Accessing facilities see Spawning 4-12Accessing files 2-17Accessing remote applications 4-15Active mode 4-11Administrator 1-9, 3-3Advantages of TDS 1-5Affinity 3-17After image 2-11After Journal 2-13After Journal Recovery Utility 2-13Application files 2-19Application Storage Areas 3-14Areas in IDS/II 2-17Assembling TDS 3-18Authority codes 3-4Avoiding resource conflicts 4-4

B

Basic concepts 2-1Batch processing 1-3Before image 2-11Before Journal 2-13Building a TDS 3-1

C

C Language 1-5Cataloging authority codes 3-4Closing files 3-25COBOL 1-5Commitment point 2-8Commitment unit 2-7

Commitments 2-7Communicating with IBM applications 4-16Communication between applications 4-10Communications 3-5Communications session 3-22, 4-14Compiling TPRs 3-10Components of transactions 2-3Concepts 2-1Connecting to remote applications 4-15Connecting to TDS 3-26Controlling access to TDS 4-26Controlling processing of data 4-2Conversation 2-5Correspondents 3-5, 4-11Creating a TDS 3-1CRNETGEN utility 3-5CU see Commitment unit: 2-7

D

Data handling 2-7Data integrity 2-11Data processing 4-2Data protection 2-11Databases 4-22Debugging TPRs 3-12Declaring correspondents 3-5Default commitment point 2-8Deferred updates 2-14Designing a TDS 3-3Designing and optimizing TDS 4-1Displaying information 3-15Documentation 1-10DOF 7-PO 3-24DPX 3-17Dummy correspondent 4-11DUMPJRNL utility 2-13

E

Emulating TDS 3-17

TDS Concepts

i-2 47 A2 26UT Rev00

End-user 1-9, 3-26End-user session 3-22Examples of TDS 1-2Exchange 2-4Explicit commitments 2-9Extended Communications Protocol 4-16External messages 3-15

F

File integrity 1-5Files 2-17, 3-25FOR DEBUG 2-2FOR INQUIRY 2-2Format mode 3-15Forms 3-15

G

GAC-EXTENDED 2-17GCOS 7 session 3-22Generalized Terminal Writersee GTWriter 3-17Generating the network 3-5Generating the TDS 3-4GPL 1-5GTWriter 3-17

H

HA 4-24Handling data and resources 2-7Handling reports 3-17High Availability 1-5High Availability see HA: 4-24Hints for Writing TPRs 3-9

I

IDS/II 4-22IDS/II database areas 2-17Images 2-11

IMAGEWorks 3-17Implicit commitments 2-9Improving availability of data 4-25Integrity 2-11INTERACTION WITH UNIX WORLD 4-20IOF 1-3IPG 3-3IQS 4-22IQS procedures 1-5

J

Journal utilities 2-13Journalization 2-11

L

Languages see Programming: 1-5Limits

Simultaneous TPRs 4-3TPRs 2-5Transactions 2-2, 4-2

LINKER utility 3-10Load module 3-18Logging off 3-27

M

Mailbox 3-22Managing terminals 4-14Mapping 4-7Master mailbox 3-22Master operator 1-9, 3-21Measuring performance 3-7Mechanisms of recovery 2-14Message identifier code seeMessage-id 2-2Message-id 2-2Mirror Disks 4-25Multimedia services 3-17

N

NETGEN 3-5Non-concurrent transactions 4-4Non-controlled files 2-18Normal mode 3-15

Index

47 A2 26UT Rev00 i-3

Number of processes 1-5Number of TPRs 2-5Number of transactions 2-2

O

Off-line files 2-19On-line files 2-19Opening files 3-25Optimizing a TDS 3-7Optimizing TDS 4-1ORACLE 4-23Organization of data 4-22

P

Passive mode 4-11PMOS see DOF 7-PO: 3-24Preparing files 3-3Preventing concurrent access 4-4Processes 1-5, 4-7Processing 1-3Processing unit see Commitment unit: 2-7Products that provide security 4-24Programmed Operator 3-24Programmer 1-9, 3-7Programming 1-5Programming see also Transactions: 1-5Protecting database 4-25Protection of data 2-11Protocols 4-14PT see TDS Pass-Thru facility: 4-15

R

Rate of processing 4-2RDDF7 4-25Real Time Statistics 3-12Real-time processing 1-1Recording statistics 2-13Recovery mechanisms 2-11Recovery techniques 2-14Reducing impact of incidents 4-24Remote Database DuplicationFacility see RDDF7 4-25Resources 2-7Resources, releasing 4-7Response time 1-3Restarting TDS 3-25Role of administrator 3-3Role of end-user 3-26Role of master operator 3-21Role of programmer 3-7Rollback 2-15Rollforward 2-16

ROLLFWD utility 2-13Rolling back a commitment 2-15Rolling forward a commitment 2-16Running a TDS 3-21Running transactions 3-26

S

Saving TPRs 3-10SBR 3-7Screen display 3-15SECUR'ACCESS 4-26Security 1-5, 4-24Setting up TDS 3-1Sharable Modules see SM: 3-10Simulate a TDS see TDS BatchInterface 3-12Simultaneity level 4-3Simultaneous transactions 4-3SM 3-10Spawning 4-12Special-purpose transactions 3-12Starting a TDS 3-22Starting end-user session 3-26Starting transactions 3-26Statistics 2-13Status line 3-15STDS 3-3Steps in Building a TDS 3-2Stopping TDS 3-25Storage Areas 3-14SYSMAINT utility 3-18

T

Tasks 3-1TCAM 4-15TDS Administrator 3-3TDS advantages 1-5TDS and other products 4-10TDS application 1-2TDS Batch Interface 3-12TDS Communications AccessMethod see TCAM: 4-15TDS documentation 1-10TDS environment 1-3TDS files 2-17TDS journalization 2-12TDS Monitor 1-4TDS non-controlled files 2-18TDS Pass-Thru facility 4-15TDS Programmer 3-7TDS session 3-22TDS Source Program see STDS: 3-3TDS Users 1-9TDS users 1-9

TDS Concepts

i-4 47 A2 26UT Rev00

TDS-controlled files 2-17TDS-HA 4-24TDSGEN 3-4Terminal Adapter 3-15Terminal Manager protocol 4-14Terminals on a network 3-6Terminating end-user session 3-27Terms 2-1Testing TPRs 3-12Thinktime 2-5TILS 3-7TM Terminal Manager protocol: 4-14TP7GEN utility 3-4TP7PREP utility 3-3TPR 2-5TPRs

and Transactions 3-8Compiling 3-10Placing in SM 3-10Testing and Debugging 3-12Writing 3-8

Transaction 1-1, 2-2Transaction Driven Subsystemssee TDS: 1-5Transaction Processing Routinesee TPR: 2-5Transactions starting transactions 4-12Tx see Transaction: 2-2Type of files 2-17Types of commitments 2-9Types of transactions 2-2Types of users 1-9

U

Understanding TDS 2-1Unmapping 4-7UPDATE 2-2User Journal 2-13Using IQS with TDS 4-22Using ORACLE with TDS 4-23

W

Windowing mode 3-15Windows 3-17Writing the STDS 3-3Writing TPRs 3-8

X

XCP1 protocol 4-16XCP2 protocol 4-18

Technical publication remarks form

Title : DPS7000/XTA NOVASCALE 7000 TDS Concepts

Reference Nº : 47 A2 26UT 00 Date: March 1993

ERRORS IN PUBLICATION

SUGGESTIONS FOR IMPROVEMENT TO PUBLICATION

Your comments will be promptly investigated by qualified technical personnel and action will be taken as required.If you require a written reply, please include your complete mailing address below.

NAME : Date :

COMPANY :

ADDRESS :

Please give this technical publication remarks form to your BULL representative or mail to:

Bull - Documentation Dept.

1 Rue de ProvenceBP 20838432 ECHIROLLES [email protected]

Technical publications ordering form

To order additional publications, please fill in a copy of this form and send it via mail to:

BULL CEDOC357 AVENUE PATTONB.P.2084549008 ANGERS CEDEX 01FRANCE

Phone: +33 (0) 2 41 73 72 66FAX: +33 (0) 2 41 73 70 66E-Mail: [email protected]

CEDOC Reference # Designation Qty

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

_ _ _ _ _ _ _ _ _ [ _ _ ]

[ _ _ ] : The latest revision will be provided if no revision number is given.

NAME: Date:

COMPANY:

ADDRESS:

PHONE: FAX:

E-MAIL:

For Bull Subsidiaries:

Identification:

For Bull Affiliated Customers:

Customer Code:

For Bull Internal Customers:

Budgetary Section:

For Others: Please ask your Bull representative.

BULL CEDOC

357 AVENUE PATTON

B.P.20845

49008 ANGERS CEDEX 01

FRANCE

47 A2 26UT 00REFERENCE

tds - atossupport.bull.com/ols/product/system/gcos7/gcos7-com/g7-dps7000/… · chapter 1 presents...

Documents