Blaise CATI Guide
Blaise CATI Guide
Blaise is a registered trademark of Statistics Netherlands.
Copyright © 2004 by Westat, Inc.
ACKNOWLEDGEMENTS
We wish to thank the many Westat staff who contributed to the writing and production of this Guide. In
addition, we wish to thank Statistics Netherlands who provided many important suggestions for this Guide but
who bears no responsibility for our errors or omissions.
FURTHER INFORMATION
All rights reserved. No part of this manual shall be reproduced, stored in a retrieval system, or transmitted by
any means, electronic, mechanical, photocopying, desktop publishing, recording, or otherwise, without
permission from Westat. No liability is assumed with respect to the use of the information contained herein.
While many efforts have been made to ensure the correctness of this book, Westat assumes no responsibility
for errors or omissions.
Terms mentioned in this book that are known to be registered trademarks, trademarks, or service marks are
listed below. In addition, terms thought to be trademarks, registered trademarks, or service marks have been
appropriately capitalized. Use of a term in this book should not be regarded as affecting the validity of any
registered trademark, trademark, or service mark.
Blaise is a registered trademark of Statistics Netherlands.
Microsoft and Windows are registered trademarks of Microsoft Corporation.
All other product names are trademarks, registered trademarks, or service marks of their respective owners.
For more information about Westat software products, including Blaise CATI and Blaise, please visit our web
site at http://www.westat.com/blaise, or contact:
Blaise Services at Westat
1650 Research Boulevard
Rockville, MD 20850 USA
Telephone: 1-301-251-1500 (U.S. and Canada) or (01) 301-251-1500 (International)
Fax: 301-294-2040
Blaise CATI Guide
Copyright © 2004 by Westat, Inc.
Printed in the United States of America.
Table of Contents
1
Introduction ...............................................................................................................1
1.1 Use of This Guide....................................................................................................2
1.1.1 Conventions Used in This Guide.....................................................................3
1.1.2 Commute Example ..........................................................................................3
1.2 The Blaise CATI Approach.....................................................................................5
1.3 Interviewing and Scheduling ...................................................................................6
1.4 Blaise Survey Management Tools...........................................................................7
1.4.1 CATI-Specific Tools .......................................................................................8
1.4.2 DEP-Specific Tools .........................................................................................9
1.4.3 General Survey Tools ....................................................................................10
1.4.4 Four Key Submodules ...................................................................................11
1.4.5 Accessing the Tools.......................................................................................13
2
Core Blaise CATI ....................................................................................................15
2.1 Quick-start CATI Exercise ....................................................................................15
2.2 Getting a CATI Datamodel Up and Running ........................................................19
2.2.1 Commute Example Organization ..................................................................19
2.2.2 Initializing the Survey Database....................................................................21
2.2.3 Adapting a Specification File ........................................................................21
2.2.4 Creating a Daybatch ......................................................................................25
2.2.5 Conducting Interviews...................................................................................27
2.3 Major CATI Datamodel Elements.........................................................................29
2.3.1 Adding INHERIT CATI................................................................................29
2.3.2 Adding User-Defined Parallel Blocks to Handle Dial Results ......................30
2.3.3 Special Case of the Appointment Block........................................................31
2.3.4 Adding CATI-Related Fields.........................................................................32
2.3.5 Declaring Secondary Keys Suitable for CATI Survey Management ............33
2.3.6 Handling Reentry...........................................................................................33
3
Blaise CATI Files.....................................................................................................35
3.1 Blaise Data File .....................................................................................................35
3.2 Daybatch File.........................................................................................................36
3.3 History File............................................................................................................37
3.4 Counts File ............................................................................................................38
3.5 Log File .................................................................................................................39
3.6 Summary of the Blaise CATI Files .......................................................................39
CATI Guide
i
Table of Contents
4
Scheduler Concepts .................................................................................................43
4.1 Daybatch................................................................................................................43
4.1.1 Creating the Daybatch ...................................................................................45
4.1.2 Choosing Which Case to Deliver ..................................................................47
4.1.3 Treating and Exiting a Case...........................................................................48
4.1.4 Reevaluating All Cases..................................................................................48
4.2 Special Features.....................................................................................................49
4.2.1 Routebacks ....................................................................................................50
4.2.2 Time Slices ....................................................................................................55
4.2.3 Time Zones....................................................................................................60
4.2.4 Quotas............................................................................................................61
5
Built-in Management Utilities ................................................................................65
5.1 Blaise CATI Specification Program ......................................................................65
5.1.1 Guidelines for Setting Background Parameters.............................................66
5.1.2 Guidelines for Setting Daybatch Parameters.................................................69
5.1.3 Factors to Consider When Setting Scheduler Parameters .............................70
5.1.4 Different Stages in a Survey..........................................................................72
5.2 Blaise CATI Management Program and History Browser ....................................73
5.2.1 Handling the Daybatch ..................................................................................73
5.2.2 Handling Individual Cases.............................................................................75
5.2.3 Interviewer Reporting....................................................................................76
5.2.4 Survey Progress Reports................................................................................77
5.3 Handling and Diagnosing Scheduler Problems .....................................................78
5.3.1 No Cases Available for Delivery...................................................................78
5.3.2 Some Cases Not Being Touched ...................................................................80
5.3.3 Daybatch Too Small ......................................................................................81
5.3.4 Remaking the Daybatch During the Interviewing Day .................................82
5.4 Disabling Menu Options........................................................................................83
6
Blaise Datamodel and DEP Extensions .................................................................85
6.1 Datamodel Extensions ...........................................................................................85
6.1.1 Interim Coding...............................................................................................85
6.1.2 Final Coding ..................................................................................................86
6.1.3 Overriding the Default Dial Result................................................................87
6.1.4 Minimal or No Use of the Dial Menu............................................................87
6.1.5 Eliminating the Make Appointment Dialog ..................................................88
6.2 DEP Configuration ................................................................................................88
6.2.1 Mode Library.................................................................................................89
6.2.2 DEP Configuration File .................................................................................91
6.2.3 Menu File.......................................................................................................92
6.2.4 Datamodel Properties ....................................................................................95
ii
Blaise
Table of Contents
7
Creating Additional Support Programs ................................................................97
7.1 Support Programs and Timing...............................................................................97
7.1.1 Processing During the Interviewing Day.......................................................98
7.1.2 Overnight Processing.....................................................................................99
7.1.3 Processing Before and After the Interviewing Period .................................100
7.1.4 Adding a Support Program to the Tools Menu............................................100
7.1.5 Support Programs in the Commute Example ..............................................102
7.2 Running Reports..................................................................................................103
7.2.1 How to Generate Report Files .....................................................................104
7.2.2 Report Example ...........................................................................................105
7.3 Reports Based on Refreshed Administrative Database Snapshots ......................107
7.3.1 How to Generate a Fresh Copy of the History File .....................................107
7.3.2 How to Refresh an Administrative Database Snapshot...............................108
7.3.3 Supervisor Treating Case.............................................................................109
7.3.4 Example of a Maniplus Utility that Refreshes Administrative Database
Snapshots.....................................................................................................110
7.4 Appointment-Related Reports .............................................................................112
7.4.1 Different Types of Appointments................................................................112
7.4.2 Future Appointment Load ...........................................................................113
7.4.3 Reporting on Appointments.........................................................................115
7.4.4 Appointment Example.................................................................................115
7.5 History Viewer ....................................................................................................116
7.5.1 Creating a History Viewer...........................................................................117
7.5.2 History Viewer Example .............................................................................118
7.6 Daybatch Viewer .................................................................................................120
7.6.1 Creating a Daybatch Viewer........................................................................120
7.6.2 Daybatch Viewer Example..........................................................................122
7.6.3 Perspective on the JoinID ............................................................................125
7.7 Review and Recode Utilities ...............................................................................126
7.7.1 Creating a Review and Recode Utility ........................................................126
7.7.2 Review and Recode Utility Example...........................................................128
7.7.3 Recoding Utilities in General ......................................................................133
8
Network Topics......................................................................................................135
8.1 Blaise CATI Performance ...................................................................................135
8.2 Blaise Network Architecture ...............................................................................136
8.3 The Local Area Network (LAN) .........................................................................137
8.4 Operational Sources of CATI Network Traffic ...................................................138
8.5 Testing Network Performance.............................................................................139
8.6 Data Integrity and Repair ....................................................................................140
CATI Guide
iii
Table of Contents
Appendix A: Installation and Use of Commute Example Files.................................143
Appendix B: Specification File Parameters ................................................................157
Appendix C: Daybatch Management ..........................................................................167
Appendix D: The CATI Emulator (BTEmula)...........................................................185
Appendix E: Glossary ...................................................................................................193
Index ...............................................................................................................................205
iv
Blaise
1
Introduction
Some defining characteristics of Computer-Assisted Telephone Interviewing
(CATI) are:
• An interviewer conducts interviews over the telephone, and
• The interviewer is guided by, and enters responses into, a computerized CATI
instrument, and
• The work of interviewers, supervisors, and others is coordinated by the CATI
system.
CATI is a complex process that requires sample management, call management,
case delivery, appointments, scheduling, interviewing, reporting, call monitoring,
and other activities to be carefully coordinated. Each of these activities may
function differently from survey to survey or even during the life cycle of a single
survey. For larger CATI operations the complexity and sophistication required of
systems support for these activities is substantial.
This guide explains the CATI features of Blaise® software so that organizations
can make effective use of these features when using Blaise by itself or in
conjunction with other software or systems. The goal is to provide clear
explanations and appropriate examples so that users can understand how the tools,
functions, processes, and parameters fit together to form a Blaise CATI
application. This guide assumes that the reader understands basic terminology and
Blaise concepts. An excellent source of CATI reference information is available
from the Blaise Online Assistant, accessible from the Blaise Control Centre menu
under Help ➤ Help Topics.
Blaise is a software system for computer-assisted interviewing owned and
developed by Statistics Netherlands. Blaise software is licensed to users in the
U.S. and Canada by Westat. Further information about Blaise software is found at
www.westat.com/blaise.
The guide is organized into eight chapters:
• Chapter 1: Introduction. Provides an overview of Blaise CATI and the tools
used in a CATI operation.
CATI Guide
1
Chapter 1: Introduction
• Chapter 2: Core Blaise CATI. Introduces the essential elements of Blaise
CATI operations, explains the tools and functions that run a survey, and
describes the major datamodel elements used in CATI.
• Chapter 3: Blaise CATI Files. Provides detailed information on the major
CATI files important for system operations.
• Chapter 4: Scheduler Concepts. Explains how the Blaise Scheduler works by
detailing how Blaise creates, updates and uses the daybatch file. This chapter
also discusses routebacks, time slices, time zones and quotas, which are used
to tailor the workings of the Scheduler for specific needs.
• Chapter 5: Built-in Management Utilities. Explains how to manage a survey
by using the core functionality provided by the Blaise CATI Specification
program, CATI Management program and History Browser. The final sections
of this chapter explain how to use these utilities to troubleshoot Scheduler
problems.
• Chapter 6: Blaise Datamodel and DEP Extensions. Presents ways in which the
Blaise datamodel can be extended beyond what is presented in Chapter 2, and
explains how to change the look and feel of the Data Entry Program (DEP).
• Chapter 7: Creating Additional Support Programs. Describes how customized
Blaise Manipula and Maniplus programs can be used for such purposes as
initializing the database, generating reports, enhancing the views of the
daybatch and history files provided in the CATI Management program and
History Browser, and providing review and recode utilities.
• Chapter 8: Network Topics. Describes selected network performance and data
integrity issues.
Appendices provide supplemental information. Appendix A: Installation and Use
of Commute Example Files explains the setup of an example survey called
Commute, used throughout the guide for demonstration purposes. Appendix B:
Specification File Parameters provides detailed information on the parameters in
the specification file. Appendix C: Daybatch Management contains in-depth
technical information regarding daybatch management. Appendix D: The CATI
Emulator (BTEmula) explains the Blaise CATI Emulator, and Appendix E:
Glossary provides a glossary of important Blaise CATI terms.
1.1
Use of This Guide
The material assumes the reader has Blaise programming and Blaise Manipula
experience, is proficient in using Windows® computers on a network, and has the
2
Blaise
Chapter 1: Introduction
Online Assistant as an additional reference. A glossary is included as Appendix E
in order to clarify terms. It is worth noting that some everyday terms, like dial
attempt, dial result, and call, are used in very specific ways in Blaise CATI.
1.1.1
Conventions Used in This Guide
• Dial results, Status/Priorities, and FuturePriorities are shown in italics, for
example busy and no need today.
• Names of parameters in the CATI Specification program are shown in italics,
for example Maximum number of dials.
• Names of buttons and names appearing in title bars are shown in bold, for
example OK and Make Dial.
• Names of edit boxes are shown in italics, for example Command line edit box.
• Datamodel field names are shown in italics, for example
CatiMana.CatiAppoint.
• Menu options are shown in italics, and an arrow is used to show navigation
from a menu item to one of its submenu items, for example Management ➤
Create daybatch.
• Branches, sub-branches and sections in the CATI Management and CATI
Specification programs are shown in italics, for example General parameters.
• File names and path names are given in the Courier font, for example
btmana.exe.
• Reserved words, function and procedure names as well as code statements are
given in uppercase in the text, for example DATAMODEL.
• Keystrokes are shown between less than and greater than symbols, for
example, <Enter>.
• Source code is provided within boxes as follows:
DATAMODEL Commute
1.1.2
Commute Example
The Commute survey used in this guide is a person-level survey developed for the
purpose of providing an example to demonstrate key points. Instructions for
downloading and installing it are provided in Appendix A: Installation and Use of
Commute Example Files. The example system requires Blaise 4.6 or later
CATI Guide
3
Chapter 1: Introduction
installed on the workstation. It is recommended that the example system not be
installed on a workstation used for management of Blaise CATI calling
operations. The example system adds custom menu elements to the CATI
Management program (btmana.exe). These might conflict with existing custom
menu elements.
The installation program creates the CommuteSurvey folder, with subfolders
CATI Manual ShortCuts, Development, and Utilities. The following
subfolders are installed in the Development folder:
• Cati. Contains all the source code files (except LIBRARY and INCLUDE files)
that are used to prepare the CATI instrument, the survey database, the survey
instrument files, and the CATI-related files discussed in Chapter 3.
• CATIInc. Contains the CATI-specific files referenced in INCLUDE
statements in the CATI source code.
• DataIn. Contains the ASCII input data file.
• Include. Contains the files referenced in INCLUDE statements in the basic
source code.
• Library. Contains the library files that are used to prepare the instrument.
• Manipula. Contains all the Manipula and Maniplus programs used by the
survey. Files referenced by these programs and not elsewhere included are also
in this subfolder.
• Reports. Contains all report files generated by Manipula and Maniplus
programs.
• Work. Contains all intermediate files used by Manipula and Maniplus
programs.
In addition to placing the CommuteSurvey folder and subfolders in the
designated file space, the installation program also places a folder on the desktop
containing several shortcuts.
Some of these shortcuts start Maniplus programs that are used to execute a
number of programs including the CATI Management and CATI Specification
programs. For example, the Commute CATI Test shortcut uses a Maniplus
program to provide functions commonly used in development and testing. The
Commute Management and Commute Interview shortcuts run similar Maniplus
programs to access the database as if one were in production. The Commute
Management shortcut can be used to launch the CATI Specification program,
4
Blaise
Chapter 1: Introduction
CATI Management program, run overnight programs, and delete completed cases
from the database.
The Utilities folder provides access to additional shortcuts to:
• Install example tools in the CATI Management program Tools menu
• Open Readme text file, and
• Uninstall the Commute example.
1.2
The Blaise CATI Approach
The Blaise CATI approach can be thought of in the six phases shown in the
following table. The first phase, Development of datamodel and customized tools,
begins with the programming of the datamodel using the integrated development
environment provided by the Blaise Control Centre. The survey instrument is
derived from the datamodel, and as part of the first phase, useful Manipula
processes, including a data initialization program, are also created.
Once the survey instrument and data initialization program are finalized, the
second phase, Setup, can begin. This phase involves the initialization of the
survey database and the setting of the parameters in the specification file that
control survey operations.
The next three phases are repeated every interviewing day. Each day needs to
begin with Preparation for daily calling, which involves the creation of a
daybatch. The daybatch contains all the cases in the database that are considered
for delivery by the Scheduler on the current day. Once the daybatch is made,
Daily calling activities can begin. When the interviewing day is over, Daily
overnight processing can start. Overnight processing generally involves making
some modifications in the database and generating assorted reports.
Post-data collection is the last phase. It does not begin until all data collection and
editing efforts have ended.
CATI Guide
5
Chapter 1: Introduction
Table 1-1: Six Phases of the Blaise CATI Approach
1.3
Phase
Steps (Tools)
Development of
datamodel and
customized tools
Setup
•
Preparation for daily
calling
Daily calling
activities
•
Daily overnight
processing
•
Post-data collection
•
•
•
•
•
•
Add CATI-related fields and blocks to datamodel. Choose
useful secondary keys. Program Manipula tools. (Blaise
Control Centre)
Initialize database. (Manipula)
Set specification file parameters. (CATI Specification
program)
Create daybatch. (CATI Management program)
Conduct interviews. (DEP directly, or through Maniplus)
Monitor daybatch and generate on-demand reports. (CATI
Management program, CATI Specification program, History
Browser, custom Manipula and Maniplus processes)
Manage sample including adding new cases, extracting
completes, updating database fields, and generating reports
and files. (Manipula processes that may run within a
Maniplus shell)
Export survey data. (Manipula)
Export questionnaire metadata. (Cameleon)
Interviewing and Scheduling
The default interviewing process consists of the repetition of the following steps:
• An interviewer requests a case.
• The Scheduler determines which of all the currently active cases in the
daybatch to deliver.
• The Scheduler delivers the chosen case to the interviewer.
• The interviewer handles the case.
• The interviewer exits the case, thereby registering a dial result for the case.
Once one case is exited, by default a new case is automatically requested.
A dial result is registered for each dial attempt in accordance with settings in the
specification file. Blaise uses the eight dial results, also called treatments, shown
6
Blaise
Chapter 1: Introduction
in the following chart. The dial results of response, non-response, disconnected or
others are considered to be concluding dial results. Once a case receives one of
these four dial results, it is no longer included in the daybatch.
Response*
Questionnaire completed.
No answer
No answer after several rings.
Busy
Busy signal heard.
Appointment
Appointment recorded.
Non-response*
Respondent unable or unwilling to cooperate.
Answering service
Answering machine or service reached.
Disconnected*
Phone number disconnected.
Others*
Other situations, such as wrong number, pay phone, or
language problems, encountered.
*concluding dial result
1.4
Blaise Survey Management Tools
Blaise CATI is implemented through a collection of tools that can be classified
into three groups:
•
CATI-specific tools,
•
DEP-specific tools, and
•
General survey management tools.
The sections that follow provide an overview of these tools. Four key submodules
of the DEP and CATI Management program are also discussed. This section
concludes by explaining how these tools are normally accessed by developers
through the Blaise Control Centre and by supervisors and interviewers through
desktop shortcuts.
All of these tools are located in the folder where you have installed the Blaise
software, the Blaise system folder.
CATI Guide
7
Chapter 1: Introduction
1.4.1
CATI-Specific Tools
These CATI-specific tools are essential elements of a Blaise implementation.
CATI Specification
Program
The CATI Specification program is used to set the
parameters in the specification file that govern Blaise
CATI operations. These parameters include valid survey
days, crew parameters, delivery parameters, groups of
users, time zones, time slices, quotas, and other settings.
Its executable file is btspec.exe.
CATI Management
Program
The CATI Management program is the supervisory
utility that controls and monitors Blaise CATI operations.
It is used to generate a daybatch containing cases ready
for interviewing and to monitor the progress of the
survey. It is also used to take actions on specific cases. Its
executable file is btmana.exe.
History Browser
The History Browser accesses the information that is
recorded in the history file after each dial attempt. It
displays a productivity summary of individual
interviewers or groups, and a chronological listing of the
history file. Its executable file is bthist.exe.
Scheduler
The Scheduler determines which case to deliver when an
interviewer requests a case. It does this by referencing
and updating the daybatch file. The Scheduler is enabled
in the DEP when the key phrase INHERIT CATI is used in
the datamodel. The fact that the Scheduler is in the DEP
explains why there is not a separate executable file for
the Scheduler.
DEP is the executable file (dep.exe) that the interviewer
uses (see section 4.1.2). It is loaded into each
workstation’s memory. This means that the Scheduler
operates in workstation memory, not on the server. When
an interviewer requests a case, a copy of the daybatch is
sent to the workstation where the Scheduler inspects it
and chooses the most suitable case. The data record itself
is delivered to the workstation for that call.
8
Blaise
Chapter 1: Introduction
CATI Emulator
1.4.2
The CATI Emulator is used to test selected network
traffic issues. Its executable file is btemula.exe. It can
be loaded onto a number of workstations where it will
request cases and run through interviews. When running,
it will exercise the Scheduler and daybatch. Appendix D
explains how to use this program.
DEP-Specific Tools
The following CATI-related datamodel extensions are discussed in further detail
in subsequent chapters.
DEP
The DEP is used to run the survey instrument. The
datamodel rules can be used to control or influence
certain aspects of CATI management. At minimum, some
CATI management blocks and a phone number field
have to be added to a datamodel in order to enable Blaise
CATI. Its executable file is dep.exe.
Modelib Editor
The Modelib Editor is used to set the parameters in the
modelib file. The modelib file is referenced while a
datamodel is being prepared to set the default look and
feel of the datamodel when it is run. Its executable file is
emily.exe. For surveys without a specific modelib file,
Blaise uses the file Modelib.bml in the Blaise system
folder by default.
DEP Configuration
Editor
The DEP Configuration editor is used to set the
parameters in the DEP configuration file. If a DEP
configuration file is specified at run time, its settings
override those in the modelib file. Its executable file is
depcfg.exe.
DEP Menu
Manager
The DEP Menu Manager is used to set the parameters in
the menu file. These parameters control the menu and
speed buttons available when the DEP is run. Its
executable file is menumana.exe. For CATI surveys
without a specific menu file, Blaise uses the file
CatiMenu.bwm in the Blaise system folder by default.
CATI Guide
9
Chapter 1: Introduction
Database Browser
1.4.3
The database browser is used to provide a view of all the
records in the database. This view can be searched and
sorted by primary key, JoinID and secondary keys. The
JoinID, the internal key of a Blaise record, links daybatch
and database records. By default, the first 20 fields are
shown, but a different set of fields can be selected. Its
executable file is dataview.exe.
General Survey Tools
The use of Manipula and Maniplus to develop customized tools is covered in
Chapter 7 of this guide. Monitor, Hospital, and Cameleon are described in the
Online Assistant in further detail.
10
Manipula
Manipula is a batch file processing utility that operates
directly on Blaise data files, ASCII, and other file types.
Typical uses of Manipula include loading a Blaise data
file, reading out completed case data, and generating
reports. Its executable file is manipula.exe.
Maniplus
Maniplus is the interactive extension to Manipula. This
utility incorporates all the functionality of Manipula, as
well as providing a powerful interface to the DEP and
additional functionality such as basic Windows® menus,
dialogs, and tabular displays. Maniplus is the only Blaise
system utility that incorporates two daybatch-specific
functions, DAYBATCH_ADD, and DAYBATCH_DEL. These
functions allow you to modify the contents of the
daybatch during calling without having to use the more
sophisticated API tools. Other CATI uses of Maniplus
include a shell around Blaise CATI, online generation
and review of lists and reports, online outcome coding,
and invocation of the DEP on a selected case.
manipula.exe is the executable file for both Manipula
and Maniplus.
Monitor
Monitor is a small network utility that can be used to see
which cases are in use by various users, and what kinds
of file access each user has. This utility should not be
confused with third party monitoring tools that allow a
Blaise
Chapter 1: Introduction
supervisor to see the screen of an interviewer. Its
executable file is monitor.exe.
1.4.4
Hospital
Hospital checks the integrity of Blaise data files. It can
also rebuild these files. Its executable file is
Hospital.exe.
Cameleon
Cameleon can be used to create a description of the
Blaise datamodel for use by another software package. Its
executable file is cameleon.exe.
Four Key Submodules
The four key submodules are identified by dialog title. They are referenced in
various places in this guide.
Make Dial
The Make Dial dialog appears by default whenever a
case is delivered to an interviewer. It contains a dial
menu and questionnaire data section along with six
buttons. The options presented in the dial menu section
and the fields included in the questionnaire data section
are in accordance with settings in the specification file.
Make Appointment
The Make Appointment dialog appears by default
whenever an interviewer or supervisor chooses to make
an appointment. It contains a date, time and summary
section along with six buttons. The allowable dates and
times are in accordance with settings in the specification
file.
CATI Guide
11
Chapter 1: Introduction
12
Treat Form
The Treat Form dialog appears whenever a supervisor
selects a case in the Forms branch of the CATI
Management program. It is very similar to the Make
Dial dialog except that it contains at least one additional
option, Call as soon as possible, in the dial menu section,
as well as the For whom field. The For whom field,
which contains a drop-down list of all interviewers and
groups listed in the specification file, is only activated
when the Dial menu option of Appointment or Call as
soon as possible is selected.
Case Summary
The Case Summary dialog appears whenever the Zoom
button is selected from the Make Dial or Treat Form
dialog. It also appears whenever a supervisor zooms a
Blaise
Chapter 1: Introduction
case in the Forms branch or a cell in the table in the View
Daybatch branch of the CATI Management program.
The Case Summary dialog contains case, appointment
and call info sections. If a cell in the View Daybatch
branch is zoomed, arrows appear in the lower left corner
if more than one case belongs to the cell. These arrows
can be used to view all relevant cases in turn.
The Case Summary also appears when you double-click
a record in View Daybatch ➤ Browse, or use the show
forms information speed button, .
1.4.5
Accessing the Tools
During the development stage, the tools are accessed through the Blaise Control
Centre, an integrated development environment. Its executable file is
blaise.exe. The Control Centre is accessed by selecting Blaise as a program
from the Startup menu.
When programming the datamodel, it may be useful to open a project and make
the .bla file the primary project file. Then irrespective of which window is the
active window, Blaise references the datamodel to prepare, run, or launch the
CATI Specification tool and other tools.
During the testing and production stage, developers and project managers may
still have to access the Control Centre occasionally for special needs and as part
CATI Guide
13
Chapter 1: Introduction
of trouble-shooting operations. However, there is no need for telephone center
supervisors and interviewers to access the Control Centre. Instead shortcuts are
normally placed on their desktops. They are expected to launch whatever
programs they need either directly or indirectly through these shortcuts.
Interviewers normally have just one shortcut, which launches the DEP. To create
this shortcut:
• Right click on the desktop.
• Select New ➤ Shortcut and the Create Shortcut dialog appears.
• Browse to locate and then select dep.exe. The full pathname for dep.exe
should appear in the Command line edit box.
• After the full pathname for dep.exe, enter the name of the .bla file for the
survey. You do not need to specify any file extension because the dep.exe
automatically looks for the .bdb and the .bmi files, which normally have the
same name. Additional command line options may be needed after the name of
the survey. These options are referenced in the Online Assistant under
Command Lines ➤ Command Line Parameters.
• Click the Next button and the Select a Title for the Program dialog appears.
• Enter the name that should appear on the desktop and click the Finish button.
• Go to the desktop and right click on the new shortcut.
• Select Properties and the Properties dialog appears.
• Select the Shortcut tab and make sure that the full pathname for the folder
containing the survey database appears in the Start in edit box. It is not
necessary to enter the full pathname here if the full pathname already appears
in the Target edit box.
• Click the OK button.
Supervisors often have just two shortcuts on their desktops. One shortcut is used
to launch the CATI Management program and the other shortcut is used to launch
the CATI Specification program. The Tools menu in the CATI Management
program can be configured so that other programs that do not require exclusive
access to the database can be launched from it. This is discussed in Chapter 7.
Overnight processing routines are normally launched from non-Blaise software.
They are usually set to execute when exclusive access to the Blaise database can
be obtained.
14
Blaise
2
Core Blaise CATI
This chapter begins with a quick start CATI exercise to let the reader experience
the CATI management tools and test the interviewing interface. The second
section repeats some of the exercises from the quick start in more depth and
applies other CATI tools and management functions that are used when running a
survey.
The third section describes the steps that were taken to prepare the datamodel for
CATI. It uses the Commute example to illustrate the process, so one can check to
see how it appears after the steps have been completed.
2.1
Quick-start CATI Exercise
Before examining in detail the various processes and components of Blaise CATI,
it is valuable for the reader to experience how Blaise CATI works. The Commute
example that accompanies this guide provides a quick-start exercise in which one
can rapidly perform the main elements of the process.
From the Commute Survey folder located on the desktop or from the
C:\CommuteSurvey\CATI Manual ShortCuts folder, run Commute CATI
Quick Test. This displays a simple menu with the three steps necessary to prepare
and run the Commute datamodel in CATI.
Figure 2-1: Quick-start Test
Select Step 1: Start Specification Program. (Clicking on the Run button is part of
the selection process). This starts the CATI Specification program.
CATI Guide
15
Chapter 2: Core Blaise CATI
Figure 2-2: CATI Specification Program
In the Survey days branch, double-click on today’s date and those of the next few
days to make them active survey days.
Figure 2-3: Survey Days
Save the file and exit (for example, by clicking on the
corner of the display).
16
in the upper right hand
Blaise
Chapter 2: Core Blaise CATI
Select Step 2:Start CATI Management Program from the quick-start menu to
display the CATI Management program. Here a CATI daybatch is created to
allow the Scheduler to deliver cases today.
Figure 2-4: CATI Management Program
To create the daybatch, either click on the sun speed button, , or select
Management ➤ Create Daybatch from the menu. When the Create Day Batch
dialog appears with today’s date, click OK.
Figure 2-5: Create Day Batch
CATI Guide
17
Chapter 2: Core Blaise CATI
In a few seconds the daybatch is created. Click OK to close the results display,
and exit the CATI Management program.
Select Step 3: Run Commute program with CATI to begin interviewing. The
Commute Survey starts with the Make Dial dialog displayed.
Figure 2-6: Running the Commute Survey
In the Make Dial dialog, select a dial result in the Dial menu area and select OK.
To enter the survey, select Questionnaire. Other dial results will be routed to
special blocks in the datamodel for individual handling.
Here are some tips to assist a first-time user of Blaise CATI:
• You may inadvertently enter the questionnaire for a case from the Make Dial
dialog and want to go back to the Make Dial dialog for that case. To do this,
enter <Ctrl-Shift-Home>.
18
Blaise
Chapter 2: Core Blaise CATI
• To exit the Make Dial dialog after finishing one or more cases, click on
Cancel in the Make Dial dialog.
• Then to exit the Commuter Survey – CATI Version DEP, click the
select Forms ➤ Exit from the menu.
symbol or
The three steps in the quick-start exercise are the core functions of Blaise CATI:
setting specifications to guide scheduling and calling, generating a daybatch of
cases eligible for calling today, and requesting cases selected from the daybatch
for calling and interviewing.
2.2
Getting a CATI Datamodel Up and Running
This section explores in detail the process of getting a CATI survey instrument up
and running once the datamodel and Manipula/Maniplus setups have been
programmed. The Commute example is used to illustrate the process.
2.2.1
Commute Example Organization
The design of an appropriate folder structure is one of the first steps in getting a
survey running. In development environments, often separate folders are used for
the primary datamodel source file, include files, external files, library files and the
mode library file. In production and test environments, separate folders can be
used for the prepared instrument, the database, Manipula/Maniplus, external files,
intermediate working files, and final reports.
Unless all the files are in the same folder, Blaise must know in which folder to
look for which files. Normally this is done by using a Blaise project (.bpf file) in
which the various components' names, locations and settings are collected.
For the Commute example, a top-level folder CommuteSurvey is used, with the
Development folder located below it. At the next lower level are specialized
subfolders. Assume that development has already occurred in the Development
folder.
CATI Guide
19
Chapter 2: Core Blaise CATI
Figure 2-7: Commute Folder Structure
In the Commute example, many of the key files are located in the Cati folder.
This is done to simplify learning and experimenting with Blaise CATI. Table 2-1
indicates where the key non-Manipula/Maniplus Commute files are placed during
the installation process.
Table 2-1: Key Commute Files
20
File
Folder
Function
Commute.bla
Cati
Primary datamodel source file.
Commute.bmi
Commute.bdm
Commute.bxi
Commute.bts
Cati
Prepared instrument files. Commute.bmi is
also known as the metadata file.
Cati
Specification file, also known as the survey
definition file (must be with database).
Commute.bdb
Commute.bfi
Commute.bpk
Commute.bjk
Commute.bsk
Modelib.bml
Cati
Database.
Cati
Mode library file (referenced during source
code preparation).
CatiMenu.bwm
Cati
Menu file (referenced by the DEP).
*.inc
Include
CATIInc
Source files included by Commute.bla.
Blaise
Chapter 2: Core Blaise CATI
2.2.2
Initializing the Survey Database
Normally the survey database is initialized by using a Manipula program to read
the records from an ASCII file into the Blaise database. At a minimum, the ASCII
file must contain an identification field and a phone number for each case. In the
Commute example, the Manipula program used to initialize the database is called
CatiDataLoad.man. It uses the ASCII file Catidata.txt, located in the
DataIn subfolder, as an input file.
To initialize the Commute database, open the program CatiDataLoad.man that
is in the Manipula folder and run it. As shown in Figure 2-8, a Blaise database of
4000 records is created in the Cati folder. For the quick-start CATI example, an
initialized database, Commute.bdb, is provided in the CATI folder, so there is no
need to run this program unless you want to refresh the data. (This can also be
done through the shortcuts by selecting the Commute CATI Test shortcut and
then choosing Refresh Blaise CATI database, however, the screen as shown in
Figure 2-8 will not be displayed.)
Figure 2-8: CatiDataLoad.man Populates Commute Database
2.2.3
Adapting a Specification File
A specification file is required to run a survey instrument. This file must be
located in the same folder as the database, and must have the same name as the
database along with a .bts extension. Blaise provides a number of default file
settings, however it is necessary to set a few additional options in the
specification file for CATI to run. Chapter 5 and Appendix B provide more
extensive information on other specification file settings.
CATI Guide
21
Chapter 2: Core Blaise CATI
The Commute example provides a specification file Commute.bts in the Cati
folder. This specification file has specific settings used to help illustrate points
throughout this manual. If you decide to modify or experiment with the
specification file, first make a backup copy of it so that the version will match the
examples in the book. If you experiment with various aspects of the Commute
example and want to restore the original specification file, re-install the entire
Commute example.
To review the specification file settings, make the .bla file for your survey the
active window in the Control Centre and then select Tools ➤ CATI Specification
from the menu bar. Four branches of the specification file are discussed below,
because these are the four branches that normally require modifications when
starting with a completely new specification file. In the Commute example here,
you only need to modify Survey days.
To access the specification file through a shortcut, use the Commute CATI Test
shortcut or the Commute Management shortcut and select the option Start
Specification Program.
Survey Days
Highlight the Survey days branch and a calendar displaying the current month
with today underlined appears. Double-click on today and the next few days to
designate survey days.
Dial Menu
Highlight the Dial menu branch to see the dial menu options that have been
selected for the Commute example.
22
Blaise
Chapter 2: Core Blaise CATI
Figure 2-9: Insert Menu Line Dialog
To add dial menu options, select the Insert button. The Insert Menu Line dialog
shown in the next figure appears. Highlight a treatment and text is filled into the
Menu line edit box. Click the OK button to include this text and treatment in the
dial menu. The Commute example already includes dial menu options for each of
the eight possible treatments. The Questionnaire treatment is required to run the
survey. Other treatments can be included depending on survey requirements.
Figure 2-10: Insert Menu Line Dialog
CATI Guide
23
Chapter 2: Core Blaise CATI
Field Selection
Highlight the Field selection branch and click the Insert button. When the
structure browser appears, notice that there is a check mark by the Phone field. If
the field does not have a check mark, click in the box to the left of Phone to mark
it as a selected field. Notice that Phone is listed in the Field selection branch
table. Click the Edit button and the Edit Field Function dialog shown in Figure
2-11 appears. As can be seen in Figure 2-11, this field has been assigned the
Telephone function. This causes Blaise to recognize the Phone field as the
Telephone field. A CATI survey cannot be run until at least one field has been
tagged as the Telephone field.
Additional fields can be selected and assigned functions if desired. This has
already been done for the Commute example. At this time check the other fields
to see which functions they have been assigned. These functions are discussed in
detail in Chapter 4.
Figure 2-11: Edit Field Function Dialog
Parallel Blocks
Highlight the Parallel block option. All of the parallel blocks in the datamodel are
automatically listed along with a possible treatment in the Parallel blocks branch.
The Questionnaire treatment causes this option to bring up the questionnaire itself
and to transfer control for exiting the case to the questionnaire. All other
treatments cause the case to be exited after the parallel block is completed. To exit
the interview through a particular parallel block and assign the busy dial result to
the case, make sure that this block is given the Busy treatment. To force an exit
24
Blaise
Chapter 2: Core Blaise CATI
through another parallel block and assign the No answer dial result, assign the No
answer treatment to this parallel block, and so on. In the Commute example, all
parallel blocks have already been assigned their correct treatments.
Figure 2-12: Parallel Blocks Branch
After making any desired modifications and reviewing the assignments, save and
exit the file.
2.2.4
Creating a Daybatch
The next step is to create a daybatch. The daybatch is the survey management file
used by the Scheduler to organize the day's calling. The Scheduler cannot deliver
cases unless a daybatch file exists for the current day. To create the daybatch,
make Commute.bla in the Cati subfolder the active window and then select
Tools ➤ CATI Management. The CATI Management program appears as shown
in Figure 2-13. Now either choose the Management ➤ Create Daybatch menu
option or click on the sun shortcut, , on the toolbar.
CATI Guide
25
Chapter 2: Core Blaise CATI
Figure 2-13: CATI Management Program
The Create Day Batch dialog, shown in Figure 2-14, appears at the beginning of
the daybatch creation process. Select the OK button in this dialog to confirm
today’s date. If no date appears on the screen, this means no more days are
available in the survey.
Figure 2-14: Date Confirmation
Next, as shown in Figure 2-15, messages appear on the screen showing that the
data file is being read and the daybatch is being written.
26
Blaise
Chapter 2: Core Blaise CATI
Figure 2-15: Notification That the Database Is Being Read
When the daybatch is completed, the Create Day Batch - Results dialog, shown
in Figure 2-16, appears. This dialog gives a breakdown by FuturePriority for all
the cases in the daybatch. To get more information on the newly created daybatch,
look at the View Daybatch branch and sub-branches in the CATI Management
program.
Figure 2-16: Breakdown by FuturePriority of All Cases in the Daybatch
2.2.5
Conducting Interviews
Interviews can be conducted once the daybatch is created. To invoke the CATI
instrument from the Control Centre, make the .bla file the active window and
use the Run ➤ Run menu option or press <Ctrl-F9>. The DEP session is now
running for the Commute example. One can also use the Commute Interview
shortcut to launch the DEP.
The DEP begins with a Make Dial dialog like the one in Figure 2-17. From the
Questionnaire data section (and Zoom button) of this dialog, information about a
particular case is available. If the Questionnaire option and the OK button are
selected, the questionnaire itself appears and the user can navigate through the
survey for a particular case. Once the survey is completed, Blaise saves the
CATI Guide
27
Chapter 2: Core Blaise CATI
information entered to the database, and the Make Dial dialog automatically
appears for another case. If there are no currently available cases in the daybatch,
a message appears. When this happens, click the OK button to remove this
message from the screen and wait a few minutes. Then select Forms ➤ Get
Telephone Number from the menu bar. If no cases are available after doing this,
refer to Chapter 5.
Figure 2-17: Make Dial Dialog Within the DEP
Options other than Questionnaire can be selected from the Make Dial dialog. For
example, if No answer is selected, the no answer parallel block appears when you
click OK. Fill in information related to the no answer. When this is done, Blaise
saves the data entered and delivers another case. If Appointment is selected, the
Make Appointment dialog appears. Once inside the questionnaire, returning to
the Make Dial dialog is possible by entering <Ctrl><Shift><Home> provided
that data entered for the case has not already been saved.
To stop conducting interviews, use the Cancel button to close the Make Dial
dialog. Then select Forms ➤ Exit from the menu bar or click on the X in the
upper right hand corner to exit the DEP.
28
Blaise
Chapter 2: Core Blaise CATI
2.3
Major CATI Datamodel Elements
Various components must be integrated into a datamodel in order for it to be used
effectively in a CATI environment. Other components are optional, but often
highly recommended. Datamodel modifications can be added to a fully tested
datamodel, or they can be incorporated during the development process. These
modifications include adding required fields, parallel blocks, and secondary key
selection. They may involve changes in specification file settings.
2.3.1
Adding INHERIT CATI
The key word phrase INHERIT CATI must be placed at the beginning of the basic
datamodel after any PRIMARY, SECONDARY, and PARALLEL sections, but before
any FIELDS, AUXFIELDS or LOCALS sections, or blocks or procedures. The phrase
INHERIT CATI does two things. It declares to the Blaise system that the Scheduler
is to be used, and it adds the CatiMana (CATI management) block along with its
three sub-blocks in the datamodel. This means that the very inclusion of the
INHERIT CATI statement in the datamodel source code changes the datamodel
structure.
The CatiMana block holds call-scheduling information, which can be viewed in
the structure browser. The three included blocks are called CatiAppoint, CatiCall
and CatiSlices.
• CatiAppoint. Stores information on the most recent appointment made and can
be used to pre-load appointments.
• CatiCall. Stores information about the very first call and the last four calls. A
call consists of one or more dial attempts. For calls with more than one dial
attempt, the information references the last of the series of dial attempts.
• CatiSlices. Stores day of week and time information for up to 32 dial attempts.
Only information for dial attempts with the dial result of No answer or
Answering service are included. The dial time is registered in respondent time.
The information is used to determine which time slice definitions are no longer
available.
The dial result associated with the most recent dial attempt is always stored in the
CatiMana.CatiCall.RegsCalls[1].DialResult field. For each case, Blaise uses the
value in this field to make scheduling decisions. The DialResult field is an
enumerated type and can only be set to Response, No answer, Busy, Appointment,
Non response, Answering service, Disconnected, and Others.
CATI Guide
29
Chapter 2: Core Blaise CATI
Blaise views the dial results of response, non-response, disconnected and others
as concluding dial results. Cases with any one of these dial results are seen as no
longer available for delivery and inclusion in the daybatch. The other four dial
results are seen as non-concluding. Cases with any one of these dial results are
viewed as available for delivery and inclusion in the daybatch in accordance with
relevant specification file settings and their previous history.
These block definitions are shown in Cati.inc in the Blaise system folder.
2.3.2
Adding User-Defined Parallel Blocks to Handle Dial Results
A customized parallel block can be added to the datamodel for each of the seven
non-questionnaire dial results. In this way, an interviewer can enter information
about the dial result and then directly exit the interview. For example, an
interviewer can get a case, choose the Answering service option from the dial
menu, go to the custom answering service parallel block and record whether a
message was left, and then exit the case. To make this possible:
• Add an answering service parallel block to the datamodel.
• Make answering service a dial menu option with the Answering service
treatment, or dial result, in the specification file.
• Give the answering service parallel block the Answering service treatment in
the specification file.
Dial result-related parallel blocks can be accessed from the DEP as well as from
the dial menu. In Blaise, all parallel blocks are always available in the DEP unless
they are placed on the route only in specific circumstances. Once an interviewer
has someone on the telephone, dial results such as No answer and Busy no longer
make sense. In the following example, four parallel blocks are available only as
long as the Introduction field is empty.
IF Introduction = EMPTY THEN
NoAnswer
AMachine
BusyCall
Disconnect
ENDIF
In the Commute datamodel, the appointment, non-response and other outcome
parallel blocks remain available until the ThankYou field is no longer empty.
30
Blaise
Chapter 2: Core Blaise CATI
A parallel block is not needed for any dial result that will be registered only from
the dial menu and for which additional information is not collected. This may be
the case for a busy. If an interviewer mistakenly enters the DEP and then realizes
that a busy should be registered, he or she can be trained to enter <Control-ShiftHome> to return to the Make Dial dialog.
Each dial result can have more than one parallel block. However, when using the
Make Dial dialog, it is advisable to combine all the information to be collected
related to one dial result in the same parallel block. This is because all dial menu
options in the Make Dial dialog with, for example, the No answer treatment will
automatically be associated with the first parallel block in the specification file
that has the No answer treatment.
2.3.3
Special Case of the Appointment Block
As mentioned in section 2.3.1, Blaise automatically adds an appointment block
called CatiMana.CatiAppoint to the datamodel when the key word phrase
INHERIT CATI is included in the datamodel. This block is automatically assigned
the type identifier TAppMana, and contains all the fields the Scheduler needs to
handle appointments. Its definition is shown below.
BLOCK TAppMana "Appointment block for CATI";
FIELDS
AppointType :(NoPreference,
CertainDate,
Period,
DayOfWeek)
DateStart: :DATETYPE
TimeStart
:TIMETYPE
DateEnd
:DATETYPE
TimeEnd
:TIMETYPE
WeekDays :SET OF TWeekDay
WhoMade
:STRING[10]
ENDBLOCK {TAppMana}
In order to use the Make Appointment dialog, you must also include a userdefined appointment block in the datamodel. Interviewers generally enter
appointment-related information into the CatiMana.CatiAppoint block through
the Make Appointment dialog. The Make Appointment dialog is available in
the DEP only if the user-defined appointment block is listed as a parallel block
with the appointment treatment in the datamodel.
The user-defined appointment block must contain at least one field. In the
Commute example, it contains two fields used for storing remarks, and an
auxfield. The user-defined appointment block must be given the Appointment
treatment in the Parallel block branch of the specification file. The option Disable
CATI Guide
31
Chapter 2: Core Blaise CATI
appointment dialog in the DEP cannot be checked. When the user-defined
parallel block is selected, the Make Appointment dialog first appears followed
by the user-defined appointment block. Once the user-defined appointment block
is completed, the DEP is automatically exited.
Provided there is a user-defined appointment block, the Make Appointment
dialog can be made available directly from the Make Dial dialog. This is
accomplished by including a dial menu option with the appointment treatment in
the Dial menu branch of the specification file.
2.3.4
Adding CATI-Related Fields
A CATI datamodel must contain a phone field usually of type STRING. This field
must be given the Telephone function in the Field selection branch in the
specification file. You can have more than one phone field.
In addition to the Telephone function, four other special functions listed in the
Field selection branch are also available in Blaise CATI. For each of these
functions selected, make sure that appropriate fields are defined. These features
are discussed in Chapter 4.
Most surveys require their own survey management fields. These fields are used
to store information on interim outcomes, final outcomes, relevant times and/or
dates, processing stage and so on. In the Commute example a special block, the
Manage block, has been created as a repository for these user-defined survey
management fields.
In addition, placeholder fields may be desirable. Although not needed at the
beginning of the survey, these fields may prove useful as the survey progresses.
The Commute example contains two placeholder fields, CatiSort and CatiSelect.
If, for example, certain types of respondents need to be excluded later in the
study, these variables can be filled with particular values for these respondent
types using Manipula. If an appropriate daybatch exclusion criterion is defined in
the Daybatch select branch of the specification file, then all cases with such
respondents will be excluded from the daybatch.
Datamodel declarations for CATI-related fields in the Commute example include
those shown in the following example.
32
Blaise
Chapter 2: Core Blaise CATI
Phone : STRING[12]
Wave : 1..20
TimeZone : STRING[3]
TimeSlice : STRING[3]
ForWhom : STRING[10]
CatiSelect : STRING[5] {This can
setup and then used as a daybatch
CatiSort: STRING[5] {This can be
setup and then used as a daybatch
be computed as needed in a Manipula
select criterion}
computed as needed in a Manipula
sort criterion}
Be sure to reference with a KEEP statement those fields that are not always on the
route, but whose values need to be stored in the database.
2.3.5
Declaring Secondary Keys Suitable for CATI Survey Management
Most CATI projects benefit from having several secondary keys. These should be
chosen either to allow users to search for a particular record, or to allow more
efficient batch processing.
Secondary keys are useful because they allow the Blaise data file to be sorted in
different ways. For example, using the telephone number as a secondary key
allows the interviewer or the supervisor to search for a case by phone number.
Setting the dial results and outcome codes as secondary keys allows the data file
to be processed during overnight batch jobs very efficiently when these values are
grouping or selection criteria in the process.
The following are secondary keys declared in the Commute datamodel.
SECONDARY
Telephone = Phone
LastDialResult =
CatiMana.CatiCall.RegsCalls[1].DialResult
Interim_Outcome = Manage.InterimOutcome
Final_Outcome = Manage.FinalOutcome
2.3.6
Handling Reentry
Since many cases are not completed on the first dial attempt, it is often necessary
to reenter a case. Every time a case is reentered, there are some CATI-related
fields that should be empty. For example, the previous information recorded by
the interviewer about an Answering service dial result should be deleted upon
reentry. That way if the interviewer needs to record another Answering service
dial result any previous responses are not evaluated.
In Blaise the way to empty fields upon reentry is by using an auxfield. Since
auxfield data are not stored in the database, an auxfield will always be empty
CATI Guide
33
Chapter 2: Core Blaise CATI
when a case is opened. A code segment can be included in a datamodel whose
execution is contingent upon an auxfield being empty. At the end of the code
segment, a value is assigned to the auxfield so that the segment is only executed
the first time through the datamodel rules. When using an auxfield for this
purpose, be sure to add a KEEP to the auxfield before the code segment. This is a
Blaise convention that is needed to make available the initial auxfield value when
the instrument is started.
In the Commute example the auxfield used for this purpose is named ReEntry.
The relevant code segment is shown in the following example.
ReEntry.KEEP
IF (ReEntry = EMPTY) THEN
NoAnswer := EMPTY
BusyCall := EMPTY
AMachine := EMPTY
Disconnect := EMPTY
OtherOutcome := EMPTY
Manage.InterimOutcome := EMPTY
ReEntry := Yes
ENDIF
In the source code above, the auxfield ReEntry is set to Yes after the survey
management parallel blocks and the InterimOutcome field are emptied. This
ensures that they will not be cleared again unless there is another reentry. Never
empty the CatiMana blocks because they are used by the Scheduler.
34
Blaise
3
Blaise CATI Files
CATI-related information in Blaise® is stored in six types of files. These files are
the data, specification, daybatch, history, counts and log files. All standard reports
provided by the system are derived from information in these files. This chapter
describes the different content, organization, scope and lifetime of each of these
files, with the exception of the specification file, which is addressed in Chapter 5.
The specification file is included in the summary chart at the end of this chapter
for reference.
3.1
Blaise Data File
The Blaise data file contains the interview cases, one record per case. Information
in the Blaise data file is entered by running the DEP, the CATI Management
program (Treat Form dialog) or Manipula and Maniplus programs. The data file
has a .bdb extension. In order to run the DEP or even browse the data file, a
corresponding .bfi, .bjk, .bpk, and possibly other files must appear along with
the .bdb file. If only the .bdb file exists, the other files can be generated by
running a recover operation using the Hospital utility.
The CATI Management information held in the Blaise data file consists of the
system-generated CatiMana blocks; user-defined CATI management fields and
blocks, including parallel blocks; the primary key; the JoinID, which is the
internal key set by the Blaise system linking daybatch and database records; and
potentially various secondary keys. The CatiMana blocks are automatically part
of the datamodel whenever INHERIT CATI is declared. The DEP and the Treat
Form component of the CATI Management program are programmed to
automatically fill in these fields with appropriate values. However, code can be
included in the survey instrument or in Manipula and Maniplus programs to
change some of the values stored in the CatiMana blocks. The three CatiMana
sub-blocks have the following functions:
• CatiAppoint holds appointment information related to the most recent
appointment made, including type of appointment, date, time, and the name of
the interviewer who made the appointment.
CATI Guide
35
Chapter 3: Blaise CATI Files
• CatiCall keeps track of calls made for the case and the last dial result
associated with each call. It holds this information for the first call as well as
the last four calls for the case in the arrayed RegsCalls subblock.
• CatiSlices contains information used to determine time slice availability. The
time and day of the week of up to 32 dial attempts are held.
Either the primary key or the JoinID can be used to link information in the Blaise
data file to appropriate records in other Blaise CATI information files.
3.2
Daybatch File
The Blaise daybatch file is a binary file that is used by the Scheduler. An ASCII
representation of it is generated whenever the daybatch is created, and updated
whenever the daybatch is browsed in the CATI Management module. The binary
version of the daybatch file has the extension .btd, and the ASCII version has
the extension .tdb. The daybatch contains records only for those cases in the
daybatch for that calling day - usually for a subset of records in the Blaise data
file. Aside from the JoinID, the fields in the daybatch file contain information that
is relevant only for the day’s scheduling and is not stored in the database. Records
from a .tdb file may look like the following:
382,5,08:00,19:00,6,0,00:00,0,0,,,
1139,5,08:00,19:00,6,0,00:00,0,0,,,
2539,5,08:00,19:00,6,0,00:00,0,0,,,
3703,5,08:00,19:00,6,0,00:00,0,0,,,
As the daybatch file can be viewed using the CATI Management program, you do
not need to create a datamodel to view it. If you need to access the contents of the
daybatch file for any other purpose than simple viewing, you can use the
following datamodel, which describes the .tdb file, as a starting point.
36
Blaise
Chapter 3: Blaise CATI Files
DATAMODEL DaybatchMeta
TYPE
TStatusCode = (BeingTreated (0),
Busy (1),
NoAnswer (2),
NewAppointmentForToday (3),
NoNeedToday (4),
NotActive (5),
Default (6),
SoftAppointment (7),
MediumAppointment (8),
BusyDefault (9),
BusySoftAppointment (10),
BusyMediumAppointment (11),
HardAppointment (12),
BusyHardAppointment (13),
SuperAppointment (14))
TFutureStatus = (Default (6),
SoftAppointment (7),
MediumAppointment (8),
HardAppointment (12),
SuperAppointment (14))
FIELDS
JoinID : INTEGER[8]
StatusCode : TStatusCode
StartInterval : TIMETYPE
EndInterval : TIMETYPE
FutureStatus : TFutureStatus
NrOfDials : INTEGER[2]
DialInterval : TIMETYPE
NrOfDialsBusy : INTEGER[2]
QuotaIndex : INTEGER[4]
Group : STRING[12]
Interviewer : STRING[12]
TimeDifference : STRING[8]
SliceID : STRING[8]
SliceInfo : STRING[20]
ENDMODEL
The first field in each record in the daybatch is JoinID. The value in this field can
be used to link to records in the database and the history file. The JoinID field is
called the InternalKey in the history file. A record maintains the same JoinID as
long as it is part of the same database. However, once a Blaise-to-Blaise copy is
made of the original database, the same records in the original and copied
databases may not have the same JoinIDs. Although JoinID is a field in the
database, it is not a field that can be accessed in the same way as fields defined in
the datamodel. A detailed discussion of the JoinID is provided in section 7.6.3.
3.3
History File
The history file is a text file in which every case treatment by the interviewer is
recorded. It is a listing of dial attempts, ordered by date and time. For example,
CATI Guide
37
Chapter 3: Blaise CATI Files
multiple records per case are recorded in this file if there have been multiple dial
attempts on the case.
The history file contains values for 15 fields by default, plus any user-added fields
that are designated in the specification file. The user-added fields are appended to
each record in the history file. They are comma-separated, and are appended in
the order in which they appear in the specification file. A file called
history.bla is distributed with the Blaise product. This file contains a
datamodel that, when prepared, can be used to convert the ASCII history file to a
Blaise history database. Adding fields in the Field selection branch in the
specification file will add these fields to the history file, however, it will not
automatically update history.bla. You must add these fields yourself to the
datamodel in the history.bla file in order to create a data definition for the
entire history file. All additional fields should be appended in the order in which
they are delineated in the specification file.
When a supervisor treats a case without running the DEP, the attempt is not
written to the history file, although information is written to the log file. This
occurs when the Treat Form dialog, accessed from the Forms branch of the
CATI Management program, is used with any Dial menu option that does not
have the Questionnaire treatment. If the supervisor uses the Treat Form dialog to
enter the questionnaire, and therefore runs the DEP, record-level data are written
to both the log file and the history file.
Either the primary key or the JoinID can be used to link information in the history
file to appropriate records in other Blaise CATI information files. Note that the
primary key is written into the history file as one field. If the primary key in the
datamodel is composed of several fields, Blaise concatenates all the values
together in one string field in the history file.
3.4
Counts File
The counts file is a binary file under the complete control of the Blaise CATI
system. Its proprietary format is not available to the user, either for reading or
writing. It is created during daybatch creation and is updated during the
interviewing day. It provides the data for the Summary and Quota branches of the
CATI Management program. The counts file is also used by the Scheduler and
DEP when necessary to determine if a quota has been met.
38
Blaise
Chapter 3: Blaise CATI Files
3.5
Log File
The log file keeps track of system events such as daybatch creation, beginning
and ending of interviewer sessions, specification file changes and system errors.
A record is also written to this file every time a supervisor treats a case or an
interviewer treats one that is not delivered by the Scheduler. An example showing
the wide variety of actions that can be recorded in the log file is shown below.
20031208;16:31:29;CatiMana ;Jim;Day batch created for 12/8/2003
(998,2,0,0)
20031208;16:31:52;CatiMana ;Jim;Treat form (5,14)
20031208;16:32:47;Data Entry;Jane;Session start
20031208;16:33:35;Data Entry;Jane;Quota 1 reached (0 removed from
daybatch)
20031208;16:33:35;Data Entry;Jane;Treat form (23,4)
20031208;16:35:40;CatiMana ;Jane;Not active numbers activated
20031208;16:37:04;ManiPlus ;Jane;Session start
20031208;16:38:00;ManiPlus ;Jane;Session end
20031208;16:38:46;Data Entry;Jane;Treat form (23,4)
20031208;16:38:53;Data Entry;Jane;Session end
20031208;16:39:31;Hospital ;Jim;Execution interrupted by user
All events like Treat form (5,14) written to the log file can be linked to records in
other CATI information files, because the first number is always the JoinID of the
case treated. The second number indicates the Status/Priority, with, for example,
the number 14 standing for super appointment. To know what number stands for
each Status/Priority, refer to the TStatusCode type definition presented in section
3.2 in a code box.
3.6
Summary of the Blaise CATI Files
The following chart delineates various dimensions of the six CATI information
files. The standard three-character file extensions are given in parentheses after
the name of the file.
CATI Guide
39
Chapter 3: Blaise CATI Files
Blaise Data
File (.bdb)
Content:
All datamodel fields, including the CatiMana
blocks.
Organization:
Proprietary binary format.
Scope:
All cases.
Lifetime:
Lifetime of the survey, beginning at data
initialization.
Usage:
•
•
•
When Updated: •
•
•
By DEP for data collection.
By CATI Management program Forms
branch.
By Manipula or Maniplus programs.
Whenever values are changed and saved in
the DEP.
Whenever values are changed in the Treat
Form dialog.
Whenever Manipula or Maniplus programs
modify the file.
Specification Content:
Parameter settings that control CATI operations.
File (.bts)
Organization:
Proprietary binary format.
Scope:
Parameters apply to all cases in the database.
Lifetime:
Lifetime of the survey.
Usage:
•
•
•
•
By Scheduler to schedule daybatch.
By CATI Management program to retrieve
appropriate settings, interviewers and
groups and create the daybatch.
By Make Appointment dialog to retrieve
acceptable appointment dates and times.
By Make Dial and Treat Form dialogs to
retrieve appropriate settings.
When Updated: Whenever the CATI Specification program is
used to change and save the specification file.
40
Blaise
Chapter 3: Blaise CATI Files
Daybatch
Content:
(.btd for
Organization:
binary
version, .tdb
for ASCII
version)
14 standard daybatch fields.
•
•
One record per case in proprietary binary
format (.btd).
An ASCII version of the daybatch file
(.tdb) is generated every time a daybatch
is created, and every time the Browse
daybatch view in the CATI Management
program is refreshed.
Scope:
Cases in current daybatch. This is usually a
subset of the cases in the database.
Lifetime:
Re-created whenever a daybatch is made.
Usage:
•
•
When Updated: •
•
By CATI Management program View
daybatch branch.
By the Scheduler to determine the most
suitable case for delivery to an interviewer.
By the DEP or CATI Management program
whenever a case from the daybatch is
obtained or exited, with minor exceptions.
When Maniplus DAYBATCH_ADD or
DAYBATCH_DEL functions are used.
•
•
15 standard history fields.
User-added fields as set in specification file.
Organization:
•
•
One line per dial attempt in ASCII format.
Cases can have multiple entries.
Scope:
All cases with dial attempts.
Lifetime:
The lifetime of the survey, starting with the first
dial attempt.
Usage:
•
History File Content:
(.bth)
•
By History Browser to provide the detail
(productivity) and list views of history data.
When read by Manipula or Maniplus
programs.
When Updated: Every time a case is exited from the DEP.
CATI Guide
41
Chapter 3: Blaise CATI Files
Counts File
(.btc)
Content:
•
•
Various counts that track the progress of the
survey.
There is no case-level information in this
file.
Organization:
Proprietary binary format.
Scope:
Case status summaries.
Lifetime:
Re-created whenever a daybatch is made.
Usage:
•
•
CATI Management program to display the
Summary and Quota tables.
The Scheduler and DEP to determine if a
quota has been met.
When Updated: Every time a case is exited from the DEP.
Log File
(.log)
Content:
•
•
Organization:
One line per system event or record-level action.
Scope:
All cases that have been obtained without being
delivered by the Scheduler.
Lifetime:
Lifetime of the survey.
Usage:
By Manipula or Maniplus programs.
When Updated: •
•
•
•
•
•
42
System events such as an interviewer
logging into the system, system errors, and
daybatch creation.
Record-level events when cases are
obtained without being delivered by the
Scheduler.
Whenever a new DEP session is begun or
ended.
Whenever a case is obtained without being
delivered by the Scheduler.
Whenever the daybatch is activated.
Whenever a quota is reached.
Whenever cases are activated through the
CATI Management program.
For various other system and record-level
events.
Blaise
4
Scheduler Concepts
Scheduling is the method by which cases in the daybatch are selected and
delivered to the interviewer to be dialed. The part of the program that performs
this function is called the Scheduler and is a component of the DEP.
When an interviewer requests a case, the Scheduler checks the interviewer's
profile, the CATI specification file, the time of day, and the daybatch. A case is
then selected from the survey database and delivered to the interviewer. At the
conclusion of a dial, the dial result is sent to the Scheduler, from which the
daybatch, history, and counts files are updated. The survey database is also
updated.
This chapter discusses call scheduling in Blaise®, including how Blaise initializes,
updates, and uses the daybatch file. Key processes described in this chapter
include:
•
Creating the daybatch file,
•
How the case to deliver is chosen based on information in the daybatch file,
•
How case-specific information in the daybatch is changed whenever a case is
handled, and
•
Scheduling or reevaluating the entire daybatch.
Detailed information on call scheduling is presented in Appendix C on daybatch
management.
This chapter also describes four special features that allow the Scheduler to be
tailored for specific needs: routebacks, time slices, time zones, and quotas.
4.1
Daybatch
Blaise uses a daybatch to optimize CATI performance. Survey databases can be
very large, and the database can contain many more records than are needed for
the interviewing day. The daybatch file is used by the Scheduler to determine
which cases to deliver, and normally contains a subset of the records from the
survey database. The daybatch contains only cases needed for that particular day,
CATI Guide
43
Chapter 4: Scheduler Concepts
and for each case only the minimum of information necessary for scheduling.
Because the daybatch is a relatively small file with a limited number of cases, the
constant reevaluation of all cases to determine the next case to be delivered can be
done quickly, without slowing down the interviewing process.
A daybatch file is created using the CATI Management program at the start of
each interviewing day. Whenever a case is delivered or exited, the daybatch file is
updated. In order to maintain the Status/Priorities within the daybatch file, the
Scheduler reevaluates the file at most every five minutes. The reevaluation is
triggered when the first request for a case in the five-minute period is made. Any
other request during the five-minute period does not trigger a reevaluation.
The daybatch file contains the following 14 fields:
44
•
JoinID. The unique number that links a record in the daybatch file with a case
in the database.
•
Status/Priority. The category that indicates how the case can be handled and
its priority. Values are no need today, being treated, default, not-active, no
answer, busy, busy default, new appointment for today, soft appointment,
busy soft appointment, medium appointment, busy medium appointment, hard
appointment, busy hard appointment and super appointment.
•
StartInterval. The time when a case last became active or, if the case is not
active, the time when it will become active.
•
EndInterval. The time that defines the end point of the range beginning with
the time given in the StartInterval.
•
FuturePriority. The category that indicates what kind of appointment, if any,
the case has pending on the current day. Values are super appointment, hard
appointment, medium appointment, soft appointment and default.
•
NrOfDials. The number of separate dial attempts that have been made for the
case as part of the current call in the current daybatch. Once a busy dial result
is recorded, subsequent consecutive busy dials (up to the maximum number
of busy dials set in the specification file) are not considered to be separate dial
attempts.
•
DialInterval. The time (in terms of the five-minute interval) when the most
recent dial attempt on the current day was exited.
•
NrOfDialsBusy. The number of consecutive busy dial attempts registered for
the case, as part of the current dial attempt.
•
Group. The name of the group to which the case should be routed.
Blaise
Chapter 4: Scheduler Concepts
•
Interviewer. The name of the interviewer to whom the case should be routed.
•
QuotaIndex. The quota category to which the case belongs.
•
TimeDifference. The hours and minutes that must be added to or subtracted
from interviewer time to get current respondent time.
•
SliceID. The user-created time slice set to which the case belongs.
•
SliceInfo. The time slice definitions, or time ranges, available to the case on
the current day.
The primary key is not included with the daybatch file. Instead, each record in the
daybatch file is identified by its unique JoinID. The JoinID can never be changed.
4.1.1
Creating the Daybatch
The daybatch file is created from the Blaise survey database. The process looks to
see what cases are available, and selects, sorts and writes the daybatch file.
Blaise automatically excludes all cases that meet one or more of the exclusion
criteria specified in Table 4-1. It then divides the remaining cases into nine
different appointment-related groups, which are ordered in accordance with the
priority assigned to each appointment type. The ordered groups are as follows:
• Hard appointment.
• Preference for a period with day part - last chance.
• Preference for a period with day part.
• Preference for day(s) in the week with day part - last chance.
• Preference for day(s) in the week with day part.
• Preference for a period or day(s) in the week without day part - last chance
(includes hard and super appointments not handled the previous day).
• Preference for a period or day(s) in the week without day part.
• Preference for a day part.
• No appointment, no preference appointment or expired appointment.
If no sort criteria are specified, Blaise sorts the cases in each group in descending
order by the number of calls. A case with one call is placed before a case with two
calls. It then randomly orders cases with the same number of calls.
CATI Guide
45
Chapter 4: Scheduler Concepts
Table 4-1: Criteria Used to Exclude Cases from the Daybatch
Criterion
Exclude if…
Last dial result
Response, non-response,
disconnected or others
No answer and days between no
answer calls has not expired
Answering service and days
between answering machine calls
has not expired
Entirely before Do not call before
time or entirely after Do not call
after time
Greater than or equal to Maximum
number of calls
Not relevant for current day
Last dial result
Last dial result
Crew times
for given day
Number of
calls
Non-expired
appointment
Daybatch
exclude fields
Daybatch
include fields
Time slices
apply
Quotas apply
Telephone
field
Case contains any of the excluded
values
Case does not contain any of the
included values
No remaining available time slices
for current day
Quota has been met for quota
category
Field assigned telephone
functionality is empty
Exclusion overridden
by hard, medium or
soft appt for current
day
No
Yes
Yes
Yes
Yes
---No
No
Yes
No
No
Blaise includes all possible cases in the daybatch that belong to the first priority
group. If there is still room in the daybatch after including all these cases, Blaise
includes as many cases as possible from the second group. Blaise continues
through the groups in order until the daybatch reaches the maximum size set in
the specification file or until all the cases from all the groups have been included
in the daybatch.
When the daybatch is first created, the Status/Priority of all cases is set to notactive. The DialInterval, NrOfDials, and NrOfDialsBusy are all set to zero. The
FuturePriority, a field designating a case’s priority in the daybatch, is set to
default unless the case has a pending appointment for the current day.
46
Blaise
Chapter 4: Scheduler Concepts
4.1.2
Choosing Which Case to Deliver
Whenever an interviewer requests a case, Blaise selects the cases in the daybatch
that meet the following criteria:
•
They are active cases, that is, they have a Status/Priority of default, busy
default, soft appointment, busy soft appointment, medium appointment, busy
medium appointment, hard appointment, busy hard appointment, or super
appointment.
•
They are suitable for this particular interviewer, that is, there are no routeback
restrictions that would exclude delivery to this interviewer.
Blaise accords the highest priority to the Status/Priority of super appointment and
the lowest priority to the Status/Priority of default. The exact ordering of
Status/Priorities is as follows:
• Super. Call as soon as possible (supervisory) appointment made by supervisor
on current day.
• Hard-busy. Busy and exact date and time appointment for current day.
• Hard. Exact date and time appointment for current day.
• Medium-busy. Busy and appointment with a specific day of week, period
and/or time range for which the current day is the last possible day.
Alternatively, busy and a missed exact date and time appointment or
supervisory appointment on the following day.
• Soft-busy. Busy and appointment with a specific day of week, period and/or
time range that is relevant for the current day, but for which the current day is
not the last chance.
• Default-busy. Busy and no appointment, except possibly an appointment with
no date and time specificity.
• Medium. Appointment with a specific day of week, period and/or time range
for which the current day is the last possible day. Alternatively, a missed exact
date and time appointment or a super appointment on the following day.
• Soft. Appointment with a specific day of week, period and/or time range that is
relevant for the current day, but for which the current day is not the last
chance.
• Default. No appointment, except possibly an appointment with no date and
time specificity.
CATI Guide
47
Chapter 4: Scheduler Concepts
Blaise delivers the case with the highest priority. Blaise accords an urgency to
chasing busies so that even a default-busy is given a higher priority than a medium
appointment. If more than one case has the highest priority and routebacks
(described in section 4.2) are being used, Blaise delivers the case that is most
suitable for the requesting interviewer. If routebacks are not being used or more
than one case is most suitable, Blaise delivers the case that has received the
fewest number of dials on the current day. If there are several cases in this
category, Blaise delivers the case with the earliest StartInterval. If there is more
than one case in this category, Blaise delivers the case that is listed first in the
daybatch.
4.1.3
Treating and Exiting a Case
When a case is delivered, its Status/Priority field is set to being treated. When a
case is exited, its Status/Priority field is set to no answer, busy, new appointment
for today or no need today. It is set to busy if the dial result is busy and to no
answer if the dial result is no answer or possibly answering service. The
Status/Priority is set to new appointment for today and the FuturePriority,
StartInterval and EndInterval are changed accordingly if an appointment has been
made that is only relevant for later during the current day. The Status/Priority can
be set to no need today for any of the following reasons:
•
The case has received a concluding dial result. The concluding dial results are
response, disconnected, non-response and others.
•
The case has received an answering service dial result and multiple answering
service calls are not allowed on the same day.
•
The case has received an appointment for some other day or days. Even if the
current day is included in the set of possible days, the Status/Priority
nonetheless goes to no need today.
Occasionally a case can be completed and exited, resulting in the meeting of a
quota target. Whenever this happens, the Status/Priority of all non-completed
cases with default FuturePriority that belong to the relevant quota category is
automatically changed to no need today.
4.1.4
Reevaluating All Cases
Blaise views the day as divided into five-minute intervals, each of which begins
when the number of minutes is evenly divisible by five. Whenever an interviewer
requests or exits a case, the Scheduler first determines if the daybatch has already
48
Blaise
Chapter 4: Scheduler Concepts
been reevaluated during the current five-minute interval. If the daybatch has not
been reevaluated, Blaise proceeds to reassess the Status/Priority of all cases in the
daybatch.
The Status/Priorities of no answer, busy and new appointment for today are
considered temporary and are changed during the reevaluation process. Cases
with the Status/Priority of busy and no answer are also given a new StartInterval
and, when time slices apply, EndInterval in accordance with parameters set in the
specification file. Some of these cases may end up with a Status/Priority of no
need today because they have received the maximum number of dials set in the
specification file.
For cases with a Status/Priority of not-active or default if the current time is
between the StartInterval and the EndInterval, the Status/Priority is set to default.
If the current time is after the EndInterval, the case’s Status/Priority is set to no
need today. If the current time is before the StartInterval, the Status/Priority is set
to not-active.
4.2
Special Features
Routebacks, time slices, time zones and quotas are four optional delivery control
features available in Blaise CATI. This section explains how to use each feature,
and discusses any special considerations for that feature.
In the CATI Management program, the View Daybatch ➤ Browse sub-branch
shows how these features are currently being applied to individual cases in the
daybatch. Figure 4-1 shows part of the daybatch file using the Commute example.
The size of the individual columns in this figure has been configured to display
clearly the Interviewer, Group, QuotaIndex, TimeDifference, SliceID and
SliceInfo fields. To change the order in which you want the fields displayed, just
drag the columns. Figure 4-1 is referenced throughout this section.
CATI Guide
49
Chapter 4: Scheduler Concepts
Figure 4-1: View of Daybatch File
4.2.1
Routebacks
The routeback feature allows the delivery of each case to a particular interviewer
or group of interviewers. This feature is used for one or more of the following
reasons.
• Familiarity. Interviewers are often asked to handle cases with which they are
familiar.
• Qualifications. Certain interviewers may be better qualified to handle certain
cases, for example, based on fluency in different languages.
• Clear division of caseload. The study design may require an individual
interviewer or group to explicitly own a set of cases.
• Creation of queues. This permits concentration on different types of cases at
different times based on queue designation.
Routebacks also allow more effective use of each individual interviewer than
would otherwise be possible. When an interviewer requests a case, if there is
50
Blaise
Chapter 4: Scheduler Concepts
more than one case in the highest priority category and available for delivery to
the interviewer, Blaise delivers the case that is most suited to the interviewer.
Suitability is determined in the following order:
1. Cases with the interviewer’s name in the interviewer field in the daybatch file.
2. Cases with the name of the interviewer’s main group in the group field.
3. Cases with the name of one of the interviewer’s secondary groups in the
group field.
4. All other cases.
To use routebacks:
• Define interviewers and groups, if any, in the Users branch of the CATI
Specification program.
• Give To whom functionality in the Field selection branch of the specification
file to a string field in the datamodel. This field is then known as the To whom
or routeback field.
• Set the routeback field for each case whose delivery is to be directed to one of
the interviewers or groups listed in the specification file. This can be done in
several ways, which are described below. A case with an empty routeback
field or a routeback field containing a name not given in the specification file
can be delivered to anyone.
As many interviewers and groups as needed can be defined in the specification
file. Each interviewer can be assigned to none, some or all of the groups. If an
interviewer is assigned to one or more groups, one of these groups must be chosen
as his or her main group.
If the name of an interviewer is in the routeback field, this name appears in the
interviewer field in the daybatch file. If the interviewer belongs to one or more
groups, the name of the interviewer’s main group is automatically filled into the
group field in the daybatch file.
The only way the group field can be empty if the interviewer field is not empty is
if the interviewer does not belong to any group. If the routeback field contains the
name of a group, this name is written into the group field in the daybatch file, and
the interviewer field in the daybatch file is left blank.
CATI Guide
51
Chapter 4: Scheduler Concepts
There are several different ways in which a name can be placed in the routeback
field in the database:
• A case can be added to the database with a name already in its routeback field.
• Overnight routines can place a name in the routeback field.
• If Routeback to interviewer is selected in the specification file and an
appointment is made, Blaise automatically writes the name of the interviewer
making the appointment into the routeback field. If Routeback to group is
selected, Blaise writes the name of the interviewer’s main group into the
routeback field when an appointment is made. In this way, cases end up routed
back to the interviewer or group familiar with them. If the user does not want
these changes to occur, the Do not change routeback option should be
selected. If the Status/Priority of the case does not go to no need today, the
interviewer and group fields in the daybatch file are updated along with the
database.
• While the DEP is running, code can be triggered that places a name in the
routeback field. An example of this is presented in section 6.1.3. If the
Status/Priority of the case does not go to no need today, the interviewer and
group fields in the daybatch file are updated along with the database.
• If any kind of appointment, including a super appointment, is made using the
Treat Form dialog, the For whom edit box with a drop down list is activated.
The name of any interviewer or group can be selected from the drop down list.
If the Status/Priority of the case does not go to no need today, the interviewer
and group fields in the daybatch file are updated along with the database.
If no routeback field is declared in the specification file, when the daybatch is
made, the interviewer and group fields in the daybatch are empty. However,
during the interviewing day, names can be placed in these daybatch fields. This
can happen by using the Treat Form dialog or the DAYBATCH_ADD function in
a Maniplus utility. If there are names in the interviewer or group field, the
Scheduler applies routeback functionality irrespective of whether a routeback
field is declared in the specification file.
Cases with a soft appointment, no preference appointment or no appointment can
be delivered only to the interviewer specified in the daybatch file. If the
interviewer field is empty, these cases can be delivered only to members of the
group specified. If both of these fields are empty or contain names that are not
listed in the specification file, these cases can be delivered to anyone.
52
Blaise
Chapter 4: Scheduler Concepts
For cases with medium, hard and super appointments, the user has the option of
specifying de-activation delays in the specification file. A de-activation delay is
the length of time in minutes that the Scheduler has to reserve a case for a specific
interviewer or group. De-activation delays are used with appointments for cases
designated to be routed back to a particular interviewer or members of an
interviewer group. When the interviewer or group members are not currently
available, de-activation delays determine how long to wait before taking other
action. As shown in Figure 4-2, there are four different de-activation delays in the
specification file. These settings are accessed by selecting the General parameters
branch in the CATI Specification program, and then clicking on the More button.
To understand how these delays work, assume that a case has a hard appointment
for 9 a.m. and that the Interviewer de-activation delay (hard) is 20 minutes and
the Group de-activation delay (hard) is 10 minutes. The following three scenarios
are possible:
• The interviewer field contains the name of an interviewer, but the group field
is empty. Delivery is restricted to the interviewer until 9:20. After 9:20, the
case can be delivered to anyone.
• The interviewer field is empty but the group field contains the name of a
group. Delivery is restricted to members of the group until 9:10. After 9:10,
the case can be delivered to anyone.
• Both the interviewer and group fields contain names. Delivery is restricted to
the interviewer until 9:20. Between 9:20 and 9:30, delivery is restricted to
members of the group. After 9:30, the case can be delivered to anyone.
Hard de-activation delays are also applied to super appointments. Medium deactivation delays apply only to medium appointments and do not have to be the
same as those for hard appointments. The status of a de-activation delay can be
determined by viewing the daybatch file or by zooming the case in the CATI
Management program or in the Make Dial dialog in the DEP. If a de-activation
delay has expired, an asterisk appears in the daybatch file before the name of the
interviewer or group. Also, the term expired appears in parentheses after the name
of the interviewer or the group in the Case Summary dialog, which appears if
you double-click on a case while browsing the daybatch, or whenever you zoom a
case.
CATI Guide
53
Chapter 4: Scheduler Concepts
Figure 4-2: More Scheduler Parameters
If Expire on de-activation delays only is not checked in the specification file,
Blaise honors the de-activation delays only if the relevant interviewer or someone
from the relevant group is on the system. If Expire on de-activation delays only is
checked, Blaise honors the de-activation delays irrespective of who is on the
system. To have exclusive case ownership all the time, set all the de-activation
delays to 1440 minutes (for all day) and check Expire on de-activation delays
only in the specification file.
In some surveys, it is desirable to place cases in different queues and then vary
the relative priority accorded to each of the queues during the interviewing day.
This is done by creating a group for each queue and writing the appropriate queue
name in the routeback field for each case. Then during the interviewing day,
increase the relative priority of one queue by placing more interviewers in it. A
queue can be completely blocked by removing all interviewers from it and by
making sure all de-activation delays cannot expire.
In the Commute example, only two groups, SPAN (Spanish) and DIF (Difficult),
are defined in the specification file. Most interviewers do not belong to either of
these groups. When the database is initialized, only a few cases are placed in each
of these groups. While interviewing occurs, cases for which a non-response of
54
Blaise
Chapter 4: Scheduler Concepts
any kind is registered are automatically assigned by the Commute code to the DIF
group. Cases for which Spanish is recognized as the spoken language are likewise
assigned to the SPAN group. The group de-activation delays are set to 1440 to
make sure that SPAN and DIF cases are not delivered to anyone else. On a given
day, to increase the rate at which DIF cases are delivered, assign more
interviewers to the DIF group.
In Figure 4-1, a name appears in the Interviewer field for the three cases with
super appointments. A supervisor specified these names while making the
appointment. An asterisk appears in front of each name because the interviewer
de-activation delay has expired. The cases routed to Carl, who belongs to none of
the groups, can now be delivered to anyone. The case routed to Sylvia can only be
delivered to someone in the SPAN group, since this is Sylvia’s main group.
4.2.2
Time Slices
Time slices are used to control the delivery of no answer cases. No answer cases
are those cases that do not have an appointment, other than a no preference
appointment, and whose most recent dial result was no answer or answering
service. Use this feature for one or more of the following reasons:
• To focus calls when respondents are likely to be available during specific time
periods on various days of the week.
• To make sure that no answer calls are spread out during the day.
• To avoid no answer calls during certain days, or certain times during certain
days.
Without the use of time slices, calls to no answer cases are spread out exclusively
based on the Minimum time between ‘other’ no-answer setting in the specification
file. This may mean that a case is delivered during more or less the same times
each day.
Setting Time Slice Parameters
The Time slices branch of the specification file for the Commute example is
shown in Figure 4-3. One time slice set, called S-1, is defined. The first six of the
nine time slice definitions are shown in the figure. Each definition includes one or
more days of the week, a time range and the maximum number of tries. Time
ranges are expressed in respondent time (see section 4.2.3 on time zones).
CATI Guide
55
Chapter 4: Scheduler Concepts
Figure 4-3: Time Slice Specification
The greater the perceived likelihood of someone answering during a particular
time slice definition, the greater the number of tries associated with this
definition. Note that the number of tries refers to tries on subsequent days, as only
one try per time slice is permitted on any given day. Overlapping time ranges for
the same day of the week are not allowed and hence do not appear. Various day
and time ranges, such as Friday after 6:30 p.m., are excluded. Time slice
definitions can be modified using the associated Edit button to access the Edit
Time Slice Definition dialog, shown in Figure 4-4.
56
Blaise
Chapter 4: Scheduler Concepts
Figure 4-4: Edit Time Slice Definition
If time slices apply and continue to apply, a no answer case can be delivered once
during each available time slice definition on a given day if Same Day is set to
Yes and Maximum number of dials is set high enough in the specification file.
Same Day can be set to Yes by checking Allow slices to be tried on same day in
the Edit Time Slice Set dialog, shown in Figure 4-5. This dialog is accessed from
the Edit button to the right of Time slice sets in the Time slices branch of the
specification file.
Figure 4-5: Edit Time Slice Set
CATI Guide
57
Chapter 4: Scheduler Concepts
If Same Day is set to No, the case can only be delivered once that day. When
Same Day is set to No, a case that continues to receive only no answers on
subsequent days accumulates calls that consist of only one dial attempt until it has
no more time slice tries or calls left. Then it is no longer included in the daybatch.
If time slices apply and a case has no more available time slice definitions left for
the current day, it is not included in the daybatch. A no answer case that has no
available time slice definitions left for any day is never again included in the
daybatch.
The total number of tries across all time slice definitions should be approximately
equal to the number of tries that can be expected per day multiplied by the
Maximum number of calls set in the General parameters branch of the
specification file. Note that a call is defined as all tries, or dials, made on a given
day, with some exceptions. If Same Day is set to No, the number of tries that can
be expected per day is one. If Same Day is set to Yes, the expected number of
tries per day can never be greater than the Maximum number of dials limit set in
the General parameters branch of the specification file.
The expected number of tries per day may be somewhat less than Maximum
number of dials if the daybatch is so large relative to the number of interviewers
that most no answer cases do not reach their Maximum number of dials limit on
the average day. In the Commute example, although four different time slices are
defined for Monday, Tuesday, Wednesday and Thursday, only three of these
definitions can be tried on a given day because the Maximum number of dials is
set to three.
Blaise always makes sure that the Minimum time between ‘other’ no-answer
setting, selected using the More button in the General parameters branch of the
specification file, is respected. When using time slices, this minimum amount of
time is added to the time a case was exited to determine the earliest possible time
that the case can be delivered again. If any part of the range included in a time
slice falls before this earliest possible time, Blaise does not deliver the case during
the entire time slice. Using the Commute example, if a no answer case is exited at
3:40 on Monday, it cannot be delivered again until the 6:30 - 9 p.m. time slice.
This is because the Minimum time between ‘other’ no-answer is set to 30 and 3:40
plus 30 is 4:10, which falls within the 4 - 6:30 p.m. time slice definition.
Once a time slice set is defined, every time the daybatch is made, appropriate
information is filled into the SliceID and SliceInfo fields in the daybatch file for
each case. The SliceID field contains the name of the relevant time slice set and in
some cases a minus sign in parentheses. If the minus sign is present it indicates
58
Blaise
Chapter 4: Scheduler Concepts
that time slices do not apply, because the last dial result was not no answer or
answering service, or because the case has a pending appointment for the current
day. The SliceInfo field contains the numbers of the time slice definitions that are
still potentially available for the current day. These numbers reflect the order in
which the definitions are listed in the specification file. Blaise knows for which
time slice definitions tries are still available for the current day by reviewing the
day and time information stored for each case in its CatiMana.CatiSlices block.
Blaise only stores the day and time of dial attempts with dial results of no answer
or answering service in this block. A time slice definition is available only if the
number of times that it has been attempted on previous days is less than the
maximum number of tries allowed for it.
In Figure 4-1, JoinID 13 shows that time slices apply because there is no minus
sign in the SliceID field. The StartInterval and EndInterval for this case are 12:00
and 16:00, respectively. These times have been set in accordance with the time
range for the second time slice definition in the specification file.
Multiple Time Slice Sets
To use more than one time slice set:
• Give Time slice functionality in the Field selection branch of the specification
file to a three-character string field in the datamodel. This field is subsequently
known as the time slice field.
• Define all possible time slice sets in the Time slices branch of the specification
file.
• Set the time slice field for each case in the database to one of the time slice
codes given in the specification file. Cases for which the time slice field is
empty are treated as if they are in no time slice set since a field has been given
Time slice functionality.
Time slice sets can be redefined each time the daybatch is re-created. However,
with the exception of changing the Max try parameter for an existing definition,
time slice definitions cannot be modified during the interviewing day without
wiping out all time slice applicability until the daybatch is re-created. Once time
slice applicability is wiped out, the delivery of no answer cases is spread out
based only on the Minimum time between other no answer setting in the
specification file, with no reference to time slice definitions.
CATI Guide
59
Chapter 4: Scheduler Concepts
4.2.3
Time Zones
The time zone feature is used if some or all respondents are located in a different
time zone than the interviewers. Time zones define the time differences between
the interviewer's location and the respondent's location.
To use time zones:
• Give Time zone functionality in the Field selection branch of the specification
file to a three-character string field in the datamodel. This field is subsequently
known as the time zone field.
• Define the time zones in the Time zones branch of the specification file. The
difference field should be set to 0 for the call center time zone. It should be set
to 60 for the first full time zone to the east of the call center time zone and to 60 for the first full time zone to the west.
• Set the time zone field for each case in the database to one of the time zone
codes given in the specification file. Cases for which the time zone field is
empty are treated as if they are in the same time zone as the call center.
Interviewer time is the relevant time in the interviewer’s time zone. Respondent
time is the relevant time in the respondent’s time zone. Appointments are made
and stored in the database in respondent time. Time slice definitions are expressed
in respondent time. The No calls time limits in the Time zones branch of the
specification file are given in respondent time. However, all information
displayed on the screen in the View daybatch branch of the CATI Management
program and the Case Summary dialog is in interviewer time.
When switching back and forth from daylight savings to standard time, no
changes are needed in the specification file or the database because the same
relationships adhere between the different time zones. The only exception to this
is for localities that use standard time year-round. For these localities, the user
needs to go through the database twice a year changing their particular time
zones.
Through version 4.5, Blaise does not handle interviewing after midnight. This
means that appointments for the same day (respondent time) for any times later
than 11:55 p.m. call center time cannot be set.
Starting in version 4.6, Blaise allows interviewing past midnight call center time.
Once Allow past midnight calling is checked in the specification file and the end
time (but not the start time) of the last crew is set after midnight, the Scheduler
continues to deliver appropriate cases until the specified end time. In these
60
Blaise
Chapter 4: Scheduler Concepts
circumstances, the Make Appointment dialog can be used to set appointment
times that involve past midnight delivery call center time. For example, with an
EST call center, an appointment can be set at 10 p.m. PST even though the case
could not be delivered until 1 a.m. the next day at the call center.
In the Commute example, the TimeZone field is given the Time zone function in
the specification file. As shown in Figure 4-6, four time zones are defined in the
Time zones branch of the specification file. Interviewer or call center time is
expressed in Central Time. Cases are entered into the database with a telephone
number in their Phone field and with a time zone code in their TimeZone field.
Any changes in these fields can be made using the Make Dial or Treat Form
dialogs because Show in dial screen and Edit allowed are checked for both these
fields in the Field selection branch of the specification file.
Figure 4-6: Time Zone Specification
In Figure 4-1, JoinID 21 demonstrates how time zones are applied behind the
scenes to change respondent time into call center time. Both the start interval and
end interval have been set in accordance with the second time slice definition for
this case that goes from 12 p.m. to 4 p.m. respondent time. Since this case is one
time zone ahead of call center time, the 12-4 p.m. range has been converted to an
11 a.m. to 3 p.m. range.
4.2.4
Quotas
Quotas are used when only a limited number of completes are required for
specified categories of cases. A completed case is one whose most recent dial
CATI Guide
61
Chapter 4: Scheduler Concepts
result is Response. Once the target has been met for a particular category, cases
belonging to the relevant category are no longer included in the daybatch. If such
cases are already in the daybatch with default FuturePriority at the time that the
target is met, their Status/Priority is automatically converted to no need today.
Normally quotas are used because of external requirements imposed on the
survey. Otherwise, consider using quotas during an occasional interviewing day
to move various categories of cases as a group to no need today.
To use quotas, give Quota functionality to the desired field(s) in the Field
selection branch of the specification file. Only enumerated type fields can be used
as quota fields.
The Quota control branch of the specification file is displayed and each possible
quota category is automatically listed once fields are given quota functionality. If
there is one quota field, the total number of quota categories is equal to the
number of possible answers defined for this field. If there are two quota fields, the
total number of quota categories is equal to the number of possible answers for
one field multiplied by the number of possible answers for the other field. For
each quota category, enter the target number of cases that must be completed.
If quotas are used, refer to the Quota branch of the CATI Management program to
view the progress that is being made toward reaching each of the individual
targets. As soon as the target is met for a particular category, the Status/Priority
of all cases in the daybatch with default FuturePriority belonging to this category
is automatically changed to no need today. Cases in a particular category are not
included in future daybatches once the quota target has been met.
In the Commute example, the AgeCategory and Job fields are both given the
quota function. As shown in Figure 4-7, in the Quota control branch of the
specification file, each of the eight possible quota categories is given a count or
target of 200 completed cases.
62
Blaise
Chapter 4: Scheduler Concepts
Figure 4-7: Quota Control Specification
The quota category to which each case in the daybatch belongs is shown in the
QuotaIndex field in the daybatch file. This can be seen in Figure 4-1. When the
daybatch is created, the number of the quota category is placed in the QuotaIndex
field for each case. For example, in the Commute survey, a 2 is placed in the
quota index field for cases belonging to the AgeCategory = UpTo21 and Job = No
category. If the category has yet to be determined, a 0 is placed in the QuotaIndex
field. As interviewing occurs, whenever a case is exited its QuotaIndex field is
updated. If enough information is available to determine the quota category, the
number of the quota category is set, otherwise -1 is placed in the QuotaIndex
field.
Blaise references the counts file to determine which quota targets have been met.
The counts file is completely remade every time a new daybatch is created. This
means that completed cases should not be removed from the database if they are
to be included in quota counts.
CATI Guide
63
Chapter 4: Scheduler Concepts
64
Blaise
5
Built-in Management Utilities
This chapter discusses several management utilities that are integrated with the
Blaise® software. These utilities assist in setting up and managing the day-to-day
operations of a Blaise survey:
• The CATI Specification program provides access to the specification file,
which contains the settings that control many aspects of the CATI operation.
• The CATI Management program provides access to the daybatch file and to a
variety of tools, including options to manipulate the daybatch and individual
cases, and run reports.
• The History Browser provides access to the history file, as well as detailed
interviewer productivity information.
This chapter discusses how to identify and resolve Scheduler problems using
these utilities. It concludes with an explanation on how to disable various CATI
Specification and CATI Management program menu options.
5.1
Blaise CATI Specification Program
The CATI Specification program is a management utility that allows viewing and
modification of the specification file. This file contains more than 50 different
parameters that can be used to control various aspects of a Blaise CATI operation.
As seen in the following figure, the specification file is divided into 11 main
branches. Note that some of these branches will not appear until they become
relevant. For example, the Quota control branch is only shown if one or more
fields are given Quota functionality in the Field selection branch.
CATI Guide
65
Chapter 5: Built-in Management Utilities
Figure 5-1: Specification File
Specification file parameters can be viewed as background, daybatch or Scheduler
parameters. Background parameters are fixed by overall design or by call center
circumstances and are not generally influenced by calling operations. Daybatch
parameters allow adjustments to be made to the size, composition or order of the
daybatch. Scheduler parameters allow adjustments to be made to the routine
operations of the Scheduler. Background parameters can be expected to change
relatively infrequently, if at all. Daybatch parameters can be expected to change
somewhat, especially as the survey goes from one stage to another. Scheduler
parameters can change frequently, even from hour to hour, as field managers try
to fine-tune the operations of the Scheduler.
This section provides guidelines for setting background, daybatch and Scheduler
parameters. Ways to vary Scheduler parameters during the lifetime of a survey are
discussed, and Appendix B: Specification File Parameters provides detailed
information on specification file parameters. The effect of changing each of these
parameters during the interviewing day is covered in this appendix. For most
specification file parameters, changes that are made will take effect immediately.
Specification file parameters are discussed in-depth in Chapter 10 of the Blaise
Developer's Guide.
5.1.1
Guidelines for Setting Background Parameters
Although situations may vary, the following guidelines are useful in setting
background parameters.
66
Blaise
Chapter 5: Built-in Management Utilities
•
Survey days. Set survey days in accordance with overall survey design. Be
sure that call center holidays are not included as survey days. Daybatches can
only be created and appointments can only be scheduled for defined survey
days.
•
Crew parameters. Set crew parameters in accordance with survey design and
call center circumstances. Times and crew sizes may need to be modified as
the survey progresses in order to accommodate unexpected patterns in
respondent availability. It is very important to get the daily start time of the
first crew and the end time of the last crew correct so that appointments will
not be scheduled when crew are not available. Do not be particularly
concerned about getting crew sizes correct, because Blaise only uses crew
sizes to spread out soft and medium appointments that do not have specific
time ranges when the daybatch is made.
•
Appointment parameters (under General parameters). Normally the Do not
change route back radio button is enabled. However, if one is using a system
in which the interviewer who makes an appointment is familiar with the case,
it may be desirable for that interviewer to be the one to continue with the
interviewing process when the case is next attempted. In this case, enable the
Route back to interviewer radio button. Set the Appointment interval to the
time intervals that are desired for the default appointment block. For example,
if 15 minutes is selected, then appointment times on the hour, 15, 30 and 45
minutes past the hour may be set. Set the Appointment buffer to the
approximate length of the average interview. The last possible appointment
time shown in the Make Appointment dialog is equal to the ending time of
the last crew minus the number of minutes in the Appointment buffer.
If you are using version 4.6 or higher and want to interview past midnight call
center time, check Allow past midnight calling. Once you have checked this
box, you can enter an end time for the last crew that extends past midnight
and into the a.m. hours of the next day. The start time of the last crew,
however, must be before midnight.
•
Do not allow multiple same day answering machine calls (under General
parameters). Enable this parameter only if a case is no longer to be delivered
on a given day once it receives a dial result of answering service. Often this is
selected when using the answering service dial result to indicate that a
callback message was left.
•
Dial menu. List options in the order interviewers should see them in the dial
menu. For each option select one of the eight Blaise dial results, or
treatments. At least one option must be given the Questionnaire treatment. If
an interviewer selects an option associated with the Questionnaire treatment,
the DEP starts the interview for the current case. If an interviewer selects an
CATI Guide
67
Chapter 5: Built-in Management Utilities
option associated with any other treatment, a parallel block will appear if a
parallel block has been assigned that particular treatment in the Parallel
blocks branch of the specification file. Whether a parallel block appears or
not, the case is given the specified dial result or treatment unless code in the
datamodel overrides this. If the dial screen will not be used, check Skip dial
menu in DEP.
•
Field selection. Include all database fields to be shown on the dial screen,
shown in the overview made available to supervisors in the Forms branch of
the CATI Management program, stored in the history file, and/or given
Telephone, To whom, Time zone, Quota or Time slice functionality. For each
included field, select the appropriate function and check all the options that
apply. Normally, after the survey begins changes are made in this branch only
to change the fields shown on the dial screen or in the Forms branch.
•
Users ➤ Interviewers. List the name of each interviewer. The string value
used to identify each interviewer should be the same as the value assigned to
BlaiseUser in the HKEY_CURRENT_USER/ENVIRONMENT subfolder in
the registry of the machine used by the interviewer. If the call center does not
intend to create an environment subfolder with a BlaiseUser field on each
workstation, then the logon name should be used to identify the interviewer.
This list of interviewers should be updated every time an interviewer leaves
or joins the survey.
•
Users ➤ Groups. If groups that require special qualifications such as
language fluency are being used, assign appropriate interviewers to these
groups.
•
Time zones. Specify time zones if the survey covers more than one time zone.
Assign a difference of 0 to the time zone in which the call center is located.
Give positive differences, in minutes, to time zones east of the call center
time zone and negative differences to time zones to the west. Change the
default values in the No calls time limits if they are not appropriate for the
survey. The no call limits are in respondent time. You cannot define separate
no call limits for each time zone. So if you use 9 a.m. as the do not call before
time, barring a hard or super appointment, no case is delivered before 9 a.m.
in its respective time zone. The no call limits apply even if no time zones
have been defined.
Consider setting the Appointment grace period at about 60 minutes. This
allows exact date and time appointments set for later in the day to be
delivered for a while after the Do not call after time.
•
68
Time slices. These divide up the interviewing week into time periods that
have a different likelihood of finding an available respondent. To define a
Blaise
Chapter 5: Built-in Management Utilities
time slice set, give it a name and a three-character code. Check Allow slices to
be tried on same day unless you want to spread out no answer dial attempts to
the maximum extent possible, or you believe that if no one answers at any
point during a given day then no one will answer at any time later on that day.
Specify time slice definitions to match the expected behavior of respondents.
For example, for school children, do not set any time slice definitions during
school hours, but have three separate after-school definitions: pre-dinner,
dinner time and post-dinner. One time slice set should be sufficient unless
there is enough information available to know how to divide respondents into
groups with different expected behavior patterns.
•
Quota control. Once one or more fields are given Quota functionality, all
possible quota categories are automatically listed in the Quota control branch.
For example if one quota field has two enumerated options and the other
quota field has four enumerated options, eight quota categories will be listed.
Set the count for each one of these categories in accordance with survey
targets.
•
Parallel blocks. All the parallel blocks in the survey instrument are
automatically listed in the Parallel blocks branch with an associated
treatment. When a parallel block given the No answer, Busy, Non-response,
Answering service, Disconnected or Others treatment is completed, Blaise
exits the case and gives it the dial result of no answer, busy, non-response,
answering service, disconnected or others, respectively (unless another dial
result is assigned by code in the datamodel). When a parallel block given the
Questionnaire treatment is completed, Blaise enters the main parallel for the
case.
5.1.2
Guidelines for Setting Daybatch Parameters
The algorithm used by Blaise to choose the cases included in a daybatch is fixed
in certain ways and cannot be changed. For example, cases with a most recent dial
result of response, disconnected, others or non-response can never be placed in
the daybatch by Blaise during its create daybatch procedure. Nonetheless, some
control can be exerted over daybatch composition by manipulating daybatch
parameters.
•
CATI Guide
Daybatch ➤ Daybatch select. In order to exclude certain kinds of cases from
the daybatch, select the appropriate database field(s) and delineate the
exclusion criteria. Alternatively, to include certain kinds of cases in the
daybatch, select the appropriate database field(s) and delineate the inclusion
criteria. When inclusion criteria are specified, any case that does not match
the inclusion criteria is excluded. Selection criteria do not apply unless Use
select fields is checked under General parameters.
69
Chapter 5: Built-in Management Utilities
•
Daybatch ➤ Daybatch sort. Sort criteria can change the order in which cases
are listed in the daybatch only within each priority grouping. For example, for
a sort in descending order by number of members in the household, a case
with a hard appointment and five household members is listed before a case
with a hard appointment and four household members. Sort criteria do not
apply unless Use sort fields is checked under General parameters.
•
Daybatch size (under General parameters). Make the daybatch large enough
so that interviewers will not run out of cases during the interviewing day.
•
Maximum number of calls (under General parameters). Toward the end of a
survey, consider increasing the maximum number of calls if the daybatch size
gets too small.
•
Days between no answer and answering machine calls (under General
parameters). Consider reducing these parameters whenever the daybatch
starts to get smaller than desirable, or toward the end of the survey.
•
Time slice maximum tries (under Time Slices). Toward the end of a survey,
consider increasing the number of tries for some or all time slice definitions.
Cases to which time slices apply are not included in the current daybatch if
they have no more tries left for the current day.
5.1.3
Factors to Consider When Setting Scheduler Parameters
There are some general factors to review when setting Scheduler parameters. The
Scheduler parameters are all under the General parameters branch, and the More
button must be clicked to reach many of them.
70
•
Maximum number of busy dials. Set to the number of times to try a busy line
before giving up. Allowing too many busy dials is problematic, because
busies have priority over non-busies and hence may keep non-busy cases
from being tried.
•
Minutes between busy dials. Set to the minimum number of minutes (when
adjusted for the five-minute interval approach used by Blaise) that the
Scheduler must wait before delivering a case that has been receiving
consecutive busies. Remember that when dealing with busies (unlike no
answers) the same minimum periods apply irrespective of the priority level of
the case. This is set using the More button in the General parameters branch.
•
Maximum number of dials. Set to the number of times to try no answers
before giving up for the day. Consecutive busies up to the maximum number
of busy dials are viewed by Blaise as the equivalent of one no answer. If the
maximum number of busy dials and the maximum number of dials are both
Blaise
Chapter 5: Built-in Management Utilities
set to 4, a case can receive up to 16 consecutive busies or up to 4 consecutive
no answers before going to no need today.
•
Minimum time between hard/super no-answer. Set to the minimum number of
minutes (when adjusted for the five-minute interval approach used by Blaise)
that the Scheduler must wait before delivering a case that has just received a
no answer and has a hard appointment or super appointment.
•
Minimum time between ‘other’ no-answer. Set to the minimum number of
minutes (when adjusted for the five-minute interval approach used by Blaise)
that the Scheduler must wait before delivering a case that has just received a
no answer and does not have a hard appointment or super appointment.
•
Interviewer de-activation delay (medium or hard). If the survey involves
exclusive case ownership, assign 1440 minutes (or 24 hours) to this
parameter. Otherwise, set to the number of minutes to restrict delivery of a
case to the assigned interviewer. The medium delay applies to cases with
medium appointments, while the hard delay applies to cases with hard and
super appointments. The medium delay is usually set to be somewhat longer
than the hard delay because medium appointments are normally not taken as
seriously and normally are not as time-critical. There is no de-activation delay
for soft appointments and cases with no appointment. This means that they
can only be delivered to the specified interviewer as long as the routeback
field maintains To whom functionality and the name of an interviewer
specified in the specification file remains in the routeback field.
•
Group de-activation delay (medium or hard). If the survey involves exclusive
case ownership, assign 1440 minutes (or 24 hours) to this parameter.
Otherwise, set it to the number of minutes to restrict delivery of a case to the
assigned group or to the main group of the assigned interviewer.
•
Expire on de-activation delays only. Check this parameter if de-activation
delays should apply regardless of whether the specified interviewer or group
is on the system. This would be the case if the survey involves exclusive or
close to exclusive case ownership. If case ownership, familiarity and/or
special characteristics are not a priority consideration, do not check this
parameter. In this way, the Scheduler waits for a more appropriate interviewer
only if such an interviewer is currently available.
•
Time slices allow multiple tries on same day. Set Allow slices to be tried on
same day to Yes to allow multiple tries on one day. Set to No to maximize the
chance that every case is touched at least once during a given day.
•
Groups. If groups that do not require specific qualifications are being used,
assign interviewers to these groups in ways that best handle current concerns.
CATI Guide
71
Chapter 5: Built-in Management Utilities
A discussion of how to use group assignments to change the priority of
queues is provided in section 4.2.1.
5.1.4
Different Stages in a Survey
At the beginning of a survey, it is often important to be sure that each case is
attempted at least once. To do this:
•
Set Maximum number of dials and Maximum number of busy dials to 2 or 3.
Do not set these maximums to 1, as appointments may be missed.
•
Set Minimum time between ‘other’ no-answer to cover the entire day.
•
Set Days between no answer calls and Days between answering machine
calls to at least 5 or 6 days.
Once all cases have been touched, it is ideal to set the specification file
parameters to minimize the number of call attempts that it takes to complete the
average case. A suggested approach is to:
•
Set Maximum number of dials and Maximum number of busy dials to at least
4 so that appointments are not missed. Note that the Maximum number of
dials should be high enough to include all the possible time slice definitions
that can be tried on one day.
•
Set Minimum time between ‘other’ no-answer to perhaps 5 or 10 minutes if
time slices are being used so that this value does not interfere with the
application of time slices.
•
Reduce Days between no answer calls and Days between answering machine
calls to 0 if you are relying on time slices to spread out dial attempts.
By the closing stage of the survey there may be very few cases left. In order to
increase the frequency with which these cases are delivered:
72
•
Dispense with time slices. Remove all time slice sets from the specification
file to completely dispense with time slices.
•
Increase the Maximum number of dials and Maximum number of busy dials.
•
Reduce the minimum times between dials and busy dials.
•
Increase the Maximum number of calls and the Maximum tries for each time
slice, if time slices are being used, so that the daybatch can include cases that
have already been tried numerous times.
Blaise
Chapter 5: Built-in Management Utilities
5.2
Blaise CATI Management Program and History Browser
Call center supervisors use the CATI Management program and History Browser
to perform various supervisory tasks. These tasks can be divided into four groups:
•
Handling the daybatch,
•
Handling individual cases,
•
Monitoring interviewers, and
•
Tracking overall progress.
This section provides information on these tasks. Normally the CATI
Management program is launched using a shortcut. Once in the CATI
Management program, select Tools ➤ CATI History Browser from the menu bar
to bring up this tool.
5.2.1
Handling the Daybatch
The daybatch needs to be made every day before interviewing begins. Select
Management ➤ Create daybatch or click on the sun speed button in the CATI
Management program. Once the daybatch is made, view all the records in the
daybatch by selecting the View daybatch ➤ Browse sub-branch. This CATI
Management view of the daybatch lists all the cases by JoinID in the order in
which they were placed in the daybatch. Since cases are placed in the daybatch in
accordance with their priority before interviewing starts, FuturePriorities of hard
appointment appear before those of medium appointment and soft appointment.
FuturePriorities of Default are listed last. As the situation changes during the
interviewing day, this strict ordering by FuturePriority breaks down.
The CATI Management view of the daybatch file cannot be sorted or searched.
However, using standard windowing techniques you can adjust column positions
and widths for the displayed fields. Beginning in Blaise version 4.6, if you check
the Save desktop checkbox available from the Tools ➤ Environment Options
submenu, the altered view of the daybatch file is saved and reappears when you
re-launch the CATI Management program.
In the CATI Management view of the daybatch file, the only way to identify
individual cases is by JoinID. This is because the JoinID is the only identifying
CATI Guide
73
Chapter 5: Built-in Management Utilities
database information that appears in the daybatch. To obtain more databaserelated information on a particular case, highlight the case and double-click. The
Case Summary dialog, which shows the primary key and telephone number, is
displayed. If the Data button in the Case Summary dialog is selected, the values
stored in all the fields that have been selected to appear on the Make Dial dialog
are visible.
To obtain information on the appointments that are scheduled by hourly interval
for the current day, select the View daybatch ➤ Appointments sub-branch and the
appointment graph appears. Even if they cover a number of hours, soft
appointments and medium appointments are only shown in the first hourly
interval in which they can be delivered. The appointment graph can provide a
useful way of determining, for example, when interviewers can best go to lunch.
To obtain more details on the individual appointments scheduled during an hourly
interval, either right-click or left-click on the relevant interval on the graph. The
right-click displays five-minute breakdowns. The left-click displays a stack of
Case Summary dialogs for each of the relevant individual cases. Go through the
stack to see which specific interviewers or groups have appointments scheduled
for the particular hourly interval.
Information on the overall state of the daybatch during the day is available in the
tables that appear when the View daybatch branch is highlighted. There is a
separate column in these tables for each individual shift listed in the Crew
parameters branch of the specification file. The View by Status table groups cases
by Status/Priority. All cases with a Status/Priority of default, busy default, busy
soft appointment, busy medium appointment, busy hard appointment, soft
appointment, medium appointment, hard appointment, and super appointment are
included in the Active category. All cases with a Status/Priority of not-active, no
answer, busy or new appointment for today are included in the Not-active
category.
The Status/Priority can be changed from not-active to active for all cases where
busies and specific appointment times are not an issue by highlighting the View
daybatch branch and selecting menu choice Management ➤ Activate. An
individual case is activated by bringing up the Case Summary dialog for the
case, selecting the More button, and then selecting the Activate button. The
Activate button is grayed out (not available) if the case cannot be activated.
Remove an individual case from the daybatch by bringing up the Case Summary
dialog for the case, and selecting the More button and then the Remove button.
The Remove button is grayed out if the case is not in the daybatch. Cases that are
removed from the daybatch remain in the daybatch listing but are given a
Status/Priority of No need today.
74
Blaise
Chapter 5: Built-in Management Utilities
It is also possible to write utility programs to modify the daybatch. Use the
Maniplus functions DAYBATCH_ADD and DAYBATCH_DEL to add or remove cases.
Individual cases are also added to the daybatch when interviewers run the DEP on
cases that are not already there. This can happen if the Browse, Get or New
options are enabled on the Forms menu in the DEP along with the Get Telephone
Number option. Supervisors can access cases that are not already in the daybatch
by using the Forms branch of the CATI Management program. Once treated, nondaybatch cases are added to the daybatch if they are given a non-concluding dial
result. The only time such cases are not added is when Apply select fields also
after the dial in the DEP is checked in the Daybatch select branch of the CATI
Specification program and the cases contain excluded or non-included values.
5.2.2
Handling Individual Cases
Individual cases are handled using the Forms branch of the CATI Management
program. Highlight a case and then from the menu bar select Management ➤
Select or double click to bring up the Treat Form dialog. Use the Treat Form
dialog to do all of the following:
•
Make a super appointment by choosing the Call as soon as possible option.
•
Change the value in the routeback field in the database by modifying the For
whom field. The For whom field in the Treat Form dialog is activated only if
an appointment is being made. The drop down list for the For whom field
contains the option of EVERYONE along with the names of all the
interviewers and groups defined in the specification file. The routeback field
cannot be changed without actually making an appointment.
•
Register a final refusal by choosing the Non-response option. The Nonresponse option is always available in the Treat Form dialog for supervisors
even if it is not included in the Make Dial dialog for interviewers.
•
Act as an interviewer and dial the case. All the menu options that appear in
the Make Dial dialog also appear in the Treat Form dialog. The DEP is run
if a menu option is selected that is associated in the Dial menu branch of the
specification file with the Questionnaire treatment. If the DEP is not run, no
record of the dial attempt is written to the history file. The CatiMana blocks
in the database are updated even if the DEP is not run.
Individual case history is reviewed by zooming the case in either the View
daybatch ➤ Browse or Forms branch. If not enough case history information is
CATI Guide
75
Chapter 5: Built-in Management Utilities
available by zooming a case, all dial attempts for the case can be tracked by
referencing the list view in the History Browser. This list can be seen by selecting
CATI History Browser from the CATI Management Tools menu, and then
selecting View ➤ List view. Some values currently stored in the database for that
case can be found by referencing the Forms branch. These values are for the
fields for which Show in overview has been checked in the Field selection branch
of the specification file.
The Forms branch of the CATI Management program can be used as a review
and recode utility. As an example, assume that you want to periodically review
cases whose last dial result is disconnected in an attempt to find new phone
numbers. You highlight the Forms branch, specify a search by the secondary key
of LastDialResult and enter the number 7 in the search box. You enter the number
7 because DialResult is an enumerated type in the CatiMana.CatiCall block and 7
is the number associated with disconnected. A list of cases with a last dial result
of disconnected appears on the screen. Highlight any one of these cases and
review the information provided in the row for this case. To see more information
on the case, zoom the case and select the Data button. When the Data button is
selected, all the values that are stored in the fields displayed in the Make Dial
dialog are shown.
If you find a new phone number based on the information obtained, you can bring
up the Treat Form dialog and change the phone number provided in the
questionnaire data section. Next, you can select a dial menu option like no answer
and click the OK button. This will put the case in the daybatch, ready to be
delivered to an interviewer with the new phone number. Blaise will not save the
old phone number, however, you can retain this by adding a field for it in the
history file. Adding fields to the history file is discussed in section 3.3.
In order for this review and recode utility example to work, LastDialResult must
be a secondary key in the survey instrument. In addition, in the Field selection
branch of the specification file all the database fields of potential interest, such as
the name and address fields, need to be selected to show in overview and/or dial
screen, and the phone field needs to have the Edit allowed option enabled (see
Figure 2-11). The phone field is automatically shown in the Make Dial dialog.
5.2.3
Interviewer Reporting
It is possible to tell which interviewers are currently running the DEP by looking
at the Active Interviewers branch of the CATI Management program. Groups with
at least one member currently running the DEP can be determined by looking at
the Active Groups branch.
76
Blaise
Chapter 5: Built-in Management Utilities
The detail or productivity (list) view in the History Browser provides a very good
way to monitor interviewer productivity. The browser references the history file,
so it covers all dial attempts since the survey first began. As shown in Figure 5-2,
you can select whichever interviewer or group and whatever range of dates that
you wish. The Count column in the table gives the number of cases, while the
Interview and Treatment columns give average number of seconds. If, for
example, you are looking at the NonResponse row, the number in the Count
column gives the number of dial attempts for the named interviewer or group
during the specified period that were registered as a non-response. The number in
the Interview column gives the average time in seconds that were spent on these
non-response interviews. The number in the Treatment column gives the average
time in seconds from the time the dial screen first appeared until the interviewer
exited these non-response cases.
Figure 5-2: History Browser Productivity View
In order to compare the performance of an interviewer or a group with overall
performance, click on the summation sign. This will show overall indicators in
parentheses. For example, the average number of seconds across all interviewers
spent on completed interviews within the selected dates is shown in parentheses
as (87) in the Interview column. The seconds for non-response interviews are all
zero, because code in the Commute example converts all non-response dial results
to no preference appointments.
5.2.4
Survey Progress Reports
The CATI Management program and History Browser provide a number of
different reports to track survey progress. Some of these reports, like the
CATI Guide
77
Chapter 5: Built-in Management Utilities
productivity view in the History Browser and the appointment graph in the View
daybatch branch of the CATI Management program, have been mentioned earlier.
To get a breakdown of cases in the current database by most recent dial result,
look at the Summary branch of the CATI Management program. By looking at
this branch, you can see how many cases are considered done and not yet done. If
you want to see how much progress has been made in the filling of various quota
categories, you can look at the Quota branch. Data in the both the Summary and
Quota branches are refreshed on a real time basis. Set the frequency with which
the data are refreshed under Tools ➤ Environment Options ➤ Auto refresh
desktop.
5.3
Handling and Diagnosing Scheduler Problems
At the beginning of a survey, settings are chosen for the specification file. As time
goes on, it is important to fine-tune some of these settings based on the needs of
the study.
The most frequent problem is that, temporarily, no cases are available for
delivery. This may affect some interviewers or all interviewers and may last for
several minutes, several hours or occur intermittently day after day. Another
common problem is that some cases may never be attempted even though the
survey has been ongoing for a considerable amount of time. Also, the daybatch
may contain far fewer cases than interviewers can handle in the course of the day.
This section deals with these three problems, and the effects of remaking the
daybatch.
Daybatch size is set in the specification file to any value between 100 and 20,000.
This sets an upper limit on the size of the daybatch. There is generally no reason
to set the daybatch size any higher than the maximum number of cases
interviewers can handle per day. Reporting and monitoring is somewhat easier
with a smaller daybatch.
5.3.1
No Cases Available for Delivery
If an interviewer reports that no cases are available for delivery, look in the CATI
Management program at the View Daybatch table for the current shift. If all or
almost all cases are Not-active, the unavailability may be due to a current time
issue. All cases are Not-active before the starting time of the first crew. Cases
without appointments for a specific time or time range are not active until the Do
not call before time set in the Time zones branch of the specification file.
78
Blaise
Chapter 5: Built-in Management Utilities
If there are a number of active cases, cases are probably not being delivered to the
particular interviewer due to routeback restrictions. Cases with a priority of
default or soft appointment can only be delivered to the interviewer or group
named in their routeback field. However, cases with medium, hard and super
appointments can be made more readily available to all interviewers by going into
the specification file and reducing de-activation delays. You can also make cases
with medium, hard and super appointments more readily available to all
interviewers by verifying that Expire on de-activation delays only, under the
More button in the General parameters branch, is not checked. If this
specification file setting is not checked, de-activation delays are only honored if
the specified interviewer or at least one member of the specified group is
currently running the DEP.
If there are many Not-active cases, try activating them. To do this, using the CATI
Management program, highlight the View Daybatch branch and then from the
menu bar select Management ➤ Activate. All Not-active cases where neither hard
appointments nor busies are being chased should become active and hence
available for delivery. Since activation does not affect busies and hard
appointments, consider going into the General parameters branch of the
specification file and reducing the Minutes between busy dials and the Minimum
time between hard/super no-answer, using the More button.
There may be many more no need today cases than expected because a quota has
just been filled. This also may occur when there are no more tries left for time
slices later in the day or because only one try is allowed per day for cases to
which time slices apply. If Do not allow multiple same day answering machine
calls is checked in the specification file, the frequent encountering of answering
machines can also produce many no need today cases.
Finally, an incorrect internal clock on a workstation can result in a number of
cases going to no need today. This could happen, for example, if workstation A is
an hour ahead of all other workstations. Once a dial result is registered for
workstation A past the Do not call after time set in the Time zones branch of the
specification file, all cases without specific appointments will go one hour too
soon to no need today (assuming no time zone complications).
If most cases have a status of no need today or if a point is reached when cases
are requiring frequent activation and sometimes no cases can be activated, there
may be no choice but to remake the daybatch. The last section in this chapter
explains why re-creating the daybatch should be considered a last resort.
CATI Guide
79
Chapter 5: Built-in Management Utilities
If, day after day, there are frequent times when no cases are available for delivery,
consider changing routeback field values. Also try to get interviewers to spread
out appointment times better. With regard to specification file settings, consider:
5.3.2
•
Increasing Daybatch size.
•
Increasing number of dials (Maximum number of dials and/or Maximum
number of busy dials) if cases go too quickly to no need today.
•
Decreasing minimum time settings (Minimum time between hard/super noanswer, Minimum time between ‘other’ no-answer, and Minutes between busy
dials).
•
Allowing more than one time slice to be tried each day.
•
Increasing the maximum number of tries allowed for various time slice
definitions.
•
Redefining time slices so that there are more time slice definitions and the
average definition covers a smaller period of time.
•
Reducing de-activation delays.
•
Disabling Expire on de-activation delays only, so that medium, hard and
super appointments are only held for interviewers and/or groups who are
actually on the system.
•
Adding more interviewers to groups that seem to be getting more cases than
they can handle.
•
Having daybatch selection criteria applied to the routeback field that reflects
interviewer availability on the current day.
Some Cases Not Being Touched
Blaise tries to spread out dial attempts as evenly as possible among all the nonconcluded cases in the database. When determining which cases to put in the
daybatch, if two cases are basically the same except that one has fewer calls than
the other, Blaise gives priority to the case with the fewer calls. When deciding
which case to deliver, if two cases are basically the same except that one has
fewer dials on the current day, Blaise gives priority to the case with the fewer
dials. Nonetheless, at some time after the start of a survey, check the tables in the
Summary branch of the CATI Management program. If a number of cases are
shown as having received no calls, then these cases have remained untouched
because they have not been getting into the daybatch or because other cases in the
daybatch are being delivered instead of these cases.
80
Blaise
Chapter 5: Built-in Management Utilities
Possible Reasons for Not Being in the Daybatch
Cases may not be in the daybatch because of daybatch exclusion or inclusion
criteria. It is important to note that once a Daybatch select inclusion criterion is
specified, all cases that do not meet this criterion are automatically excluded. For
example, if the age range of 16 to 65 is included, all people over 65 are
automatically excluded.
When applying sort criteria, these criteria override the number of calls criterion
used by Blaise. If using quotas, the untouched cases may belong to quota
categories that have already been filled.
It is possible that the daybatch size may be too small. The daybatch should be
large enough to include not just cases with appointments, but also a number of
Default cases.
Possible Reasons for Not Being Delivered
There may not be enough interviewer hours available to be able to attempt all the
cases in the survey during the period reviewed. Alternatively, interviewers may be
spending too much time working on appointments and busies. If the survey is set
to allow the maximum number of dials (9) and busy dials (9) and the minimum
number of minutes between dials and busies (5), a case can conceivably be tried
81 times in an eight-hour period, even if someone has left the telephone off the
hook. Once the first busy is registered, during each subsequent five-minute
interval a case is accorded a higher priority than any case that has never been
touched.
Cases may not be delivered because the interviewers or groups named in their
routeback field are not present much of the time. Alternatively, some routeback
fields may contain the names of interviewers that are spelled differently in the
specification file or in the registry (or in the login name if the registry is not being
used to identify interviewers) and hence are not recognized.
5.3.3
Daybatch Too Small
If the daybatch is far smaller than expected, review the Summary branch in the
CATI Management program. By looking at the overall total in the Not yet done
table, determine how many cases are considered by Blaise to be not yet concluded
in the database. This number may be smaller than originally estimated and may
account for the small size of the daybatch.
CATI Guide
81
Chapter 5: Built-in Management Utilities
If using quotas, the daybatch may be small because some or all quotas have been
filled. Look at the Quota branch in the CATI Management program to determine
the extent to which this is true.
If using time slices, it is possible that no more time slice definitions are available
for a large number of cases. For example, if there are five time slice definitions
that can be tried five times each and more than one time slice can be tried per day,
then for a case that receives only no answers, all time slice definitions may be
used up in five days. This assumes that five or more dials are allowed per day.
Re-create the daybatch before interviewing begins if its size can be increased. To
increase its size:
5.3.4
•
Increase the Maximum number of calls.
•
Reduce Days between no answer calls and Days between answering machine
calls.
•
Make daybatch selection criteria less stringent.
•
Increase the number of tries allowed for various time slice definitions.
Remaking the Daybatch During the Interviewing Day
Although the daybatch can be remade at any point during the interviewing day,
there are a number of costs associated with doing so. All interviewers need to be
off the system before the daybatch can be remade. This may mean lost
interviewing time.
The first time a case is attempted after the daybatch is made, the number of calls
registered for a case (CatiMana.CatiCall.NrOfCall) is automatically incremented
by one. If the daybatch is created five times on a given day and a case is tried at
least once after each remake, it will end the day with a total of five calls.
Normally all the dial attempts on one day are seen as constituting just one call.
Hence, you may not want to increment the total number of calls for a case so
abruptly in the course of one day.
Each time the daybatch is made, the number of dials and number of busy dials are
set to zero. Also cases that were initially in the daybatch may not appear in the
daybatch when it is remade. This means that by re-creating the daybatch, you will
almost invariably lose the scheduling strategy, such as minutes between busies,
that was being applied to some cases.
82
Blaise
Chapter 5: Built-in Management Utilities
5.4
Disabling Menu Options
It is possible to limit the extent to which users can modify the specification file,
by providing a shortcut to the CATI Specification program that contains a /M
switch. The /M switch can be immediately followed by the name of an INI file
that contains the following:
Dayparams = 0 or 1
CrewInformation = 0 or 1
Generalparams = 0 or 1
DialMenu = 0 or 1
TimeZones = 0 or 1
ParallelBlocks = 0 or 1
GroupsInterviewers = 0 or 1
QuotaControl = 0 or 1
SelectFields = 0 or 1
DBSortFileds = 0 or 1
DBSelectFields = 0 or 1
TimeSlices = 0 or 1
Optionally, instead of an INI file, the /M switch can be followed directly by 12
plus or minus signs. The plus sign is the same as a 1 in the INI file, and allows
read/write access to the relevant specification file branch. The minus sign is the
same as a 0 in the INI file, and allows only read access.
For example, if some users are only permitted to modify general parameters, and
interviewers and groups, their shortcut to btspec.exe can be specified as:
btspec.exe /M--+---+-----
Beginning in version 4.6, a /M switch can be used to limit read/write access in the
CATI Management program. In the case of the CATI Management program, the
INI file is structured as follows:
CreateDaybatch = 0 or 1
ScheduleDaybatch = 0 or 1
Activate = 0 or 1
Zoom = 0 or 1
Select = 0 or 1
Plus or minus signs can be used instead of the INI file. As an example, if some
users are permitted to use the CATI Management program to do everything
except treat cases using the Treat Forms dialog, their shortcut to btmana.exe
can be specified as:
btmana.exe /M++++-
CATI Guide
83
Chapter 5: Built-in Management Utilities
84
Blaise
6
Blaise Datamodel and DEP Extensions
Some surveys can be enhanced by extending the basic Blaise® CATI datamodel.
This chapter discusses techniques to customize the datamodel to suit the needs of
the study. In addition, changing some of the DEP configuration settings from the
defaults may be useful for a particular study. This chapter describes configuration
and use of the DEP.
6.1
Datamodel Extensions
The basic CATI datamodel discussed in Chapter 2 can be extended to fit various
needs. This section discusses five possible extensions: interim coding, final
coding, overriding the default dial result, minimal or no use of the dial menu, and
eliminating the Make Appointment dialog.
6.1.1
Interim Coding
The eight Blaise dial results can be used without further elaboration. However, for
some surveys additional detail is needed for survey management. For these
surveys, a set of interim codes can be created, and then code can be included in
the datamodel to assign the appropriate interim code every time the DEP is run.
Interim codes are used in the Commute example. The codes are implemented as a
Blaise enumerated type called TInterimOutcome. This type is defined in
Mylib.lib.
In Commute, the interim code is assigned automatically by the procedure
POutcome. This procedure is implemented at the datamodel level. It looks at the
various responses to determine which interim code to give to the field
InterimOutcome. The procedure is found in the POutCome.prc file.
The following code snippet from the POutcome procedure shows some of its
logic.
CATI Guide
85
Chapter 6: Blaise Datamodel and DEP Extensions
IF (ThankYou = Continue) OR
(Confirm <> EMPTY AND NumberJobs = 0) THEN
InterimCode := CompleteInterview
FinalCode := CompleteInterview
ELSEIF (Person.Confirm <> EMPTY) AND (NumberJobs > 0) THEN
InterimCode := PartialInterview
FinalCode := PartialInterview
ELSEIF Appt <> EMPTY THEN
InterimCode := Appointment
ELSEIF Disconnect <> EMPTY THEN
InterimCode := NoLongerInService
The example shows how both the InterimCode and the FinalCode are set for the
completed and partially completed cases. For other outcomes only the
InterimCode is set.
The Manage block contains an arrayed block called OutcomeHistory in which
interim codes for up to 60 attempts can be stored. It is important to store interim
code history in the database if programmed algorithms are used to derive final
outcomes from interim code history. Interim codes can also be stored in the
history file.
6.1.2
Final Coding
Normally final codes are used along with interim codes. A final code is assigned
to each case when it is closed out and indicates why the case was closed out.
Frequently used final codes include complete interview, partial interview, various
kinds of refusals, ineligible or unavailable respondent, always busy, language
problem, cell phone, pager and disconnected.
Final codes can be assigned by the rules section within the datamodel or by
overnight Manipula setups. For example, a protocol can be chosen that
automatically sets a final code of faxline whenever three consecutive interim fax
codes are encountered.
The final codes used in the Commute example are derived from the AAPOR
(American Association for Public Opinion Research) website, www.aapor.org.
They are implemented as a Blaise enumerated type called TAAPOROutcome. This
type is defined in Mylib.lib. In the Commute example, final codes of
CompleteInterview and PartialInterview are assigned by the same procedure that
assigns these interim codes. The remaining final codes are assigned by using the
Review and Recode utility covered in section 7.7. The Daybatch select criteria are
used to exclude all cases with a final code from the daybatch.
86
Blaise
Chapter 6: Blaise Datamodel and DEP Extensions
6.1.3
Overriding the Default Dial Result
Every time the DEP is run on a case, Blaise automatically assigns a dial result in
accordance with the treatment assigned in the specification file to the block
through which the case was exited. For example, if exiting through a block with
the busy treatment, Blaise assigns the dial result of busy. If exiting through the
datamodel itself instead of through a parallel block, Blaise assigns the dial result
of response.
Blaise provides a way to override this default treatment by letting you directly
write into the CallResult auxfield. Any assignment made inside the rules of the
datamodel to CatiMana.CatiCall.CallResult overrides the default dial result that
would otherwise be stored in the database by Blaise.
In the Commute example, an entry into the OtherOutcome parallel block normally
results in the case being closed out. Sometimes this would not be appropriate. For
example, if there is a language problem recorded in the Lingo field in the
OtherOutcome block, and you learn that the language is Spanish, then it is
possible to set the Blaise outcome to something other than a closeout. In the
following code snippet, the CallResult auxfield is set to Appointment, thereby
making Appointment the dial result for the case. A NoPreference appointment is
written into the database as the appointment type and the ForWhom field is set to
the Spanish (SPAN) group.
IF OtherOutcome.Lingo = Spanish THEN
CatiMana.CatiCall.CallResult := Appointment
CatiMana.CatiAppoint.AppointType := NoPreference
ForWhom := 'SPAN'
ENDIF
If you never run the DEP because you select a non-questionnaire option on the
dial menu with no associated parallel block, Blaise automatically assigns the dial
result associated with the option in the specification file. There is no way to
override this dial result, because the code in the datamodel is never accessed.
6.1.4
Minimal or No Use of the Dial Menu
The dial menu can be used exclusively as the way for interviewers to obtain
information before attempting a case. In these circumstances only one option,
associated with the Questionnaire treatment, need appear on the dial menu. After
reviewing this information, interviewers would go right into the DEP. All dial
results would be registered in accordance with a script instead of having the
interviewer attempt contact with the respondent on an ad hoc basis while still at
the dial menu. As part of the script, the database information that would otherwise
CATI Guide
87
Chapter 6: Blaise Datamodel and DEP Extensions
be shown in the Make Dial dialog could be presented in a more readily
informative way in the info pane of the instrument.
The scripting approach could use parallel blocks to register all dial results other
than Questionnaire. Alternatively, the datamodel could be programmed to contain
non-contact as well as contact routes. If interviewers go down non-contact routes
and then exit, the CallResult auxfield must be used to assign the appropriate dial
result.
The dial menu can be dispensed with all together. To do so, check Skip dial menu
in DEP in the Dial menu branch of the specification file.
6.1.5
Eliminating the Make Appointment Dialog
Most Blaise CATI users find the Make Appointment dialog a satisfactory way to
make appointments since it offers a number of different types of appointments
and contains built-in edit checks that only allow appointments to be made in
accordance with the time and date settings in the specification file. However, in a
particular survey you may not want to use the Make Appointment dialog
because of the need to restrict the times, dates and appointment types for all or
some cases to a greater degree than allowed by the Make Appointment dialog.
Alternatively, you may not want to use the Make Appointment dialog because
you may want to script specific text for the interviewers to use for appointments
or you may want to allow the interviewers to set appointments using such
terminology as one day later or one hour later.
To expand the appointment block defined in the datamodel so that it can be used
by itself and not in conjunction with the Make Appointment dialog:
• Check Disable appointment dialog in the DEP in the Parallel blocks branch of
the specification file.
• Make sure that the appointment block collects all required information and that
this information is specifically written into the CatiMana.CatiAppoint subblock. This block must contain within itself all necessary edit checks if you do
not want times, dates and days that are inconsistent with specification file
settings to be entered in the database.
6.2
DEP Configuration
This section describes how to configure the DEP to run a CATI instrument. If the
DEP is not specifically configured by the user, Blaise provides default settings.
88
Blaise
Chapter 6: Blaise Datamodel and DEP Extensions
6.2.1
Mode Library
In the process of preparing a datamodel, Blaise references what is called a mode
library file in order to know how to customize the look and feel of the prepared
datamodel. As shown in Figure 6-1, a particular mode library file can be specified
in the Project Options dialog that appears when Project ➤ Options is selected
from the Control Centre menu bar. If you are not using projects, Blaise will not
remember this setting if a project is opened, or if this field is changed for another
DEP and then you reopen the original DEP. If no mode library file is specified in
the Project Options dialog, Blaise looks for a file named modelib.bml in the
same folder as the .bla file. If no such file exists, Blaise automatically references
the modelib.bml file in the system folder where the Blaise executables are
stored.
Figure 6-1: Specifying a Particular Mode Library File
CATI Guide
89
Chapter 6: Blaise Datamodel and DEP Extensions
To create and modify mode library files, select Tools ➤ Modelib Editor from the
menu bar in the Control Centre. Every time mode library settings are changed, the
file must be saved and the datamodel re-prepared before the changes can take
effect.
There are a number of mode library settings that are of particular interest in
CATI:
• The options Minimize allowed and Resize allowed in the Style ➤ Options
branch are usually not checked in CATI operations. This prevents the
interviewer from minimizing the DEP and getting to other parts of the
Windows® desktop. Note that if CATI is enabled, Blaise automatically
prevents a case being exited unexpectedly in the DEP, so there are no Modelib
settings needed to address this concern.
• Checking the option Show parallels on tabsheet provides interviewers with an
easier way to access parallel blocks than having to select Navigate ➤ Sub
Forms from the menu bar of the DEP. Parallel blocks are particularly
important in CATI operations because they are used to register dial results.
• Check Make audit trail and use the browse button to enter the full path name
of the file audit.dll to have audit trails made. This DLL is included in the
DOC\Chapter5\Audit subfolder of the Blaise system folder. Next create a
text file <datamodel>.aif in the same folder as your datamodel to tailor the
audit recording for your needs. For the Commute example, this would be
Commute.aif, and would contain the lines:
[AuditTrail]
Forms=1
Extra=1
The parameter Forms=1 stores the audit data for a case in a uniquely named
file. Extra=1 adds information on the Windows user and the datamodel used
in the interview to the audit trail. Additional information is available in the
Online Assistant under More on Blaise Language ➤ Audit Trails.
• The Auto save interval setting on the Standard tab of the Toggles ➤
Interviewing branch governs the frequency of saving data from workstation
memory to the server data file. Auto save should be on in case of power failure
during calling to preserve most of the data record. It is important to weigh the
frequency of auto saving versus the amount of local area network (LAN)
traffic that might result.
• The Prompt save when finished option always needs to be checked in order for
the interviewer to be able to exit an interview in CATI mode. A dialog that
asks if you want to save the form appears at the end of the interview. You must
90
Blaise
Chapter 6: Blaise Datamodel and DEP Extensions
answer yes to exit the interview. If you do not want this dialog to appear, you
can check Auto save when finished along with Prompt save when finished.
• Check the Check before dial setting on the Advanced tab of the Toggles ➤
Interviewing branch so that the datamodel rules are executed before the case is
presented to the interviewer. This setting needs to be checked to ensure that
certain survey management fields are cleared each time before a case is
entered.
• The Search Settings control the trigram search that may be in use in the
datamodel either to browse a specific case, or in the interview itself. The
trigram search is intrinsically data and network intensive, and, if frequently
used in a CATI survey, may cause slowness. Experiment with these settings if
necessary to see what their effect on LAN traffic would be. LAN traffic issues
must be weighed against interviewer performance needs. For some intensive
applications, it may be necessary to load trigram search files on the local hard
drive.
6.2.2
DEP Configuration File
The DEP configuration file can be used to override settings in the mode library
file at run time. By default Blaise does not reference any DEP configuration file.
However, if a configuration file is specified, the settings in this file are applied
instead of the settings from the mode library file that have already been
incorporated into the datamodel. A configuration file can be specified in the Run
Parameters dialog as shown in Figure 6-2. If the DEP is invoked using a
command line option, a DEP configuration file can be specified with a /C as part
of the command line.
CATI Guide
91
Chapter 6: Blaise Datamodel and DEP Extensions
Figure 6-2: Specifying Particular Files Using Run Parameters Dialog
Create and modify a DEP configuration file by selecting Tools ➤ Dep
Configuration from the menu bar in the Control Centre. Changes can be made
while the DEP is being run, and take effect as soon as the DEP is restarted
provided that the configuration file has been saved.
DEP configuration files are used when a datamodel is to be run in different
environments. For example, an instrument may be multi-mode CAPI and CATI,
or a CATI instrument may be used on two different LANs with differently
configured workstations.
6.2.3
Menu File
When running the DEP, Blaise references what is called the menu file to
determine what options should be available from the menu bar in the DEP. As
shown in Figure 6-2, you can specify a particular menu file in the Run
Parameters dialog. If invoking the DEP using a command line option, a menu
92
Blaise
Chapter 6: Blaise Datamodel and DEP Extensions
file can be specified with /M as part of the command line. If no menu file is
specified, when CATI is enabled Blaise looks for a file named CatiMenu.bwm in
the same folder as the database. If no such file exists, Blaise automatically
references the CatiMenu.bwm file in the system folder where the Blaise
executables are stored.
Create and modify menu files by selecting Tools ➤ Dep Menu Manager from the
menu bar in the Control Centre. Changes made while the DEP is being run take
effect immediately provided that the modified menu file has been saved.
The Forms Menu in the DEP can be customized so an interviewer can obtain
cases using:
• Get Telephone Number, whereby the Scheduler decides which case to deliver.
This is the only option made available by default.
• Browse, whereby the entire database is displayed and the interviewer can
select any case, irrespective of whether the case is in the daybatch or not. The
view of a database shown in the Browse option can be customized by using a
.bdv file (see Database Browser in the Online Assistant). A .bdv file with
the same name as the database and in the same folder as the database is
automatically referenced. Alternatively, the DEP can be launched with the /F
command line switch referencing the desired .bdv file.
• Get, whereby an interviewer can obtain a case by entering its primary key,
irrespective of whether the case is in the daybatch or not.
• New, whereby an interviewer can enter a new case into the database.
These four options are only available from the Forms menu if a case has yet to be
obtained. If the Make Dial dialog appears on the screen and you want to obtain a
different case, first remove this dialog by clicking on the Cancel button. In Figure
6-3, the Get Telephone Number and Browse options have no X in front of them
and hence would be available when the DEP is run and a case has yet to be
obtained. In the default CatiMenu.bwm file, only the Get Telephone Number
option is available.
CATI Guide
93
Chapter 6: Blaise Datamodel and DEP Extensions
Figure 6-3: Customizing the Forms Branch with Menu Manager
Browse is especially useful because it allows interviewers to readily handle
incoming calls. When interviewers select Browse, they are given a view of all
records in the database. They can search for a particular case by the primary key
or any one of the secondary keys. You can determine which database fields are
included in the view given to interviewers. To do so, select Database ➤ Browse
Contents for the survey database in the Control Centre. Right click when the
database is displayed and select the desired fields. Then save this view in a .bdv
file that has the same name as the survey database. When interviewers select a
case using the Browse option, the case is delivered to them whether or not it is in
the daybatch.
Once the DEP is being run on a particular case, all Forms menu options, except
the Save option, are automatically grayed out and hence not available. This is
because options such as Delete, Exit, and Close, including the X button in the
upper right hand corner of the dialog, are never enabled in CATI. Interviewers are
only allowed to exit by completing the survey instrument or explicitly going
through a parallel block that has not been given the Questionnaire treatment.
They are never allowed to delete cases but are allowed to undo all edits.
94
Blaise
Chapter 6: Blaise Datamodel and DEP Extensions
6.2.4
Datamodel Properties
In the process of preparing a datamodel, Blaise references the settings in the
Datamodel Properties dialog. These settings, which deal with input line display,
parallel blocks and languages, are saved in the .bxi file. The Datamodel
Properties dialog can be accessed by selecting Project ➤ Datamodel Properties
from the Control Centre menu bar.
As shown in Figure 6-4, the Datamodel Properties dialog can be used to change
the name used for a parallel block on the tabsheet. The Quit form at end check
box has no effect in CATI. Interviewers can exit from parallel blocks only in
accordance with specification file settings.
Figure 6-4: Specifying Names for Parallels
If there are multimedia or help languages in your datamodel, be sure to check in
the Languages tab only those spoken languages that should be available to
interviewers.
CATI Guide
95
Chapter 6: Blaise Datamodel and DEP Extensions
96
Blaise
7
Creating Additional Support Programs
This chapter describes support programs that can enhance the core utilities
discussed in Chapter 5. Support programs can be used to customize a variety of
functions such as initializing the database, producing reports, modifying views of
the daybatch and history files, and providing review and recode capabilities.
Although other non-Blaise software, such as MS-Visual Basic or C++, can be
used, often these support programs are written in Manipula and Maniplus. Refer
to the Blaise® Maniplus Developer’s Guide for more details on using Maniplus.
This chapter discusses support programs and the tasks that are generally
performed by these programs. It uses the Commute example throughout.
7.1
Support Programs and Timing
Timing is a critical factor when dealing with support programs. Some support
programs are designed to run only at certain times and in certain circumstances,
while other programs can run at any time. For example, programs that access the
entire database should not run if any other program is simultaneously accessing
the database. Programs that access only an individual record in the database can
run at any time. A program that makes a quick copy of the history file and then
accesses this copy can also run at any time.
Support programs can be accessed through the Tools menu in the CATI
Management program, the Blaise Control Centre, shortcuts (normally on the
desktop), the start menu, a Maniplus shell, or non-Blaise software. This section
explains how to add support programs to the Tools menu in the CATI
Management program. This is often the preferred way for supervisors to access
these programs since they normally have the CATI Management program already
open on their desktops. However, it is important to remember that support
programs that access the entire database in EXCLUSIVE mode cannot be run from
the CATI Management program since the CATI Management program itself
accesses the entire database.
CATI Guide
97
Chapter 7: Creating Additional Support Programs
7.1.1
Processing During the Interviewing Day
The interviewing day normally begins with the creation of a daybatch for the
current day and ends when the last interviewer logs off the system. During this
period, support programs may be used for the generation of reports or the
provision of interactive supervisory utilities. Although support programs run
during the interviewing day can be accessed from shortcuts or the Control Centre,
they are normally launched from the Tools menu in the CATI Management
program.
Manipula programs that access the entire file run very slowly with the ACCESS =
SHARED setting. The nightly programs that are illustrated here use the ACCESS
= EXCLUSIVE mode for rapid processing at night, when exclusive access to the
file is available. Any programs that are run on the entire data file when
interviewing is occurring must use ACCESS = SHARED so they do not interfere
with interviewing activities. Therefore, most support programs that need to run on
the entire data file during the day access the database indirectly. The setup for this
is somewhat involved, and the details for how to do this are illustrated later in this
chapter in the examples involving the administrative database snapshot.
Manipula or Maniplus programs that directly access individual database records
can run quite quickly and efficiently without interfering with the ongoing
interviewing process. This access method is illustrated in the Review and Recode
utility at the end of this chapter. The GET method is used to obtain the individual
record, the setting ACCESS = SHARED is specified and the WRITE method is
used if the record is updated.
Under unusual circumstances it may be necessary to access the entire live data file
from a Manipula or Maniplus program while interviewing is in process. If such
access is essential, then the data file must be accessed with ACCESS = SHARED
in order to not interfere with production. The use of the setting ONLOCK =
CONTINUE will cause the program to skip over any records that are locked. Such
a program will not run quickly, but it will not interfere with production activities.
If the program is searching the file for something or if a rough report is being
produced, skipping locked records could be preferred, because it allows the
program to proceed efficiently without either waiting or failing. ONLOCK has
two additional settings, WAIT and FAIL, which cause the system to wait for a
locked record to be released or cause the program to fail if it encounters a locked
record. This method of access is not illustrated in this chapter, because it is slow,
and so is avoided whenever possible.
98
Blaise
Chapter 7: Creating Additional Support Programs
7.1.2
Overnight Processing
The overnight period begins at the end of the interviewing day and ends at the
beginning of the next interviewing day. During this period, support programs may
be used to accomplish a variety of tasks. Some tasks may need to be done before
other tasks. Some tasks may need to be done daily, others weekly, others
intermittently when needed. A list of possible tasks in a typically used order is
presented here.
• Generation of end-of-day reports. These reports reflect the situation at the end
of the interviewing day based on information in the database, daybatch and/or
history file.
• Archiving of the database. For ease of browsing and in particular if structure
changes are possible, the .bmi file for the datamodel and for associated
external files should be archived with the database.
• Database maintenance. A Blaise-to-Blaise copy of the database can be
created to replace the current database to make sure that index files are not
corrupted and that the database is not becoming too fragmented. Cases may
end up with different JoinIDs when a Blaise-to-Blaise copy is generated. In
addition, Hospital can be used to check the integrity of Blaise data files, and
rebuild files if necessary.
• Addition or deletion of records. New or revived cases may be added to the
database. Cases may be removed if they are completed, ineligible, impossible
to trace and so on as long as removing them does not interfere with other
study requirements, such as some uses of quotas.
• Batch modification of various database fields. For example, the number of
days remaining may need to be updated, or algorithms that set interim or final
outcome codes can be applied. Fields can be reset to make more cases
available for daybatch inclusion.
• Creation of files. These are to be used the next interviewing day, and often
include a copy of part of the database.
• Generation of start-of-day reports. They reflect the situation at the beginning
of the forthcoming interviewing day after all overnight updates and fixes have
been entered.
Usually one master program is prepared that subsequently executes each of the
overnight processing tasks. Often, this master program is written in a software
package such as WinBatch and is set off by some network control system later in
the evening. Overnight processing tasks are typically not included in the Tools
CATI Guide
99
Chapter 7: Creating Additional Support Programs
menu of the CATI Management program, since as long as the CATI Management
program is running, Manipula and Maniplus programs cannot have exclusive
access to the database.
7.1.3
Processing Before and After the Interviewing Period
Before the interviewing period can begin, the database must be initialized. For
this purpose, normally a Manipula setup is used to convert phone numbers,
unique case identifiers and possibly other data in an ASCII file into a Blaise
database.
When the interviewing period is over, data must be extracted from the Blaise
database for backend processing. Data extraction can also occur during the
interviewing period.
7.1.4
Adding a Support Program to the Tools Menu
To add a program to the Tools menu in the CATI Management program:
• Select Tools ➤ Configure Tools from the menu bar and the Tools Menu
Editor dialog appears.
• Click on the Add button and the Tools Edit dialog appears.
• Enter the name of the tool in the Menu title edit box.
• Click the browse button in the Program edit box and locate the program to be
used. Select this program and its full path name appears in the Program edit
box. If desired, change the path name to the physical location for the program,
rather than the logical drive mapping.
• If input file names need to be specified for the program to run, enter these
names after the program name in the Program edit box.
• Enter the folder in which the input files can be found in the Working folder
edit box. Full or relative path names can be used. Relative path names are
preferred, because the same tool can be used from many different folders as
long as the same file names and relative path structure are retained.
• Click on the OK button and the tool is added to the list of available tools.
100
Blaise
Chapter 7: Creating Additional Support Programs
Figure 7-1: Tools Edit Dialog
In the Tools Edit dialog example above, Review outcomes is chosen as the menu
title. When selected, the program manipula.exe is run on the file RandR.man.
In order to find RandR.man, Blaise looks in the Manipula folder. It finds this
folder by starting in the folder where the database referenced by the CATI
Management program is stored and then looking for a Manipula subfolder
immediately below this folder.
Tools that are composed of a series of programs require an umbrella program that
calls each program in the series in turn. Such umbrella programs can be written
using Maniplus or other software. The top-level program should be referenced in
the Tools Edit dialog. Be sure to specify WAIT for those RUN commands that need
to be completed before the next statement in Maniplus is executed.
When you declare the added tools in the Tools menu, leave the CATI
Management program, and then come back to this utility, the added Tools menu
choices are still in the Tools menu. Blaise stores these settings in the Windows®
registry. For Blaise version 4.6, the settings are in
HKEY_CURRENT_USER\Software\StatNeth\Blaise\4.6\CATI\Tools.
Tools also can be added to the Tools menu by directly modifying the registry
through the use of .reg files.
It is possible to supervise two or more surveys at once from the CATI
Management program. However, at any given time only one survey is highlighted
in the left-hand column of the CATI Management program. The CATI History
Browser and all the tools added by you to the Tools menu automatically use the
folder that contains the database for the highlighted survey as their starting point.
CATI Guide
101
Chapter 7: Creating Additional Support Programs
This means that by using the same file names and keeping the same relative path
structure, you can use the same tools in more than one survey.
7.1.5
Support Programs in the Commute Example
The Commute example includes a number of support programs, all of which are
written in Manipula or Maniplus and stored in the Development\Manipula
folder. The Commute Management shortcut launches a Maniplus program
(CommuteManage.msu). The following four basic options are available from this
program:
• Run overnight programs. Runs CatiList.msu, CatiReport.msu and
ApptList.msu. CatiList.msu generates CatiList.asc from the
database. CatiReport.msu and ApptList.msu use the data in
CatiList.asc to generate overnight reports.
• Start CATI Management program. Launches the CATI Management program.
Any installed support programs are accessed from the CATI Management
Tools menu.
• Start Specification Program. Launches the CATI Specification program.
• Delete completed cases from the database. Runs ReadOut.msu, which
deletes cases with a final outcome of CompleteInterview from the database
and saves them in an ASCII file.
The Commute CATI Test shortcut launches the Maniplus program
CommuteCATITest.msu. It has the same four basic options as the Commute
Management shortcut, along with three additional options. The first two, Run
Commute program with CATI disabled and Run Commute program with CATI
enabled, invoke the Commute DEP directly, the first in browse mode with CATI
disabled and the second with CATI enabled. The last option, Refresh Blaise CATI
database, checks to see if the Commute database already exists. If it does not
exist, it runs CatiDataLoad.msu, which reads data in the text file
CatiData.txt into the Commute database. If the database already exists, it
checks with the user to determine whether to run CatiDataLoad.msu, which
will refresh all of the Commute database, causing previously entered data to be
lost.
Once the Install-Uninstall Commute Tools shortcut provided in the Utilities folder
during the Commute Survey installation process (see Appendix A) has been
selected, the Tools menu in the CATI Management program is configured so that
all the other support programs can be launched from it. These are all programs
102
Blaise
Chapter 7: Creating Additional Support Programs
that supervisors may wish to run during the day. The tools available from the
Tools menu of the CATI Management program are listed in Table 7-1 and
covered in detail in subsequent sections of this chapter. Make sure that the file
CatiList.asc exists in the Work folder before attempting to run these
programs. To create CatiList.asc, run CatiList.man in the Control Centre
or run the overnight programs option made available through either the Commute
Management or Commute CATI Test shortcut.
Table 7-1: Programs Added to the CATI Management Tools Menu
Tool
Purpose
Umbrella program
Other Manipula/
Maniplus programs
referenced
7.2
Assess Blaise
database
Report on number
of cases touched
and not touched
by time zone and
group
ViewTouchReport.man
CatiReport.man
Enhanced
daybatch
view
Search, sort and
summarize
daybatch file
DaybatchViewer.man
DaybatchPrime.man
Trace History
View, search and
sort entire history
file
ViewHist.man
CopyFileA.man
ToHistory.man
List all
appointments
List all pending
appointments
ApptView.man
ApptList.man
Progress
reports
Report on number
and percentage of
cases with each
interim or final
outcome
Outcomes.man
Review
outcomes
Review and
update interim
and final
outcomes
RandR.man
OutcomeSummary.man
CopyFileA.man
LastAttempt.man
HistoryMerge.man
MergedFileCopy.man
CopyFileA.man
LastAttempt.man
HistoryMerge.man
MergedFileCopy.man
Running Reports
A number of reports are routinely available in the CATI Management program
and the History Browser (see Chapter 5). Other custom reports including the
examples listed below may be needed for some studies:
CATI Guide
103
Chapter 7: Creating Additional Support Programs
• A daily listing of cases for which mailouts were requested during the previous
day, which should be sent to the staff preparing mailouts.
• A list of all appointments scheduled for next week by date and time, which
should be available for the staffing coordinator each Friday.
• A list of discrepancies and cases that may be ready to be closed out, for a
supervisor to review during the interviewing day.
• Case status summaries by region for the project manager to review the first of
each month.
This section explains how to generate custom reports. It then discusses how the
file TouchReport.prn is generated in the Commute example. Reports dealing
with the daybatch are covered in section 7.6, which deals exclusively with the
daybatch.
7.2.1
How to Generate Report Files
Manipula is used to generate most report files. The input data can be obtained
from the database. In some circumstances, data can be obtained from the history
file and/or the log file. Detailed information about each of these files is provided
in Chapter 3.
Reports that are going to be generated only overnight can directly use the
database as an input file. Alternatively, a report can use what is know in this
manual as an administrative database snapshot as the input file, instead of the
database itself. If an administrative database snapshot is used, the Manipula
program can be run during the interviewing day as well as overnight. As
mentioned earlier, while interviewing is occurring the database can only be
accessed with the setting ACCESS = SHARED. Since shared access involves the
locking of each record one at a time, access to the database can be too slow to be
realistically useful.
The administrative database snapshot should normally contain all the records in
the database, but only the fields that may need to be referenced during the
interviewing day. These fields vary from survey to survey, but often include
interim codes, phone numbers, assigned interviewer or group, and appointment
information. Section 7.3 describes how to update the administrative database
snapshot during the interviewing day.
The flowchart in Figure 7-2 shows the complete report generation process. The
step involving the administrative database snapshot is surrounded by broken lines
104
Blaise
Chapter 7: Creating Additional Support Programs
because it is optional. The report files are known in Manipula as PRINT files.
They are text files that can have headers, footers, and page and line feeds. Once
the report files are generated, use the Control Centre to display and print them.
Since they are text files, non-Blaise software can also be used to display and print
these files.
Figure 7-2: Report Generation Process
database
7.2.2
administrative
database
snapshot
Manipula
process
report
file(s)
Report Example
Assess Blaise database is an example of a tool that generates a report file and then
displays it in Notepad. The report file is called TouchReport.prn. The report
itself, shown in the following figure, presents the number of touched and
untouched cases in the database with separate breakdowns by time zone and
group. It can be used by supervisors to determine the extent to which cases have
been attempted at least once.
CATI Guide
105
Chapter 7: Creating Additional Support Programs
Figure 7-3: TouchReport.prn
The Manipula program CatiReport.man is used to produce
TouchReport.prn. When TouchReport.prn is generated overnight, the
survey database can be used as the input file. In the example given here an
administrative database snapshot CatiList.asc is used instead as the input file.
CatiList.asc, which is routinely generated as part of overnight processing,
contains a snapshot view of the database as it exists just before interviewing
begins again. The use of CatiList.asc instead of the survey database itself
means that the Manipula setup that generates this report can also be used any time
during the interviewing day. If CatiList.asc is current then
TouchReport.prn will be as current as CatiList.asc. The updating of
CatiList.asc during the interviewing day is discussed in the next section.
The Manipula program CatiReport.man contains global auxfields in which the
totals for all the relevant categories are stored. Note that AUTOREAD is set to NO
and a WHILE loop is used to read all the records in CatiList.asc. As the cases
are read one-by-one the counts in the relevant auxfields are incremented
appropriately. Once the loop is exited, the individual lines containing the auxfield
totals are written to TouchReport.prn.
In the tool Assess Blaise database, a Maniplus shell, ViewTouchReport, is used to
run the CatiReport.man and then display TouchReport.prn using Notepad.
You can substitute other software packages for Maniplus and/or Notepad.
106
Blaise
Chapter 7: Creating Additional Support Programs
7.3
Reports Based on Refreshed Administrative Database
Snapshots
Sometimes during the interviewing day it is necessary to generate reports that are
as up-to-date as possible. As discussed previously, it is not possible to effectively
access the database, history or log files during the interviewing day. However, it
is possible to make a copy of the history file during the interviewing day. Up-todate information can then be obtained from this copy. Since database fields can be
selected for inclusion in the history file in the Field selection branch of the
specification file, the history file can provide information not only on its standard
15 fields, but also on all the database fields that have been selected for inclusion
in it.
Although a copy of the history file by itself can be used to generate up-to-date
reports, this is not usually done, because all the information in the database cannot
be inferred from the history file. This is because information on cases that have
not yet been attempted, or were attempted by using the CATI Management
program without entering the DEP, is not included in the history file. Moreover,
during the interviewing period, cases can be added to or deleted from the database
and overnight batch processing can modify the values in various fields without
any of this being reflected in the history file.
To overcome deficiencies that would result from using a copy of the history file
by itself, an administrative database snapshot, as discussed in section 7.2.1, can be
generated during overnight processing. Information from this snapshot can then
be combined with information in the copied history file to provide thorough and
fairly up-to-date information throughout the interviewing day. This information
can then be used to generate more up-to-date reports.
The next sections explain how to generate a copy of the history file, and then how
to combine this copy of the history file with an administrative database snapshot
in order to get a refreshed administrative database snapshot. A Maniplus utility,
Outcomes.man, included in the Commute example, can be used to refresh an
administrative database snapshot and generate reports based on the refreshed
snapshot.
7.3.1
How to Generate a Fresh Copy of the History File
The Blaise product subfolder Samples\Dll\FileCopy provides a dynamic link
library file called blfcopya.dll that can be used to safely copy the history file
during calling. It can be used from a Maniplus program on demand to make the
CATI Guide
107
Chapter 7: Creating Additional Support Programs
file copy. The DLL locks the Blaise database, allowing a safe copy to another
location. Once the file is copied, the database lock is released.
Maniplus source code that performs the copy is shown in the following example.
This program is called CopyFileA.man.
PROCESS BLFCopyA "Blaise file copy for ANSI, used with
Blaise versions 4.3 and above."
AUXFIELDS
Res, Reslt: INTEGER
PROCEDURE CopyFile
PARAMETERS
IMPORT
AFileName: STRING
{May contain a wild card in the
extension, like 'all.*'}
IMPORT
TargetDir: STRING
EXPORT
Reslt: INTEGER
ALIEN('BLFCopyA.DLL', 'CopyFileWhileLocked')
ENDPROCEDURE
MANIPULATE
IF FILEEXISTS('..\Work\Commute.bth') THEN
Reslt := RUN('DEL..\Work\Commute.bth')
ENDIF
CopyFile('..\CATI\Commute.bth', '..\Work\Commute.bth', Res)
IF Res <> 0 THEN
DISPLAY ('History file copy failed.', WAIT)
ENDIF
The procedure CopyFile implements the lock and copy with the ALIEN
instruction. You can name the file to be copied and the target location. In the
example above the copied file has the same name as the original history file, but
is copied to the Manipula subfolder. The IF statement checks to see if the file
Commute.bth exits, and deletes the file if it does exist.
7.3.2
How to Refresh an Administrative Database Snapshot
The flowchart in Figure 7-4 shows how an administrative database snapshot can
be combined with a fresh copy of the history file to produce a refreshed
administrative database snapshot. A specific example of this process will be
discussed in section 7.3.4. All the fields that can be modified during the
interviewing day in the administrative database snapshot should also be included
in the history file. Then the values in these fields can be updated by values in the
history file.
108
Blaise
Chapter 7: Creating Additional Support Programs
Figure 7-4: Refreshing an Administrative Database Snapshot from a Copy
of the History File
administrative
database
snapshot
fresh copy of
history file
Manipula
process
Manipula
refreshed
administrative
database
snapshot
last attempt for
today history file
The first step of this process involves the creation of what is called here the last
attempt for today history file. This file has the same structure as the history file,
but only contains records for dial attempts that have occurred on the current day.
For cases for which there has been more than one dial attempt on the current day,
only the most recent record is included.
Once the last attempt for today history file is generated, a Manipula process is run
in which the administrative database snapshot is the primary input file and the last
attempt for today history file is the secondary input file. The refreshed
administrative database snapshot is the output file. Cases are linked using the
primary key. The JoinID field can be used instead of the primary key if JoinIDs
have not been changed during the survey. Whenever a match is found, the
refreshed administrative database snapshot values are updated accordingly. The
final product can be an entirely new file and/or a revised copy of the
administrative database snapshot.
7.3.3
Supervisor Treating Case
If supervisors are using the Forms branch of the CATI Management program to
treat cases, there is a potential drawback to using a copy of the history file to
update database information. Any activity initiated through the Forms branch that
does not result in the running of the DEP is not reflected in the history file even
though it is reflected in the database and the daybatch.
The log file is the only place where supervisory interventions are recorded. If, for
example, you wanted to know the number of super appointments that have been
set for today for a particular interviewer, you can reference the log file. Super
CATI Guide
109
Chapter 7: Creating Additional Support Programs
appointments are represented by all lines that end with Treat Form (x, 14) where x
can be any JoinID.
7.3.4
Example of a Maniplus Utility that Refreshes Administrative
Database Snapshots
The tool Progress reports provides an example of a Maniplus shell that can be
used to generate two different reports. Progress reports is one of the Commute
survey tools installed in the CATI Management Tools menu by running InstallUninstall Commute Tools. These reports are saved in text files called
InterimOutcome.prn and FinalOutcome.prn and can be viewed or printed
directly using any standard text editor. The tool provides the additional capability
to view the reports directly from the Control Centre as shown in Figure 7-5. This
report-viewing option was implemented using a Blaise look-up on the text files.
For each interim outcome in Figure 7-5, the number and percentage of cases in
the current database with this outcome are presented. The report header indicates
the date and time of the history file extract that is used to generate the report. The
corresponding final outcome report, not shown here, would be similar but with
final outcomes instead of interim outcomes.
Figure 7-5: Interim Outcome Report
110
Blaise
Chapter 7: Creating Additional Support Programs
The Maniplus shell is named Outcomes.man. When first invoked, the Maniplus
screen shown in Figure 7-6 appears. When Outcomes ➤ Tabulate Outcome Codes
is chosen, Outcomes.man checks to make sure that CatiList.asc is present in
the Work folder. This is an administrative database snapshot that should have
been made before interviewing began on the current day. If no interviewing is
occurring and the CATI Management program is not running, you can create
CatiList.asc by running CatiList.man.
If CatiList.asc is found, the following programs are run in order:
• CopyFileA.man. Copies the history file into the work folder.
• LastAttempt.man. Creates a version of the history file that contains only
the last attempt for each case attempted on the current day.
• HistoryMerge.man. Generates an updated version of CatiList.asc called
HistoryMerge.asc.
• MergedFileCopy.man. Replaces CatiList.asc with
HistoryMerge.asc.
HistoryMerge.man cannot directly update CatiList.asc, because an ASCII
file cannot be defined as an UPDATEFILE in a Manipula setup.
Figure 7-6: Generate and Display Progress Reports
CATI Guide
111
Chapter 7: Creating Additional Support Programs
To see on-line the report for interim outcomes, choose Outcomes ➤ View
Outcome Codes ➤ Interim Outcome. The information in this report will reflect the
information in CatiList.asc. It will normally be as up-to-date as possible only
if you have just previously chosen Outcomes ➤ Tabulate Outcome Codes.
7.4
Appointment-Related Reports
Appointment-related reports can deal with past appointment history, or can look
at future appointments in an attempt to help make weekly, daily or even hourly
staffing decisions.
7.4.1
Different Types of Appointments
Only information related to the most recent appointment is stored in the
CatiMana.CatiAppoint block in the database. This is the information shown when
a case is zoomed to look at the appointment info in its Case Summary dialog.
There are seven different possible appointment types:
• Date and time (start date and start time),
• Period and day part (start date, end date, start time, and end time),
• Weekday and day part (one or more days, start time, and end time),
• Only period (start date and end date),
• Only week day (one or more days),
• Only day part (start time and end time), and
• No preference.
Each type requires the additional information shown above in parentheses for
completeness. As shown below, a period and day part appointment has an
associated start date, end date, start time, and end time.
112
Blaise
Chapter 7: Creating Additional Support Programs
Figure 7-7: Case Summary Dialog
When a second appointment is made for a case, the information related to the first
appointment is overwritten in the CatiMana.CatiAppoint block in the database.
To retain previous appointment information, it is advisable to add
CatiMana.CatiAppoint fields to the history file.
If using time zones, the times stored in the CatiMana.CatiAppoint block are in
respondent time. The times that are shown in the Case Summary dialog are
converted behind the scenes by Blaise into interviewer time.
7.4.2
Future Appointment Load
A report showing the number of exact date and time appointments scheduled for
each hourly interval on a given day is straightforward to prepare. To do this, go
through the database and count the number of such appointments, making sure to
make appropriate adjustments when dealing with different time zones.
A more complex report is one that shows the number of weekday appointments
scheduled for each hourly interval on a given day, for example next Tuesday. A
number of different criteria can be used to determine which appointments to
include in this report. These criteria may be:
CATI Guide
113
Chapter 7: Creating Additional Support Programs
• Include all weekday appointments for which Tuesday is one of the specified
days, irrespective of how many other different days may be specified.
• Include only weekday appointments for which next Tuesday is the first
possible day.
• Include only weekday appointments for which next Tuesday is the last
possible day.
• Include only weekday appointments for which a specified time range has
been given.
Once you have decided which appointments to include, you need to make any
necessary time zone adjustments. In addition, you must decide what hourly
interval to assign to appointments with a time range that spans more than one
hourly interval. For example, is an appointment for 3 p.m. to 5:30 p.m. to be
assigned to the 3-4 interval, the 4-5 interval or the 5-6 interval or to all three of
these intervals? If it is assigned to all three intervals, should it count only as onethird of an appointment in each of these hourly intervals? Or should it count as
two-fifths of an appointment in the 3-4 and 4-5 interval and one-fifth of an
appointment in the 5-6 interval?
If you opt to include appointments for Tuesdays that do not have a day part,
choosing an hourly interval becomes especially tricky. When preparing the
daybatch, the Blaise Scheduler automatically makes the Do not call after time the
EndInterval for such cases. The StartInterval for such cases, however, can be the
starting time of any of the crews since the Scheduler tries to spread out such cases
among the various crews. For these reasons, it may be a good idea to provide a
separate count that is not broken down by hourly interval for cases without a day
part.
Period appointments provide similar problems to those discussed above for
weekday appointments. When it comes to no preference appointments, consider
excluding them from any listing of future appointments that is used to help make
staffing decisions since they are inherently very tentative.
Note that cases with various kinds of appointments may remain in the database
even though they have a concluding status, such as Response or Non-response. It
makes no sense to report appointments that will never be honored on a list of
future appointments.
114
Blaise
Chapter 7: Creating Additional Support Programs
7.4.3
Reporting on Appointments
The only summary appointment information available in Blaise is the graph
shown in the Appointments sub-branch of the View daybatch branch in the CATI
Management program. Blaise draws and refreshes this graph in accordance with
the information provided in the daybatch file. If time zones are defined, all times
are converted into call center time. All appointments are shown within the hour
interval that they can first possibly be called. For example, an appointment for
9:30 to 12 noon any day would be shown only in the 9-10 a.m. interval.
You can use this graphical approach to get some idea of the appointment load for
any date in the future. To do so, copy the database to an isolated workstation and
then change the date on the workstation to the desired future date. Then make the
daybatch and view the Appointments sub-branch.
7.4.4
Appointment Example
The tool List all appointments generates a report called ApptList.prn. An
example of this report, which lists all appointment data stored in the database by
group, is shown below. CatiList.asc is used as the input file. CatiList.asc
is an administrative database snapshot that contains all the fields in the
CatiMana.CatiAppoint block.
The Manipula process ApptList.man is run to generate ApptList.prn. One
line for each case for which the CatiMana.CatiAppoint.AppointType field is not
empty is written to ApptList.prn. Hence appointments for dates in the past or
for cases that have been closed out, but not removed from the database, are
included. Since time zone adjustments are made in the process of generating
CatiList.asc, they are not made in ApptList.man.
ApptList.man contains a MANIPULATE section, followed by a SORT section,
followed by another MANIPULATE section, which is followed by a PRINT
section. The SORT section sorts all the appointments by BeginDate and
BeginTime. The second MANIPULATE section adds a blank line after each group
of appointments with the same beginning date. The PRINT section adds headers
and footers.
CATI Guide
115
Chapter 7: Creating Additional Support Programs
Figure 7-8: List of All Appointments by Group
In this example, a Maniplus shell named ApptView.man is used to run
ApptList.man and then display the resulting report on the screen using
Notepad. If ApptView cannot find CatiList.asc in the Work folder, it displays
a message that it cannot be run until CatiList.asc becomes available. If you
want ApptList.prn to convey the latest possible information during the
interviewing day, you separately need to update CatiList.asc before running
ApptView.man.
7.5
History Viewer
As described in Chapter 5, the History Browser provides a very good way to
monitor interviewer productivity and to create useful listings. This section
describes how to generate additional customized views of the history file.
Two different possible approaches are presented. One approach involves the use
of dataview.exe, the Blaise database browser provided with the Blaise product.
The other approach involves the use of a Maniplus lookup on a temporary table in
memory. Other approaches involving non-Blaise products are possible, but are
not discussed here. This section has an example of a history viewer that is
provided with the Commute survey, using the Blaise database browser approach.
116
Blaise
Chapter 7: Creating Additional Support Programs
To see an example that uses the Maniplus lookup approach, refer to the daybatch
viewer example covered in the next section.
7.5.1
Creating a History Viewer
The flowchart that follows shows two different ways to generate a history viewer.
The first approach involves the creation of a Blaise database that can then be
viewed using the database browser provided as part of the set of Blaise
executables. The second approach involves the creation of a Maniplus temporary
file that can then be viewed as part of a Maniplus lookup operation. The first
approach involves less programming, while the second approach allows for the
inclusion of a number of useful additional features within the history viewer.
These additional features include various searches, sorts and filters as well as the
ability to select individual cases for the purpose of review and/or data
modification.
In both approaches, start with a fresh copy of the history file to be viewed. Use
blfcopya.dll provided with the Blaise product to make a separate copy of the
history file. This process is discussed in section 7.3.1.
The history file is a comma-separated ASCII text file. To convert it into either a
Blaise database or a Maniplus temporary file, first create a data definition for the
Blaise database or the temporary file. Blaise makes the creation of such a data
definition easy, because the file history.bla is routinely provided with the
Blaise product in the Doc\Chaptr10 subfolder. The history.bla file defines a
history datamodel that contains the 15 standard history file fields. All that is
needed is to add any extra fields selected for inclusion in the history file to the
end of this list of 15 fields. Make sure that the additional fields are listed in the
same order that they are listed in the Field selection branch of the specification
file. Once the definition of the history datamodel is completed, prepare the file.
The resulting history.bmi file provides the data definition that will be needed
in the USES section of the Manipula process that is used to convert the copy of the
history file into a Blaise database or a Maniplus temporary file.
CATI Guide
117
Chapter 7: Creating Additional Support Programs
Figure 7-9: History Viewer Process
fresh copy of
history file
fresh copy of
history file
Manipula
process
Blaise
history
database
Dataview
on-line view of
Blaise
history
database
Maniplus
process
memory
history
file
Maniplus
lookup
on-line view of
memory
history file
When using the first approach, make sure that you include a secondary key
definition in the history.bla for each field or combination of fields that will be
used to sort and search the history database. The database browser only makes
sort and search options available for primary and secondary keys.
It is important in most circumstances never to delete a field added to the history
file, or to change the order of fields added to the history file. If such changes are
made, entries in the History file for dial attempts that pre-date the change will not
be correctly read or displayed, because the fields will be misidentified using the
new order.
7.5.2
History Viewer Example
The tool Trace History provides an example of a Maniplus program, called
ViewHist.man, that can be used to produce a history viewer. The following
sequence of commands in ViewHist.man reads a copy of the history file into a
Blaise history database and invokes the DEP with the /B browser option.
MANIPULATE
Reslt := CALL('CopyFileA')
Reslt := CALL('ToHistory')
AHistoryFile.OPEN('History')
Reslt := AHistoryFile.EDIT('/B')
AHistoryFile.RELEASE
The first CALL uses the DLL to safely copy the history file. The second CALL
reads the data into a Blaise history data file using a simple ASCII to Blaise
Manipula program. The EDIT function invokes the DEP on the Blaise history file
and brings up the browser as shown in the following figure.
118
Blaise
Chapter 7: Creating Additional Support Programs
Figure 7-10: Blaise Data Browser on a Blaise History Database
In the drop down list in the screen above, four secondary keys are defined. These
present a listing in the order of:
• Interviewer, dial date, and time.
• Primary key, dial date, and exit time (useful for tracing a case).
• Dial date and exit time.
• JoinID, dial date, and exit time.
Secondary key definitions can be altered to suit your needs. Secondary keys are
modified, added, or deleted in the history.bla file that reads the history file.
After modifying this file, re-prepare it to create a new .bmi file.
In the screen above, the data are sorted by primary key, date, and time. If another
key is selected from the drop down list, the order of the display is likely to
change. If the No key option is selected, the records are sorted by the order in
which they were read into the database.
Usually all of the steps to create and display a history viewer take only a few
seconds to execute. Switching a secondary key for a different display order also is
CATI Guide
119
Chapter 7: Creating Additional Support Programs
very quick. LAN traffic issues and the size of the history file have an impact on
performance.
7.6
Daybatch Viewer
The View daybatch branch of the CATI Management program is described in
Chapter 5. Blaise provides standard views of the daybatch. For some studies,
customized views are needed and this section presents two approaches. One
approach involves the use of dataview.exe, the Blaise database browser
provided with the Blaise product. The other approach involves the use of a
Maniplus lookup on a temporary table in memory. Other approaches involving
non-Blaise products are possible, but are not discussed here.
The daybatch viewer that is provided with the software for this manual is
discussed in this section. This example uses the Maniplus lookup on a memory
table approach.
This section concludes by providing perspective on the JoinID field. JoinID is
particularly important when dealing with the daybatch file, because JoinID
provides the only way to link the daybatch file with the database.
7.6.1
Creating a Daybatch Viewer
The following flowchart shows two different ways to generate a daybatch viewer.
The first approach involves the creation of a Blaise database that can then be
viewed using the database browser provided as part of the set of Blaise
executables. The second approach involves the creation of a Maniplus temporary
file that can then be viewed as part of a Maniplus lookup operation. The first
approach involves less programming, while the second approach allows for the
association of a number of useful additional features with the lookup table. These
additional features include various searches, sorts and filters as well as the ability
to select individual cases for the purpose of review and/or data modification.
In both approaches, use the ASCII version of the daybatch as an input file. The
ASCII version of the daybatch file has a .tdb extension. It is automatically
generated every time the daybatch is created. Afterwards, during interviewing, the
ASCII version must be refreshed by hand to ensure up-to-date information. This
is done by leaving the View daybatch ➤ Browse branch of the CATI Management
program and returning to it. When the message appears to refresh the contents of
the daybatch, not only will the display on the screen be refreshed, but also the
associated .tdb file.
120
Blaise
Chapter 7: Creating Additional Support Programs
Beginning in Blaise version 4.6, the ASCII version of the daybatch no longer
needs to be refreshed by hand. This is because the CATI Management program
(btmana.exe) can be invoked with either the /A or the /AB command-line
switch. When invoked with the /A switch, the ASCII daybatch file is refreshed
every time a tool is launched using the Tools menu in the CATI Management
program. When invoked with the /AB switch, the CATI Management program
runs in batch mode and refreshes the ASCII daybatch file. As an example, in the
Commute survey the following code can be added to a Maniplus program before
the ASCII daybatch file is used as an input file.
Reslt := RUN(‘”C:\Program Files\StatNeth\Blaise46\btmana.exe” /AB
..\Data\Commute’)
If, as assumed here, btmana.exe has been included in the default folder used by
the standard Blaise installation program, this code launches btmana.exe to
refresh Commute.tdb (the ASCII daybatch file) and then closes btmana.exe.
To include any database fields in the viewer, an administrative database snapshot
must also be used as a second input file. Any such snapshot must be linked to the
first input file by JoinID, since JoinID is the only means by which a record in the
daybatch file can be identified in the survey database. If the values in the fields
that are included in the administrative database snapshot do not change during the
interviewing day, the copy can be generated only once at the beginning of each
interviewing day. However, if these values may change, the administrative
database snapshot should be refreshed before it is used as an input file. The
updating of an administrative database snapshot is discussed in section 7.3.2. As
discussed in previous sections of this chapter, the Blaise database should not be
directly referenced during the interviewing day because accessing the entire
database in shared mode while interviewing is occurring usually would be too
slow to be practical.
CATI Guide
121
Chapter 7: Creating Additional Support Programs
Figure 7-11: Daybatch Viewer Process
ASCII
daybatch
Manipula
process
Blaise
daybatch
database
Dataview
on-line view of
Blaise
daybatch
database
Maniplus
lookup
on-line view of
memory
daybatch file
administrative
database
snapshot
ASCII
daybatch
Maniplus
process
memory
daybatch file
administrative
database
snapshot
When using the first approach, make sure to include a secondary key definition
for each field or combination of fields that will be used to sort and search the
Blaise daybatch database. The database browser only makes sort and search
options available for primary and secondary keys.
7.6.2
Daybatch Viewer Example
The tool Enhanced daybatch view provides an example of a Maniplus program
called DaybatchViewer.man that can be used to produce an enhanced daybatch
viewer. It is enhanced because the viewer includes not only the 14 standard
daybatch fields, but also 2 fields that are derived from the database and do not
appear in the daybatch. One of these fields is the two-digit region. The other field,
called PrimaryKey, is a concatenation of the four database fields that comprise the
primary key.
If the menu option Daybatch Details ➤ View Daybatch Details is selected, the
procedure FillTempFileProc is called. It uses CatiList.asc and the .tdb file
to create a memory table called TempDaybatch. Then the procedure
ShowTempFileProc is called with a lookup that displays TempDaybatch on the
122
Blaise
Chapter 7: Creating Additional Support Programs
screen as shown below. If CatiList.asc or Commute.tdb do not exist, the
daybatch cannot be viewed.
Figure 7-12: Enhanced Daybatch View
If the Sort button is selected, the order in which the viewer is sorted can be
changed. The options shown in the Figure 7-13 are all available. In Figure 7-12,
the cases are sorted by Status/Priority.
Figure 7-13: Sort Dialog
CATI Guide
123
Chapter 7: Creating Additional Support Programs
If the Refresh button is selected, a message asks if you want to refresh View
daybatch in the CATI Management program. If you do, you must return to the
CATI Management program and refresh by leaving the View Daybatch ➤ Browse
branch and then returning to it. Once you return to the Commute daybatch viewer
utility, if you answer Yes and have actually refreshed View daybatch, an updated
version of the daybatch appears on the screen.
The enhanced daybatch viewer also contains a menu option called Daybatch
Summaries. Use this option to generate and display three different on-line
summaries using the data in the TempDaybatch memory table. These summaries
are an optional part of a daybatch viewer, but can be used to see daybatch totals
by group, region, or another field.
An example of a summary report by region is shown in Figure 7-14. This report is
generated by first using the SETREADKEY function to sort the TempDaybatch
memory table by region. Then TempDaybatch is read record-by-record.
Whenever a new region is encountered, the total record count for the previous
region is stored in the TempRegionSum temporary memory file along with the
number of the previous region. After all the records in TempDaybatch have been
read, a lookup dialog is used to display TempRegionSum on the screen.
Figure 7-14: Daybatch Summary by Region
124
Blaise
Chapter 7: Creating Additional Support Programs
7.6.3
Perspective on the JoinID
Whenever a Manipula process is run that creates a new Blaise database, each
record in the database is assigned a unique number known as the internal key or
JoinID. The first record read into the database is given the JoinID of 1, the second
record the JoinID of 2 and so on. If a new case is added to the database by
running a Manipula process or the DEP, Blaise assigns a JoinID to the new case
that is one greater than the highest JoinID currently in use in the database. This
means that the JoinID of a deleted case is not reused unless it happens to be the
highest JoinID.
You can obtain the JoinID in three different ways:
• From the Control Centre, select Database ➤ Browse Contents (or launch
dataview.exe) for the database. Right click and select Display Options and
check Internal record number. Click the OK button and the database is
displayed with the JoinID, labeled Internal Number. If No key is selected as
the sort option, the database is sorted by JoinID (i.e., the order in which the
records were entered into the database).
• The JoinID can be accessed in a Manipula or Maniplus program by using the
FORMNUMBER method. For example, the following code snippet can be used
as part of a Manipula program that generates a text file that lists all primary
keys along with their JoinIDs.
OutFile.JoinID := InFile.FORMNUMBER
• Both the primary key and JoinID are included as standard fields in the history
file. In List view in the History Browser, the JoinID field appears immediately
to the right of the primary key (ThePrimKey field).
When browsing the daybatch in the CATI Management program, the JoinID is
shown without the primary key. The value of the primary key of a particular case
can be determined by zooming (double-clicking on the case or using the Zoom
speed button or Zoom menu option) the case to bring up the Case Summary
dialog. The primary key is the first field shown in the Case Summary dialog .
Although it may be tempting to use the JoinID as the primary key, it is not
advisable. At various points during the survey, to guard against possible database
corruption or to handle existing database corruption, it may be useful to create a
CATI Guide
125
Chapter 7: Creating Additional Support Programs
Blaise-to-Blaise copy of the database. During the copying process, there is a real
possibility that some or even all of the cases will end up with different JoinIDs.
7.7
Review and Recode Utilities
Maniplus can generate different review and recode utilities to view and modify
information stored in the survey database. Data can be viewed in a number of
ways. One way involves running the DEP on an individual record basis in edit
mode. Another way is via a formatted data display that shows selected values in a
dialog.
This section presents an example of a utility that is used to set final codes on a
case-by-case basis for the Commute example. While some final codes in the
Commute example are assigned by rules in the datamodel (such as a complete
case), many final codes can be set manually with this utility. This utility has an
option that shows the pattern of outcomes from multiple attempts with one
respondent. For example, a case where there have been several hard appointments
that have been missed by the respondent may really be a refusal that does not
warrant further effort. Once a case has received a final code, it is no longer
included in the daybatch.
7.7.1
Creating a Review and Recode Utility
The following flowchart shows the underlying framework of a review and recode
utility. Since such utilities are normally used by supervisors during the
interviewing day, their initial input needs to come from an administrative
database snapshot and not directly from the database itself. This is because
accessing the entire database itself in shared mode would be too slow during the
interviewing day. The generation of a refreshed administrative database snapshot
is discussed in section 7.3.
Figure 7-15: Review and Recode Utility Process
administrative
database
snapshot
Maniplus
process
database
memory file
Maniplus
processes
database
The refreshed administrative database snapshot is used to generate the database
memory file. The database memory file is displayed on the screen as a lookup
table. Depending on the ultimate purpose of the utility, both the administrative
126
Blaise
Chapter 7: Creating Additional Support Programs
database snapshot and the database memory file need not contain all the records
or all the fields in the database. However, the administrative database snapshot
must include all the records and fields required by the database memory file.
There are a variety of buttons that can be displayed on the screen along with the
lookup table for the database memory file. Each button can be used to launch a
different Maniplus process. The Maniplus processes can be used to perform four
different functions:
•
Modifying the lookup table,
•
Generating a formatted data display for review and recoding of the case
highlighted in the lookup table,
•
Running the DEP on the highlighted case, and
•
Generating reports, dealing with all or some cases.
Modification of the lookup table often involves searching, sorting or filtering. It is
usually done so that supervisors can locate the cases they wish to review. From
time to time during the interviewing day, the modification of the lookup table
may also involve updating the values in the lookup table to reflect the current
status of the database. A refreshed administrative database snapshot needs to be
generated whenever the lookup table is to be refreshed.
A formatted data display is normally a key component of the recoding process. It
is carefully designed to show not only the database fields that may need to be
recoded, but also all the database fields whose values need to be reviewed as part
of the recoding process. Supervisors can enter new values into fields that need
recoding on the formatted data display. These new values can then be written
directly into the production database.
In order to obtain current values for the fields presented in the formatted data
display, the appropriate record in the production database is locked and then read.
The record stays locked until completely processed. If changes in database fields
are made, these changes are written directly to the locked record in the production
database. Owing to the ability to lock individual records, the review and recode
utility can write directly to the database even though it must obtain its initial
information on all the records by reading from an administrative database
snapshot and not from the database itself.
The DEP is run on individual cases that supervisors wish to review in detail. The
DEP is invoked in a Maniplus process with the EDIT function. Frequently, the
CATI Guide
127
Chapter 7: Creating Additional Support Programs
statement to invoke the DEP uses the switches shown in the following code
sample.
Reslt := UpFile.EDIT( '..\Commute /D /RE /G /K' + PrimaryString + ' /X')
It is necessary to use /D to disable CATI and thereby bypass the Scheduler. The
selected case is identified by /G /K followed by the primary key. The /X is used in
order to make sure that the DEP is run only on one case. The /R is used to run the
DEP in read-only mode. The combination /RE is used to allow the entry of data
that will not be saved. If /R or /RE is not used, all changes made while navigating
through the case can be saved to the database, which may or may not be desirable
because the rules will be invoked and unexpected DEP changes could result. This
does provide an alternative way, other than a formatted data display, to modify
the data in the database.
A variety of different reports can be generated from the database memory file.
These reports can be used to facilitate the review process.
7.7.2
Review and Recode Utility Example
The tool Review outcomes provides an example of a Maniplus program, called
Review and Recode (RandR.man), that can be used as a review and recode
utility. When Review outcomes is first chosen from the Tools menu, the following
prompt appears.
Figure 7-16: Fresh Information Prompt
The prompt allows you to decide whether to update the review data. If Yes is
chosen, CatiList.asc is updated from the history file as documented
previously.
Next, the procedure FillTempTable is run in order to create the memory database
file from CatiList.asc. A Maniplus lookup is used to display this memory file
on the screen. An example of this lookup appears in the following figure.
128
Blaise
Chapter 7: Creating Additional Support Programs
Figure 7-17: Review and Recode Utility
The functions of the buttons are as follows:
•
Review brings up the DEP on the highlighted case so that data in the
instrument can be reviewed. When the case is closed, however, any changes
made are not saved.
•
Refresh makes an updated copy of CatiList.asc and the memory database
table. It uses a copy of the history file to make the updates. The old memory
database table is replaced on the screen by the updated memory database
table.
•
Code brings up a recoding screen to assign a final code to a case. If a final
code is assigned, the case will not be eligible for future daybatches.
•
Sort allows the lookup table to be sorted in the order of the JoinID, primary
key, or interim code. For the latter choice, since the interim codes are an
enumerated type, the sort is in the order in which the interim codes are listed
in their type definition.
•
Filter allows the records shown in the memory table to be limited to those
with a specific interim code.
•
Close exits the program.
CATI Guide
129
Chapter 7: Creating Additional Support Programs
Review Button
The Review button brings up a read-only DEP on the chosen case, allowing a
review of the most recent interview. Such a review may be helpful in determining
an appropriate final outcome code.
Figure 7-18: DEP from Review on the Chosen Case
The case is shown as the interviewer would have seen it and data can be entered.
However, upon exit, the data are not saved and the following prompt appears.
Figure 7-19: Review Prompt on Exit from DEP
130
Blaise
Chapter 7: Creating Additional Support Programs
Code Button
The Code button brings up the Set Final Code dialog shown in the following
figure.
Figure 7-20: Set Final Code
The contents of the OutcomeHistory array from within the datamodel record are
displayed in the upper left-hand part of the dialog. This allows the supervisor to
see a summary of the attempts for this case. In the example above, this case has
been attempted only one time. By choosing Known respondent refusal, the case is
given a final outcome code as illustrated in the following screen. The field
Manage.FinalOutcome in the record in the Blaise data file is updated directly by
this dialog.
Figure 7-21: Final Code is Set
This final outcome code and others can be excluded from subsequent daybatches
by setting Daybatch select exclusion parameters in the specification file as shown
in the following figure.
CATI Guide
131
Chapter 7: Creating Additional Support Programs
Figure 7-22: Specification File Excluding Final Codes
Although not done in RandR.man, in a custom review and recode utility it may
be desirable to add code that uses the function DAYBATCH_DEL to remove a case
with a newly-set final outcome code from the current daybatch. It may also be
useful to write the newly-set final outcome code to the database memory file and
CatiList.asc. The Refresh button as programmed in this utility is presented as
a helpful first step in designing utilities, hence it does not refresh newly-set final
outcome codes, because it uses the data in the history file to make updates, and
information on outcome code changes is not written into the history file. It is
possible to create a log file for this utility and write information about any code
changes into this log file. This information can be used for update purposes.
Filter Button
The Filter button brings up the Select Interim Outcome Code dialog shown in
the following figure. Highlight one of the interim outcomes and select the Filter
on code button to bring up a lookup table that contains the subset of cases in the
database with the chosen interim outcome.
132
Blaise
Chapter 7: Creating Additional Support Programs
Figure 7-23: Select Interim Outcome Code
By choosing Firm initial refusal by respondent, for example, the following subset
of records appears.
Figure 7-24: Subset of Records in Review and Recode Utility Lookup
By subsetting records, it is possible to focus on a particular class of interim
outcomes.
7.7.3
Recoding Utilities in General
Recoding utilities, which allow supervisors to update various fields in the
database while interviewing is occurring, can take several different forms. The
review and recode utility described in the previous section begins by providing
supervisors with a list of all the cases in the database. The supervisors can search,
sort and/or filter this list in order to pinpoint the particular cases that they can
subsequently review individually and possibly recode.
CATI Guide
133
Chapter 7: Creating Additional Support Programs
If supervisors already know how to identify the cases that should be recoded,
there is no need to provide them with a list of all the cases in the database. In such
circumstances, the Maniplus utility can simply open the live database in shared
mode. A GET statement can be used to obtain each record that is to be updated.
The revised record can subsequently be written back to the live data file. If
inactive cases are changed to active cases through this process, they can be added
to the current daybatch by using the DAYBATCH_ADD function.
134
Blaise
8
Network Topics
This chapter discusses selected topics related to the operation of Blaise® software
on a local area network (LAN).
8.1
Blaise CATI Performance
Performance refers to the response time experienced by users of the Blaise system
when performing a CATI survey. Slow performance can usually be traced to the
development of the instrument or to network issues. There may be some overlap
between the two. Performance problems due to instrument construction
sometimes manifest themselves in field-to-field slowness. Performance problems
due to network issues may have many different manifestations including slow
external file access and slow delivery of a case from the Scheduler.
When performance issues occur, try to determine whether the performance
problem is instrument or network related. This can be done by putting the
instrument and all of its infrastructure on a local drive, totally separate from the
network, and testing to determine if the performance problems persist. If they do,
then the problems are probably instrument related. If the problems disappear, they
are probably network related.
The network features most likely to impact CATI performance include:
•
File server characteristics such as processor speed and server memory,
•
Workstation elements such as processor speed, memory, and operating
system,
•
Bandwidth of connections,
•
Throughput of routers, connectors, and other devices between the file server
and the workstations, and
•
Network operating system characteristics.
Performance diagnosis and tuning for a highly interactive, real-time application
like Blaise CATI is usually not required for short term or small-scale surveys but
may be required for large-scale or ongoing surveys. The need is partly dependent
CATI Guide
135
Chapter 8: Network Topics
on the volume of data and number of users in relation to the technical
configuration and operational management practices related to the network.
Because all networks vary in this regard, it is important for organizations to plan
and test large-scale or ongoing applications in consultation with their local
systems experts.
8.2
Blaise Network Architecture
The Blaise approach is to rely as much as possible on the capacity of workstations
and minimize the load on the server. The roles of the server and the workstation
are given below.
Server
Holds the Blaise CATI database and passes data records as
requested by the Scheduler.
Usually holds the external files, including WinHelp and multimedia files (some or all external files can go on the
workstations).
Holds the instrument files until they are loaded into workstation
memory.
Holds the current version of the daybatch.
Holds the Blaise system executables (can alternately go on the
workstations).
Often holds the audit trails (can alternately go on the
workstations).
Holds the counts and history files.
Workstation
memory
Many of the Blaise system executables and DLLs are loaded
into memory.
The instrument is loaded into memory.
The data record is loaded into memory.
136
Blaise
Chapter 8: Network Topics
Workstation
memory
(continued)
When the interviewer enters a response, the data are entered into
the record in workstation memory.
When an interviewer requests a case, a copy of the daybatch is
read from the server by the workstation. The workstation selects
a case from the daybatch. Once a case is selected, a message is
sent to the server to lock the record in the survey database, and
the daybatch copy disappears.
The Blaise Scheduler works on the basis of fixed five-minute
intervals. The first workstation to request a case within each
five-minute interval must reevaluate or schedule the daybatch
before it can select a case. Once a case is selected, the newlyscheduled daybatch is sent back to the server. This means that
scheduling invariably takes place on a workstation, not on the
server.
Although it is possible for the network operating system to synchronize times,
Blaise CATI does not synchronize workstation dates and times with the server
date and time. All history file and other times are set in workstation time. A
workstation time that is a few minutes off of the server time will not cause
problems, but one that is off by a considerable amount can cause problems
because of the sensitive date and time aspect of CATI calling.
8.3
The Local Area Network (LAN)
Ideally, the LAN used for Blaise CATI should be physically separate from other
organization LANs. If the server, the workstations, and everything in between are
not separate, there is a risk of problems caused by others saturating the network
resources. Here are two examples of problems arising from these types of
situations.
•
A LAN is shared between CATI and general office work. CATI interviewers
are doing well, but then an office worker decides to load 100,000 records to a
database system on the LAN. The database load takes over almost all network
resources, and the interviewing process, if it involves any access to network
files, slows to a crawl.
•
The server and the workstations are configured and managed specifically for
CATI use, but CATI use is not taken into account in managing the network
CATI Guide
137
Chapter 8: Network Topics
connecting them. One day, changes are made in the LAN architecture and
CATI performance drops substantially until testing and tuning is done with
CATI in mind.
Knowledgeable LAN administrators can generally solve network problems if they
are aware of the necessity of maintaining fast network performance for CATI
interviewing. Performance that is adequate for general office functions may be
insufficient for interviewing. The best solution is to work closely with a LAN
administrator and perform pre-testing of performance prior to production CATI
work.
8.4
Operational Sources of CATI Network Traffic
There are several sources of Blaise CATI network traffic. Basic Blaise CATI,
after the workstations have been logged on, has minimal traffic. This is because
while the interview proceeds, the data entry, processing, and execution of the
instrument rules all occur on the workstation. As interviews are exited, there is
minimal traffic to store a record on the server and to get a new record.
Since a spike in network traffic may occur if many interviewers log in at the same
time, some organizations log on all workstations early in the morning before
calling begins. An alternative solution is to stagger the logons.
A CATI instrument with external file access adds to the network traffic. This is
because the external file information and data description is on the server. If the
instrument makes many unnecessary calls to the external file, for example, every
time a new data value is entered, performance problems may result. The
developer can take steps to access the external file only when necessary.
Also, external files with read-write access may cause performance issues.
Because the DEP does not write to external files, large performance gains may be
realized by making the external data files read-only. If external files are a
continuing source of performance problems, try to load the external files onto the
local C: drive.
While normal data entry is made in workstation memory, an audit trail normally
writes to a file on the server, with writes made for every new data item that is
entered as well as other interviewer actions. The audit trail thus is a constant
source of network traffic. To avoid this, audit key function can be configured to
write audit information to the local C: drive while interviewing takes place. Using
this DLL will decrease network traffic and improve performance.
138
Blaise
Chapter 8: Network Topics
Autosave is a Blaise feature that saves the in-memory workstation data record to
the server at regular intervals. In case of LAN failure such as power loss, the
entire record is not lost. The interval is set in minutes. A frequent autosave is
more secure, but also more intensive in terms of network traffic. A less frequent
autosave is riskier, but less expensive for network traffic.
Third party systems add to the network load. For example, a third party system
may be used for monitoring interviewer workstations. Other third party systems
include telephony, security, and utility systems.
Any Blaise instrument use of coding facilities, either alphabetic or trigram, adds
to network traffic because of the cross-record searching on the centrally stored
coding frame. Alphabetic searches add minimal traffic, but trigram searches can
add more traffic. If an instrument has extensive trigram searches and many
workstations, large gains may be realized by making the coding files read-only. If
performance problems continue, a solution is to load the trigram coding files
locally on the C: drive or on a virtual memory drive in workstation memory.
Accessing cases takes several forms in Blaise CATI. The most common form has
the Scheduler choose and deliver a case. However, there are times when the
interviewer must choose a case from the database. This can happen when a
respondent calls in and wants to be interviewed on the spot. The instrument
developer usually provides secondary keys such as telephone number or the
respondent name or address. If one or more of these search keys are trigram keys,
it can add to network traffic as the interviewer is modifying the trigram search
string. Since the search is on the central database, it is not possible to load this
search file on the local drive or in local memory, or to make this file read-only. If
many interviewers need to select cases individually, monitor performance and
consider switching to alphabetic searches if difficulties arise.
8.5
Testing Network Performance
After survey instruments are developed and CATI functionality is added, it is
useful to do testing in a network environment with multiple testers simulating the
production situation as closely as possible. It is not always possible to identify
potential unique network complications by generalizing from other tests and
surveys.
Network performance can be tested in various ways. One option is to use testers
or interviewers to exercise the LAN by entering test data simultaneously. Another
CATI Guide
139
Chapter 8: Network Topics
option is to have a tester with a stopwatch time the various components. There are
three kinds of tools that exercise the network:
• The Blaise-supplied BTEmula is described in Appendix D: The CATI
Emulator (BTEmula). This utility brings the instrument and record into
memory, assigns dial results, and can change values stored in the database. It
is fairly easy to operate, and lets you start to judge how the network is
performing. However, it does not exercise coding utilities, it does not put the
normal instrument screens on the workstation, and it does not invoke the audit
trails.
• A script-playing system, such as WinBatch or Windows Script Host, can be
used to make scripts that exercise the workstation in much the same way as an
interviewer would. The normal CATI screens are displayed, audit trails are
invoked, and coding and other intensive features can be played. This kind of
system runs the workstation in the same way the interviewer does.
• A commercial testing system, such as WinRunner, can play back scripts and
watch for problems.
Often a variety of test instruments are developed to exercise the LAN in different
ways. Two examples are:
•
A small instrument with just a few data entry cells in conjunction with a very
large daybatch. The stress this instrument provides is the constant requesting
of records and the storing of the records. Every workstation will be handling
from several to many cases a minute.
•
An instrument with many regular external file reads and trigram coding
accesses.
A LAN administrator can assist with monitoring network activity where
necessary.
8.6
Data Integrity and Repair
Although data corruption is rare, a Blaise database can be corrupted because the
main data-holding file (the .bdb file) is corrupted, an index file is corrupted, or
some other auxiliary file such as a remarks file is corrupted. A corrupt data file
can manifest itself in several different ways:
140
Blaise
Chapter 8: Network Topics
•
A Manipula program cannot read the entire file.
•
A data browser does not work properly, for example, it cannot see all records.
•
An interviewer sees unusual characters on the screen.
•
The Scheduler cannot deliver a case.
•
Hospital diagnosis says the file is corrupt.
When symptoms of corruption are detected, users should close down all calling as
quickly as possible, even if only one interviewer is having the problem. Then
rebuild the Blaise data file with Hospital. Check the Hospital diagnosis to see if a
problem still exists, and if no problems exist, resume calling. If a problem is still
reported by Hospital, perform a Blaise-to-Blaise copy (see section 7.1.2) and
rerun the diagnosis with Hospital.
One reported source of data corruption on Windows NT and 2000 networks is the
system setting called opportunistic record locking. This is enabled by default. For
Blaise file and record handling to function properly, opportunistic record locking
must be disabled. See the Blaise Online Assistant for further information.
As with all software applications users should implement regular system backups
to avoid data loss associated with unanticipated system failures.
CATI Guide
141
Chapter 8: Network Topics
142
Blaise
Appendix A: Installation and Use of Commute Example
Files
This appendix explains how to install and run the Commute example. The
appendix also includes the code provided in the sample Commute source file,
Commute.bla. The Commute example and related files used in this guide can be
downloaded from the Westat Blaise web site, http://www.westat.com/blaise,
under Documentation.
In order to install and use the Commute example, your computer must have
Blaise® 4.6 or higher available as the default version. The installer checks the
registry to determine the default version of Blaise present on the system.
Install/Uninstall Process
Running CommuteSurveyInstall.exe
The Commute example is installed by running CommuteSurveyInstall.exe.
You must agree to the license agreement that appears on your screen before
proceeding with the installation. Once you have accepted the agreement, you are
asked to select a destination folder for the CommuteSurvey folder, as shown
below.
CATI Guide
143
Appendix A: Installation and Use of Commute Example Files
Figure A-1: Select Destination Folder in the Install Program
You are also asked as shown in Figure A-2 to select a start menu folder. By
default, it is given the name Commute Survey. After choosing a start menu folder
name, you are presented with the Create a desktop icon checkbox, which is
checked by default. Keep this box checked to have a folder with the same name
and contents as the start menu folder placed on your desktop. It is useful to have
both a start menu and desktop folder.
144
Blaise
Appendix A: Installation and Use of Commute Example Files
Figure A-2: Select Start Menu Folder in the Install Program
When satisfied with the options that appear in the Ready to Install dialog, click on
the Install button. When the installation is complete, you are given the option to
read the Read This First.html file or exit the setup program.
The Uninstall Process
You can remove the Commute Survey folder from your start menu and desktop
by clicking on the UnInstall Commute Survey shortcut. This shortcut is available
from the Utilities folder in the Commute Survey start menu and desktop
folder. The uninstall process also removes all files and folders that were installed
in the CommuteSurvey folder, provided they have not been modified since
installation. You must manually delete any files that have been modified.
After Installation
Folder Structure
After the system is installed, the CommuteSurvey folder should appear where
specified during installation on your local hard drive or the network. As shown in
CATI Guide
145
Appendix A: Installation and Use of Commute Example Files
the following figure, the CATI Manual ShortCuts, Development, and
Utilities folders should be immediately below the CommuteSurvey folder.
Figure A-3: CommuteSurvey Folders
The three subfolders of the installed Commute Survey are described below:
• CATI Manual ShortCuts folder. This folder is copied by the installation
program to the Commute Survey folder on your desktop, and contains the
shortcuts to the example applications.
• Development folder. This folder contains all the folders and files needed to use
the example system.
•
Cati. Contains the CATI instrument, CATI database, modelib, menu,
and related files.
•
CATIInc. Contains the CATI-specific files referenced in INCLUDE
statements in the CATI source code.
•
DataIn. Contains the initialization data file (Catidata.txt)
•
Include. Contains the files referenced in INCLUDE statements in
the basic source code.
•
Library. Contains the library files that are used to prepare the
instrument.
•
146
Manipula. Contains the various Manipula and Maniplus programs.
Blaise
Appendix A: Installation and Use of Commute Example Files
•
Reports. Contains report files; this folder is initially empty.
•
Work. Contains intermediate files used during the execution of
Manipula programs; this folder is initially empty.
• Utilities folder. This folder contains the files needed to run the three shortcuts
provided inside the Utilities folder installed in the start menu and on the
desktop.
Start Menu and Desktop Shortcuts
After installing the Commute Survey, there is a Commute Survey folder in your
start menu and possibly on your desktop. This folder contains a subfolder,
Utilities, and the following shortcuts:
• Read This First. This gives explanations of, and links to, the tools provided in
the other shortcuts, plus some web links.
• Commute CATI Quick Test. This starts a Maniplus shell to run the CATI
example in three steps.
• Develop CATI Source. This launches the Control Centre with Commute.bla
as the active window.
• Commute CATI Test. This starts a Maniplus shell that can be used for testing
the CATI example. This shell has additional options not found in the quick test
shell.
• Commute Interview. This starts a program that can be used to deliver cases to
interviewers.
• Commute Management. This program shows some of the management tasks
that can be automated using Maniplus.
Utilities Shortcuts
The three shortcuts inside the Utilities folder, shown in the following figure,
perform these specialized tasks:
Figure A-4: Utilities Shortcuts
CATI Guide
147
Appendix A: Installation and Use of Commute Example Files
• Install-Uninstall Commute Tools. Modifies the folder of your registry so that
the Commute example tools are added to the Tools menu in the CATI
Management program, and any previously entered tools are removed and
stored elsewhere. The Tools menu consequently appears as shown in Figure A5 below. These tools have all been defined using relative path names. The
Install-Uninstall Commute Tools shortcut also provides the optimal method to
remove the Commute tools and restore the previous registry settings. Blaise
must always be closed prior to running Install-Uninstall Commute Tools
shortcut or it will not work correctly. If the Commute example tools are
installed and you uninstall Commute Survey either with the uninstall option or
with the option provided when reinstalling Commute Survey, it will not
uninstall the Commute Tools from the Tools menu in the CATI Management
program, but it will uninstall the Install-Uninstall Commute Tools shortcut. If
the Commute example tools are installed with Install-Uninstall Commute
Tools, there are three possible ways to uninstall them:
• The uninstall option of Install-Uninstall Commute Tools is the easiest
way to uninstall these tools, but it must be done while Commute
Survey is installed.
• An alternate file, c:\@CommuteRestoreTools_<additional
identifier>.reg, is created during installation that will uninstall
the Commute Tools and restore the previous registry settings. The
name of the file varies, because the install program uses the network
name or a similar identifier, if available, as part of the procedure
name. To run this file just double-click on it.
• The tools can be removed directly from the CATI Management
program using Tools ➤ Configure Tools ➤ Remove. This will remove
the tool(s), but it will not restore the earlier settings.
Figure A-5: CATI Management Tools Menu
148
Blaise
Appendix A: Installation and Use of Commute Example Files
• UnInstall Commute Survey. Enables you to uninstall the Commute example. If
the Commute example tools have been installed, they must be uninstalled
using the Install-Uninstall Commute Tools shortcut before uninstalling
Commute Survey.
• ReadMe.txt. Provides detailed information on the install/uninstall process and
Install-Uninstall Commute Tools shortcut.
Using the Commute Example System to Accomplish Key Tasks
Once you have installed the Commute Survey and run Install-Uninstall Commute
Tools in the Utilities folder, you can use the Commute example to accomplish key
CATI tasks. These tasks can be accomplished either through the Control Centre or
via the six desktop start menu or desktop shortcuts that have been installed.
This section delineates the alternate ways by which you can accomplish the key
tasks. The Control Centre is normally used in the development stage. The
Commute CATI Test shortcut is designed for testing and training purposes. It
provides the only way outside the Control Centre by which you can refresh (reinitialize) the Blaise Commute database. The Commute Management shortcut is
designed for daily use by supervisors at a call center. The overnight processing
option in both the Commute CATI Test and Commute Management shortcuts
should only be used only when interviewing is not occurring.
Modifying the Source Code
In order to modify the source code, you must bring up the Control Centre with
Commute.bla as the active window. To test datamodel code changes without
having to make a daybatch, check Disable CATI from the Run ➤ Parameters
menu in the Control Centre. To test in CATI mode, disable Disable CATI and
create a daybatch. It is not possible to test in CATI mode without an existing
database or a specification file in which the current day is one of the specified
survey days.
Initializing the Blaise Commute Database
The Manipula program CatiDataLoad.man must be run to initialize or reinitialize the Blaise Commute database. This program creates the Commute Blaise
database in the Cati subfolder from the 4000 records in the Catidata.txt file
in the DataIn subfolder. The Blaise Commute database should be created once
and only once in a production environment. It can be generated and then refreshed
numerous times for testing purposes. The program can be run in two ways:
CATI Guide
149
Appendix A: Installation and Use of Commute Example Files
• Make CatiDataLoad.man in the Manipula subfolder the active window in
the Control Centre. Then select Run ➤ Run from the menu bar, click on the
green triangle speed button, or press <Ctrl><F9>.
• Use the Commute CATI Test shortcut to select the Refresh Blaise CATI
database option.
Modifying the Specification File
In order to make a daybatch and have the Scheduler deliver cases, today’s date
must be included as a survey day in the Survey days branch of the specification
file. In addition, the survey days listed in the specification file should include all
future days on which you wish to schedule appointments. The start time of the
first crew and end time of the last crew in the Crew parameters branch of the
specification file must include the time period during which you want cases to be
delivered.
You may also want to modify the specification file to include yourself as an
interviewer and as a member of one or both of the groups. Do this by using the
Users ➤ Interviewers branch of the specification file. The interviewer name that
you enter for yourself in the specification file must be identical to the name that is
entered for BLAISEUSER in the environment subfolder of the
HKEY_CURRENT_USER folder in the registry of your computer. If there is no such
entry in your registry, the interviewer name that you enter for yourself must be
identical to your login name.
If you do not enter yourself as an interviewer in the specification file, your name
cannot appear in the Active Interviewer branch of the CATI Management
program. If you do not include yourself in a particular group, without changing
pre-existing specification file settings cases assigned to that group can never be
delivered to you.
There are two ways to launch the CATI Specification program:
• With Commute.bla as the active window in the Control Centre, select Tools
➤ CATI Specification from the menu bar.
• Use the Commute CATI Test or Commute Management shortcut to select the
Start Specification Program option.
Creating the Daybatch
To create the daybatch, open the CATI Management program and select
Management ➤ Create daybatch from the menu bar or click on the sun speed
button. There are two ways to start the CATI Management program:
150
Blaise
Appendix A: Installation and Use of Commute Example Files
• With Commute.bla as the active window in the Control Centre, select Tools
➤ CATI Management from the menu bar.
• Use the Commute CATI Test or Commute Management shortcut to select the
Start CATI Management Program option.
Conducting Interviews
The DEP must be launched in order to conduct interviews. There are three ways
to launch the DEP:
• With Commute.bla as the active window in the Control Centre, select Run ➤
Run from the menu bar, click on the green triangle speed button, or press
<Ctrl><F9>.
• Use the Commute CATI Test shortcut to select the Run Commute program
with either the CATI disabled or CATI enabled option.
• Use the Commute Interview shortcut to select the Run Commute Interview
option. CATI is automatically enabled.
Using Support Programs
The support programs all reside in the Manipula folder. For development and
debugging purposes, they can all be run from the Control Centre.
One of the support programs, CatiList.man, creates what is known in this
manual as the administrative database snapshot. It uses the Commute database in
the Cati folder as the input file and generates CatiList.asc, the
administrative database snapshot, in the Work folder. This is one of the key
overnight processing tasks. It accesses the database with the setting ACCESS =
EXCLUSIVE (the default setting) and hence cannot be run during the interviewing
day when other programs are also accessing the Commute database. There are
two ways to run this program:
• Make CatiList.man in the Manipula subfolder the active window in the
Control Centre. Select Run ➤ Run from the menu bar, click on the green
triangle speed button, or press <Ctrl><F9>.
• Use the Commute CATI Test or Commute Management shortcut to select the
Run overnight programs option. This option results in the running of
CatiList.man followed by running of two report-generating programs,
CatiReport.man and ApptList.man.
One of the support programs, ReadOut.man, is designed to delete all completed
cases from the Commute database and write them into the Commute.asc file.
This is a task that may only be run once at the end of the survey, or intermittently
CATI Guide
151
Appendix A: Installation and Use of Commute Example Files
during the lifetime of the survey. It accesses the database with the setting
ACCESS = EXCLUSIVE (the default setting) and hence cannot be run during the
interviewing day when other programs are also accessing the Commute database.
There are two ways to run this program:
• Make ReadOut.man in the Manipula subfolder the active window in the
Control Centre. Select Run ➤ Run from the menu bar, click on the green
triangle speed button, or press <Ctrl><F9>.
• Use the Commute CATI Test or Commute Management shortcut to select the
Delete completed cases from the database, and make ASCII copy option.
With the exceptions of CatiList.man, ReadOut.man and
CatiDataLoad.man (which is discussed in the Initializing the Blaise Commute
Database section above) all the other support programs in the Manipula folder can
be used during the interviewing day. Six of these programs are meant to be run as
separate stand-alone programs. The rest of the programs are referenced by the six
stand-alone programs.
The six stand-alone programs that can be used during the interviewing day are
ViewTouchReport.man, DaybatchViewer.man, ViewHist.man,
ApptView.man, Outcomes.man and RandR.man (see Table 7-1). In order to
run any of these programs the file Catilist.asc, the administrative database
snapshot, must exist in the Work folder. There are two ways to run any of these
programs, which can be demonstrated by using RandR.man as an example:
• Make RandR.man in the Manipula subfolder the active window in the
Control Centre. Select Run ➤ Run from the menu bar, click on the green
triangle speed button, or press <Ctrl><F9>.
• Start the CATI Management program (see Creating the Daybatch above) and
then select Tools ➤ Review Outcomes.
If Review Outcomes does not appear as an option in the Tools menu bar, you need
to run Install-Uninstall Commute Tools. To do this, select the Install-Uninstall
Commute Tools shortcut from the Utilities subfolder in the Commute Survey
folder. Click on the Install button when the Commute Tools Registry Utility
dialog appears.
NOTE: The Commute example has been designed so that the Cati folder
contains not only the Commute.bla file, but also the prepared instrument
(Commute.bmi, Commute.bdm and Commute.bxi), the database
(Commute.bdb, Commute.bfi, Commute.bpk, Commute.bjk, and
Commute.bsk), the specification file (Commute.bts), the mode library file
(Modelib.bml) and the menu file (CatiMenu.bwm). The inclusion of these files
152
Blaise
Appendix A: Installation and Use of Commute Example Files
in one folder is not indicative of what normally happens in the real world, but is
useful when trying to demonstrate basic CATI concepts in as simple a way as
possible. Multiple folders can only be handled by the introduction of additional
layers of complexity that would usually involve the use of projects or the
specification of a series of Run parameters in the Control Centre or command line
switches as part of shortcuts.
Commute Sample Code (Commute.bla)
DATAMODEL Commute "Commuter Survey - CATI Version"
PRIMARY
Ident, PersonNo
SECONDARY
Telephone = Phone
LastDialResult = CatiMana.CatiCall.RegsCalls[1].DialResult
Interim_Outcome = Manage.InterimOutcome
Final_Outcome = Manage.FinalOutcome
PARALLEL
NonResponse = NonResp
Appointment = Appoint
OtherOutcome
NoAnswer
Answering_Machine = AMachine
Disconnect
BusyCall
INHERIT CATI
INCLUDE "..\Library\Mylib.lib"
INCLUDE "..\Library\Transport.lib"
LOCALS
LANAME : STRING[30]
INCLUDE "..\Include\IDENT.INC"
FIELDS
PersonNo : 1..20 {Part of primary key.}
Name : STRING[33] {Name of respondent.}
{User-defined CATI Management fields}
Phone : STRING[12]
Wave : 1..20
TimeZone : STRING[3]
TimeSlice : STRING[3]
ForWhom : STRING[10]
CatiSelect: STRING[5] {This can be any
Normally by the
CatiSort : STRING[5] {This can be any
normally by the
CATI Guide
value written into the database,
use of a Manipula program}
value written into the database,
use of a Manipula program}
153
Appendix A: Installation and Use of Commute Example Files
{Subject matter blocks below.}
INCLUDE "..\Include\ADDRESS.INC"
INCLUDE "..\Include\BPERSONT.INC"
INCLUDE "..\Include\WORKPLCY.INC"
INCLUDE "..\Include\BWORKT.INC"
{Address}
{Person}
{WorkPolicy, called in BWorkT.INC}
{Work}
{Parallel CATI outcome blocks below.}
INCLUDE "..\CATIInc\NONRESP.INC"
{\CATIInc\onse}
INCLUDE "..\CATIInc\APPOINT.INC"
{Appoint}
INCLUDE "..\CATIInc\DISCONCT.INC" {For disconnect outcomes}
INCLUDE "..\CATIInc\AMACHINE.INC" {For answer machine/service outcomes}
INCLUDE "..\CATIInc\NOANSWER.INC" {For no answer call outcomes}
INCLUDE "..\CATIInc\BUSY.INC"
{For busy call outcomes}
INCLUDE "..\CATIInc\OTHER.INC"
{For 'other' call outcomes}
INCLUDE "..\CATIInc\POutCome.prc"
INCLUDE "..\CATIInc\MANAGE.INC"
AUXFIELDS
ReEntry "Re-entry into form?" : TYesNO
InterimOutcomeIndex : 1..60
Introduction "@YNAME: @W^[email protected]@Y
@/@/Hello, this is ^LANAME from the Survey Institute.
We contacted you recently in person to obtain data on commuting habits.
We are conducting a follow-up study with individuals who were interviewed
previously to see if there have been any changes in workplace commuting
policy since the last survey. Your cooperation is extremely important to
the accuracy of the survey and your individual report will be kept
confidential. @/" : TContinue
ThankYou "@G Thank you for your time. @G"
/ "Thank you" : TContinue
RULES
LANAME := UserName
{Either the environmental variable BlaiseUser or the login
name }
CatiMana.KEEP
Manage.KEEP
PersonNo.KEEP
Wave.KEEP
TimeZone.KEEP
TimeSlice.KEEP
Name.KEEP
Phone.KEEP
ForWhom.KEEP
CatiSelect.KEEP
CatiSort.KEEP
Introduction
Address
Person
IF Person.NumberJobs > 0 THEN
Work
ENDIF
ThankYou
IF ThankYou = EMPTY THEN {Appoint and NonResp are available as long as
ThankYou is empty}
Appoint
NonResp
ENDIF
154
Blaise
Appendix A: Installation and Use of Commute Example Files
IF Introduction = EMPTY THEN
{non-contact dial results are available until
contact is made}
NoAnswer
AMachine
BusyCall
Disconnect
ENDIF
IF (ThankYou = EMPTY) AND (NonResp.Done = EMPTY) AND {defines when
OtherOutcome is available}
(Appoint.Done = EMPTY) THEN
OtherOutcome
ENDIF
IF OtherOutcome.Lingo = Spanish THEN
CatiMana.CatiCall.CallResult := Appointment
CatiMana.CatiAppoint.AppointType := NoPreference
ForWhom := 'SPAN'
ENDIF
{Code outcomes with a procedure}
IF (ThankYou <> EMPTY) OR (Person.Confirm <> EMPTY) OR
(AMachine.Done <> EMPTY) OR (BusyCall.Done <> EMPTY) OR
(NonResp.Done <> EMPTY) OR (NoAnswer.Done <> EMPTY) OR
(Disconnect.Done <> EMPTY) OR (OtherOutcome.Done <> EMPTY) OR
(Appoint.Done <> EMPTY) THEN
POutcome (ThankYou,
Person.Confirm,
Person.NumberJobs,
NoAnswer.Done,
BusyCall.Done,
Appoint.Done,
NonResp.Done,
Disconnect.Done,
AMachine.Done,
OtherOutcome.Done,
BusyCall.WhatKind,
AMachine.LeftMessage,
NonResp.RespIdentity,
NonResp.NonRespStrength,
NoAnswer.WhatKind,
OtherOutCome.Details,
Manage.InterimOutcome,
Manage.FinalOutcome)
ENDIF
{Determine next empty bucket and shift InterimOutcome's down 1}
InterimOutcomeIndex.KEEP
IF InterimOutcomeIndex = EMPTY THEN
InterimOutcomeIndex := 1
Manage.OutcomeHistory.INSERT(InterimOutcomeIndex)
ENDIF
Manage.OutcomeHistory[InterimOutcomeIndex].InterimOutcome :=
Manage.InterimOutcome
Manage.OutcomeHistory[InterimOutcomeIndex].Date := SYSDATE
Manage.OutcomeHistory[InterimOutcomeIndex].Time := SYSTIME
ReEntry.KEEP
IF (ReEntry = EMPTY) THEN {clears out old info the first time through}
NoAnswer := EMPTY
CATI Guide
155
Appendix A: Installation and Use of Commute Example Files
BusyCall := EMPTY
AMachine := EMPTY
Disconnect := EMPTY
OtherOutcome := EMPTY
Manage.InterimOutcome := EMPTY
ReEntry := Yes {makes sure that this if condition is executed only once}
ENDIF
RESERVECHECK
RESERVECHECK
RESERVECHECK
LAYOUT
BEFORE Address NEWPAGE
AT Address INFOPANE ForAddress
AT Work INFOPANE ForWorkInfo
BEFORE ThankYou NEWPAGE
AFTER ThankYou NEWPAGE
ENDMODEL
156
Blaise
Appendix B: Specification File Parameters
These tables list specification file parameters with their possible values and the
effects of changing them after the daybatch is made. While precautions have been
taken in preparing this document, the user assumes responsibility for determining
if these settings are appropriate for a particular survey and for testing the effects
of these settings. Each table represents a branch, sub-branch or equivalent in the
specification file. Each row in a table represents a parameter that can be changed.
When parameters are changed during the interviewing day, the changes can have
the intended effect on all cases, no effect, a limited effect on some cases or an
unintended effect. Most parameters fit into the first category. For example,
changes in Scheduler parameters are applied to all the cases as soon as the
daybatch is scheduled (reevaluated), which is usually within five minutes.
Changes in dial menu, appointment, interviewers and groups parameters apply to
each case for which the DEP is launched as soon as the changes are saved.
Changes in daybatch parameters have no effect until a new daybatch is made.
Time-related fields in the daybatch are not changed when time zone parameters
are changed, but new appointment for today times are adjusted in accordance with
changes in time zone parameters. Changing some time slice parameters can have
completely unintended effects in the current daybatch, because these changes
disable all time slice applicability.
Survey Days
Setting
Possible Values
Effect on Changing after Daybatch Made
Start date
Date
•
Cannot be changed if before current
day.
•
Changes possible appointment dates.
End date
Date
Changes possible appointment dates.
Crew Parameters (Global and/or for Individual Dates)
Setting
Possible Values
Effect on Changing after Daybatch Made
Crew Size
1, 2, 3..999
None.
CATI Guide
157
Appendix B: Specification File Parameters
Setting
Possible Values
Effect on Changing after Daybatch Made
Start time current day
Interviewer time
•
None unless after present time.
•
Changes possible appointment times for
current day.
•
Cases will not be delivered until new
start time is reached.
•
StartInterval in daybatch file is not
updated to reflect new start time.
•
Changes possible appointment times for
current day.
•
Changes daybatch closing time (cases
are not delivered after this time).
•
EndInterval in the daybatch file is not
updated to reflect new end time.
End time current day
Interviewer time
Start time future days
Interviewer time
Changes possible appointment times.
End time future days
Interviewer time
Changes possible appointment times.
Allow past
midnight calling
Enabled, disabled
If checked, the end time of the last crew
shift can extend past midnight.
Daybatch Parameters (These Are Referenced Each Time the
Daybatch Is Made and at No Other Time)
Setting
Possible Values
Effect on Changing after Daybatch Made
Daybatch size
100, 200, 300..20000
None, until new daybatch is made.
Maximum
number of calls
1, 2, 3..99
None, until new daybatch is made.
Days between
no answer calls
0, 1, 2..100 days
None, until new daybatch is made.
Days between
answering
machine calls
0, 1, 2..100 days
None, until new daybatch is made.
Use sort fields
Enabled, disabled
None, until new daybatch is made.
158
Blaise
Appendix B: Specification File Parameters
Setting
Possible Values
Effect on Changing after Daybatch Made
Use select fields
Enabled, disabled
Automatically disables Apply select fields
also during get mode in the DEP and Apply
select fields also after the dial in the DEP.
Appointment Parameters
Setting
Possible Values
Effect on Changing after Daybatch Made
Route back to
interviewer
Enabled, disabled
If enabled, Scheduler writes name of
interviewer into routeback field if an
appointment is made.
Route back to
group
Enabled, disabled
If enabled, Scheduler writes name of
interviewer’s main group into the routeback
field if an appointment is made.
Do not change
route back
Enabled, disabled
If enabled, Scheduler cannot change
routeback field.
Appointment
interval
5, 10, 15..60 minutes
Changes time intervals shown in Make
Appointment dialog.
Appointment
buffer
5, 10, 15..180
minutes
Changes latest possible appointment starting
time.
Scheduler Parameters
Setting
Possible Values
Effect on Changing after Daybatch Made
Maximum
number of dials
1, 2, 3..9
•
Changes number of dials allowed before
going to no need today.
• Changes how medium and soft
appointment dial attempts are spread out.
•
Maximum
number of busy
dials
CATI Guide
1, 2, 3..9
Changes number of time slices that can
be tried on one day.
Changes number of consecutive busies
allowed in one dial.
159
Appendix B: Specification File Parameters
Setting
Possible Values
Effect on Changing after Daybatch Made
Do not allow
multiple same
day answering
machine calls
Enabled, disabled
Changes whether an answering service dial
result goes to no need today or is treated
like a no answer.
Scheduler Parameters (More Button)
Setting
Possible Values
Effect on Changing after Daybatch Made
Interviewer deactivation delay
(medium)
5, 10, 15..1440
minutes
Changes the amount of time that medium
appointments can be held for a referenced
interviewer.
Group deactivation delay
(medium)
5, 10, 15..1440
minutes
Changes the amount of time that medium
appointments can be held for a referenced
group.
Interviewer deactivation delay
(hard)
5, 10, 15..1440
minutes
Changes the amount of time that hard
appointments can be held for a referenced
interviewer.
Group deactivation delay
(hard)
5, 10, 15..1440
minutes
Changes the amount of time that hard
appointments can be held for a referenced
group.
Expire on deactivation delays
only
Enabled, disabled
Changes whether de-activation delays are
relevant when an individual or group is not
on the system. For example, if a group is
not working, should an appointment
intended for the group wait for the deactivation delay before going to some other
group, or should it go to another group
immediately.
Minimum time
between
hard/super noanswer
5, 10, 15..1440
minutes
Changes how no answers are spread out
when chasing a hard or super appointment.
160
Blaise
Appendix B: Specification File Parameters
Setting
Possible Values
Effect on Changing after Daybatch Made
Minimum time
between ‘other’
no-answer
5, 10, 15..1440
minutes
•
Changes how no answers are spread out
when not chasing a hard or super
appointment.
•
May change whether a time slice can be
tried.
•
May change how soft and medium
appointments are spread out.
Minutes
between busy
dials
5, 10, 15..1440
minutes
Changes how consecutive busies are spread
out.
Dial Menu (Multiple Menu Lines Possible)
Setting
Possible Values
Effect on Changing after Daybatch Made
Menu line
Any text that can
appear as an option
on the dial screen
Changes what is on the Make Dial dialog.
Treatment
Questionnaire, No
answer, Busy,
Appointment, Non
response, Answering
service,
Disconnected, Others
Changes what treatment is associated with
each dial screen menu line.
Skip dial menu
in DEP
Enabled, disabled
If checked, the Make Dial dialog will not
appear at all. This would disable the ability
to see information before entering the case.
Skip
confirmation
message box
Enabled, disabled
Use description
in dialog
Enabled, disabled
If checked, a confirmation screen will not
appear before entering the case. This may
be desirable if you wish to eliminate this
keystroke for efficiency’s sake.
If checked, the description, instead of the
variable name, is used for the fields shown
in the Questionnaire data section of the
Make Dial dialog.
CATI Guide
161
Appendix B: Specification File Parameters
Field Selection (Multiple Instances Possible)
Setting
Possible Values
Effect on Changing after Daybatch Made
Field
Datamodel field
Does not change any functionality, but can
change if a field appears on the dial screen,
in the forms overview, in the history file
and/or if the field can be edited on the dial
screen.
Function
None, Telephone, To
whom, Time zone,
Quota, Time slice
•
May change some functionality and
should not be done until a new daybatch
is created.
•
If no field has telephone functionality,
the CATI Management program cannot
be launched or reloaded.
Dial
Yes, no
Changes whether field appears on dial
screen.
List
Yes, no
Changes whether field appears in the forms
overview in the CATI Management
program.
Edit
Yes, no
Changes whether field can be edited on the
dial screen.
History file
Yes, no
Changes whether field is stored in the
history file and should only be made if the
structure of the history file is to be changed.
Groups (One for Each Group)
Setting
Possible Values
Effect on Changing after Daybatch Made
Group
Group name
If modified or deleted, group won’t be
recognized. This may change de-activation
delays and result in some cases not being
delivered to anyone.
Members
0, 1 or more
interviewer names
Changes group membership.
Non members
0, 1 or more
interviewer names
Changes group membership.
162
Blaise
Appendix B: Specification File Parameters
Interviewers (One for Each Interviewer)
Setting
Possible Values
Effect on Changing after Daybatch Made
Interviewer
Interviewer name
If modified or deleted, interviewer will not
be recognized. This may change deactivation delays and result in some cases
not being delivered to anyone.
Member of
group
0, 1 or more group
names
Changes suitability of various cases for the
interviewer.
Not member of
group
0, 1 or more group
names
Changes suitability of various cases for the
interviewer.
Main group
Empty or group name
•
For routeback to group setting, changes
name filled in routeback field by
Scheduler.
•
Changes suitability of various cases for
the interviewer.
Time Zones (One for Each Time Zone)
Setting
Possible Values
Effect on Changing after Daybatch Made
Code
3-character code
None, except for changing how
appointments made for later today are
converted to call center time.
Difference
-960..-15, 0, 15..960
None, except for changing how
appointments made for later today are
converted to call center time.
Name
Time zone name
None.
No Calls Time Limits
Setting
Possible Values
Effect on Changing after Daybatch Made
Do not call
before
Respondent time
StartInterval in the daybatch file is not
updated to reflect new starting time.
Do not call after
Respondent time
EndInterval in the daybatch file is not
updated to reflect new ending time.
CATI Guide
163
Appendix B: Specification File Parameters
Setting
Possible Values
Effect on Changing after Daybatch Made
Appointment
grace period
0, 5, 10..240
Changes the number of minutes that a hard
appointment can be delivered after the Do
not call after time.
Time Slice Sets (One for Each Time Slice Set)
Setting
Possible Values
Effect on Changing after Daybatch Made
Name
Any name
None.
Code
3-character string
Disables all time slice applicability for
current daybatch.
Same day
Yes, no
Changes whether more than one slice can be
tried on the same day.
Time Slice Definitions (One for Each Time Slice Definition in
Each Time Slice Set)
Setting
Possible Values
Effect on Changing after Daybatch Made
Days
Sunday, Monday,
Tuesday..
Disables all time slice applicability for
current daybatch.
(set of one or more
days of the week)
From
Respondent time
Disables all time slice applicability for
current daybatch.
Until
Respondent time
Disables all time slice applicability for
current daybatch.
Max try
1, 2, 3..99
None.
164
Blaise
Appendix B: Specification File Parameters
Daybatch Select Fields (Multiple Instances Possible)
Setting
Possible Values
Effect on Changing after Daybatch Made
Field name
Datamodel field
Changes field to which exclusion or
inclusion criteria are applied when browsing
up cases or getting cases by their primary
key.
Values
Possible values for
datamodel field
Changes values excluded or included when
browsing up cases or getting cases by their
primary key.
Include
Yes, no
Changes whether inclusion criteria are
applied when browsing up cases or getting
cases by their primary key.
Exclude
Yes, no
Changes whether exclusion criteria are
applied when browsing up cases or getting
cases by their primary key.
Field Applicability
Setting
Possible Values
Effect on Changing after Daybatch Made
Apply select
fields also
during get mode
in the DEP
Enabled, disabled
Changes whether exclusion and inclusion
criteria are applied when browsing up cases
or getting cases by their primary key.
Apply select
fields also after
the dial in the
DEP
Enabled, disabled
Changes whether cases that are excluded
from the daybatch due to exclusion or
inclusion criteria are added to the daybatch
once they are browsed up or gotten using
their primary key.
Daybatch Sort Fields (Multiple Instances Possible)
Setting
Possible Values
Effect on Changing after Daybatch Made
Sorting Order
Ascending,
descending
None.
CATI Guide
165
Appendix B: Specification File Parameters
Setting
Possible Values
Effect on Changing after Daybatch Made
Field name
Datamodel field
None.
Quota Control (Multiple Instances Possible)
Setting
Possible Values
Effect on Changing after Daybatch Made
Categories
Enumerated values
from datamodel for
field(s) selected as
quota field(s)
Cannot be changed unless the datamodel is
changed or quota field selection is changed.
Count
0, 1, 2..over 2 billion
May change whether a case is delivered,
depending on if the quota category to which
it belongs is filled or not.
Parallel Blocks (One for Each Parallel Block in the Datamodel)
Setting
Possible Values
Effect on Changing after Daybatch Made
Parallel block
Datamodel parallel
block
Cannot be changed unless the datamodel is
changed.
Treatment
Questionnaire, No
answer, Busy,
Appointment, Non
response, Answering
service,
Disconnected, Others
Changes what treatment is associated with
each parallel block in the datamodel.
Disable
appointment
dialog in the
DEP
Yes, no
Determines if the Make Appointment
dialog appears first when a parallel block
with the appointment treatment is selected.
166
Blaise
Appendix C: Daybatch Management
This appendix provides an overview of the Blaise Scheduler from a programming
point of view. It explains how Blaise initializes and then changes values in fields
in the daybatch file and how Blaise uses these values to determine which case
should be delivered whenever an interviewer requests a case. Fields in the
daybatch file appear in italics. Status/Priorities are also italicized.
There have been some relatively minor changes in the Scheduler over time. This
appendix deals with the Scheduler as presented in Blaise® version 4.6 build 840.
The Daybatch File
In order to understand Blaise CATI in depth, you must first understand how
Blaise initializes, updates and uses the daybatch file. The daybatch file contains
the following 14 fields:
• JoinID. The unique number that links a record in the daybatch file with a case
in the database.
• Status/Priority. The category that indicates how the case can be handled.
Values are: no need today, being treated, default, not-active, no answer, busy,
busy default, new appointment for today, soft appointment, busy soft
appointment, medium appointment, busy medium appointment, hard
appointment, busy hard appointment and super appointment. It is convenient
to divide the 15 categories into 4 different groups: no need today, being
treated, active and inactive. The active group (default, busy default, soft
appointment, busy soft appointment, medium appointment, busy medium
appointment, hard appointment, busy hard appointment and super
appointment) includes all categories whose cases can currently be delivered.
The inactive group (not-active, busy, no answer and new appointment for
today) references cases that can be delivered later in the day but not within the
current five-minute interval.
• StartInterval. The time when a case last became active or, if the case is not
active, the time when it will become active.
• EndInterval. The time that defines the end point of the range beginning with
the time given in the StartInterval.
CATI Guide
167
Appendix C: Daybatch Management
• FuturePriority. The category that indicates what kind of appointment, if any,
the case has pending on the current day. Values are: super appointment, hard
appointment, medium appointment, soft appointment and default.
• NrOfDials. The number of separate dial attempts that have been made for the
case as part of the current call in the current daybatch. Once a busy dial result
is recorded, subsequent consecutive busy dials (up to the maximum number of
busy dials set in the specification file) are not considered to be separate dial
attempts.
• DialInterval. The time (in terms of the five-minute interval) when the most
recent dial attempt on the current day was exited.
• NrOfDialsBusy. The number of consecutive busy dial attempts registered for
the case, as part of the current dial attempt.
• Group. The name of the group to which the case should be routed.
• Interviewer. The name of the interviewer to whom the case should be routed.
• QuotaIndex. The quota category to which the case belongs.
• TimeDifference. The hours and minutes that must be added or subtracted from
interviewer time to get current respondent time.
• SliceID. The time slice set to which the case belongs.
• SliceInfo. The time slice definitions available to the case on the current day.
The primary key is not included with the daybatch file. Instead, each record in the
daybatch file is identified by its unique JoinID.
In order to understand the operation of the Blaise Scheduler, you must first
understand the difference between the registering of dial results for individual
cases and the periodic scheduling of all cases. When an interviewer exits a case,
thereby registering a dial result, the values in some daybatch fields are changed
for the particular case and only for the particular case. When the entire daybatch
is scheduled, Blaise systematically reviews all the cases in the daybatch to
identify the cases that should currently be active. As part of this scheduling
process, the values in some daybatch fields for a number of different cases may be
changed. The table at the end of this appendix identifies the daybatch fields that
can be modified due to scheduling or the registering of a dial result.
When initially generating and then subsequently updating the daybatch file,
Blaise must also reference the current settings in the .bts file. This file is known
here as “the specification file.” In this appendix, specification file settings are
italicized and followed by a bracketed reference to the relevant branch in the
168
Blaise
Appendix C: Daybatch Management
specification file. As a general rule, specification file settings can be changed
during the interviewing day and the new settings take effect immediately. This
applies to all settings in the General Parameter and User branches of the
specification file. However, there are a few settings where changes made during
the day are not reflected in the daybatch file and hence not applied. In the case of
time slices, any change in time slice definitions results in the emptying out of the
SliceID and SliceInfo fields for all cases in the daybatch. If this occurs, no time
slices are applied until a new daybatch is made.
In this appendix, we will start with the simplest possible base case, where there
are no time zones, time slices, routebacks or quotas. After we have reviewed in
detail the base case, we will explain what happens in terms of initializing,
registering a dial result and scheduling when we add time slices, time zones,
routebacks and quotas. Finally we will examine the various priorities in order to
explain how Blaise determines what case to deliver to an interviewer.
Note that Blaise divides the day into five-minute intervals, all of which begin
when the number of minutes is evenly divisible by five. All times given in the
daybatch file are expressed in terms of these five-minute intervals. For example,
if an interviewer exits a case at 9:12 a.m., the DialInterval, which represents the
time exited, is set to 9:10 a.m. because the call was exited within the 9:10 to 9:15
interval.
Base Case
Initializing Status/Priority, FuturePriority, NrOfDials, NrOfDialsBusy,
StartInterval and EndInterval
When the daybatch is first created, all cases are listed with a Status/Priority of not
active, zero NrOfDials and zero NrOfDialsBusy. Cases with an exact date and
time appointment scheduled for the current day are given a FuturePriority of hard
appointment. Cases that have a missed exact date and time appointment for the
previous calling day and were not contacted are given a FuturePriority of medium
appointment. All other cases that have relevant appointments for the current day
are given a FuturePriority of soft appointment, if the current day is not the last
possible day for the appointment. They are assigned a FuturePriority of medium
appointment, if the current day is the last possible day for the appointment. The
FuturePriority is set to default for all other cases, including cases that have never
been called and cases with a no preference appointment.
CATI Guide
169
Appendix C: Daybatch Management
The default start time is the starting time of the first crew of the day, unless the
Do not call before time [Time zones branch] is later than this time. In such
circumstances, the Do not call before time [Time zones branch] is the default start
time. Likewise for the end of the day, the default end time is the ending time of
the last crew of the day, unless the Do not call after time [Time zones branch] is
earlier than this time. In such circumstances, the Do not call after time [Time
zones branch] is the default end time.
When the daybatch is first created, the StartInterval and EndInterval are
determined as a function of FuturePriority as follows:
Table C-1: Setting of StartInterval and EndInterval When Daybatch Is Made
FuturePriority
StartInterval
EndInterval
Default
Default start time
Default end time
Hard appointment
Specified time
Default end time, or
specified time plus
grace period if later
and crew is available
Medium appointment
derived from missed
previous day hard
appointment
Default start time
Default end time
Medium and soft
appointment with specific
beginning and ending
times
Specified beginning time
Specified ending
time
Medium and soft
appointments without
specific time ranges,
excluding medium
appointments derived
from missed hard
appointments
One of the starting crew
times, spread out so that
such appointments are
divided among the various
crews in accordance with
projected crew size
Default end time
Obtaining a Case
Generally, interviewers obtain cases by running the DEP (dep.exe). Supervisors
obtain cases by running the CATI management program (btmana.exe). There
are four possible ways for an interviewer to obtain a case. These options are
available by selecting Forms from the menu bar while running the DEP. Each
170
Blaise
Appendix C: Daybatch Management
option can be enabled or disabled in the Dep Menu Manager. The default option
is Get Telephone Number, whereby Blaise uses priority and interviewersuitability criteria, described below, to determine which is the best case to deliver
to the interviewer at the particular time. If the Browse option is available, an
interviewer can see all the cases in the database and select whichever case he or
she desires. With the Get option, the interviewer can enter the primary key of any
of the cases in the database. With the New option, the interviewer can specify a
new primary key and enter a new case in the database. Supervisors obtain cases
by selecting a case from the database from the Forms branch of the CATI
Management program.
Once a case already in the daybatch is obtained, its Status/Priority is changed to
being treated. Its Status/Priority remains being treated until the case is exited. If a
case is obtained that is not currently in the daybatch, depending on its dial result
and specification file settings, it may be added to the daybatch when it is exited.
Registering a Dial Result and Exiting a Case
One of eight different dial results must be assigned to a case before the case can
be exited. As soon as the case is exited, Blaise reevaluates the case in the light of
the dial result and the nature of the appointment made (if the dial result is
appointment). If the dial result is complete, non-response, disconnected, others,
appointment (not necessarily for today), or answering service (when Do not allow
multiple same day answering machine calls [General parameters branch] is
checked), Blaise applies its concluding treatment. For cases that are already in the
daybatch, the concluding treatment means that their Status/Priority becomes no
need today and their NrOfDials is incremented by one.
If the dial result is no answer or answering service (when Do not allow multiple
same day answering machine calls is not checked), Blaise assigns the
Status/Priority of no answer, but makes no other changes upon exiting the case. If
the dial result is busy, Blaise assigns the Status/Priority of busy, but likewise
makes no other changes upon exiting the case. If the dial result is appointment
and the appointment is a hard appointment for later in the day or a medium
appointment for which the current day is the only possible day, Blaise assigns the
Status/Priority of new appointment for today and changes the FuturePriority to
either hard appointment or medium appointment.
As part of the process of registering a dial result, the five-minute time interval in
which each case is exited is stored in its DialInterval field. The time on the
interviewer’s workstation is used, so it is important to synchronize times on all
workstations and servers.
CATI Guide
171
Appendix C: Daybatch Management
The following table summarizes the adjustments, depending upon dial result,
made in the daybatch file for each individual case when it is exited. A series of
dashes indicates that no changes are made when the case is exited. Some of these
fields are changed, however, when the case is subsequently scheduled.
Table C-2: Daybatch Field Changes When a Case Is Exited
Daybatch field
Concluding
dial result
Appt not
necessarily
for today
Appt necessarily
for today
Noanswer or
answerservice
Busy
Status/Priority
No need
today
No need
today
New appt for
today
No answer
Busy
StartInterval
--------
-------
Starting time for
appt
--------
------
EndInterval
--------
--------
Ending time for
appt (if a range of
times is given) or
default end time,
or starting time
plus grace period
if crew is
available
--------
------
FuturePriority
-------
--------
Hard appt or
medium appt
-------
------
NrOfDials
Incremented
by 1
Incremented
by 1
Incremented by 1
------
------
No entry is made in the daybatch file for cases that receive Blaise’s concluding
treatment and are not already in the daybatch. However, a new entry is made at
the end of the daybatch file for all cases that are not already in the daybatch to
which the concluding treatment is not applied. The only exception to this rule
occurs when Apply select fields also after the dial in the DEP [Daybatch select
branch] is enabled. In these circumstances, a case cannot be added to the
daybatch if the values in its select fields (those fields to which selection criteria
are applied during daybatch creation) are such that it could not be included in the
daybatch.
Registering a Super Appointment
At any point after the daybatch is created, a supervisor using the CATI
Management program can give a super appointment to a case. To do this:
• View the list of all cases in the Forms branch.
172
Blaise
Appendix C: Daybatch Management
• Select the particular case by double-clicking it, or using the menu option
Management ➤ Select.
• Select Call as soon as possible from the dial menu.
Giving a case a super appointment is considered a different activity from
obtaining a case. No dial result is assigned and the number of calls for the case is
not incremented. If a super appointment is given to a case that is not in the
daybatch, the case is automatically added to the end of the daybatch.
When a super appointment is registered for a case, its Status/Priority is set to
super appointment and its FuturePriority is set to super appointment. Its
DialInterval and StartInterval are set to the five-minute interval in which the
super appointment was made. Its EndInterval is set to the default end time.
Activating Cases
When there are no cases currently available for delivery, or at any other time after
a daybatch is created, a supervisor can use the CATI Management program to
activate all the cases in the daybatch. To do this:
• Highlight the View Daybatch branch.
• Select Management from the menu bar.
• Select Activate, and accept the confirmation dialog.
A supervisor can also activate an individual case already in the daybatch:
• Highlight the View Daybatch ➤ Browse branch in the CATI Management
program.
• Double-click on the specific case.
• When the Case Summary dialog appears, click on the More button.
• When the More Info dialog appears, click on the Activate button.
Only cases with a Status/Priority of not-active, a FuturePriority of default, soft or
medium appointment, and zero in the NrOfDialsBusy field can actually be
activated. When a case is activated, its StartInterval is changed to the current fiveminute interval and its Status/Priority is changed to default. None of its other
daybatch fields are changed.
CATI Guide
173
Appendix C: Daybatch Management
Scheduling the Daybatch
Blaise schedules the daybatch the first time that an interviewer requests a case or
exits a case at the beginning of a five-minute interval. It also schedules the
daybatch whenever a supervisor chooses Management ➤ Schedule from the CATI
Management program menu bar. The scheduling process can be divided into three
steps.
Step 1: Adjusting the number of dials
Changes are made in the number of dials for cases with a Status/Priority of new
appointment for today, no answer and busy as shown in the following table.
Table C-3: Adjusting the Number of Dials
Daybatch
field
New
appointment
for today
No answer
Busy
NrOfDials
Set to 0
Incremented
by 1
Incremented by 1 if and only if
NrOfDialsBusy = 0 before
scheduling begins
NrOfDials
Busy
Set to 0
Set to 0
Incremented by 1 and then reset
to 0 if maximum number of
busies is reached
The maximum number of busies (these busies must all be consecutive busies) is
reached when the NrOfDialsBusy reaches the Maximum number of busy dials
[General parameters branch]. At this point, Blaise stops chasing busies and
aggregates all the consecutive busies into the equivalent of one dial. Because the
NrOfDials field is incremented at the same time as the first busy is registered,
Blaise does not increment the NrOfDials at the time that the maximum number of
busies is reached (unless of course the maximum number of busies is set to one).
If after these adjustments the NrOfDials reaches the Maximum number of dials
[General parameters branch], the Status/Priority is changed to no need today. If
this happens, Steps 2 and 3 below are skipped.
Step 2: Determining a new StartInterval
A new StartInterval needs to be determined for all cases with a Status/Priority of
no answer or busy. In order to do this, the minimal possible spread needs to be
obtained from the specification file. For cases with a Status/Priority of no answer
and a FuturePriority of hard or super appointment, the minimal possible spread is
equal to the value given in Minimum time between hard/super no-answer
174
Blaise
Appendix C: Daybatch Management
[General parameters branch]. For all other no answer cases, the minimal possible
spread is equal to the value given in Minimum time between ‘other’ no-answer
[General parameters branch].
For cases with a Status/Priority of busy, if the NrOfDialsBusy equals one, the
minimal possible spread is equal to the first of the eight different values stored in
the Minutes between busy dials [General parameters branch] settings. If
NrOfDialsBusy is 2, then the minimal possible spread is equal to the second value
stored in Minutes between busy dials [General parameters branch] settings and
so on. If the NrOfDialsBusy equals zero, the minimal possible spread is
determined in the same way as it is for a Status/Priority of no answer.
The minimal possible spread is added to the DialInterval to get the earliest
possible start time. If the earliest possible start time is equal to or later than
EndInterval, the Status/Priority goes to no need today. If the earliest possible start
time is before the EndInterval, the StartInterval is set equal to the earliest possible
start time for cases with a FuturePriority of default, hard appointment or super
appointment. The determination of the StartInterval is somewhat more
complicated for cases with a FuturePriority of medium or soft appointment,
because in addition to honoring the minimal possible spread, the Scheduler tries
to spread call attempts out more or less evenly throughout the possible calling
period.
One exception is made to the rule that if the earliest possible start time is equal to
or later than EndInterval, the Status/Priority goes to no need today. This
exception occurs in the case of medium appointments with specified time ranges
on the last day of the survey. Blaise allows the equivalent of a new call to be
applied to these cases. It resets both the NrOfDials and NrOfDialsBusy to zero,
while setting the FuturePriority to default, the Status/Priority to default, the
StartInterval to the current five-minute interval and the EndInterval to the default
end time.
Step 3: Comparing current time with StartInterval and EndInterval
As a final step, the StartInterval needs to be compared with the current time for
cases whose Status/Priority has not already gone to no need today. If the current
time is before the StartInterval, the Status/Priority is set to not-active. If the
current time is between the StartInterval and the EndInterval, the Status/Priority
is set to whichever one of the nine active Status/Priorities is appropriate. If the
current time is equal to or later than the EndInterval (this can happen only in the
base case when there are soft or medium appointments with specified time
ranges), the Status/Priority goes to no need today.
CATI Guide
175
Appendix C: Daybatch Management
Adding Time Slices
Initializing SliceInfo, SliceID, StartInterval and EndInterval
When the daybatch is first created, the SliceID field is automatically filled in with
the appropriate time slice code. In some surveys a field in the database is given
time slice functionality in the specification file. In these instances the string stored
in the database in the field with time slice functionality is written into the SliceID
field. If the time slice field is blank or unrecognizable in the database, the SliceID
field is left empty in the daybatch file.
If no field has been given time slice functionality, the code of the first time slice
set defined in the specification file is written into the SliceID field, for all cases. If
no time slice set has been defined in the specification file, the SliceID field is
empty.
If the SliceID field is filled in, the SliceInfo field must be filled in with the
numbers of all available time slice definitions for the current day. The time slice
definitions for any given time slice set are numbered in order, starting with 1, for
the first definition given in the specification file. A time slice definition is
available if it is relevant for the current day and the case has not yet received the
number of no answer or answering service dial results specified under Max tries
[Time slices branch]. For example, if the first definition is for Mondays from 2
p.m. to 5 p.m. with 2 tries and today is Monday, the SliceID of 1 can be listed
only if the case has never been called or has only received one no answer or
answering service dial result on a Monday between 2 and 5 p.m.
If time slices are applicable, the StartInterval is set to the beginning time of the
earliest time slice definition in the SliceID field and the EndInterval is set to the
ending time of this time slice definition. Time slices are basically designed to
spread out no answer (and answering service) attempts. They are only applicable
for cases with default FuturePriority whose most recent dial result is no answer
or answering service. They are not applicable for cases that have never been
attempted. If the StartInterval and EndInterval are set in accordance with a time
slice definition, a minus sign in parentheses is added at the end of the SliceID
field.
Time Slice Applicability During Scheduling
Time slices become inapplicable when any case with a Status/Priority of new
appointment for today, or busy is scheduled. When this happens, the minus sign,
if it exists, is removed from the SliceID field. Alternatively, when they are
relevant, time slices become applicable for any case with a Status/Priority of no
176
Blaise
Appendix C: Daybatch Management
answer with a default FuturePriority. When this happens during scheduling, a
minus sign, if it does not already exist, is added to the end of the SliceID field.
Adjusting StartInterval and EndInterval During Scheduling
When time slices are applicable, the StartInterval and EndInterval must be
changed whenever a case with a Status/Priority of no answer is scheduled. If the
relevant time slice set only allows one try per day, the case automatically goes to
no need today. Even if more than one try is allowed per day, only one try per time
slice definition is permitted per day. This means that once a time slice definition
is tried, Blaise must find a new time slice definition in which the case can be
delivered. In order to do this, Blaise adds the Minimum time between ‘other’ noanswer [General parameters branch] to the DialInterval to determine the earliest
possible start time. Blaise then determines which of the available time slice
definitions in the SliceInfo field start at or after the earliest possible start time. It
takes the earliest of these time slice definitions and sets the StartInterval and
EndInterval accordingly. If there are no available time slice definitions that start
at or after the earliest possible start time, the Status/Priority goes to no need
today.
When time slices are applicable, the StartInterval and EndInterval may also have
to be changed for cases with a Status/Priority of default or not-active. This
happens if the current time is equal to or later than the EndInterval. In these
circumstances, Blaise determines if there is an available time slice definition that
includes the current time and sets the StartInterval and EndInterval accordingly.
The Status/Priority is correspondingly set to default. If there is no available time
slice definition that includes the current time, Blaise finds the earliest possible
next available time slice definition and sets the StartInterval and EndInterval
accordingly. The Status/Priority is set to not-active. If no appropriate time slice
definition is available, the Status/Priority is set to no need today.
Changing Value of Time Slice Field in the Database
If the value in the time slice field is changed in the database, the SliceID and
SliceInfo fields are not changed in the daybatch file. Blaise continues to reference
the information in the daybatch file. Changes to the time slice field in the database
take effect the next time the daybatch is created.
CATI Guide
177
Appendix C: Daybatch Management
Adding Time Zones
Initializing TimeDifference
If a field is given time zone functionality in the specification file, the
TimeDifference field is filled in when the daybatch is first created. Blaise enters
the difference (in hours and minutes) given in the specification file for whatever
time zone appears in the time zone field in the database. If the time zone field in
the database is empty, or the same as interviewer time, the TimeDifference field is
left empty.
Adjusting Times
All times used in the daybatch file are in interviewer time. Appointment times
(derived from running the DEP), time slice definitions [Time slices branch] and
the no call limits [Time zones branch] are in respondent time. This means that the
hours and minutes given in the TimeDifference field must be subtracted from the
respondent times before these times can be used in the determination of the
interviewer-based StartInterval and EndInterval. When a minus sign is present in
the TimeDifference field, the subtraction of a negative value basically means that
the TimeDifference is added to the respondent time to get the interviewer time.
For example, let us take a situation with three contiguous times zones. Time zone
A is 60 minutes ahead of time zone B, which in turn is 60 minutes ahead of time
zone C. Interviewer time is time zone B time. A time slice definition defined in
the specification file, or an appointment range defined in database as 4 p.m. to 6
p.m., would result in the daybatch file having a start interval to end interval range
of 3 p.m. to 5 p.m. for time zone A, 4 p.m. to 6 p.m. for time zone B, and 5 p.m.
to 7 p.m. for time zone C.
Changing Value of Time Zone Field in the Database
If the value in the time zone field is changed in the database, the TimeDifference
field is not changed in the daybatch file. However, Blaise routinely references the
database to ascertain how much of a time difference adjustment, if any, should be
made to appointment times, time slice ranges and no calls time limits.
178
Blaise
Appendix C: Daybatch Management
Adding Routebacks
Initializing Interviewer and Group
If a field is given routeback functionality in the specification file, then when the
daybatch is first created, the value in the routeback field is written into the
Interviewer field, if this value is listed as the name of an interviewer in the Users
➤ Interviewers branch of the specification file.
Alternatively, the value in the routeback field is written into the Group field, if
the value in the routeback field in the database is listed as a group in the Users ➤
Groups branch of the specification file. If the Interviewer field is filled in and
groups have been defined in the specification file, the name of the interviewer’s
main group is written into the Group field.
Changing the Interviewer and Group
The value stored in the routeback field in the database for any given case can be
changed while running the DEP. It can also be changed when using the CATI
Management program to treat a case, by assigning a different interviewer or group
to the case. Finally the value stored in the routeback field can be changed if either
Route back to interviewer [General parameters branch] or Route back to group
[General parameters branch] is enabled in the specification file. If Route back to
interviewer [General parameters branch] is enabled, then whenever an
appointment is made for a case, the name of the interviewer making the
appointment is automatically filled into the routeback field. Likewise if Route
back to group [General parameters branch] is enabled, the name of the main
group of the interviewer making the appointment is automatically filled into the
routeback field. If the value stored in the routeback field in the database is
changed, and the case does not go to a Status/Priority of no need today, the
change in value is also reflected in the Interviewer and/or Group fields in the
daybatch.
Restricting Delivery in Accordance with the Values in the Interviewer and
Group Fields
Cases with a FuturePriority of default or soft appointment are only delivered to
the interviewer named in the Interviewer field. If the interviewer field is empty,
but the group field is not empty, default and soft appointment cases are only
delivered to interviewers that are listed in the specification file as belonging to the
specified group. If both the interviewer and group fields are empty, cases with a
FuturePriority of default and soft appointment can be delivered to any
interviewer.
CATI Guide
179
Appendix C: Daybatch Management
Blaise relaxes the restrictions that apply to default and soft appointment cases for
cases with medium, hard and super appointments. It does this by letting users set
expiration delays in the specification file. In the case of medium, hard and super
appointments, both the Interviewer de-activation delay [General parameters
branch] and the Group de-activation delay [General parameters branch] can be
set to anywhere from 5 minutes to 1440 minutes (24 hours). If Expire on deactivation delays only [General parameters branch] is checked in the
specification file, an Interviewer de-activation delay [General parameters
branch] of 10 minutes means that the routeback to the specified interviewer
expires 10 minutes after the starting time of the appointment. Once this delay has
expired, an asterisk appears after the name of the interviewer in the daybatch file.
As long as the delay has not expired, the case can be delivered only to the
specified interviewer.
If the Group de-activation delay [General parameters branch] is set to 20 and no
interviewer is specified in the Interviewer field, the routeback to the group expires
20 minutes after the starting time of the appointment. However, if an interviewer
is specified in the Interviewer field, the interviewer delay must expire first, before
the 20-minute group delay is applied. Once the group delay has expired, an
asterisk appears after the name of the group in the daybatch file. Note that the
specification file allows for two different sets of interviewer and group expiration
delays. One set applies to medium appointments, while the other set applies to
both hard and super appointments.
The Expire on de-activation delays only [General parameters branch] setting in
the specification file plays a critical role in determining if a routeback delay has
expired. If this setting is not enabled, expiration delays are only relevant if the
specified interviewer, or someone from the specified group, is actually involved
in interviewing. For example, if the group de-activation delay is 20 minutes, but
no one from the group is involved in interviewing, Blaise expires the group deactivation delay if Expire on de-activation delays only is not checked.
Adding Quotas
Initializing QuotaIndex
If one or more fields are given quota functionality in the specification file, then
when the daybatch is first created the quota category to which each case belongs
is written to the QuotaIndex field. Integers are used to represent quota categories.
If you select the Quota control branch in the specification file, you can see all
quota categories. The integer 1 is given to the first category listed, the integer 2 to
180
Blaise
Appendix C: Daybatch Management
the second category, and so forth. If not enough information exists in the database
to assign a case to any quota category, a zero is written into its QuotaIndex field.
Filling a Quota
Cases that belong to a quota category that has already been filled are not included
in the daybatch. If during the course of an interviewing day, a case is completed
that brings the number of completed cases for its quota category up to the count
targeted in the specification file, all other cases in the daybatch from this quota
category with default FuturePriority are automatically given the Status/Priority of
no need today. This quota-based adjustment occurs as soon as the triggering case
is exited and not as part of the scheduling process.
Modifying the QuotaIndex
If enough information is gathered on a case during the interviewing day to assign
it to a quota category or to change its quota category, the new quota category is
written to the QuotaIndex field as soon as the case is exited. If any case is
attempted but cannot be assigned a quota category, -1 is written into its
QuotaIndex field.
Priorities (Determining Which Case to Deliver)
When an interviewer requests a case, Blaise systematically goes through all the
active cases in the daybatch that can potentially be delivered to the particular
interviewer. In order to determine if a case can be delivered to a particular
interviewer, Blaise looks in the daybatch file at the names in the Interviewer and
Group fields, as well as at the FuturePriority. A case can be delivered to a
particular interviewer in any of the following situations:
• The interviewer’s name is in the Interviewer field,
• The Interviewer and Group fields are both empty,
• The Interviewer field is empty and the interviewer is a member of the group
listed in the Group field,
• The FuturePriority is medium, hard or super appointment and an asterisk (for
an expired delay) appears in both the Interviewer and Group fields or an
asterisk appears in one of these two fields and the other field is empty, or
• The FuturePriority is medium, hard or super appointment and an asterisk (for
an expired delay) appears in the Interviewer field and the interviewer is a
member of the group listed in the Group field.
CATI Guide
181
Appendix C: Daybatch Management
Blaise assigns one of nine different priorities to each case that can be potentially
delivered to the particular interviewer. These priorities in order are:
• Super
• Hard-busy
• Hard
• Medium-busy
• Soft-busy
• Default-busy
• Medium
• Soft
• Default
Super, hard, medium, soft and default priorities are derived from a FuturePriority
of super appointment, hard appointment, medium appointment, soft appointment
and default, respectively. The term busy is only added to the priority if the last
dial result on the current day was a busy and not the last possible busy in a
consecutive set of busies (i.e., the NrOfDialsBusy is greater than zero).
Once Blaise determines the highest priority possible for an interviewer, it focuses
only on the cases at this priority level. For example, if there are no cases with
super priority but one with hard-busy priority, it delivers this particular case to
the interviewer.
If there is more than one case potentially deliverable to a particular interviewer
within the highest available priority, Blaise chooses the case to deliver by
ascertaining the most suitable case for the interviewer.
Suitability, from most suitable to least suitable, is determined as follows:
• Interviewer’s name is in the Interviewer field,
• Interviewer’s main group is in the Group field,
• One of the interviewer’s secondary groups is in the Group field,
• The case can go to anyone.
182
Blaise
Appendix C: Daybatch Management
Suitability is determined irrespective of whether delays have or have not expired.
This means that even if a delay has expired, interviewers get cases meant for them
before they get cases at the same priority meant for other interviewers.
If several cases are equally suitable at the highest available priority level, Blaise
delivers the case with the lowest NrOfDials. If several such cases share the lowest
NrOfDials, Blaise delivers the case with the earliest StartInterval. If several such
cases share the same StartInterval, Blaise delivers the case that is listed first in
daybatch file.
Table C-4: Possibility of Daybatch Field Modification by Activity
Daybatch
Field
Registering a
Dial Result
Scheduling
Activation
of All Cases
Registering a
Super
Appointment
JoinID
Never
Never
Never
Never
Status/Priority
Always
Sometimes
Sometimes
Always
StartInterval
Sometimes
Sometimes
Sometimes
Always
EndInterval
Sometimes
Sometimes
Never
Always
FuturePriority
Sometimes
Never
Never
Always
NrOfDials
Sometimes
Sometimes
Never
Always
DialInterval
Always
Never
Never
Always
NrOfDialsBusy
Never
Sometimes
Never
Always
Group
Sometimes
Never
Never
Never
Interviewer
Sometimes
Never
Never
Never
QuotaIndex
Sometimes
Never
Never
Never
TimeDifference
Never
Never
Never
Never
SliceID
Never
Never
Never
Never
SliceInfo
Never
Never
Never
Never
CATI Guide
183
Appendix C: Daybatch Management
184
Blaise
Appendix D: The CATI Emulator (BTEmula)
What Is the CATI Emulator?
The standard Blaise® product comes with a CATI emulation utility, called the
CATI Emulator. The CATI Emulator can be used to test some aspects of network
performance under Blaise CATI operation. It can be run on any number of
workstations, where each workstation requests cases and runs through interviews.
When running, the CATI Emulator exercises Blaise CATI components, such as
the Scheduler and the daybatch file. The CATI Emulator executes the instrument
rules, and reads from external files as dictated by the datamodel code. Cases are
delivered according to your routeback specifications if appropriate. Network
traffic is generated. The use of the CATI Emulator for network testing is much
less expensive than using interviewers to test network issues.
It should be emphasized that BTEmula is a CATI emulator. It does not
necessarily exercise every possible aspect of Blaise CATI or your network. For
example, it does not display the usual interviewer screens, nor does it produce an
audit trail. Also, the CATI Emulator does not necessarily update all appropriate
CATI management fields (those in the CatiMana block of the datamodel).
Depending on your needs or interests, you may have to supplement the CATI
Emulator with other software, such as script-playing software. However, it is very
easy to set up and use, and it allows you to address a significant number of
network issues.
How to Run and Control the CATI Emulator
There are two user-created files that drive the CATI emulation process:
• The option file (.teo), which you must set up before running the CATI
Emulator. This file contains parameters to control and customize the
emulation.
CATI Guide
185
Appendix D: The CATI Emulator (BTEmula)
• The data script files (.sc1, .sc2, …), which are optional. The CATI
Emulator can be used two ways: with and without these data scripts. Data
scripts are files that you create to dictate values to be assigned to specific
fields during the interviews. A data script file contains field names and their
corresponding field values. A line in the data script file looks like this:
QuotaQuestions.Married,1
Note that the data script field names collectively need not represent a valid path
(skip pattern) for the instrument. This simplifies script creation for you. These
data scripts can be used by the CATI Emulator to simulate an interview, one entry
at a time. By default, the CATI Emulator does not use data scripts. To have the
CATI Emulator use them, specify UseScripts=1 in the option file.
The CATI Emulator is an executable file, btemula.exe, at the top level of the
Blaise product folder (for example, in C:\Program
Files\StatNeth\Blaise46\). The folder Samples\Cati below the top level
of the Blaise product folder contains a set of files that can be used to demonstrate
the use of the CATI Emulator. To use these files, in the Control Centre:
• Prepare the Oeps.bla file.
• Prepare and run the Oeps.man file to create the Oeps Blaise database.
• Make Oeps.bla the active window and launch the CATI Specification
program. Make today one of the survey days and save the change.
• Launch the CATI Management program and create a daybatch.
You can start the CATI Emulator by double-clicking btemula.exe using
Windows Explorer, or by adding btemula.exe as an option in the Tools menu
of the CATI Management program. When the Select Emulator Options File
dialog appears, highlight the Oeps.teo file and select the Open button, or
double-click on the Oeps.teo file. The CATI Emulator starts running. Screens,
like the one shown in Figure D-1, appear and allow you to track emulator activity.
To stop the CATI Emulator click the Close button. It may take a short time for the
program to stop, depending on the parameters in your option file.
186
Blaise
Appendix D: The CATI Emulator (BTEmula)
Figure D-1: The CATI Emulator Screen on a Workstation
The Option File
The parameters set in the option file drive and control the emulation process. The
option file has a typical Windows® INI-file structure (sections with a number of
Option=Value combinations), with the default extension .teo. Here is a sample
CATI Emulator option file:
[EmulatorSettings]
DataFile=oeps
MetaFile=oeps
WorkDir=.
MetaSearchPath=
ExternalSearchPath=
UseScripts=1
RandomOrder=1
CheckBeforeDial=1
MinInterview=1
MaxInterview=10
MinDialTime=1
MaxDialTime=15
MinQuestTime=1
MaxQuestTime=20
DialFreq1=100
DialFreq2=30
DialFreq3=20
DialFreq4=10
DialFreq5=10
DialFreq6=10
DialFreq7=5
DialFreq8=5
DialFreq9=5
DialFreq10=5
AppointFreq=10
[DataScripts]
Count=2
SCRIPT1=oeps.sc1
SCRIPT2=oeps.sc2
The specific parameters of the option file are defined in the following table.
CATI Guide
187
Appendix D: The CATI Emulator (BTEmula)
Table D-1: Option File Parameters
Option File Parameter
Description
DataFile
Name of Blaise data file (.bdb file) to be used.
MetaFile
Name of Blaise metadata file (.bmi file) to be
used.
WorkDir
Name of the work folder. WorkDir=. is used to
indicate the folder where the .TEO file resides.
MetaSearchPath
Search path for metadata files.
ExternalSearchPath
Search path for external data files.
UseScripts
0 (= NO)
The default.
1 (= YES)
Instructs the CATI Emulator to use data
scripts.
CheckBeforeDial
0 (= NO)
The default. The rules will be checked
before the dial is performed.
1 (= YES)
188
MinInterview
Minimum time an interview must last (only used
if UseScripts=0).
MaxInterview
Maximum time an interview may last (only used
if UseScripts=0). If the option selected from the
Dial menu activates the questionnaire, a random
time between MinInterview and MaxInterview is
used as a delay before the form is updated in the
data file. This time includes the time needed to
perform the check. The emulator uses this random
time to simulate the interview process.
AppointFreq
The percentage of appointments that are to be set
for a random time later on the current day.
MinDialTime
Minimum time allotted for the simulation of the
“dial process” for a case.
MaxDialTime
Maximum time allotted for the simulation of the
“dial process” for a case. A random time between
MinDialTime and MaxDialTime is used. Note: a
dial delay is imposed, but the Dial menu does not
actually appear on the emulation workstation.
MinQuestTime
Minimum time the system waits after “answering”
a question from the data script (only used if
UseScripts=1).
Blaise
Appendix D: The CATI Emulator (BTEmula)
Option File Parameter
Description
MaxQuestTime
Maximum time the system waits after
“answering” a question from the data script (only
used if UseScripts=1).
DialFreqn
Frequency (count) used to calculate the
percentage of cases that are to receive the dial
result chosen in line n-1 in the Dial menu branch
of the specification file. Blaise normalizes the
frequencies DialFreq1..DialFreqx to sum up to
100 percent. An example appears after this table.
RandomOrder
0 (=NO)
The CATI Emulator processes the data
scripts in the order specified in the [DataScripts]
section of this option file. After processing the last
script, it starts again with the first one and
continues in order.
1 (=YES) The default. The CATI Emulator uses
the data scripts in random order.
Example: DialFreq Parameters
Assume that in the Dial menu branch of the specification file, the first three
entries get the treatment of Questionnaire, Appointment and Busy, respectively. In
the option file all DialFreqs are set to zero (or left blank) except for the
following:
DialFreq2=100
DialFreq3=60
DialFreq4=40
In this situation, the CATI Emulator normalizes these numbers and generates
cases such that 50 percent result in questionnaires (interviews), 30 percent result
in appointments, and 20 percent are busy.
The Data Script Files
Data scripts are optional files that dictate values to be assigned to specific fields
during the simulated interview process.
In the [DataScripts] section of the option file, you can specify the number and
names of the data script files. With the Count= line in the option file, you indicate
CATI Guide
189
Appendix D: The CATI Emulator (BTEmula)
the number of data scripts. Each data script file name has to be provided on a
separate line as follows:
[DataScripts]
Count=2
SCRIPT1=oeps.sc1
SCRIPT2=oeps.sc2
In the data script file itself (*.sc1), each line must contain a field name (the
complete name including the block-dot-notation), followed by a comma, followed
by the value. For an enumerated field, the value specified must be numerical (the
use of labels is not accepted).
QuotaQuestions.Age,20
QuotaQuestions.Married,1
Questions.Employed,1
Questions.WatchTV,1
Questions.HowMany,10
Log File
For each survey, Blaise automatically records system-type events in a log file.
The log file is given the same name as the .bmi file, but with a .log extension.
Whenever a CATI Emulator session ends, summary information about the session
is entered into the log file. This information is explained in the table below.
Table D-2: Log File Parameters
190
Log File Parameter
Description
Average time dialcompleted (sec)
Average time (including “scheduling”) to select
and update a form for which the questionnaire is
not started. This includes treatments such as
Busy, No Answer, etc.
Max time dial-completed
(sec)
Maximum time (including “scheduling”) needed
to select and update a form for which the
questionnaire is not started. This includes
treatments such as Busy, No Answer, etc.
Blaise
Appendix D: The CATI Emulator (BTEmula)
Log File Parameter
Description
Average time selectinterview (sec)
Average time (including “scheduling”) needed to
select a form for which the questionnaire is
started.
Max time select-interview
(sec)
Maximum time (including “scheduling”) needed
to select a form for which the questionnaire is
started.
Average time check (sec)
Average time needed for checking rules of a case
(only if UseScripts=0).
Max time check (sec)
Maximum time needed for checking rules of a
case (only if UseScripts=0).
Average time end (sec)
Average time (including “scheduling”) needed to
update a form for which the questionnaire is
started.
Max time end (sec)
Maximum time (including “scheduling”) needed
to update a form for which the questionnaire is
started.
CATI Guide
191
Appendix D: The CATI Emulator
192
Blaise
Appendix E: Glossary
Activate
Activating a case converts its Status/Priority from Not-active to Default (i.e.,
active), provided that its last dial result was not busy and its FuturePriority is not
hard appointment. This makes the case available for delivery. A supervisor may
use the CATI Management program to activate either a single case or all cases.
Active
An active case is one that is in the daybatch and available for delivery to an
interviewer. It has a Status/Priority of default, busy default, soft appointment,
medium appointment, hard appointment, busy soft appointment, busy medium
appointment, busy hard appointment, or super appointment.
Administrative database snapshot
The administrative database snapshot contains all the cases in the current
database, but only the fields that may need to be referenced during the
interviewing day. It is called a snapshot because, unlike the actual survey
database, it reflects a certain point in time and is not automatically updated during
the interviewing process. Normally an administrative database snapshot is
generated as one of the final overnight processing steps. It can be refreshed
periodically during the interviewing day via current information obtained from
the history file and then used to generate up-to-date lists and reports.
Appointment
If a respondent has been contacted and the interview has begun, but cannot be
completed during the current call, then an appointment is made to continue the
interview at some future time.
Appointment type
Appointment type can be looked at from four different points of view.
The Make Appointment dialog drop-down list contains four different types:
exact date, period, weekday and no date.
CATI Guide
193
Appendix E: Glossary
The History Browser displays the AppointType field that can contain one of seven
different types. These types are Date and time, Period and day part, Weekday and
day part, Only period, Only weekday, Only day part and no preference.
The datamodel field CatiMana.CatiAppoint.AppointType is an enumerated type
with possible values of CertainDate, NoPreference, DayOfWeek, and Period.
The FuturePriority field in the daybatch contains the value super appointment,
hard appointment, medium appointment, soft appointment or default.
The following table shows the interrelationship between these four different
points of view:
CatiMana.CatiAppoint. FuturePriority in
AppointType Make
field in
Appointment AppointType type
daybatch
history file
Date type time type
Date and time Exact date CertainDate
Hard appointment (on
exact time
given date)
Period and
day part
Period – day
part
or
Exact date day part
Weekday and Weekday day part
day part
Period
Medium appointment
(on day after given
date)
Medium appointment
(on last possible day)
Soft appointment (on all
other days)
Weekday
Medium appointment
(on last possible day)
Soft appointment (on all
other days)
Only period
Period – no
time
Period
Medium appointment
(on last possible day)
Soft appointment (on all
other days)
194
Blaise
Appendix E: Glossary
CatiMana.CatiAppoint. FuturePriority in
AppointType Make
field in
Appointment AppointType type
daybatch
history file
Date type time type
Only
Weekday - no Weekday
Medium appointment
weekday
time
(on last possible day)
Soft appointment (on all
other days)
Only day part No date - day
part
Period
Medium appointment
(on last possible day)
Soft appointment (on all
other days)
No preference No date - no
time
Super
appointments
are not
registered in
the history
file
NoPreference
CertainDate
Super
appointments
cannot be
made from the
Make
Appointment
dialog
Default
Super appointment (on
given date)
Medium appointment
(on day after given
date)
Busy dial
A busy dial is defined as a dial attempt with a busy dial result that increments the
busy dial counter.
Busy dial counter
Although the term busy dial counter is not specifically used in Blaise, it is useful
to think of the value in the NrOfDialsBusy field in the daybatch file as a busy dial
counter. The daybatch is created with all cases having zero busy dials. Each time
the dial result of busy is recorded and the Maximum number of busies has not
been reached, the busy dial counter is incremented by one. Each time a non-busy
dial result is recorded or a busy dial result is recorded and the Maximum number
of busies is reached, the busy dial counter is reset to zero.
CATI Guide
195
Appendix E: Glossary
Call
A call is defined as a dial attempt that increments the call counter. In Blaise, call
has a precise definition that is somewhat different from what users often expect.
See also Call counter.
Call counter
Although the term call counter is not specifically used in Blaise, it is useful to
think of the value in the CatiMana.CatiCall.NrOfCall field in the database as a
call counter. The call counter is set to zero for all cases that have never been
attempted. The only circumstances in which the call counter is ever changed is
when the dial counter goes from zero to one for a given case. This means that the
first dial attempt on any day increments the call counter, but that subsequent dial
attempts on that day do not increment the call counter unless the daybatch is
remade or an appointment is made for later in the day.
Case
Each record in the database is known as a case or form.
CATI Management program
The CATI Management program (btmana.exe) is used by supervisors during
the interviewing day to control and monitor key activities. It is also known as the
Management Program or Btmana. It can be accessed in the Control Centre by
selecting Tools ➤ CATI Management from the menu bar or from a desktop
shortcut.
Counts file
This file contains the information made available in the Summary and Quota
branches of the CATI Management program. It is a binary file that is not directly
accessible to users.
Datamodel
The collection of data definitions and interrelationships that comprise a survey is
known as a datamodel. From a programming point of view, a datamodel is
defined by all the code, including code brought in by INCLUDE statements, that is
in a .bla file between the key words DATAMODEL and ENDMODEL.
Daybatch
The daybatch file (or simply daybatch) is a survey management file used by the
Scheduler to determine which cases to deliver. It normally contains a small subset
196
Blaise
Appendix E: Glossary
of the records in the survey database. The daybatch file has 14 fields in which
information is stored and updated when necessary for each record. A new
daybatch file with the extension .btd is created every time a daybatch is made.
Day part
The day part is a term used in the Make Appointment dialog to refer to a specific
time range. Any appointment for which a specific time range has been defined is
called an appointment with a day part.
De-activation delay
This concept applies only when there is a routeback field to cases whose
FuturePriority is medium, hard or super appointment. The de-activation delay is
the length of time the Scheduler has to reserve a case for a specific interviewer or
group of interviewers.
Default
The term default can be confusing in Blaise CATI because default is one of the 14
possible Status/Priorities and one of the five possible FuturePriorities. A case
with a default FuturePriority has no pending appointment. A case with a default
Status/Priority in the daybatch is currently active and hence available for
delivery.
Dial
A dial is defined as anything that increments the dial counter. It is not the same as
a dial attempt because not all dial attempts result in the incrementing of the dial
counter. See also Dial counter.
Dial attempt
A dial attempt occurs whenever a case is handled by using the DEP and a dial
result is registered. All dial attempts are recorded in chronological order in the
history file.
Dial counter
Although the term dial counter is not specifically used in Blaise, it is useful to
think of the value in the CatiMana.CatiCall.RegsCalls[1].NrOfDials field in the
database and the NrOfDials field in the daybatch file as a dial counter. The
daybatch is created with all cases having zero dials. Each time a case is attempted,
the dial counter is incremented by one (except for consecutive busy dials, which
count as one dial until the Maximum number of busy dials is reached). Once the
CATI Guide
197
Appendix E: Glossary
interviewing day has begun, the dial counter can be reset to zero if the daybatch is
remade or a new appointment for today is made. If supervisors use the CATI
Management program to make an appointment (including a super appointment)
without entering the DEP, the dial counter is not incremented.
Dial interval
DialInterval is the daybatch field that stores the time, in terms of the five-minute
interval, in which an interviewer last exited the case on the current day.
Dial menu
The Dial menu is the top section of the Make Dial dialog. The options that appear
in the Dial menu are set in the Dial menu branch of the specification file.
Dial result
A dial result is the outcome that has been registered by Blaise for each dial
attempt. It is stored in the CatiMana.CatiCall.RegsCalls[1].DialResult field when
the case is exited. A dial result can be one of eight enumerated values: Response,
Busy, No answer, Appointment, Non-response, Answering service, Disconnected,
Others.
Dial screen
This is another term for the Make Dial dialog.
DLL
A Dynamic Link Library (DLL) is a collection of auxiliary programs, any of
which can be called when needed by the primary application.
End interval
EndInterval is the daybatch field that stores the end point of the range beginning
with the time given in the StartInterval.
Form
Each record in the database is known as a case or form.
Function
There are five different special functions in Blaise CATI that can be assigned to
various database fields. These functions, Telephone, To whom, Time zone, Quota
198
Blaise
Appendix E: Glossary
and Time slice, are assigned by using the Edit Field Function dialog available
from the Field selection branch of the specification file.
Future priority
FuturePriority is the field in the daybatch file that indicates whether the case has
a pending appointment and if it does have an appointment, the importance to the
Blaise Scheduler of the appointment. The FuturePriority is set when the daybatch
is created and can only be changed if an appointment is made for later that same
day. Its five possible values are: super appointment, hard appointment, medium
appointment, soft appointment, and default (no appointment). See also
Appointment type.
Grace period
The grace period applies only to exact date and time appointments. It indicates the
number of minutes after the given exact time during which the Scheduler must
attempt to honor the appointment, provided that crew are scheduled in the
specification file. The grace period is not relevant until after the Do not call after
time limit. This is because the Scheduler automatically keeps trying all exact date
and time appointments until the Do not call after time is reached. If the grace
period is 90 minutes and the Do not call after time is 8 p.m., an appointment for
7:30 p.m. would be honored until 9 p.m., while an appointment for 8:30 p.m.
would be honored until 10 p.m. An appointment for 3 p.m. would be honored
until 8 p.m.
Hanging number
A hanging number is said to occur whenever Blaise notices that a case listed in
the daybatch file as being treated is not locked. Such an unlocked case is not
available for delivery until the hanging number status is cleared.
History Browser
The History Browser (bthist.exe) is used to view the records in the history file
as well as summary information by interviewer and/or group that is compiled
from the records in the history file. It is also known as the CATI History Browser,
the history program or bthist. The History Browser can be accessed from the
CATI Management program by selecting Tools ➤ CATI History Browser from
the menu bar or from a desktop shortcut.
CATI Guide
199
Appendix E: Glossary
History file
Information on each dial attempt is stored in chronological order in the history
file. The history file is an ASCII file that can be viewed by using the History
Browser. It has a .bth extension.
Internal record number
See JoinID.
Five-minute Interval
Blaise CATI divides the day into five-minute intervals. One such interval would
be 8:05 a.m. through 8:10 a.m. All Blaise CATI time operations are performed in
one of these intervals. Each interval is bound by two times: starting time and
ending time.
Instrument
An instrument is a prepared datamodel. It is composed of the .bmi, .bdm and
.bxi files that are produced when a datamodel is prepared.
Join ID
JoinID is an internal identifier created and used by Blaise to uniquely identify
each record in the survey database. It is also known as the internal record number
or internal key, and is a positive number. The lowest JoinID is 1.
Log file
A log file is automatically created and then updated by Blaise in order to store
information on system-type events. These events include the beginning and
ending of each DEP session.
Make Dial dialog
The Make Dial dialog appears within the DEP window when an interviewer
obtains a new case unless Disable dial menu is checked in the specification file. It
provides information on the case in its Questionnaire data section and a possible
way to register dial results in its Dial menu section.
Not-active
Not-active is both a Status/Priority and generic term that is used to refer to all
cases that are currently in the daybatch that are not presently being treated or
available for delivery but may become available later. All cases with a
200
Blaise
Appendix E: Glossary
Status/Priority of not-active, busy, no answer and new appointment for today are
seen as generically not-active.
Parameters
Parameters is another name for settings.
Quota function
The Quota function can be given in the specification file to one or more database
fields that are of the enumerated type. Blaise creates a quota category for each
combination of possible responses. For example, if there are 2 quota fields and
each field has 4 possible responses, there will be 16 quota categories. Targets
need to be specified for each quota category. Once a target is reached, cases
belonging to that quota category will no longer be delivered.
Routeback
See To whom function.
Schedule
Each time a case is requested within a new five-minute interval, Blaise CATI
systematically reviews all the cases in the daybatch to identify the cases that
should currently be active. This is known as scheduling the daybatch. As part of
this scheduling process, the interim Status/Priorities of no answer, busy, and new
appointment for today are replaced by no need today, not-active, or one of the
nine active Status/Priorities.
Specification file
This file contains the parameters that define when and how a survey should be
executed. The specification file is created by the CATI Specification program and
has a .bts extension. It is also know as the CATI specification file or the spec
file.
Specification Program
The Specification Program (btspec.exe) is used to view and modify the
parameters in the specification file. It is also know as the CATI Specification
program or BtSpec. It can be accessed in the Control Centre by selecting Tools ➤
CATI Specification from the menu bar or from a desktop shortcut.
CATI Guide
201
Appendix E: Glossary
Start interval
StartInterval is the daybatch field that indicates the time, in terms of the fiveminute interval, that a case last became active or will become active.
Status
Generally, the term status means the same as the term Status/Priority. In the View
by Status table in the View Daybatch branch of the CATI Management program
there are four status categories. The correspondence between these status
categories and the Status/Priority is shown in the following table:
Status/Priority
Status category
Being treated
Being treated
No need today
No need today
Not active, No answer, Busy, New appointment for today
Not-active
Default, Soft appointment, Medium appointment, Busy
default, Busy soft appointment, Busy medium appointment,
Hard appointment, Busy hard appointment, Super
appointment
Active
Status/Priority
Status/Priority is the daybatch field used by the Scheduler to track the status of
each case. It can contain one of the following 15 values: Being treated (0), Busy
(1), NoAnswer (2), New appointment for today (3), No need today (4), Not-Active
(5), Default (6), Soft appointment (7), Medium appointment (8), Busy default (9),
Busy soft appointment (10), Busy medium appointment (11), Hard appointment
(12), Busy hard appointment (13), and Super appointment (14). The numbers in
parentheses are used for Status/Priority in the ASCII version of the daybatch file.
Supervisor
The supervisor is the one who is responsible for the survey during interviewing.
Supervisors manage, for example, daybatch creation, operational problem
resolution, and interview exceptions.
202
Blaise
Appendix E: Glossary
Survey
The term survey can be used to refer to an instrument. It can also refer to a group
of survey instruments or the entire set of activities involved in the collection of
data.
Survey instrument
See Instrument.
Telephone function
The Telephone function must be given in the specification file to a database field
that is then known as the telephone field. The value assigned to the telephone
field automatically appears as the first item in the Questionnaire data section of
the Make Dial dialog. It is the value that is automatically given to the DLL that
calls phone.exe when the Dial button is selected from the Make Dial dialog.
Time slice function
The Time slice function can be given in the specification file to a database field
that is then known as the time slice field. The value assigned to the time slice field
is used to determine which time slice set should apply to a given case.
Time zone function
The Time zone function can be given in the specification file to a database field
that is then known as the time zone field. The value assigned to the time zone
field is used to determine which time zone should apply to a given case.
To whom function
The To whom function can be given in the specification file to a database field
that is then known as the to whom or routeback field. Blaise routes delivery of
cases to interviewers and/or groups based on values in their to whom fields.
Treat Form dialog
The Treat Form dialog available through the Forms branch of the CATI
Management program is the supervisor’s equivalent of the Make Dial dialog. It
has Make Dial screen elements plus a few extra supervisor-only items, such as
the Call as soon as possible choice (to make super appointments).
CATI Guide
203
Appendix E: Glossary
Treatment
The term treatment as used in the CATI Specification program is just another
name for dial result.
Zoom
To zoom a case means to bring up the Case Summary dialog for the case. You
can zoom a case by selecting the Zoom button in the Treat Form or Make Dial
dialog. You can also zoom a case by using the Management ➤ Zoom menu option
in the CATI Management program.
204
Blaise
Index
A
Activating cases · 74, 79, 193
Active case(s) · 47, 181, 193
Administrative database snapshot · 98, 104, 107,
193. See also CatiList.asc
As input file · 109, 121
Creating · 107
Daybatch viewer and · 121
Recommended composition · 104
Refreshing · 107, 108, 109, 110
Treat forms problem · 109
Using in report process · 104
Using in utility · 106, 111, 115, 122, 126, 127
American Association for Public Opinion
Research (AAPOR) · 86
Appointments · 193
Appointment block · 31, 88
Appointment graph · 74
Appointment type · 193
Data storage · 29, 35
Day part · 197
De-activation delays · 71
Disabling Make Appointment dialog · 166
Entering · 31
Future load · 113
Grace period · 68, 164, 172, 199
Hard appointment · 44, 45, 47, 53, 71, 73, 74,
160, 164, 167, 168, 169, 170, 182, 193,
194, 199, 202
Making · 88, 113, 172
Making super appointments · 75
Medium appointment · 53, 74, 170, 193, 194
No preference · See No preference
appointment
Parameters · 67, 159
Priority in Blaise · 45, 47
Reporting on · 115
Reports · 112
Requirements for scheduling · 67
Retaining information · 113
Routeback usage · 52, 53, 75
Same day · 60
Scheduler handling · 31
CATI Guide
Setting past midnight · 61
Soft appointment · 52, 74, 170, 193, 194
Super appointment · 52, 53, 74, 75, 172, 193,
194, 195
Time zones · 60
Types of · 112
User-defined appointment block · 31
Viewing · 74
ApptList
.man · 103, 115, 116, 151
.msu · 102
.prn · 115, 116
ApptView.man · 103, 116, 152
Audit trail · 90, 136, 138, 140, 185
Autoread · 106
Autosave · 139
Auxfield data · 33
B
Bdb file · See Blaise data file
Blaise Control Centre
Development tools · 6, 7, 13, 97
Online Assistant · 1
Starting CATI instrument · 27
Blaise data file · 40
Blaise network architecture · 136
Blaise.exe · See Blaise Control Centre
Blaise-to-Blaise copy · 99, 126, 141
BlaiseUser · 68
Blfcopya.dll · 107, 117
Browse database · 94
Btc file · See Counts file
Btd file (binary version of daybatch) · See
Daybatch file
Btemula.exe · See CATI Emulator (BTEmula)
Bth file · See History file
Bthist.exe · See History Browser
Btmana.exe · See CATI Management program
Bts file · See Specification file
Btspec.exe · See CATI Specification program
Busy dial · 49, 168. See also Dial result
Busy dial counter · 44, 46, 82, 169, 195
205
Index
C
Call · 196
Call counter · 45, 80, 82, 196
Cameleon · 11
Case · 196
Case delivery control features
Quotas · 49
Routebacks · 49
Time slices · 49
Time zones · 49
Case Summary dialog · 12, 53, 60, 113, 173
Data button usage · 74
CATI Emulator (BTEmula) · 9, 140
Data script files · 186
DialFreq parameters · 189
Log file · 190
Log file parameters · 190
Option file (.teo) · 185, 187
Option file parameters · 188
Running and controlling · 185
Screen on workstation · 187
CATI files · 35
Blaise data file · 35
CATI Management program · 8, 14, 26, 65, 73,
196
Accessing support programs · 97
Active Groups branch · 76
Active Interviewers branch · 76
Adding support programs to Tools menu · 97,
100
Appointment graph · 74
Creating the daybatch · 150
Daybatch Not yet done table · 81
Daybatch View by Status table · 74
Forms branch · 109, 162
Forms branch, using as review and recode
utility · 76
Handling individual cases · 75
Menu options, disabling · 83
Quota branch · 38, 62
Summary branch · 38, 78, 81
Tools menu · 14, 148
View daybatch - Appointments branch · 74
View daybatch - Browse branch · 120
View daybatch branch · 27, 74, 78, 120
CATI performance · 135
Diagnosis and tuning · 135
Field-to-field slowness · 135
Problems · 135
Slow case delivery · 135
Slow external file access · 135
206
CATI Specification program · 8, 14, 65, 201
Crew parameters branch · 67
Daybatch - Daybatch select branch · 32
Daybatch - Daybatch select branch, exclusion
parameters · 131
Daybatch - Daybatch sort branch · 70
Dial menu branch · 67
Field selection branch · 24, 32, 60, 68, 117
General parameters branch · 53, 58
Menu options, disabling · 83
Parallel blocks branch · 24, 25, 68, 69
Quota control branch · 62, 69
Survey days branch · 67
Time slices branch · 68
Time zones branch · 68
Users - Groups branch · 68, 71
Users - Interviewers branch · 68
CATI utilities
Enhancing · 97
Cati.inc · 30
CatiList
.asc · 102, 103, 106, 111, 112, 115, 116, 122,
123, 128, 129, 151. See also Administrative
database snapshot
.man · 111, 151
.msu · 102
CatiMana blocks · 29, 35
CatiAppoint · 29
CatiCall · 29
CatiMana.CatiAppoint · 35, 88, 112, 113, 115
CatiMana.CatiAppoint.AppointType · 115,
194
CatiMana.CatiCall · 36, 76
CatiMana.CatiCall.CallResult · 87
CatiMana.CatiCall.NrOfCall · 82, 196
CatiMana.CatiCall.RegsCalls[1].DialResult ·
29, 198
CatiMana.CatiCall.RegsCalls[1].NrOfDials ·
197
CatiMana.CatiSlices · 29, 36, 59
Updating · 75
CatiMenu.bwm · 9. See DEP menu file
CatiReport.man · 106, 151
CatiReport.msu · 102
Coding · 139
Commute example
Accomplishing key tasks · 149
After installation · 145
Assess Blaise database tool · 103, 105, 106
CATI Management program, running · 17
CATI Manual Shortcuts folder · 146
CATI Quick Test · 15
CATI Specification program, running · 16
Blaise
Index
Code button in review and recode utility · 131
Code sample · 153
Commute.bla · 153
Conducting interviews · 151
Creating the daybatch · 150
Daybatch Details Sort dialog · 123
Daybatch Summaries · 124
Daybatch, creating · 17
Delete completed cases from the database ·
102
Development folder · 146, 147
Dial menu · 22
Enhanced daybatch view · 123
Enhanced daybatch view tool · 103, 122
Exiting DEP from review and recode utility ·
130
Filter button in review and recode utility · 132
Final outcome code in review and recode
utility · 131
Folder structure · 145, 146
Generate and Display Progress Reports · 111
Initializing the database · 21, 149
Installing · 4, 143
Installing, selecting destination folder · 144
Installing, selecting start menu folder · 145
Install-Uninstall Commute Tools · 148
Interim Outcome report · 110, 112
Interviewers · 150
List all appointments tool · 103, 115
List of appointments by group report · 116
Make Dial dialog · 18
Make Dial dialog, Dial menu · 18
Modifying source code · 149
Modifying the specification file · 150
Organization · 19
Overnight processing · 149, 151
Programs added to Tools menu · 103
Progress reports tool · 103
Quick-start CATI exercise · 15
ReadMe.txt · 149
Review button in review and recode utility ·
130
Review outcomes tool · 103, 128
Run overnight programs · 102, 151
Running DEP from review and recode utility ·
130
Select Interim Outcome Code dialog from
review and recode utility · 132
Shortcuts · 4, 146, 147
Specification file · 21
Start CATI Management program · 102
Start Specification program · 102
Support programs · 102, 151
CATI Guide
Survey days · 16, 22
Tabulate Outcome Codes · 111, 112
Trace History tool · 103, 118
Uninstalling · 143, 145
View Daybatch Details · 122
Commute.bla · 25, 143, 151
Full text · 153
Commute.tdb · 123
Control Centre menu bar
Project Options selection · 89
CopyFileA.man · 108, 111
Counts file · 38, 42, 196
Quota targets · 63
Create Day Batch dialog · 17, 26
Breakdown by FuturePriority of cases · 27
Date confirmation · 26
Notification that the database is being read · 27
Results dialog · 27
D
Data entry program (DEP) · 9
Auto save interval setting · 90
Check before dial setting · 91
Command line options · 14
Configuration · 88
Configuration settings · 85
Counts file usage · 38
Extensions · 85
Get telephone number menu option · 28
Make Dial dialog · 28
Minimize allowed option · 90
Options · 90
Prompt save when finished option · 90
Resize allowed option · 90
Search Settings · 91
Show parallels on tabsheet option · 90
Data integrity and repair · 140
Database
Archiving · 99
Batch modification of fields · 99
Blaise-to-Blaise copy · 99, 126, 141
Browsing · 94
CATI-related fields · 32
Data extraction · 100
EXCLUSIVE mode · 97
Initializing · 21
Integrity and repair · 99, 126, 140
Manage.FinalOutcome field · 131
Record addition and deletion · 99
Reports · 99
207
Index
Database browser · 10
Datamodel · 196
Customizing · 85
Extensions · 9, 85
Input line display · 95
Languages · 95
Major elements · 29
Parallel blocks · 95
Parallels, naming · 95
Properties · 95
Dataview.exe · 116, 120. See also Database
browser
Daybatch · 196
Adding a case · 75
Adjusting number of dials · 174
Adjusting times · 178
ASCII version of · 120
Browsing · 36
Case delivery determination · 47
Cases not in daybatch · 81
Changing group · 179
Changing interviewer · 179
Changing value of time slice field · 177
Changing value of time zone field · 178
Comparing current time with StartInterval and
EndInterval · 175
Creating · 8, 17, 25, 45, 73
Crew times for given day · 46
Determining StartInterval · 174
EndInterval field initialization · 176
Exclude fields · 46
Excluding cases · 46
Excluding outcome codes · 131
Exclusion criteria · 32, 81
Field modification by activity · 183
Group field initialization · 179
Include fields · 46
Inclusion criteria · 81
Initial field values · 169
Initializing TimeDifference · 178
Interviewer field initialization · 179
Last dial result · 46
Log file usage · 39
Management of · 43, 167
Modifying with Maniplus · 75
Non-expired appointment · 46
Number of calls · 46
Priorities in delivering cases · 181
Quotas apply · 46
Recreating · 79
Reevaluation of Status/Priorities · 44
Remaking during interviewing day · 82
Removing an individual case · 74
208
Restricting case delivery · 179
Routebacks · 179
Scheduling · 174
Selection criteria · 46, 81, 82, 164
Size · 70, 78, 80, 81, 82
SliceID field initialization · 176
SliceInfo field initialization · 176
Sort criteria · 45, 81
StartInterval field initialization · 176
Suitability of cases for delivery · 182
Telephone field · 46
Time slices apply · 46
Time slices in · 176
Time zones · 178
Viewing · 27
Viewing records · 73
Daybatch file · 36, 41, 167
CATI emulation · 185
Creating · 45
DialInterval field · 44, 168
EndInterval field · 44, 61, 114, 167, 169, 170,
176, 178, 198
Field changes upon exiting a case · 172
Fields · 167
FuturePriority field · 27, 44, 46, 73, 168, 169,
170, 172, 182, 183, 194, 197, 199
Group field · 44, 51, 168
Interviewer field · 45, 51, 168
JoinID field · 44, 45, 167
NrOfDials field · 44, 82, 168, 169
NrOfDialsBusy field · 44, 82, 168, 169
QuotaIndex field · 45, 63, 168, 181
SliceID field · 45, 58, 168
SliceInfo field · 45, 168
StartInterval field · 44, 114, 167, 169, 170,
176, 202
Status/Priority field · 44, 167, 169
TimeDifference field · 45, 168, 178
Viewing · 50
Daybatch viewer · 103, 120
Creating · 120
Example · 122
Flowchart · 120
Process · 122
DAYBATCH_ADD · See Maniplus
DAYBATCH_DEL · See Maniplus
De-activation delay · 53, 71, 79, 80, 197
Default · 197
Definitions of terms · 193
DEP Configuration editor · 9
DEP configuration file · 91
Run parameters usage · 92
Specifying files · 92
Blaise
Index
DEP menu file · 92
Browse menu option · 93, 171
Get menu option · 93, 171
Get Telephone Number menu option · 93, 171
Modifying · 93
New menu option · 93, 171
DEP Menu Manager · 9, 93
Customizing Forms branch · 94
Dep.exe · See Data entry program (DEP)
Depcfg.exe · See DEP Configuration Editor
Dial · 197
Dial attempt · 6, 197
Dial counter · 44, 46, 80, 82, 168, 169, 197
Dial interval · 198
Dial menu · 198
Adding options · 23
Answering service option · 30
Call as soon as possible · 173
Make Dial dialog · 11, 200
Minimal or no use of · 85, 87
Non-questionnaire treatments · 87
Running DEP from · 75
Skipping in DEP · 68
Treat Form dialog · 12, 38, 76
Dial result · 7, 29, 171, 198
Answering service · 7, 48, 55, 171, 176
Appointment · 7
Busy · 7, 24, 44, 48, 171, 195
Concluding · 48, 171
Disconnected · 7, 171
No answer · 7, 25, 55, 171, 176
Non-response · 7, 171
Others · 7, 29, 46, 48, 69, 161, 166, 171, 198
Overriding default · 87
Parallel blocks · 30
Registering · 6, 171
Response · 7
Secondary key · 33
Dial screen · 162, 198
DLL · 136, 198
E
Edit Field Function dialog · 24, 199
Emily.exe · See Modelib Editor
End Interval · See Daybatch file
External files · 99, 136, 138
CATI Guide
F
Final coding · 86, 99
Assigning codes · 86
Excluding from daybatch · 131
Final outcome code · 130, 131, 132
FinalOutcome.prn · 110
Five-minute interval · 44, 46, 48, 137, 169, 171,
174, 200, 201
Form · 90, 188, 190, 191, 196, 198
FORMNUMBER · 125
Function · 198
Quota · 62
Time zone · 61
FuturePriority · 194. See Daybatch file
G
Glossary of terms · 193
Grace period · 68, 172. See Appointments
H
Handling reentry · 33
Hanging number · 199
Hard appointment · See Appointments
History Browser · 2, 6, 8, 41, 65, 73, 101, 199
AppointType field · 194
List view · 76, 77, 125
Productivity view · 77
Reports · 77
Using · 73
History database · 38, 118
Secondary keys · 119
History file · 8, 37, 38, 41, 65, 68, 75, 77, 108,
109, 117, 162, 193, 199, 200
Adding fields · 38, 107, 113, 117
AppointType field · 194
Copying · 97, 107, 117, 118
Customized views · 116
Deleting fields · 118
Dial attempts · 197
Fields · 38, 125
Interim codes · 86
Linking files with · 109
Modifying view of · 97
Network performance · 120
Reordering fields · 118
Reports · 99, 104
209
Index
Super appointments · 195
Times · 137
History viewer · 103, 116, 119
Creating · 117
Example · 118
Process · 118
History Viewer
Example · 119
History.bla · 38, 118, 119
History.bmi · 117
HistoryMerge.man · 103, 111
HKEY_CURRENT_USER · 68, 101, 150
Hospital utility · 10, 11, 35, 99, 141
Hospital.exe · See Hospital utility
I
INHERIT CATI · 8, 29, 31, 35
Insert Menu Line dialog · 23
Instrument · 4, 5, 9, 20, 27, 88, 136, 146, 152, 200
Test · 140
Interim coding · 85, 86, 99, 129
Reports · 112, 132
InterimOutcome.prn · 110
Internal key · 10, 35, 37, 125, 200
Internal record number · 125, 200
Interview process · 6, 44
Accessing a case by primary key · 94
Activating cases · 173
Conducting interviews · 27, 151
Exiting a case · 24, 30, 95, 171
Manipula and Maniplus processing · 98
Network performance · 137, 138
Obtaining a case · 93, 170
Performance report · 76
Processing after interviewing period · 100
Processing before interviewing period · 100
Registering a dial result · 171
Registering a super appointment · 172
Simulating · 185, 189
Stopping interviews · 28
Interviewer reporting · 76
Interviewing after midnight · 60
J
JoinID · 10, 35, 121, 129, 200
Accessing in Maniplula or Maniplus · 125
Administrative database snapshot and · 121
Daybatch field · 167
210
Daybatch file usage · 36, 37, 73
Linking files with · 36
Obtaining from primary key · 125
Perspective on · 125
L
Last attempt for today history file · 109
LastAttempt.man · 103, 111
Local area network (LAN) · 137, 138
Monitor utility · 10
Sources of CATI network traffic · 90, 91, 120,
137, 138
Testing network performance · 9, 139, 185
Log file · 38, 39, 42, 107, 109, 190, 200
Parameters · 190
Reports · 104
M
Make Appointment dialog · 11, 31, 61, 193
Eliminating · 88
Make Dial dialog · 11, 12, 61, 162, 200
De-activiation delay, viewing status · 53
Parallel blocks · 28
Questionnaire data section · 27
Returning to from questionnaire · 28, 31
Zoom button · 12, 27
Management utilities · 7, 65
CATI Management program · See CATI
Management program
CATI Specification program · See CATI
Specification program
History Browser · See History Browser
Maniplus · 10
DAYBATCH_ADD function · 10, 52, 75, 134
DAYBATCH_DEL function · 10, 75, 132
Processes · 127
Support programs · 97
Manipula · 10
EXCLUSIVE mode · 98
SHARED mode · 98
Support programs · 97
Manipula.exe · See Maniplus. See Manipula
Medium appointment · See Appointments
Menu title edit box · 100
Menumana.exe · See DEP Menu Manager
MergedFileCopy.man · 111
Mode library · 89
Specifying · 89
Blaise
Index
Modelib Editor · 9, 90
Modelib file · 9
Monitor · 10
Monitor.exe · See Monitor
N
Network issues · See Network topics
Network performance · See Local area network
(LAN)
Network topics · 135
No appointment · 45, 47, 52, 71, 199
No calls time limits · 60, 68, 78, 79, 163
No preference appointment · 45, 52, 55, 114, 169,
195
Not-active · 44, 46, 49, 74, 78, 79, 167, 173, 175,
177, 193, 200, 201, 202
Number of calls · 45, 80, 82, 196
O
Opportunistic record locking · 141
Outcome codes · See also Interim coding. See
also Final coding
Secondary key · 33
OutcomeHistory array · 86, 131
Outcomes.man · 103, 107, 111, 152
Overnight processing · 5, 6, 99, 102, 103
Administrative database snapshot · 107, 151,
193
Batch · 33, 107
Database fields, batch modification · 99
Database maintenance · 99
File creation · 99
Manipula setups · 86
Record addition and deletion · 99
Reports · 104, 106
Reports, generating end-of-day · 99
Reports, generating start-of-day · 99
Routines · 14, 52
P
Parallel blocks · 24, 68, 69, 166
Customized · 30
Datamodel properties · 95
Make Dial dialog · 28
Naming · 95
CATI Guide
No answer · 28
Specifying tab access · 90
User-defined · 30
Parameters · 201
Phases of Blaise CATI approach · 5
Phone field · 24, 32
Placeholder fields · 32
Primary key · 35, 45, 122, 129
Determining value for a case · 125
Linking files with · 36, 38
Obtaining JoinID from · 125
Program edit box · 100
Project Options dialog
Specifying mode library · 89
Q
Questionnaire treatment · 23
Quick-start CATI exercise · See Commute
example
Quota function · 201
QuotaIndex field · 63, 181
Quotas · 61, 166, 180. See Case delivery control
feature
Commute example usage · 62
Counts file usage · 63
Effect on available cases · 79
Effect on daybatch size · 81, 82
Filling a quota · 181
Initializing QuotaIndex · 180
Modifying the QuotaIndex · 181
Quota functionality · 62, 69
R
RandR.man · 103, 128, 132
ReadOut
.man · 151
.msu · 102
Recoding Utilities · 133. See also Review and
recode utility
Reports
Appointment example · 115
Appointment-related · 112
Based on administrative database snapshots ·
107
Daybatch summary by region · 124
Example · 105
Future appointment load · 113
Generating report files · 104
211
Index
Generation process · 104, 105
History file data · 104
Log file data · 104
Running · 103
Respondent time · 178
Review and recode utility · 103, 126, 129
Creating · 126
Example · 128
Fresh information prompt · 128
Process · 126
Routebacks · 50, 201. See Case delivery control
feature
Creating of queues · 50
Database field · 75
Division of caseload · 50
Do not change routeback option · 52
Effect on case availability · 79, 80
Effect on case delivery · 81
Interviewer familiarity with cases · 50
Interviewer qualifications · 50
Routeback to group · 52, 179
Routeback to interviewer · 52, 179
Suitability for case delivery · 51
To whom functionality · 51
Usage · 51
S
Schedule · 201
Scheduler · 8, 25, 43
CATI emulation · 185
Count file usage · 38
Diagnosing problems · 78
Handling problems · 78
Reevaluating cases · 48
Setting parameters · 69
TAppMana block · 31
Treating and exiting a case · 48
Scheduler problems
Cases never attempted · 78
Cases not being delivered · 81
Cases not being touched · 80
Daybatch too small · 81
No cases available for delivery · 78
Scheduling · 137
Adjusting StartInterval and EndInterval · 177
Time slice applicability · 176
Secondary keys · 33, 76, 119, 139
SETREADKEY function · 124
Shortcuts · 14
Creating · 14
212
Soft appointment · 170, 194. See Appointments
Specification file · 40, 201
Modifying · 21
Specification file parameters · 8, 65, 66, 157
Allow past midnight calling · 60, 67
Allow slices to be tried on same day · 69, 71
Apply select fields also after the dial in the
DEP · 172
Appointment parameters · 67, 159
Background parameters · 66
Background parameters, guidelines for setting
· 66
Crew parameters · 67, 74, 157
Daybatch parameters · 66, 69, 157, 158
Daybatch select · 86
Daybatch select fields · 69, 165
Daybatch size · 70
Daybatch sort fields · 70, 165
Days between answering machine calls · 82
Days between no answer and answering
machine calls · 70
Days between no answer calls · 82
De-activation delays · 53, 79, 80, 197
Dial menu · 67, 157, 161
Do not allow multiple same day answering
machine calls · 67
Edit allowed · 61
Expire on de-activation delays only · 54, 71,
79, 180
Field applicability · 165
Field selection · 38, 51, 59, 61, 62, 68, 76, 162
Group de-activation delay · 180
Group de-activation delay (medium or hard) ·
71
Groups · 46, 51, 68, 71, 76, 80, 157, 162, 179
Interviewer de-activation delay · 180
Interviewer de-activation delay (medium or
hard) · 71
Interviewers · 54, 68, 76, 80, 81, 157, 163, 179
Max try · 59
Maximum number of busy dials · 70, 80, 81,
174
Maximum number of calls · 46, 70, 82
Maximum number of dials · 58, 70, 80, 81,
174
Minimum time between hard/super no-answer
· 71, 79
Minimum time between 'other' no-answer · 58,
71
Minutes between busy dials · 70, 79, 81, 175
No calls time limits · 68, 163
Parallel blocks · 69, 95, 166
Phone field · 24
Blaise
Index
Quota control · 63, 69, 166, 180
Same day · 58
Scheduler parameters · 54, 66, 70, 157, 159
Show in dial screen · 61
Skip dial menu in DEP · 68
Survey days · 67, 157
Time slice definitions · 45, 56, 68, 70, 82, 164,
169, 176
Time slice maximum tries · 70
Time slice sets · 57, 59, 68, 164
Time zones · 68, 78, 79, 115, 163
Specification program · See CATI Specification
program
Speed buttons · 9
Start interval · See Daybatch file
Status · 202
Status/Priority · 202
Daybatch file · 44
Default · 47, 197
No need today · 48, 52
Non-concluding cases · 48
Order of priorities · 47
Super appointment · 47
Treating and exiting cases · 48
Super appointment · See Appointments
Supervisor · 202
Support programs
Accessing · 97
Creating · 97
EXCLUSIVE mode · 97, 98
Maniplus · 97
Manipula · 97
Processing during interviewing day · 98
SHARED mode · 98
Timing · 97
Survey · 203
Survey instrument · See Instrument
Survey management
Multiple surveys at once · 101
Secondary keys · 33
Survey management fields · 32
User-defined · 32
Survey progress reports · 77
Survey stages · 72
T
TAppMana · 31
Tdb file (ASCII version of daybatch) · See
Daybatch file
Telephone function · 24, 32, 203
CATI Guide
Time slice function · 59, 203
Time slices · 55, 164. See Case delivery control
feature
Definitions of, editing · 57
Effect on available cases · 79, 80
Effect on daybatch size · 82
Sets, defining · 69
Sets, editing · 57
Specification of · 56
Time zone function · 178, 203
Time zones · See Specification file parameters.
See Case delivery control feature
Specifying · 61
Usage · 60
TimeZone field · 60, 61
To whom function · 203. See Routebacks
Tools Edit dialog · 100, 101
Tools Menu Editor dialog · 100
TouchReport.prn · 104, 105, 106
Treat Form dialog · 12, 61, 75, 203
Call as soon as possible option · 12, 75
EVERYONE option · 75
For whom edit box · 52
For whom field · 12, 75
Making appointments · 52
Non-response option · 75
Super appointment, making · 75
Zoom button · 12
Treatment · 204. See also Dial result
Troubleshooting Scheduler · See Scheduler
problems
U
User-defined appointment block · See
Appointments
V
ViewHist.man · 103, 118, 152
W
Windows registry settings · 101
Working folder edit box · 100
Workstation time
Problems due to incorrect · 137
213
Index
Z
Zoom · 12, 27, 53, 75, 76, 112, 125, 204
214
Blaise
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement