Meridian IVR VT100 Gateway Development Guide Publication number: Product release: Document release: Date: 555-9001-316 Meridian IVR 2.0/I Standard 1.0 February 1996 © 1996 Northern Telecom All rights reserved Printed in the United States of America 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.
iii Publication history February 1996 This document is the first standard issue for Meridian IVR release 2.0/I. Meridian IVR VT100 Gateway Development Guide Product release 2.
v Contents About this guide ix Who should use this guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix How to use this guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix Additional Nortel manuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Conventions used in this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Chapter 1: About the VT100 Gateway 1-1 The VT100 terminal . . . . . . . . . . . . . . . . . . . . .
vi Contents Chapter 4: IVR 2.0/I call flow interface 4-1 Using the COMI, COMO, and COMA cells to access the host computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 Setting the COMI cell parameters . . . . . . . . . . . . . . . . . . . . . . . 4-2 An application using the COMI, COMO, and COMA cells . . . . 4-11 Appendix A: Host error messages A-1 Terminal Resource Server (TRS) Messages . . . . . . . . . . . . . . . . .
Contents vii Figure 3-10 Figure 3-11 Figure 3-12 Figure 3-13 Figure 4-1 Figure 4-2 Figure 4-3 Figure 4-4 Figure 4-5 Figure 4-6 Figure 4-7 Figure 4-8 Logout-action template used by the initial-action template for accounting application............................. 3-16 Action template for accounting application............ 3-18 Reset-action template for accounting application . 3-19 Logout-action template for accounting application 3-20 Accessing the mainframe........................................
ix 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.
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.
1-1 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.
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.
About the VT100 Gateway 1-3 Figure 1-2 VT100 application screen sample ACME Accounting 1. 2. 3. 4. 5. Accounts Receivable Accounts Payable Reports Inventory 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.
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.
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.
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.
2-1 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.
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.
Template files 2-3 Figure 2-1 Voice response system vs. terminal operator An operator follows this sequence to retrieve data: A customer follows this sequence to retrieve data: 1. Starts the “accounting” application. 1. Calls into the AP, activating a voice application. 2. Selects the “Accounts Receivable” menu option. 2. When prompted, selects the Accounts Receivable option from a menu prompt. 3. Asks the caller for account information. 4. Enters the caller’s account number. 5.
2-4 Template files Figure 2-2 Action and screen templates #action-template action-type screen1 screen2 screen3 #screen1-template screen1 field-descriptor1 field-descriptor2 key-descriptor #screen2-template screen2 field-descriptor1 field-descriptor2 key-descriptor #screen3-template screen3 field-descriptor1 field-descriptor2 key-descriptor 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
Template files 2-5 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 screen.conf file. Action templates A VT100 transaction typically moves through several screens until it locates specific information.
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 getbalance.act, it would have this path: u/ivr/3270/getbalance.act The syntax of an action template is shown in Figure 2-3.
Template files 2-7 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 In Figure 2-4, action-name is getbalance, the name of the action template file without the .act extension. The app-name is accounting.
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 is the file name of the action template file without the .act extension.
Template files 2-9 Figure 2-5 Reset-action template sequence sample For an action template that follow this sequence: The reset-action template follows this sequence: Application Menu Screen Application Menu Screen Account Number Screen Account Number Screen Customer Information Screen Customer Information Screen Entering a hyphen “-” in the reset-action entry indicates that no reset-action template is specified.
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 reset_cust as the reset-action entry.
Template files 2-11 Figure 2-7 Logout action flow For an initial-action template that brings the host computer Logout-action Template application to the accounting package menu, and an action template that brings the host computer application from the Login Application Menu Screen to the Customer Information Screen Screen, then the logout-action template brings the host computer application back to the Login Screen.
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 .scn extension) identifies the screen template used during the VT100 transaction.
Template files 2-13 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 should use 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).
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 Return key is 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.
Template files 2-15 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.
2-16 Template files Figure 2-11 Screen template syntax #comment screen-name validation tag offset field-descriptor field-descriptor • • • key-descriptor sleep-descriptor validation tag 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.
Template files 2-17 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.
2-18 Template files #comment The first line of the template in Figure 2-12 is a comment. The comment line is not required but is recommended to describe the purpose of the screen template. Comments can be embedded anywhere in the screen template and start with the “#” symbol. If a comment begins a line, no non-comment fields may follow the comment. However, a comment may appear after a non-comment field, such as after the field descriptor line shown in Figure 2-12.
Template files 2-19 validation-tag This entry specifies the validation-tag used on the screen. The entry should be text that always appears in the same location every time this screen displays. For the example, “Account” is always displayed starting at location 1,1 whenever a customer’s Account Receivable screen is displayed.
2-20 Template files Figure 2-13 The field-descriptor syntax row,column field-name field I/O Note: If the application running on the host is stream-based, meaning the screen scrolls as the user enters data and retrieves responses, you should enter the field-descriptor as follows: 0,0- BLANKOUT In this instance, the field-descriptor will clear the TRS memory space associated with the application screen so that your application call flow will know where to retrieve the appropriate data.
Template files 2-21 If you enter “0,0” and a hyphen for the row,column and field-name entries, the field I/O specified is executed at the current cursor location. To locate field-names on the screen for reading, the offset of the upper left corner of the screen is 1,1 and the lower, right corner is 24,80. field-name This entry identifies the field being accessed on the terminal screen. If the field-descriptor is 0,0 (i.e.
2-22 Template files Table 2-1 Valid field I/O entries Entry Description * Inputs the contents of the next input buffer (transmitted from the Meridian IVR 2.0/I application) into the field and used for COMI cells. $num Outputs the contents of the field into the next output buffer. num is a number in the range 1-31 and represents the number of characters in the field TRS will put in the output buffer. If you do not assign num a value, TRS will place 31 characters into the buffer.
Template files 2-23 When entering a field-descriptor, the entries on the line should be separated by white space or tab characters. If you are entering text for the field I/O, the TRS ignores any white space you include with the value until it encounters the new line character (e.g., the value includes several words).
2-24 Template files keyname The name of the key for this screen. Table 2-2 lists the valid keys you can enter.
Template files 2-25 sleep-descriptor (optional) A sleep-descriptor causes the transaction to pause for a specified number of seconds. You can use a sleep-descriptor to pause the transaction for a specified period of time before or after processing a key-descriptor. The waiting period takes into account the time the host computer may take to process the information entered on the screen, and to move to the next screen. The transaction waits at any point where you place a sleep-descriptor.
2-26 Template files position-indicator This entry should be set to 0,0. @ Identifies that this line is a sleep-descriptor. num Specifies the number of seconds that the session should sleep. For example, to wait 25 seconds, you would code the sleep-descriptor as 0,0 @25 Initial-action templates Before you can process any information on the host computer using the VT100 Gateway, you need to set the starting point for each of your terminal sessions.
3-1 Chapter 3: Getting started Before using the VT100 Gateway Before you can use the VT100 Gateway, you must complete these tasks: • If necessary, install a multiport adapter board and expander box. • Create the action and screen templates necessary to navigate through the host application and return the desired information (see Chapter 2). • Create the screen.conf, trs.conf, vt100.ctl, and com.conf files (described in this chapter). • Before starting IVR 2.
3-2 Getting started screen.conf file Since the VT100 protocol is character based, it has no built in mechanism for notifying the TRS that host output has ended and the application is ready for input. Creating the screen.conf file allows the TRS to quickly process host output by eliminating the time it spends waiting after host output ends. The TRS uses the screen.conf file to determine the end of host transmission. The TRS checks every screen sent from the host against the screens you define in screen.
Getting started 3-3 Figure 3-1 screen.conf file syntax Keyword:Begin string:End string: The colons (:) are used as field delimiters and must be placed in the specified positions without any additional white space. Keyword: The keyword identifies the screen. If the keyword contains a space or a colon, then enclose the keyword in quotation marks. Since the keyword’s purpose is to identify each screen, choose a unique keyword for each different screen.
3-4 Getting started Note: The TRS considers the begin string and the end string part of the data. See Figure 3-2 for an example of the screen.conf file. Figure 3-2 screen.conf file Meridian IVR In Figure 3-2, PROGRAM MENU is the keyword for the first screen. Since it contains a “s13is” case, it also searches for the begin string PROGRAM MENU. Upon finding the begin and end string, the TRS continues the transaction.
Getting started 3-5 Figure 3-3 trs.conf file syntax app-name:board-number>session-number:initial-template:heartbeat:protocol The colons (:) and the greater than (>) symbols are used as field delimiters and must be placed in the specified positions without any additional white space. app-name The app-name entry identifies the application on the mainframe to which you assign the session. The name entered here is the same name you enter in the action templates that are executed by the IVR 2.0/I application.
3-6 Getting started initial-template The initial-template entry identifies an initial-action template (without the .act file extension) for setting the startup action for the specified sessions when connecting to the host computer. The start-up action brings the specified sessions to the screen on the host computer where the action templates start when processing requests. Figure 3-4 shows the flow of a sample initial-action template.
Getting started 3-7 heartbeat You can specify an optional heartbeat action for the application specified by app-name. You can use this feature to send an indication to the host that a session is still active. Some hosts log out sessions that remain idle for a period of time. You can also use the heartbeat action to check connectivity, verifying that the session remains on the appropriate screen.
3-8 Getting started You want to set up the VT100 Gateway to initialize the sessions as follows: • initialize sessions 2-3 for accounting with acctinit.act, • initialize sessions 4-8 for market with login.act, • initialize sessions 9-10 for banking with login.act, and • initialize sessions 15-17 for airline with signin.act Figure 3-5 illustrates how you should set up trs.conf to implement the configuration for only the accounting application. Figure 3-5 trs.
Getting started 3-9 Figure 3-6 vt100.ctl file syntax session-number device-name terminal-type Figure 3-7 shows a vt100.ctl file, based on the example trs.conf file in Figure 3-5. Figure 3-7 vt100.ctl file for accounting application 2 3 /dev/ttyi1b vt100 /dev/ttyi1c vt100 Meridian IVR VT100 Gateway Development Guide Product release 2.
3-10 Getting started The follow sections describe each entry in the vt100.ctl file. session-number The session-number entry specifies the session this line defines. For example, the first line in Figure 3-7 defines the terminal type to be used for session 2. The entry must be a single number, ranging from 2 to 16. You do not need to list the sessions in numerical order, and you can skip session numbers.
Getting started 3-11 The com.conf file must be created if the baud rate is anything other than 9600. The com.conf file is located in the vt100 directory and a sample is shown in Figure 3-8. Figure 3-8 com.conf file Meridian IVR Creating the com.conf file allows you to adjust the following values. IXON IXON allows you to stop host output by sending ASCII DC3, and restart host output by sending ASCII DC1. IXON prevents input queue overflow.
3-12 Getting started Baud Rate 300 to 19200. Setting the baud rate tells the TRS the rate at which it is to communicate with the host. Set the baud rate by typing B then the rate. For example B4800 or B19200. Parity PARENB enables parity generation and detection. PAREVN sets parity to even. PARODD sets parity to odd. CSTOPB CSTOPB select 1 stop bit per character. If CSTOPB is not specified, then there are 2 stop bits per character. DIAL_UP Enter DIAL_UP in the com.conf file if IVR 2.
Getting started 3-13 A complete sample transaction This section summarizes how the sample accounting application would start up, retrieve a customer’s balance and reset for the next transaction. The sample transaction uses these templates in the following way: • The initial-action template logs on to the host computer and starts up the “acct” application. • The action template chooses the “Accounts Receivable” option from the application’s menu and retrieves a customer’s balance.
3-14 Getting started Figure 3-9 Initial-action template for accounting application Templates Corresponding Screens #initial action template to start #the accounting application #filename: acctinit.act acctinit accounting - clrinit acctlog1.scn acctlog2.scn atacctmenu login: #screen template that logs #into the host #filename: acctlog1.
Getting started 3-15 The screen template acctlog1.scn does the following: • enters the login name • enters the password • waits three seconds for the host to process the login action The screen template acctlog2.scn does the following: • at the system prompt, enters the command to run the application • types the ENTER key to start the application • waits five seconds for the host to run the accounting application The screen template atacctmenu.
3-16 Getting started Figure 3-10 Logout-action template used by the initial-action template for accounting application Templates Corresponding Screens ACME Accounting #logout-action template for the #acctinit initial-action template #filename: clinit.act clinit accounting – – clrmenu logout 1 Accounts Receivable 2 Accounts Payable 3 Reports 4 Inventory 5 Exit Enter menu selection: ACME Accounting #screen template to exit the #accounting application #filename: clrmenu.
Getting started 3-17 Action template performing a transaction As shown in Figure 3-10, the initial-action template brings the session to the application’s menu screen. The action template created to get a customer’s balance starts at that screen.
3-18 Getting started Figure 3-11 Action template for accounting application Templates #action template to perform steps #required to retrieve customer's balance #filename: getbalance.act getbalance accounting clr_cust logout_cust accrec #choose Ac.
Getting started 3-19 The reset-action template is designed to return the session to the “acct” application’s menu screen where it awaits the next transaction. Figure 3-12 shows the reset-action template, and its accompanying screen templates. Figure 3-12 Reset-action template for accounting application Action Template #reset-action template for the getbalance #action template, filename: clr_cust.
3-20 Getting started Figure 3-13 Logout-action template for accounting application Action Template #logout-action template for the getbalance #action template, filename: logout_cust.act logout_cust accounting — — clrcust #exits customer info screen clrmenu #exits applicatoin menu logout #logouts out to prepare for login Screen Template #screen template to clear customer info #screen, filename: clrcust.
4-1 Chapter 4: IVR 2.0/I call flow interface Now that you understand how to script VT100 transactions as action and screen templates, you can begin integrating these templates into your IVR 2.0/I Applications (Figure 4-1).
4-2 IVR 2.0/I call flow interface Figure 4-2 Activating the gateway from a COMI cell START COMA ANSW GDAT MENU 1 2 COMI COMI COMO COMO PDAT PDAT TRS Action Template Screen Templates Input Buffers Output Buffers HANG To Host Computer To develop an application that processes one or more terminal sessions, start as if you were developing any other voice application: • Determine the telephone interaction with the caller and create the corresponding IVR 2.0/I call flow.
IVR 2.0/I call flow interface 4-3 Figure 4-3 COMI cell parameter window start getbalance transaction Meridian IVR VT100 Gateway Development Guide Product release 2.
4-4 IVR 2.0/I call flow interface The following sections describe what you should enter in each area of the parameter window. COMI cell name In order to make the cell easy to identify, includes the name of the action template the cell calls out. The cell name shown in Figure 4-3 is “start getbalance transaction.” Call Audit Enabled Determines if this cell logs the following information to the call audit statistics file (audit_stat.
IVR 2.0/I call flow interface 4-5 COMI cell timeout Select the number of seconds you want the TRS process to wait for the transaction to complete by moving the slider under “Timeout”. There is an available range from 1 to 75 seconds. This indicates the maximum time for the COMI cell to start the transaction and send the necessary input buffers, and for the COMO cell to receive the output buffers.
4-6 IVR 2.0/I call flow interface Setting the COMO cell parameters Once you have set the COMI cell to send information, code the COMO cell to receive information. You must place a COMO cell directly after the COMI cell to complete the transaction, even if the host computer is not sending any data to any output buffers. The TRS process sends verification that the transaction completed successfully or it sends notification that there was an error in the COMO cell.
IVR 2.0/I call flow interface 4-7 Figure 4-4 COMO cell parameter window Receive Balance The following sections describe what you should enter in each area of the parameter window. COMO cell name The cell name shown in Figure 4-4 is “Receive Balance.” The name helps identify the function of the cell. Meridian IVR VT100 Gateway Development Guide Product release 2.
4-8 IVR 2.0/I call flow interface Call Audit Enabled Determines if this cell logs the following information to the call audit statistics file (audit_stat.d): • Application Name • Cell Name • Cell Number • Date and Time of Cell Execution • Contents of the Cell Comment field • Contents of the Call Audit Information buffer The default setting is No. Call Audit Information When you enable Call Auditing, the Call Auditing process logs the contents of this buffer to the audit_stat.d file.
IVR 2.0/I call flow interface 4-9 Note: You must enter the output buffers in the same order they will be used by the TRS process. If your application uses more than 10 output buffers, string COMO cells together until you have enough buffers. Connect the input branch of each subsequent COMO cells to the “MORE DATA” branch of the previous COMO cell. COMO cell branches As shown in Figure 4-5 on page 4-9, the COMO cell has several branches.
4-10 IVR 2.0/I call flow interface Table 4-1 Branches of the COMO cell (continued) Branch MORE DATA Reason the branch would be taken The transaction requires additional output buffers For each COMO cell, use either the “END OF DATA” branch, or the “MORE DATA” branch, but not both. If you use the “MORE DATA” branch, the next cell must be another COMO cell. The last COMO cell should use the “END OF DATA” branch.
IVR 2.0/I call flow interface 4-11 An application using the COMI, COMO, and COMA cells Figure 4-7 shows a sample IVR 2.0/I application that uses the COMI, COMO, and COMA cells to retrieve a customer’s account balance stored on a host computer. This example application uses the action and screen templates created in Chapter 3. A caller activates this example application by pressing “1” after hearing the prompt played by the MENU cell.
4-12 IVR 2.0/I call flow interface Figure 4-7 IVR 2.0/I application accessing the TRS process from the COMI, COMO cells Prior to the execution of this application, the initial-action template is executed (when IVR 2.0/I is started on the application processor). Once a call from a customer is received, the IVR 2.0/I application performs these steps: 555-9001-316 Standard 1.
IVR 2.0/I call flow interface 4-13 Table 4-2 Application cell functions Step Description Cell 1 The ANSW cell answers the incoming call. Cell 2 The GDAT cell plays a prompt requesting the caller to enter an account number. The number entered is stored in the ACCOUNTNUMBER buffer. Cell 3 The MENU cell plays a prompt instructing the caller to press 1 to get an account balance, or press 2 to get an account update.
4-14 IVR 2.0/I call flow interface Figure 4-8 on page 4-15 shows how the COMI and COMO cell parameters relate to the screens defined on the host computer. This transaction uses an action template, getbalance, to call three screen templates - one to choose the Accounts Receivable menu, one to enter the account number, and one for the customer information screen. Each screen template lists the fields that will be accessed. 555-9001-316 Standard 1.
IVR 2.0/I call flow interface 4-15 Figure 4-8 COMI/COMO cell parameters, TRS templates, and VT100 screens Templates Corresponding Screens From Action Template parameter in COMI cell #action template to perform steps #required to retrieve customer's balance #filename: getbalance.act getbalance acctng clr_cust logout_cust accrec #choose Ac. Rec menu acctno #enters account number customer #retrieves balance #screen template to choose accounts #receivable option, filename:accrec.
A-1 Appendix A: Host error messages Terminal Resource Server (TRS) Messages ERR: Unable to reset application environment Meaning: TRS was unable to reset the 3270 system. Action to take: Stop IVR 2.0/I. Make sure the 3270 board has been downloaded correctly. The download command should be included in the .profile file. ERR: Unable to load configuration file Meaning: TRS was unable to load the configuration file trs.conf. Action to take: Syntax error in trs.conf under 3270 directory, revise it.
A-2 Host error messages Action to take: Contact your Nortel service representative. ERR: Create_screen_templates Meaning: TRS was unable to open a screen template file or found a syntax error in the screen template files. Action to take: Check the screen template files. Make sure they are syntax error free, readable text files. ERR: Create_action_templates Meaning: TRS was unable to open an action template file or found a syntax error in the action template files.
Host error messages A-3 ERR: All available sessions are non-operational Meaning: None of the sessions is operational. Action to take: Make sure the communication board has been downloaded correctly. The download command should be included in .profile file. ERR: xx Sessions are Operational Meaning: TRS found that xx sessions are operational. Action to take: Check to see if the number matches the defined number of sessions in the trs.conf file.
A-4 Host error messages Action to take: Contact your Nortel service representative. ERR: xx is not a keyword Meaning: The screen template contains an invalid keyword. Action to take: Revise the screen template. Make sure the KEYWORD (&LOGIN_ID, &PASSWORD, &LU_BUF1 and &LU_BUF2) are spelled correctly. ERR: BD xx SS xxx ERR: start host notify Meaning: TRS was unable to communicate with host on Board xx session xxx. Action to take: Contact your Nortel service representative.
Host error messages A-5 ERR: CH=xx BD xxx SS xxxx: Session not working-manual mode Meaning: This particular session is not working. TRS was unable to attach this session. Action to take: Contact your Nortel service representative. ERR: CH=xx ERR::Parse: Incorrect Action [xxx] Meaning: Action template xxx was not found under the 3270 directory. Action to take: Create an action template which matches the action template name in the COMI or USER cell.
A-6 Host error messages ERR: Send Aid key failed Meaning: TRS did not succeed in sending the aid key to the host. Action to take: Make sure that the host connection exists. ERR: CH=xx Process:ERR: Syntax error for variable operation Meaning: Syntax error in internal variable operation. Action to take: Check the screen templates which use the internal variable operation. ERR: CH=xx Process:ERR: write to screen Meaning: TRS was unable to copy a string to the presentation screen.
Host error messages A-7 Action to take: None. Notification only. ERR: 3270 Envoy Process Startup Meaning: 3270 envoy has been started up. Action to take: None. Notification only. ERR: Process Startup Meaning: The TRS process with no 3270 communication capability has been started up. This TRS process cannot run applications which access a remote host via COMI, COMO, COMA or USER cells. Action to take: None. Notification only.
A-8 Host error messages ERR: CH=xx illegal Command xxx Meaning: TRS received an illegal command from another process. Action to take: Contact your Nortel service representative. ERR: Server Node file trs.node does not exist Meaning: trs.node file was missing from the envoy process node. Action to take: This error message happens in two cases. In the envoy-server case, a TRS envoy cannot communicate with a TRS server running on another node because the trs.
Host error messages A-9 ERR: Send_with_aid: Connect to session xx failed Meaning: TRS failed to connect to session xx before sending the aid key. Action to take: Check the communication system to make sure it works properly. ERR: Send_with_aid: failed with return code of xx Meaning: TRS failed to send the aid key. Action to take: Check the communication system to make sure it works properly.
A-10 Host error messages Action to take: Contact your Nortel service representative. ERR: Create_queue_object: Attempt to create Queue class instance failed Meaning: TRS was unable to allocate memory for the QUEUE_CLASS structure. Action to take: Contact your Nortel service representative. ERR: A request for this channel is already being processed Meaning: The last COMO cell did not retrieve all the output buffers from TRS.
Host error messages A-11 Action to take: Contact your Nortel service representative. ERR: Create_idle_timer: Idle timer memory allocation failed Meaning: TRS was unable to allocate memory for the idle timer structure. Action to take: Contact your Nortel service representative. ERR: Configuration file trs.conf not found Meaning: Configuration file trs.conf was either not found or not readable. Action to take: Create or change the permissions of trs.conf under 3270 directory.
A-12 Host error messages ERR: Protocol missing, specify 3270 or VT100 Meaning: The protocol type was missing from the trs.conf protocol field. Action to take: Make sure that ‘3270’ or ‘vt100’ is specified in the protocol field. ERR: Incorrect syntax for ping action Meaning: The heartbeat action template was specified incorrectly in the trs.conf file. Action to take: Revise the trs.conf file so that the heartbeat field has the correct syntax.
Host error messages A-13 ERR: First LU cannot be less than xx. Meaning: The first session defined in the trs.conf file was less than allowed as specified by xx. Action to take: Revise the session field of the trs.conf file. ERR: Last LU cannot be greater than xx Meaning: The last session defined in trs.conf was greater than allowed as specified by xx. Action to take: Revise the session field of trs.conf file. ERR: An Invalid Board# xx is specified Meaning: The board number xx specified in trs.
A-14 Host error messages ERR: in map.dat:Session xx not defined in trs.conf Meaning: The session number xx defined in the map.dat file was not defined in the trs.conf file. Action to take: Revise the map.dat file or the trs.conf file and make sure that the session number matches. ERR: read data from file ../3270/lubuf.dat Meaning: Syntax error in lubuf.dat file. Action to take: Revise lubuf.dat file. ERR: Invalid Board number xx specified in ../3270/lubuf.dat Meaning: lubuf.
Host error messages A-15 Action to take: Revise the password in lubuf.dat file so that the length of the password does not exceed xxx. ERR: In ../3270/lubuf.dat:lu_buf1 exceeds xx characters Meaning: There are too many characters in the lu_buf1 field defined in the lubuf.dat file. Action to take: Revise the lu_buf1 field in the lubuf.dat file so that the length does not exceed xx. ERR: In ../3270/lubuf.
A-16 Host error messages ERR: Screen name xx must match the file name without .scn Meaning: Invalid screen name defined in the screen template file. Action to take: Revise the screen template file and make sure the screen name is the screen template file name without .scn. ERR: Validate tag xx of screen xxx exceeds xxx characters. Meaning: There are too many characters in the validation tag field defined in the screen template file.
Host error messages A-17 Action to take: Revise the application to keep the screen templates within the limit specified by xx. ERR: Open action file xx failed Meaning: TRS failed to open the action file xx. Action to take: Create or change permissions of the action template file to readable. ERR: Memory allocation failure for ACTION entry Meaning: TRS was unable to allocate memory for the action structure. Action to take: Contact your Nortel service representative.
A-18 Host error messages ERR: reset action xx of the action xxx not found Meaning: The reset action template xx defined in the action template xxx was not found under the 3270 directory. Action to take: Create the appropriate reset template file. ERR: logout action xx of the action xxx not found Meaning: Logout action xx defined in the action template xxx was not found under the 3270 directory. Action to take: Create the appropriate logout template file.
Glossary-1 Glossary VT100 Gateway terms This section lists brief definitions of the terms appearing in this guide. Application With respect to IVR, an application is a program that controls the activity on one or more telephone trunks connected to an AP. With respect to a host computer, it can be any type of program that carries out a task. Application developer A person who creates IVR applications. Application processor A computer or workstation running IVR.
Glossary-2 Channel A telephone trunk within a cluster of APs. COMA Cell IVR cell that cancels a transaction in a VT100 terminal session. It does not terminate the session itself. COMI Cell IVR cell that sends input to a VT100 terminal session via the TRS process. COMO Cell IVR cell that receives output from a VT100 terminal session via the TRS process. Always follows the COMI cell and is necessary for the completion of any transaction initiated by COMI.
Glossary-3 Transaction The function performed by a set of action and screen template files when executed by the TRS. TRS Terminal Resource Server. IVR process that manages the assignment of available VT100 terminal resources on the application processor. Moves data between IVR and a host application. VT100 terminal Terminal type emulated by the VT100 Gateway product. Meridian IVR VT100 Gateway Development Guide Product release 2.
Meridian IVR VT100 Gateway Development Guide Nortel Customer Documentation 522 University Avenue, 14th Floor Toronto, Ontario, Canada M5G 1W7 © 1996 Northern Telecom All rights reserved Publication number: Product release: Document release: Date: 555-9001-316 2.0/I Standard 1.