Information is subject to change without notice. Northern Telecom reserves the right to make
changes in design or components as progress in engineering and manufacturing may warrant.
Nortel, Meridian IVR, Meridian Mail, ACCESS, and Meridian 1 are trademarks of Northern
Telecom. VT100, DEC, and VT420 are tr ademarks of Digital Equipment Corporation. HP, LaserJet,
and ThinkJet are trademarks of Hewlett-Packard Company. X Window System and X are
trademarks of the Massachusetts Institute of Technology. NCD is a trademark of Network
Computing Devices Inc. UNIX is a registered trademark of AT&T. Voicetek and VTK are trademarks
of Voicetek Corporation. Motif is a trademark of Open Software Foundation Inc. Touch tone is a
trademark of Bell Canada. Intel and Pentium are trademarks of Intel Corporation. SCO is a
trademark of The Santa Cruz Operation Inc.
Publication history
February 1996
This document is the first standard issue for Meridian IVR release 2.0/I.
iii
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
Contents
About this guideix
Who should use this guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
Procedure 2-1 Accessing transaction information ........................2-5
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
About this guide
Who should use this guide
The Meridian IVR 2.0/I VT100 Gateway Development Guide is intended for
use by Meridian IVR 2.0/I application developers whose voice applications
require VT100 based access to computer resources external to the application
processor. The VT100 communications board and its supporting software are
not part of the VT100 Gateway product.
This manual assumes that the user is familiar with the operating
characteristics of the VT100 terminal, and is experienced in creating voice
applications with Meridian IVR 2.0/I. You should also be familiar with the
UNIX operating system and the vi text editor (or another text editor installed
on your application processor).
How to use this guide
This guide contains the following chapters and appendices:
Chapter 1: About the VT100 Gateway
This chapter provides an overview of the VT100 terminal and a description
of the Meridian IVR 2.0/I VT100 Gateway features.
ix
Chapter 2: Template files
This chapter explains how to create the necessary files for sending data to and
receiving data from a remote computer.
Chapter 3: Getting started
This chapter describes the steps you must perform and the additional files you
must create to activate the VT100 Gateway software. This chapter also
includes a sample set of template files.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
x
About this guide
Chapter 4: IVR 2.0/I call flow interface
This chapter explains how to integrate the templates you created in Chapter 3
with your Meridian IVR 2.0/I application call flow.
Appendix A: Host error messages
This appendix lists error messages and provides information on
troubleshooting.
Additional Nortel manuals
You may find the following manuals useful while reading this manual.
ManualNTP Number
Meridian IVR Application Development Guide
Meridian IVR System Administration Guide
Conventions used in this guide
Throughout this guide, several typographic conventions have been used to
highlight certain types of information.
•Items that are part of the Meridian IVR 2.0/I screens appear in quotes (for
example, “Function Code” in the parameters window).
•Meridian IVR 2.0/I buffer names are shown in all upper case characters
(for example, the CURRENT MESSAGE buffer).
•Items that are file names or messages are shown in
the
/u/ivr/vt100/getbalance.act
For convenience, this guide uses the keyname <Enter> to represent both the
Enter and Return keys.
file).
NTP 555-9001-310
NTP 555-9001-300
bold
(for example,
555-9001-316 Standard 1.0 February 1996
Chapter 1: About the VT100 Gateway
This chapter provides an introduction to the Meridian IVR 2.0/I VT100
Gateway as well as
•background on the VT100 terminal
•descriptions of the Meridian IVR 2.0/I VT100 Gateway software
•a description of the TRS configuration
•a brief glossary of terms used in this guide
The VT100 terminal
The VT100 terminal, developed by the Digital Equipment Corporation
(DEC), has become one of the most widely used computer terminals in the
world. This widespread acceptance makes the VT100-style of host
communication a standard for all computer manufacturers. See Figure 1-1.
1-1
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
1-2
About the VT100 Gateway
Figure 1-1
Terminals connected to a host computer
Host
VT100 Terminals
The VT100 terminal uses an asynchronous communication protocol to
transmit characters to and from a host computer. The VT100 Gateway
communicates with a host through a serial port and a modem, or through a
serial port and a direct connection. With respect to the VT100 Gateway
product, a host computer is any computer that can accept a VT100 terminal
connection, including mainframes, minicomputers, and workstations.
The standard VT100 terminal has a 24x80 character display, and can be
accessed
non-sequentially
on the screen. This allows you to delete and insert text, scroll the page, and
move the cursor to any position on the screen. Your ability to access the
VT100 screen non-sequentially depends on the host application you are
using.
Figure 1-2 shows a sample VT100 terminal running a sample host
application. This sample accounting application is used throughout the guide
to illustrate how to develop applications using the VT100 Gateway.
Note:
The screens shown in this guide are examples only and are not part of
any real application.
555-9001-316 Standard 1.0 February 1996
. This means the terminal can access text anywhere
About the VT100 Gateway
1-3
Figure 1-2
VT100 application screen sample
ACME Accounting
1. Accounts Receivable
2. Accounts Payable
3. Reports
4. Inventory
5. Exit
Enter menu selection:
vt100
An active host to terminal connection is called a session. The VT100 Gateway
can execute a series of transactions during a session. A transaction is the
series of steps required to perform a specific function like finding a
customer’s account balance. When one transaction finishes, the session is
available to execute another transaction. The Meridian IVR 2.0/I application
processor, when configured with the VT100 Gateway product, can control
multiple simultaneous sessions with the host computer.
The Meridian IVR 2.0/I VT100 Gateway product allows a Meridian IVR
2.0/I application to establish sessions with a host just as multiple VT100
terminals would. Any programs or commands you can execute from a VT100
terminal, you can execute with Meridian IVR 2.0/I via the VT100 Gateway.
Meridian IVR 2.0/I can store host output in the buffers of an application, then
play the information to a caller.
The application processor physically connects to the host via a modem if the
host is not local, or via a null modem connector if the host resides locally.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
1-4
About the VT100 Gateway
The VT100 Gateway software
You can install the Meridian IVR 2.0/I VT100 Gateway on Intel’s new
generation 64-bit PentiumTM microprocessor. To support the VT100
Gateway, the application processor must
•have an ACCESS link connected to Meridian Mail
•be connected to one or more host computers via an asynchronous
connection
•have enough serial ports to provide enough terminal connections (one
digiBoard with 8 ports per card)
Northern Telecom (Nortel) does not supply the VT100 communication
hardware. Figure 1-3 shows the typical hardware configuration for processing
VT100 terminal sessions.
Figure 1-3
Meridian IVR 2.0/I VT100 Gateway configuration
Async
HOST
(Application processor)
555-9001-316 Standard 1.0 February 1996
MIVR
ACCESS Link
MERIDIAN MAIL
About the VT100 Gateway
1-5
A Meridian IVR 2.0/I process called the Terminal Resource Server (TRS)
controls all VT100 sessions, as well as manages all host connections. The
TRS runs as a stand-alone process within the Meridian IVR 2.0/I architecture,
and starts when Meridian IVR 2.0/I is started. To use the TRS, place a COMI
cell in the Meridian IVR 2.0/I call flow at the point where you need to
establish a host connection. The COMI cell sends requests for information to
the TRS process, which then passes them on to the host. A COMO cell
retrieves the information sent to the TRS process by the host, and then ends
the transaction. A COMA cell aborts the host transaction in the case of a
hang-up or an error. This process is shown in Figure 1-4.
Figure 1-4
TRS communication process
Cleanup
START
Handler
COMA
2
COMI
COMO
PDAT
Host
TRS
process
Input
Buffers
Output
Buffers
ANSW
GDAT
MENU
1
COMI
COMO
PDAT
HANG
The TRS process uses template files (described in Chapter 2) to control the
communication process between the Meridian IVR 2.0/I application and the
host computer.
As illustrated in Figure 1-4, the TRS uses the data passed to it by the input
buffer as a signal to establish a terminal session. The TRS then controls the
screen display on the host computer.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
1-6
About the VT100 Gateway
ATTENTION!
The TRS process for managing calls is restricted to handling one active
line at a time (single threaded mode).
Therefore, you should add a loop to applications that interact with the
TRS so that customers who call at peak hours are informed on the
status of their call. For example, you can allow callers to hear a
recurring message that an operator will assist them as soon as possible.
555-9001-316 Standard 1.0 February 1996
Chapter 2: Template files
The TRS process uses action and screen templates to maneuver through the
screens of a host application. These templates exchange information with the
host application screens and transfer information to and from the TRS’s
buffers. Coupled with the VT100 emulation software and hardware, they
provide the host with exactly the same type of input as a terminal operator.
This chapter explains how to:
•Determine the actions a terminal operator performs to enter and retrieve
information
•Create the action and initial action template files that define the sequence
of host application screens for each transaction
•Create the screen template files that define the sequence of fields
encountered on each screen
Note:
If you make backups of your template files, do not store them in the
/u/ivr/3270 directory or in any subdirectory under /3270. You should make a
directory at the same hierarchical level or higher as /3270. For example, if
/u/ivr/3270bak is specified, the TRS process searches the /3270 directory and
any subdirectories within it for files with the
.act
or
.scn
extensions.
2-1
Determining the required transactions
Imagine that you are an operator sitting at a terminal. In order to perform a
specific task, you type information and press function keys until you
accomplish the desired task. Perhaps a caller asks you to look up a customer’s
account balance, or enter an order. The series of steps you perform at the
terminal enable the application on the host computer to complete the
transaction.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
2-2
Template files
To develop a voice application that accesses the same information as a
terminal operator, you need to tell Meridian IVR 2.0/I how to execute the
same series of actions that the terminal operator executes. You provide this
information in ASCII files called template files.
Template files provide the layout and content of each screen in the host
application as the terminal operator sees them. Figure 2-1 compares a
transaction done by a terminal operator to one done by a customer calling into
a voice response system.
Note:
The first step performed by the terminal operator is not performed by
the action template. It is performed by the initial-action template (described
later in this chapter). The initial-action template handles the login and moves
the application to the appropriate screen to begin the transaction.
555-9001-316 Standard 1.0 February 1996
Figure 2-1
Voice response system vs. terminal operator
Template files
2-3
An operator follows this
sequence to retrieve data:
1.Starts the “accounting”
application.
2.Selects the “Accounts
Receivable” menu option.
3.Asks the caller for account
information.
4.Enters the caller’s account
number.
5.Reports the balance when
the customer’s information
appears on the screen.
The TRS requires two types of template files:
•
Action templates
order to perform a specific transaction.
•
Screen templates
screen that require data, and define all keystrokes required for the screen.
A customer follows this sequence
to retrieve data:
1.Calls into the AP, activating a
voice application.
2.When prompted, selects the
Accounts Receivable option from a
menu prompt.
3.When prompted, enters account
information. At this point, the application sends a request for information to TRS. TRS then executes the
action template for this specific
transaction.
4.Hears the playback of
requested information.
5.Hangs up.
, which describe the sequence of screens traversed in
, which validate each screen, define the fields on the
Figure 2-2 shows how screen templates relate to action templates.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
VT100 based applications often have format inconsistencies that make it
difficult for the TRS to efficiently determine when the host application is
ready for input and what region of the host screen contains vital information.
These inconsistencies are due to the character based nature of the VT100
protocol.
In addition, the VT100 communication protocol has no way of notifying the
TRS that host data transmission has ended. From the terminal operator’s
perspective, it is easy to tell when host transmission ends because the
operator’s requested information appears on the screen. From the TRS’s
perspective, there is nothing inherent in the VT100 protocol to provide
notification of the end of host output. The TRS encounters a stream of data
from the host, and from this must determine the identity of each screen as well
as locate the end each screen. To enable the TRS to do this, as well as cope
with screen inconsistencies, you must create a file called
555-9001-316 Standard 1.0 February 1996
screen.conf
.
The action templates, screen templates, and screen.conf file are ASCII text
files that use a simple syntax to define the screen flow and input/output fields.
The sections that follow provide a detailed explanation of the templates, as
well as the information necessary to create the
Action templates
A VT100 transaction typically moves through several screens until it locates
specific information. The screens may be a series of commands issued at the
operating system prompt, or they may be screens within an application
running on the host computer. Whenever Meridian IVR 2.0/I references an
action template, the VT100 Gateway executes the screen templates listed in
the action template, moving through the application just as a terminal
operator would. An action template must specify the same sequence of
screens that the terminal operator traverses.
A separate action template defines each transaction. In the example shown in
Figure 2-1, if you want to select a menu option other than “Accounts
Receivable,” you would define another action template.
Action templates describe the flow of the screens that comprise a particular
transaction. For example, if you want a transaction to access billing
information for a specific client, as a terminal operator you would perform the
following steps:
screen.conf
Template files
file.
2-5
Procedure 2-1
Accessing transaction information
1
Log on to the computer.
2
Start the “acct” application.
3
Select the “Accounts Receivable” menu.
4
When prompted, enter the client’s account number and press the
Return key. A screen would appear displaying the client’s billing
information.
5
Read the account information on the screen.
In a Meridian IVR 2.0/I VT100 transaction, an initial-action template
performs steps 1 and 2. The initial-action template automatically executes
when the TRS process starts (initial-action templates are described later in
this chapter.). An action template created to execute this transaction would
perform steps 3 through 5.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
2-6
Template files
Action template syntax
An action template is an ASCII file created with a text editor. The action
template files you create must reside in the /u/ivr/3270 directory or in a
subdirectory below /u/ivr/3270. They must also have the file name extension
.act. For example, if you created an action template called
would have this path:
u/ivr/3270/getbalance.act
The syntax of an action template is shown in Figure 2-3.
The lines depicted as • represent additional screen templates used in the
transaction. Each screen template corresponds to a specific host application
screen which appears on the terminal during a session. Screen templates are
listed in the action template in the same order as they appear during the actual
terminal session. (Screen templates are discussed later in this chapter). The
example in Figure 2-4 illustrates an action template file which describes a
transaction for retrieving account information. This sample application is
used as a development example throughout this guide.
555-9001-316 Standard 1.0 February 1996
Figure 2-4
Action template for accounting application
#Example action template file: filename is getbalance.act
getbalance accounting reset_cust logout_cust
#acctrec chooses the balance option from the main menu
acctrec
#acctno specifies the account number for the customer
acctno
#customer displays the customer’s account balance
customer
Template files
2-7
In Figure 2-4,
without the
is
reset_cust
(file name
action-name
.act
extension. The
(file name
reset_cust.act
logout_cust.act
is
getbalance
app-name
).
Manual mode
, the name of the action template file
is
), and the
accounting
logout-action
. The
is
reset-action
logout_cust
is omitted because manual mode
is not required for this transaction (a description of manual mode follows).
The remaining lines identify the sequence of screens (
customer)
the TRS must traverse to retrieve the customer billing
accrec, acctno
, and
information. These screens are listed in the order that they must be accessed.
An explanation of each entry in the action template syntax follows.
#comment
The first line of the template in Figure 2-3 is a comment. The comment line
is not required but is recommended to describe the purpose of the action
template.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
2-8
Template files
Comments start with the “#” symbol and can be embedded anywhere in the
action template. If a comment begins a line, no non-comment fields may
follow the comment in that line. However, a comment may appear after a
non-comment field, such as after the screen template name as shown in Figure
2-4. It is good practice to heavily comment files so that changes can be made
easily in the future.
action-name
The
action-name
extension. The
example, if the action template’s file name is
enter
getbalance
is the file name of the action template file without the
action-name
is required to begin the transaction. For
getbalance.act
, you would
for the action-name.
.act
app-name
When you set up your application processor with the VT100 Gateway, you
must create a
application on the host computer (the
trs.conf
file that assigns TRS session numbers to the
trs.con
f file is described in Chapter 3).
Choose a name for the host computer application name; it does not need to
match any actual application name on the host computer.
As an example, this guide uses the
host computer “
The
app-name
acct
” application.
you specify in the action template must exist in the
file (discussed in Chapter 3). Meridian IVR 2.0/I passes the
TRS function, which uses the name to start the appropriate session with the
host computer.
reset-action
The
reset-action
specifies an action template to be processed when the
transaction completes or if the transaction fails. Typically, the reset-action
template is used to bring the host computer application back to its main screen
so it is ready to process the same type of transaction. Figure 2-5 shows the
sequence a sample reset-action template follows.
555-9001-316 Standard 1.0 February 1996
app-name
“accounting” to represent the
trs.conf
app-nam
e to the
Figure 2-5
Reset-action template sequence sample
For an action template
that follow this sequence:
The reset-action template
follows this sequence:
Template files
2-9
Application
Menu
Screen
Account
Number
Screen
Customer
Information
Screen
Entering a hyphen “-” in the
Application
Menu
Screen
Account
Number
Screen
Customer
Information
Screen
reset-action
entry indicates that no reset-action
template is specified.
If no reset-action template is specified and the transaction being executed by
the action template fails, the logout-action template (described in the next
section) is executed. If the transaction succeeds and there is no reset-action
template specified, the host computer application remains at the screen where
the transaction ended.
When you create a reset-action template, do not specify reset-action or
logout-action templates in it. For example, Figure 2-6 shows a sample
reset-action template.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
2-10
Template files
Figure 2-6
Reset-action template sample
#This reset-action template returns the host computer application
#to the main menu screen from the customer information screen
#filename: reset_cust.act
reset_cust accounting – –
clrcust
#exit the customer information screen
atmenu
#leave the session at the menu screen
The action template using this reset-action template would enter
as the
reset-action
entry.
logout-action
The
logout-action
specifies a logout-action template to be executed if the
reset-action template fails, or if the transaction fails and there is no
reset-action template specified. If the transaction succeeds, the logout-action
template is not executed.
The TRS uses the logout-action template to return the failed transaction to the
initial screen (usually a login screen). After it successfully executes the
logout-action template, it executes the initial-action template (described later
in this chapter) after 30 seconds. Figure 2-7 shows the flow of the logout
action template.
555-9001-316 Standard 1.0 February 1996
reset_cust
Figure 2-7
Logout action flow
For an initial-action template that brings the host computer
application to the accounting package menu, and an action
template that brings the host computer application from the
Application Menu Screen to the Customer Information
Screen, then the logout-action template brings the host
computer application back to the Login Screen.
Action Template
Template files
Logout-action Template
Login
Screen
2-11
Initial-action Template
Login
Screen
Application
Menu
Screen
Application
Menu
Screen
Account
Number
Screen
Customer
Information
Screen
Application
Menu
Screen
Account
Number
Screen
Customer
Information
Screen
The logout-action template locates the screen where the transaction failed. If
for example, the transaction failed at the account number screen, the
logout-action template locates the screen template with the appropriate
validation tag and starts from that screen.
Entering a hyphen for the
logout-action
entry indicates that no logout-action
template is specified. If neither a reset-action template nor a logout-action
template is specified and the transaction fails, the host computer application
remains at the point where the transaction failed. Future transactions that try
to use this session would also experience errors because the screen where the
session remained would not be the expected starting screen (unless the
transaction can start from any screen).
When you create a logout-action template, do not specify reset-action or
logout-action templates. Figure 2-8 shows a sample logout-action template.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
2-12
Template files
Figure 2-8
Logout-action template sample
#This logout-action template returns the application to the login
#screen from the customer information screen
logout_cust accounting – –
clrcust
#exits the customer information screen
clrmenu
#exits the acct application, shows the system prompt
screen-template
The
screen-template
(the file name of the template without the
extension) identifies the screen template used during the VT100 transaction.
Enter the screen templates in the exact order they appear during the
transaction. Each screen template must be listed on a separate line. The
syntax for screen templates is described later in this chapter.
.scn
<manual mode> (optional field)
The
<manual-mode>
entry allows you to attach a session resource to a
particular channel. You can then use the same session for consecutive
Meridian IVR 2.0/I transactions. This type of session is not released when
the transaction is finished. To exit manual mode you must execute a COMA
cell in the Meridian IVR 2.0/I application or process another action template
that does not contain the manual mode option. Chapter 4 describes how to
use the COMA cell.
To specify manual mode, enter
name. If you omit
manual,
automatic mode, the session assigned to the action template is free for use
when the transaction is completed.
555-9001-316 Standard 1.0 February 1996
manual
after the logout-action template
automatic mode is used for the template. In
Note:
You should not specify a reset-action template in an action template
that uses manual mode. Manual mode is designed to stay at a specific screen.
The next transaction received by the session will start at the last screen of the
action template that used manual mode. This next transaction
automatic mode and specify a reset-action template that brings the session
back to the starting screen of the first action template (that specified manual
mode).
Screen templates
Screens used by the host computer could be a series of commands entered at
the system prompt coupled with the system’s response to those commands, or
screens defined by applications on the host computer. You should define
screen templates that issue the system commands to start the application
(usually as part of the initial-action template), and then screen templates that
make menu selections and enter or retrieve data from the screens displayed
by the application. This guide uses an accounting application as an example.
Each screen contains fields. For the VT100 Gateway, a field is any place on
the screen where data is entered or displayed. For example, the cursor
location after a system prompt where you would type a command is
considered a field. Also, within an application, the area on the screen where
an account balance is displayed is also considered a field (the traditional
definition of a field).
Template files
should
2-13
use
For a specific transaction, specific data is entered in certain fields, and data is
read from other fields. A screen template identifies those fields on the screen
that are used to process a transaction. Only the fields that are used in the
transaction are included in the template. Figure 2-9 shows a sample screen.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
2-14
Template files
Figure 2-9
Screen showing fields and the system prompt
login: vad
Password:
Last login: Fri Apr 16 16:01:34 from publisher
ULTRIX V4.2 (Rev. 96) System #9: Mon Jul 29 10:08:24 EDT 1994
$acct
In Figure 2-9,
vad
has been entered into the login field. If the
pressed, the application starts and the screen is replaced by the application
screen.
A sample application screen showing fields is shown in Figure 2-10. Here, the
customer’s name is entered in the customer field.
555-9001-316 Standard 1.0 February 1996
Return key
is
Figure 2-10
Application screen for accounting application
Account Number:845-23-87
Customer:Jane K. SmithCurrent Balance:2482.14
Address:19 Alpha RoadPayment Due:150.00
ChelmsfordPayment Due Date:4/30/93
MA 01824
Options:
1Print invoice
2Enter payment
3Enter purchase
4Exit
Type menu selection:
Different transactions may access different fields on a screen. For example,
a transaction to locate the payment due would only need to access that field,
while a transaction retrieving the customer’s balance would only need to
access the Current Balance field.
Template files
2-15
A screen template is an ASCII file created with a text editor. The screen
template files you create must reside in or under the Meridian IVR 2.0/I
/u/ivr/3270 directory and must have the file name extension
example, if you created a screen template called
customer.scn
.scn
, it would have
. For
these paths:
u/ivr/3270/customer.scn
For each accessed field, there should be a field descriptor specified that
governs how data is retrieved from or entered in the field. The screen
template can include both data input entries as well as data output entries.
Screen template syntax
The syntax of a screen template is shown in Figure 2-11.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
2-16 Template files
Figure 2-11
Screen template syntax
#comment
screen-name validation tag offset validation tag
field-descriptor
field-descriptor
•
•
•
key-descriptor
sleep-descriptor
The lines depicted as • represent additional field-descriptor lines. The
example in Figure 2-12 illustrates a screen template file that obtains the
balance from the screen shown in Figure 2-10.
555-9001-316 Standard 1.0 February 1996
Figure 2-12
Screen template for accounting application
#Screen template file to obtain the current balance; filename: customer.scn
customer1,1Account
#places balance into buffer
0,0Balance:$
In Figure 2-12, the first line is a comment describing the screen template file.
The screen-name is “customer,” the name of the screen template file without
the .scn extension. The “1,1” represents the location of the validation tag on
the screen. The row is listed first, followed by the column. “Account” is the
screen validation tag.
Template files 2-17
The fourth line is the field-descriptor that describes an action to take. This
field descriptor is going to find an exact match to “Balance:” and place the
contents of the field into a buffer. The field-descriptor line has many
variations, depending on what you want to do with a field. For example, the
third line in Figure 2-12 could be entered as
2,48 — $
This would place the contents of the field starting at 2,48 into the next buffer.
See “field-I/O” later in this section.
An explanation of each entry in the screen template follows.
Meridian IVR VT100 Gateway Development Guide Product release 2.0/I
Loading...
+ 67 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.