Академический Документы
Профессиональный Документы
Культура Документы
Form Reference 308 Documentation was added for the new form CC Reset for SQL Server
(CCRS)
Form Reference – The Mag Tape Option Defaults (MTOD) form was obsoleted.
Envision®
Runtime Administration
Release 4.7/4.8
March 10, 2010
For last-minute updates and additional information about this manual, see AnswerNet page 2103.81.
Runtime Administration
Datatel, Inc.
4375 Fair Lakes Court
Fairfax, VA 22033
(703) 968-9000
(800) DATATEL
www.datatel.com
Table of Contents
17 Overview
19 About This Manual
19 In This Chapter
19 Who Should Read This Manual?
20 How This Manual is Organized
37 Process
38 Forms
38 Batch Programs
39 Procedures
39 Operator
40 Device
40 Peripheral
41 Security
51 Setup
53 Introduction to Setup
55 Defining System Parameters
55 In This Chapter
55 Using the Envision Parameters Edit (EPED) Form
56 MIO Indexing Mode (Envision 4.7 Only)
57 Oracle I/O Off (Envision 4.7 Only)
57 Disable Full OCI (Envision 4.7 Only)
57 SQL Select Off (Envision 4.7 Only)
57 Read Cache Size (Envision 4.7 Only)
58 Read Cache Log State (Envision 4.7 Only)
58 Clear Cache Off (Envision 4.7 Only)
59 Execute Log On
59 Numeric Precision
59 Subscription Enabled
59 Inbound EDX TX Enabled
60 Use Passive FTP
60 Windows Clients
60 Error Stamping
61 MIO Level Check Disable
61 UT Debug String
61 DMI Print Server IP/Port (Envision 4.7 Only)
75 Printing
75 Understanding Levels of Printing
75 Operating System
75 Database Management System Software
75 LPTR
76 SETPTR
76 Application Software
76 Change Peripheral Defaults Form
78 Defining Printers to Envision for Windows NT and
Windows 2003/2008
78 For All Printers Defined On The Same Local Server as
Colleague
79 For a Network Print Server
131 Security
133 Security Overview
133 Introduction
133 Logging In
134 UNIX
134 Windows 2003/2008
135 For All Platforms
137 Logging Off
187 Maintenance
189 Maintenance Introduction
189 Scheduling System Maintenance
189 Saves
190 Consolidation of Job Histories
190 Purges
190 Disk Maintenance
191 Sample Daily Schedule
191 Notes
247 Troubleshooting
249 Introduction to Troubleshooting
249 Recovery Guidelines
250 Troubleshooting Envision-Based Software
293 Appendices
295 System Setup Worksheets
295 Worksheet for Device Definition (SDD)
296 Worksheet for System Operator Definition (SOD)
297 Worksheet for Security Classes
298 Worksheet for Function Keys (SKB1)
299 Worksheet for Cursor Keys (SKB2)
300 Worksheet for Graphic Characters
301 Worksheet For Special Purpose Characters
481 Index
Overview
Overview
In This Chapter
This chapter of Runtime Administration provides the background knowledge
that you need to fully understand how the software works. Specific Envision
terminology is defined and an introduction to the software development tools
and documentation is presented. The directory, account and file structure is
also explained. An overview of conventions for cataloging programs and
definitions of the control files is provided.
What is Envision?
Envision is one of a category of computer programs referred to as computer-
aided software engineering (CASE) tools. CASE tools are programs that
automate the development, design, implementation, installation, and
maintenance of computer applications.
Structure of Envision
Envision consists of two components:
Envision Tool Kit (ETK)
Envision Runtime (UT)
Procedure Generator
Data Element Definition
Applications
Documentation
Envision Runtime
Envision Runtime (UT) is the executable code needed to run an application.
In addition to the code generated by the Process Generator, UT contains the
System Administration setup forms that establish the operating environment
for an application.
Menu definition
BROWSE shell
Remote account specification
Envision Forms
All Envision processes are performed by entering data on Envision forms.
Each function listed on the main Envision menu has its own corresponding
menu, or set of menus, from which you select the processes you want to
perform. Similarly, each process has its own form or set of forms for
displaying or entering information.
Form Layout
In general, an Envision form contains the following areas:
Header block
Data area
LookUp area
Header Block
The header block is the set of fields at the top of the form. The fields in the
header block display information about the application and process with
which you are working. Figure 1 on page 24 shows header information for a
form in the Envision Tool Kit.
Data Area
The data area is the middle part of the form. The contents of the data area
differ according to the form with which you are working. Fields in the data
area are described in the individual form description chapters.
LookUp Area
Many Envision input or inquiry forms have a LookUp area.
The LookUp area prompts you for a specific piece of information. When you
enter the information, Envision extracts associated data from the database and
displays it in the header block or the data area.
The LookUp area also contains options, such as Cancel, Finish, and Help.
If you select the online help from any data entry field on the form, the system
displays information on the purpose of the field.
Process forms
Detail forms
Online help
Some process forms contain fields that are preceded by an asterisk (*).
Detailing from one of these fields displays either a detail form or a text
editing form. A detail form can be either a form for entering data related to the
field or an inquiry form that displays additional information related to the
field. Online help provides both process and field help messages.
The following sections describe each of these form types in more detail and
explain how to use them in Envision.
Menus
A menu is an organized list of Envision functions. In Envision, each item on a
menu is called a process, and each process is associated with one or more
forms used to run the process.
There are four different types of processes in Envision. When only one type of
process is shown on a menu, the items on that menu are numbered
sequentially, beginning with the number 1. When two or more types are
available, the items are either stacked in the center of the form or grouped into
quadrants and sequentially numbered according to process type. The four
process types and their numbering schemes are as follows:
Maintenance. Numbered sequentially from 10 to 19.
Process Forms
You perform an Envision function from an Envision process form. The data
area of a process form has spaces of specified length, called fields, where data
is displayed or entered. Each major field is labeled to identify the data in that
field.
Detail Forms
Some fields on a process form are preceded by an asterisk (*). These fields are
detail fields, and the asterisk indicates that you can access another form,
called a detail form, from the detail field.
You can use Envision detail forms to view, enter, or modify additional
information associated with the field from which you accessed the detail
form.
In some detail fields, the system displays a form for the default text editor so
that you can enter text or program code to customize an Envision process.
You can find additional information about detail forms and how to use them in
the Guide to User Interfaces.
Envision Fields
Envision uses the following field types:
Standard Field. A standard field is a normal full-process data entry field
whose contents can be entered or modified.
Phantom Field. Phantom fields do not appear on any area of the form.
These fields are input fields where the program loads variables and data
that the process needs. Usually, you do not need to see the data in these
input fields. Phantom fields often appear as prompt fields just below the
body of the form. Such fields usually prompt for a record ID or other key
for the main record that the process needs.
Inquiry Field. An inquiry field, also called a display-only field, is a field
containing data that cannot be accessed or changed from the process form
on which it appears. Although inquiry fields appear on the form, you
position the cursor on an inquiry field to access the field. Inquiry fields
display data that can be used to determine other data that you need to enter
or change. A data element may appear on one process form as an inquiry
field and on another process form as a standard field.
Basic Concepts
Many Envision application forms display information or accept data entry
through fields called window fields. Windows can appear on both process and
detail forms.
What is a Window?
A window is a field in which you can enter or display more than one instance
of a single data element, or a single set of data elements. In Envision, we refer
to the data elements as values, and we refer to the fields in a window as multi-
valued fields. A window can contain either of the following:
A list of single values. A window with a list of single values is called a
single-valued window.
A list of value sets. Each value set consists of a basic value, called a
controller, and a group of other values associated with the controller. This
kind of window is called a multi-valued window.
Envision numbers each value or set of related values, and you can retrieve
information using special window movement keys and commands.
Terminology
The following defines some of the terminology surrounding windows:
List. A common data structure in Envision. A list provides storage for and
maintenance of many values for a single data element. The list structure is
the basis for the following Envision database usage types:
• List field. A multi-valued set of data values. The list data structure is open-
ended; that is, there is no theoretical limit to the number of values that can
be in a list.
• Associated field. A set of related data values maintained as a group;
groups are maintained across lists.
• Q-select field. A list of record keys that point to additional information in
another file.
• Block field. A list of data values that cannot be modified and are displayed
as a single entity.
Window Controller. The first (left-most) value in a window. This value
determines the names used for window variables and subroutines. The
window controller is the key field for the window. The values of other
window elements are determined by the value entered into the window
controller. In windows containing keys to secondary files, the window
controller is the field containing those keys.
When a window contains more than a single data element (that is, when the
window consists of parallel lists or associated multi-values), the controller
is always the first (left-most) data element in the sequence of window
elements. The controller characteristics apply to all of the associated fields
within the window; however, Envision stores only the controller key, not
the associated field values, as part of the window. Based on the controller
key, Envision accesses and displays the values for these associated fields
whenever you run the process.
Controller-on-the-fly. A feature that lets you define the set of controllers
to view in a window. For instance, a professor may want to view the grades
for a subset of the students he teaches. The window the professor is paging
through shows records for all the students he teaches, but he may only want
to look at records for students in a particular course or course section.
Using the controller-on-the-fly feature, the professor can define a subset of
records that he wants to view. In effect, this feature provides an on-screen
query process, which then permits modifications to the records instead of
just reporting on them.
Window Group. A numbered set of data items appearing on one line of a
window.
Page. The set of groups that are displayed at one time. A window group
appears on only one page. If each window page consists of three window
groups, page 1 displays groups 1 through 3; page 2 displays groups 4
through 6; and so on. Regardless of how you select a window group, its
position within the page is constant. Each page except the last page has a
constant number of groups. The last page may contain fewer groups.
Data Field Group. A single-line window that does not scroll.
Window Element. A distinct data item within a window.
Window Label. A heading that identifies a window.
Field Label. A descriptive title identifying a data element on the form,
either for a single field or for a window with multiple elements per line.
Status Line. A line of information displayed at the bottom of the form to
help you use windows. When the cursor is in a window, the status line
displays either Controller or Element, followed by the field label to indicate
the location of the cursor. The total number of entries and the line number
of the cursor appear on the right side of the status line:
Value n of m. Where n is the cursor location line and m is the total number
of entries in the window.
Types of Windows
Envision has two types of windows: Vertical windows and Horizontal
windows.
Vertical Windows
Vertical windows scroll up and down. A vertical window may have one or
many values in a group. Envision processes individual fields in the window in
sequence, beginning with the controller (the left-most value) and continuing
to the last associated value before proceeding to the next set of values.
Horizontal Windows
Horizontal windows scroll left and right. A horizontal window usually has
only one value per group. Horizontal windows are less common than vertical
windows and are usually used for shorter fields, like code validation fields,
when the form design does not permit a vertical window.
Processing Windows
Each window on an Envision form has a corresponding set of internal
subroutines for processing the window. The names of the subroutines indicate
their functions with respect to the window controller:
WNDW.INIT.controller. Initializes all variables used to process values in
the windows.
WNDW.DEL.controller. Runs when you delete a window group.
WNDW.INS.controller. Runs when you insert a window group.
V.fieldname. Contains the value from the list of the current window
iteration (WNDW.controller.INDX).
VS.fieldname. Indicates that the lists within a window have been added to,
or taken from, a master list; assigned by Envision.
Sort/Break Criteria
Use the Change Sort Specification form to change the order in which a list of
values is sorted. This form automatically appears during a procedure if you
are able to alter the default sort sequence. You cannot access this form
directly from a menu.
Features
Envision Runtime (UT) contains the executable code needed to run an
application. In addition to the code generated by the Process Generator, UT
contains the System Administration setup forms that establish the operating
environment for an application. Some of the features include the following:
Utilities. Envision Runtime’s utility programs are the core to the execution of
an Envision-based application. The utilities centralize the reading from and
writing to disk. Each Envision process narrows the range of potential loss of
data by grouping disk I/O into a single burst. The transaction commit
capability allows a set of updates within a program to be treated as one.
Instead of each update being treated individually, the set of updates are treated
as a group. Transaction commit mitigates the possibility of an incomplete
system update during a computer or disk failure by concentrating all the
record updates into a single burst of disk writes. This also sets the stage for
more comprehensive recovery procedures.
Terminology
Envision is a sophisticated and comprehensive application development
environment and, as such, has a vocabulary all its own. Some of the terms
presented in this section are standard industry terms. Others are terms coined
specifically for Envision. The purpose of this section is to present some of the
more fundamental concepts key to Envision.
Application
An application is a set of programs which are grouped together to meet the
needs of a functional area. These programs allow users to maintain and
display information stored in the database associated with the grouping of
programs. The programs and the elements in the database share certain
characteristics specific to the functional area. For example, Colleague Finance
(CF) is an application, and the General Ledger (GL) and Budget Management
(BU) are modules that reside in CF.
Application Trees
Envision uses application trees to provide a hierarchical relationship among
applications. At the root of every application tree is the Runtime application,
UT. The UT application encompasses the most fundamental characteristics
required by every other Envision-based application. Every other Envision-
based application is subordinate to, or is farther down the tree than, the UT
application.
Any subordinate application can “look up” the tree to use any characteristic
defined further up the tree. Two applications that have characteristics in
common, therefore, can maintain their modularity and integrity since
common characteristics can be defined in an application which appears
further up in the tree structure.
Tree Reads
When a requested characteristic does not reside in a given application,
Envision performs what are called tree reads. A tree read searches from the
subordinate application up the tree through each higher application for the
requested characteristic. Each application in the tree is searched until
Envision finds the characteristic or until it reaches the base of the tree, the UT
application. If the characteristic is not found in any of the higher applications,
Envision informs the requesting program, at which time the user may add the
new characteristic to the subordinate application, if permitted. If Envision
finds the characteristic in a higher application, the subordinate application be
able to only use the definition, being unable to modify the definition.
Module
A module in Envision is a subset of programs within an application which are
more closely related within the functional area. While all programs share
characteristics within the functional area, some programs are more tightly
coupled and therefore can be segmented even further.
which the other modules in the application are dependent. A base module can
function without an optional module, but the base module must be present in
order for an optional module to run. An example of this dependence is the
Colleague Finance Budget Management module. The Budget module requires
the base General Ledger module to be present; Budget cannot run without
General Ledger. General Ledger, however, can run without Budget.
The base module for an application is always included with the delivery of
that application.
Process
An Envision process provides a function or service within a functional area.
The function may be interactive maintenance of several data elements,
printing values stored in the database to a line printer, or modification of data
elements run without user interaction. A process is defined through the
Envision Tool Kit, resulting in the creation of a program. The compiled
version of these programs can be run by the end user through the Envision
Menu Processor.
The Envision Menu Processor is itself a process. This utility program from the
Runtime application, UT, displays to the user a list of processes from which
the user can select. Each process on the menu can be a program which
provides a certain function, or another menu, which will present to the user
another list of choices. The Menu Processor is run each time an Envision-
based application is initialized and remains active until the user leaves the
application.
Batch Programs
Procedures
Forms
Envision form processes are interactive programs that solicit user input by
displaying information on a form and accepting information from a terminal
keyboard. As described in the previous chapter, there are four basic kinds of
Envision forms:
Menus
Processes
Detail Form
Online Help
Each type of form displays a given amount of information on the user’s form.
The user then processes the information presented. Envision forms process
single records at a time; there is one primary record, which may have
associated secondary records. The current record must be released before the
user can process another record.
Batch Programs
Envision Batch Programs are non-interactive looping programs that work
from lists of records. The typical batch structure allows the program to
perform the same functions on selected records. While some batch programs
work on only one record, Envision provides fourth-generation (4GL)
programming statements which allow the processing of many records in
exactly the same way.
Procedures
An Envision Procedure is a predefined sequence of steps which provide a
specific function. Each step in a procedure must be defined before it can be
included as a step. The following are the types of steps valid in an Envision
Procedure:
User Forms. Form processes used within a procedure to elicit option and
parameter information from an end user.
Jobs. Batch and form processes, programs, and any other procedure step
that is not a user form or list step.
List specifications. Create SSELECT or SELECT commands within a
procedure to create a list of records based on user input entered from a
form.
Operator
The term operator in Envision is synonymous with user: any person who uses
an Envision-based application. Each operator must have a valid operator
definition in order to use an application. The definition may reside in the
application the operator is using, or may reside in an application higher up the
tree. The operator definition controls the access the user has to the processes
in the application and other characteristics unique to the operator, such as the
operator’s Envision password and initial application menu.
Each operator is identified by his login ID. This ID is also used for identifying
when the user adds or changes a record in the database. When a user runs a
procedure in background mode, Envision uses his login ID as part of the
unique key which records the results of the procedure. Any person attempting
to use an application for which he has no operator definition is logged off the
system.
Device
A device in Envision is a terminal. Each unique combination of display
characteristics and keyboard mappings has a unique device definition. The
display characteristics define how Envision displays graphics characters and
video attributes on the user’s terminal form. Keyboard mappings associate the
character strings generated by keys on the user’s terminal keyboard with
special Envision functions.
Peripheral
A peripheral in Envision is a destination for output from procedures.
Peripheral definitions include line printers, terminals and magnetic tape
drives. Some procedures allow the end user to alter the definition of the
peripheral for that execution. Each peripheral definition includes the
following characteristics:
Description. A description that is used in LookUp resolutions, procedure
specifications, and procedure definition reports.
Width. An integer that controls the end-of-line processing for output to the
peripheral.
Length. An output length is the number of lines reserved for printing
output from a batch program or a report. The total of the output length, the
top margin, and the bottom margin is the number of lines for the printed
page.
Top Margin. The number of lines left blank at the top of the output.
Bottom Margin. The number of lines left blank at the bottom of the output.
Mode. The peripheral mode determines the default target output device for
the peripheral definition.
Form Name. The spooler system of your host computer may allow form
names that prevent the printing of documents unless a special form is
loaded in the output device.
Banner. For printed output, this name appears on the banner page. For
output target from the HOLD file, this name becomes the record ID for the
output.
Location. Some spooler systems allow you to specify a location at which
printed output will be processed.
Copies. The number of copies of the output to produce.
Defer Time. Defining a print time is useful for long reports or batch
programs. By deferring execution, you can reduce the load on your host
computer at peak usage times and increase the load at low-usage times.
Other Options. Other printer options may be specified to further control
the production of the output.
Security
Envision Security allows the system administrator to define and control which
processes, records, and fields users may and may not access. Envision
Security controls user access using three layers of security definitions:
1. Menu and Process Security are controlled via security classes. Each
operator is assigned a security class and each security class defines the
menu and process mnemonics available to users in that class. The Envision
Runtime Menu Processor controls the user’s access to menus and
processes according to his security classes. The Menu Processor does not
display mnemonics for which the user has no access. Even if the user
knows a mnemonic for which he has no access, the Menu Processor
prevents the execution of the menu or mnemonic associated with that
mnemonic.
2. Record Security allows the system administrator to restrict the access to
certain records in selected files based on selection-like criteria. Each user
has a set of predefined characteristics. Envision Runtime compares these
characteristics against the security criteria for a requested record or list of
records. If the user has access to the requested record or list of records,
Envision Runtime allows the user to process the record as defined by the
security criteria. If the user fails to pass the security test, access to the
record is denied.
Record Security is an optional Envision file service provided only for files
defined through the Envision Tool Kit. Non-Envision files are not allowed
to have record security definitions. Since only files defined in Envision
can have record security definitions, all Envision processes honor record
security.
Field Security is an optional Envision file service provided only for files
defined through the Envision Tool Kit. Non-Envision files are not allowed
to have record security definitions. Since only files defined in Envision
can have record security definitions, all Envision processes honor record
security.
appl.DOC
appl.ENV*
appl.ERROR*
appl.FILE.SPECS*
appl.HELP*
appl.HELP.LONG*
appl.INSERTS
appl.MENU*
appl.OBJ
appl.OPERS*
appl.PARMS*
appl.PPROCESS*
appl.PRCS.CTL*
appl.PRCS.DEF
appl.PRCS.GEN*
appl.PRINTERS*
appl.SECLASS*
appl.SOURCE
appl.SUBROUTINES
appl.VALCODES*
appl.VOC
File names above with an asterisk (*) indicate those files that are subject to
tree reads. Tree reads allow Envision Runtime to search through the envision
hierarchy for a requested record. Envision Runtime first searches the current
application file for a requested record. If the record is not found in the current
application file, Envision Runtime searches the next application in the
application tree for the requested record. Envision Runtime continues to
traverse the application tree until it finds the requested record, or until it
reaches the UT application. The application tree is stored in the appl.CTL file.
along with definitions from the CDD and FILE.SPECS files, to create
programs.
appl.PRCS.GEN. Stores details of either a procedure definition or a list
specification. For procedure definitions, the appl.PRCS.GEN record has a
list of the steps that make up the procedure, as well as defining other
parameters that control the options available to end users when the
procedure is run. These records are populated via the Procedure Definition
(PGDF in ETK and JDEF in Runtime) forms. Procedure definition records
included with the delivery of an application should not be modified, and
new records should not be added. To add new procedures, use the Screen
Procedure Specs (SPSP) form. For list specifications, the appl.PRCS.GEN
record contains specifications such as selection, sort, and break criteria.
These records are populated via the Procedure List Specification (PGLS in
ETK) form.
appl.PRINTERS. Stores the peripheral definitions for the application.
These definitions control the appearance and destination of the output for
batch programs and reports. In addition to line printers and other hardcopy
devices, the PRINTERS file stores records for magnetic tape output
devices. The PRINTERS file is populated via the Peripheral Definition
(PDEF) form in the Runtime application (UT). Do not modify peripheral
definition records included with the delivery of an application. New
peripheral definition records may be added.
appl.SECLASS. Stores the security class definitions for the application.
These definitions are lists of processes that the end users are allowed to
access. The SECLASS file is populated via the Security Class Definition
(SCD) form of the Runtime application. The system administrator controls
the security classes defined for each work-flow of users of the application.
appl.SOURCE. Stores the source code for all the generated programs and
insert modules for the application. The Envision Code Generator uses the
data base compiler to generate the executable object code, which is stored
in the appl.OBJ file.
appl.SUBROUTINES. Stores the source and object code for all non-
generated programs and subroutines.
appl.VALCODES. Stores the validation and translation tables for coded
data elements. Each table contains codes, their descriptions and any special
processing associated with each code value. End users can modify some
tables, while other tables are restricted from modification. See the
documentation for a each application to determine if you can modify a
specific VALCODE table.
appl.VOC. Stores the information necessary to update the current account
and any associated REMOTE accounts. Written to RFSPECS for use at
runtime.
Trans-Application Files
In addition to the suite of application files, every Envision-based application
requires trans-application files. Parameters which affect every Envision-based
application are stored in files shared by all applications. The files shared
among applications, called trans-application files, are listed below:
APPL.CTL
DEVICES
RFSPECS
STRATEGIES
SYSDEFS
UFSPECS
encoded and written to the associated RFSPECS record for the file in
question. Transaction logging and user-specified indexing are two of the
parameters defined in UFSPECS and written to RFSPECS at runtime.
The trans-application files and tree-read application files have the greatest
impact on the set-up procedures defined in this chapter. A device definition
exists regardless of application. An operator record may exist, not in the
current application, but in an application several layers higher in the
application tree. A security class may be defined at a higher-level application,
but redefined to add further restrictions at a lower-level application.
Shared Files
Shared files are Envision files that Datatel provides some or none of the
records and you as the user control the contents of the file. For example,
consider the trans-application file SYSDEFS. Datatel provides certain records
which should not be changed, such as display tables and default keyboard
tables. Other records in SYSDEFS, such as TASKLIST and
ENVISION.PARAMETERS, are controlled completely by you, the system
administrator. Another example of a shared file is the application file MENU.
While Datatel provides default menu records which are refreshed for each
release, you can create your own menu records to customize your Envision-
based application.
Below is a list of the shared files. Do not change records provided by Datatel
in the files marked with an asterisk (*). Though you may add records to these
files, do not change existing records.
Protected Files
Protected file is the final category of Envision files. Protected files contain
records that affect the execution and generation of an Envision-based
application. Do not change the records in the following protected Envision
files:
CDD
DOC
ENV
FILE.SPECS
HELP
HELP.LONG
INSERTS
OBJ
PRCS.DEF
SOURCE
SUBROUTINES
Since these files are stored as a part of an Envision release, the records in each
file will be replaced when a new release is loaded and installed.
Note: While you may be able to change the values stored in the
records of these files, we strongly recommend you do not change any
records in these files without first consulting Datatel.
Setup
Setup
Introduction to Setup
This section defines tasks that must be accomplished before the Colleague
software can run at your site. In addition, guidelines for optional custom tasks
are provided.
Procedures for printing and directing Colleague print jobs are also outlined, as
well as instructions for running a job in background mode.
Finally, conversion guidelines are provided for sites writing their own
conversions and sites contracting Datatel to write the conversions.
Worksheets to assist with some of the setup tasks can be found in “System
Setup Worksheets” beginning on page 295.
In This Chapter
This chapter contains detailed information about the Envision Parameters Edit
(EPED) process. Discussion of parameter records pertaining to the modules
within an application may be found in the application administration guides.
Note that changing between modes 3 and 4 is only part of the reindexing
process. All the indexing specs must be defined in a way that works with the
selected option. For example, mode 3 requires a data storage file for each
index, and mode 4 requires a storage field for subroutine-based indices. Also,
in order to function properly, all indices must be rebuilt, using either UTBI or
UTBA, after changing this flag.
Note: The Oracle I/O Off flag is valid only in Oracle environments
Note: The Disable Full OCI flag is active only in Oracle environments.
Note: The SQL Select Off flag is valid only in Oracle environments.
Execute Log On
All executions of shell commands from within Envision programs, such as
record SELECTS, are performed through a central MIO routine,
S_MIO_EXECUTE. Enter Yes in the Execute Log On field to enable the
user to record a log of each unique operation. Records of the form
userid.EXECUTE.LOG are maintained in the HOLD file, where userid is the
user ID of the person running the process. The default for this field is “No”.
Numeric Precision
Enter in the Numeric Precision field the maximum number of decimal digits
(significant digits) to be used in numeric value calculations against variables.
For example, if you enter 4, then .9999 is not rounded; however, .99999 is
rounded to 1.0.
Subscription Enabled
Enter Yes in the Subscription Enabled field to enable DMI transaction
transmission. The default for this field is “No”.
If you enter “No”, then DMI_DISPATCH does not accept EDX transactions
from DMI, and returns an error message.
Set this field to “Yes” if your institution needs passive FTP to successfully run
ExpressLoad and other Envision processes that use FTP. Setting this field to Y
forces Envision processes that perform FTP (such as ExpressLoad) to include
the “passive” keyword in its script. This allows the client to initiate both the
data port and command port connections to the server.
Windows Clients
The standard Windows FTP client does not support passive FTP. To make
passive FTP fully functional with Windows, you must first install third-party
FTP client software on your server.
If you use Windows, set this field to “Yes” only if both of the following are
true:
You need passive FTP to run Envision FTP.
You have a Windows FTP client on your server that supports passive FTP.
Error Stamping
Enter Yes in the Error Stamping field if you want each program that
references a specific error message to be logged within that error record. This
can help track usage patterns for specific error messages. This field is
normally set to “No” because the error file is a shared resource at runtime and
is likely to be in an area of the system that is intended to be read-only.
UT Debug String
If you want to preload a value into the UT Debug String for every session,
enter it in the UT Debug String field.
The debug string controls the turning on of debug code in various processes.
Normally, no debug string is entered in the UT Debug String field on the
EPED form; thus, the debug string is empty at the beginning of each session.
You can use the UT Process Debug Activation (UTDB) form to set the debug
string manually for the current session only. If you enter a value in the UT
Debug String field on the EPED form, however, it will be loaded in every
session in the current account.
Note: The DMI Print Server IP/Port fields are used in Envision 4.7
only. In Release 18.0,you can set up a DMI listener with a print server
role as described in Implementing Stylesheet Printing available on the
Datatel Web site.
In This Chapter
Validation codes are used in Envision to:
Limit the valid responses a user has for data entry
Make standard the values for certain data elements
Code Files
Code files are used when, in addition to the description of the code, you need
to store more information. The first field in each record contains the
description of the code. The remaining fields in a record can be used to store
any information pertinent to the code.
For example, the file DORMS contains records keyed by a code, one code for
each dormitory. The first field in each record is the name of the dormitory
corresponding to the coded key. Other pertinent information stored in a
DORMS record might be total capacity and whether the dorm is co-ed. A
code file is specific to an Envision-based application and, therefore, would
have a separate form process within the application to maintain the records in
the code file.
Code Tables
Code tables, on the other hand, are stored in the application file
appl.VALCODES, where appl is the mnemonic for the application. Validation
code tables are maintained, regardless of the application, through the
Validation Code Maintenance (VAL) form. Each table can contain any
number of codes, which are stored in a multi-valued list. Each code has
associated with it four parameters:
The description of the code
With each application, Datatel delivers the validation tables required for that
application. In some cases, these tables cannot be modified by the user.
Usually, the tables, which you should not modify, have special processing
codes for certain code values. Processes within the application are dependent
on these processing codes and the tables are therefore defined by Datatel.
Most validation code tables, however, require custom values specific for each
customer. These tables require no special processing or special instructions on
how to fill in the special processing fields are included with the load
instructions for the application.
Tables defined and maintained by Datatel are restored each time a release is
installed. Tables that you define and maintain are not overwritten by the
release installation. If a given validation table or valcode table is missing for
an application, the release installation process will provide the default table.
Valcode tables are stored in the application file VALCODES and are subject
to tree reads.
Enter the code in the first field in each window group along with its
description and minimum entry string. The minimum entry string is the fewest
number of characters the user must enter in order for Envision Runtime to
recognize that string as a code. For example, if you have four codes defined in
your table (NORTH, SOUTH, EAST and WEST), the minimum entry strings
might be N, S, E, and W. Each code can have one minimum entry string, and
each minimum entry string must be unique. Unless you have specific
instructions telling you how to fill in the special processing fields, leave these
two window elements blank.
Next enter the maximum code size. This determines how many characters a
user can enter when a data element on a form uses this validation code table.
The user can enter fewer characters but cannot enter more characters than the
maximum.
Note: The maximum code length must be as long as the longest code
defined in the table. For example, if a code in the table is NORTH and
the maximum code length is 3, the user will not be able to enter that
code since it is 5 characters. The maximum code length is usually
used in conjunction with the zero fill numbers flag.
The zero fill flag determines if numeric codes in this table are front padded
with zeroes. The advantage of zero filling is that all numeric codes are the
same length, the maximum code length. If you wish to zero fill numeric codes
in this table, be sure to specify the zeroes in the maximum code length.
In This Chapter
This chapter describes how to modify your UNIX_CONTROL record in the
SYSDEFS file. To do this, use the UNIX_CONTROL Record Editing
(UCRE) form. The UCRE form eliminates the need to update the
UNIX_CONTROL record from the command line.
Form Used
Table 2 lists and describes the form used in this chapter.
UNIX_CONTROL_HP
UNIX_CONTROL_SUN
UNIX_CONTROL_LINUX
Although the UNIX_CONTROL record has 25 fields, only six of those fields
may need custom modification. This form gives you access to these six fields.
If you modify the UNIX_CONTROL record, you must log out of Colleague
for the changes to take effect.
Note: If you are on a Windows server, you cannot access this form.
If your server's operating system is not AIX, HP, SUN, or LINUX, you
will see a message that no template was found, and the template
values for the UNIX_CONTROL record will be blank.
NOMESSAGE Option
If you want to suppress confirmation messages, this field allows you to enable
Envision print routines to add the NOMESSAGE option to SETPTR
commands. Enter Yes if you want the system to issue confirmation messages
when output is sent to the printer; otherwise, enter No.
This field displays the template value for your UNIX_CONTROL record.
Host Type
This field allows you to view or update the value for the host type (suffix) of
the source template record for the UNIX_CONTROL record. For example, if
the source for the UNIX_CONTROL record is the UNIX_CONTROL_HP
template record, this field would contain the string “HP”. This field is used for
documentation purposes only.
This field displays the template value for your UNIX_CONTROL record.
Printer Subroutine
This field allows you to view or update the name of the printer subroutine that
identifies a routine to extract printer and form information. This name will
usually be similar to the following: S_platform _PRINT_INFO where
platform describes the type of UNIX (for example, LINUX or AIX).
The name of the subroutine you enter will be validated. You can use LookUp
to view a list of available subroutines.
This field displays the template value for your UNIX_CONTROL record.
Batch Subroutine
This field allows you to view or update the name of the batch subroutine that
identifies a routine to submit a job to a batch queue for later execution.
Currently, a job name, start time, queue name, and priority are used.
The name of the subroutine you enter will be validated. You can use LookUp
to view a list of available subroutines.
This field displays the template value for your UNIX_CONTROL record.
This field allows you to view or update the UniData command needed to set
the terminal characteristics before entering the Envision environment. This
command must set to half-duplex mode at a minimum, and remap or turn off
the erase and kill commands.
This field displays the template value for your UNIX_CONTROL record.
This field allows you to view or update the UNIX command string that will be
executed in a UniBasic program. The command returns a sorted, trimmed
string of UNIX process IDs (PIDs) — one for each instance of UniData that is
running a phantom process.
ps -aef | fgrep PHANTOM | fgrep -v fgrep | tr -s ' ' '\011' | cut -f3 | sort
ps -aux | fgrep PHANTOM | fgrep -v fgrep | tr -s ' ' '\011' | cut -f2 | sort
This field displays the template value for your UNIX_CONTROL record.
Step 1. From the Envision Runtime (UT) application, access the UNIX_CONTROL
Record Editing (UCRE) form.
Step 2. View or update the UNIX_CONTROL record. Refer to online help for more
information.
Printing
Application Software
Operating System
Refer to your operating system documentation for information about
configuring the printing on your operating system.
LPTR
The LPTR keyword appended to the end of a query language sentence sends a
query report to the printer. In UNIX the report will print at the default printer
lp0.
SETPTR
You can change the destination of the printer by issuing a SETPTR command.
The SETPTR command allows you to define the characteristics of your print
job. For example, you can specify the number of copies to print, the banner
page, page lengths, but most importantly the printer destination.
The SETPTR option that allows you to change the printer destination is the
FORM option. The syntax of the command is:
:SETPTR ,,,,,,FORM formname
Application Software
A default form name displays on the form and the user can accept it or change
it. If you change the defaults, the defaults return the next time the report is
run.
The defaults that display on the Change Peripheral Defaults form can be
changed permanently through the Peripheral Default (PDEF) form in
Runtime. Usually, the user changes just the default form name. The other
characteristics such as page widths and lengths should not be changed.
There are two options for printing routines, depending on how printers are
defined in Windows NT or Windows 2003/2008.
If all printers are defined on the same local server as Colleague, see “For
All Printers Defined On The Same Local Server as Colleague” immediately
below.
If you are using a network print server, see “For a Network Print Server”
beginning on page 79.
Note: You must exit the account completely and log back into it in
order to reset common with the new print routine.
The VALID.PRINTERS table is not delivered with the software, and must be
added. You can specify printers in the valcode table using the UNC format
(\\servername\printername) in order to make any printer on the network
accessible. Printers defined to Envision using UNC need not be defined to the
local NT server.
Make certain that the contents of the Code field and the Min Entry field are
identical in order to ensure that the print routines that handle printer validation
(I_PRINTERS_CONVERT in UT.INSERTS) will use the information you
have entered in the Special Processing field. If the Code field and the Min
Entry field do not match exactly, the value from the Min Entry field is used in
any SETPTR command and on the printer selection screen presented during
batch processing. This can result in an error message if the value in the Code
field is entered in a peripheral selection screen when the value in the Min
Entry field does not match it.
Note: Although PSFP is displayed at the top of the form, this is the
same form that will appear after any Envision form that runs a
procedure which allows execution in phantom mode. Note that it
“inherits” the mnemonic from its calling procedure.
Step 1. If the user enters “Yes” in the Execute in Background Mode field, the task will
run in background mode. The Background Execution Type field is enabled for
input.
If the user selects E(nvision Process Handler), the task is submitted to the
Envision Process Handler.
Step 3. When the Envision Process Handler is selected, the user can specify the date
and time of the first run and schedule subsequent runs, if any, for the task,
including a date to stop automatic scheduling.
Step 1. Enter the names of one or more custom paragraphs in the Process Paragraph
Names fields.
Step 2. Select a Process Handler queue for each paragraph in the Queue field. If no
queue is specified, the DEFAULT queue is automatically selected.
Step 3. The remaining fields allow you to specify the date that the process should be
run next and to schedule subsequent runs, if any, for the task, including a date
to stop automatic scheduling.
Modify the queue assignment and scheduling of any task that has been
submitted to the Process Handler.
The Processing Queue Names fields display the available queues. You can
add or edit queue names in these fields.
Step 3. In the Security Class Queues Queue field, enter one of the queue names
shown in the Processing Queue Names fields. The Security class Queues
Queue field is validated against the list of available queues in the Processing
Queue Names fields.
Whenever you submit a Batch or Report to the Process Handler, the task is
associated to the queue that corresponds to the security class associated with
the user ID. If there is more than one security class associated with the user
ID, the first one is used to assign the queue.
Whenever this user submits a Batch or Report to the Process Handler, the task
is associated to the assigned queue for the user ID without regard to security
classes.
If you enter stop dates and times, the Process Handler will stop submitting
tasks to the queue at that time. You can also specify suspend start and end
times if you want the Process Handler to stop submitting tasks between
certain times.
The header of the PRQM form displays the following two fields:
Process Handler COMO ID. The COMO ID associated with the Process
Handler.
PID. The operating system process ID for the Process Handler.
The Process Handler COMO ID is displayed so that its record in the _PH_
directory file can be analyzed, if needed. Also, the PID is displayed that
originally created the COMO file. See AnswerNet Support Solution page
6154 for information on troubleshooting with COMO files.
When starting any inactive queues on this form, the PRQM process will
populate the Expired Scheduled Processes window with any processes that
are beyond their stop (expire) date, but which were never invoked due to an
inactive queue. You must enter an action for the Process Handler to take for
each expired scheduled process.
Step 1. To specify global settings that apply to all queues, complete the fields in the
upper portion of the PRQM form.
Enter the date and time to start all queues in the Start All Queues on [date]
at [time] fields.
Enter the maximum number of concurrent tasks for all queues in the Max
for All Queues field. This maximum is enforced on each queue.
Step 2. To specify settings for an individual queue, complete the fields for that queue
in the lower portion of the PRQM form.
Enter the date and time to start the queue in the Start Date/time fields.
Enter the date and time to stop the queue in the Stop Date/time fields.
To have the processor stop submitting tasks to the queue for a specified
period of time, enter values in the Suspend Start and Suspend End Time
fields.
Note: You cannot set suspend start and suspend end times globally.
They must be set for individual queues.
Enter the maximum number of concurrent tasks for the queue in the
Maximum Processes field.
Step 3. The Process Paragraph Name field displays the names of scheduled processes
that have expired. These are processes with a stop date that has expired, but
which were never started due to an inactive queue.
In the Action field, select an action to perform on the expired process. The
following actions are available:
Run One Last Time. Use this action to run the expired process one last
time.
Cancel. Use this action to cancel the expired process.
Use the Reset Process Queue Handler (RSPH) processing form, shown in
Figure 12, to stop all queue processing and to reset the Process Handler.
The active queues and running tasks are displayed in informational fields.
Enter Yes in the Do you want to reset all Processing Queues field to reset
the Process Handler.
Enter No or leave the field blank if you do not want to reset the Process
Handler.
Note: If you want to view the same data that is shown on the RSPH
form without the option of resetting the Process Handler, use the
Running Processes (RPRI) inquiry form. For more information about
inquiry forms, see “Using Inquiry Forms” beginning on page 110.
All tasks that are currently running will continue to completion, no new tasks
are started, and the Process Handler is reset.
Managing Processes
Three forms allow you to schedule tasks:
The Outstanding Processes (OPRM) maintenance form, described in “The
Outstanding Processes (OPRM) Form” beginning on page 95
The My Processes (MYPR) maintenance form, described in “The My
Processes (MYPR) Form” beginning on page 102
The Process Scheduling (PRSC) maintenance form, described in “The
Process Scheduling (PRSC) Form” beginning on page 100
The Process Paragraph Name, Sched, Submit Date and Submit Time fields are
informational, and cannot be edited on the OPRM form. You must detail to
the Process Scheduling (PHTS) form to edit individual process schedules.
The processes run in the order shown on the list, subject to eligibility
conditions. If a task is ineligible to run for any reason, the Process Handler
moves to the next task. In order for a task to be eligible to run, the following
conditions must be met:
Step 2. The specified queue must contain fewer than the maximum allowed number
of concurrent processes.
Step 3. The current date and time must be later than or equal to the next run scheduled
date and time.
Use the Move Process From Position/to Position fields to reorder the
processes in the list. You can change the queue assignment of a process by
selecting the desired queue in the Queue field.
Note: To view the data that is displayed on the OPRM form without
the option of editing it, use the Outstanding Processes (OPRI) inquiry
form. For more information about inquiry forms, see “Using Inquiry
Forms” beginning on page 110.
To edit the scheduling of a task shown on the OPRM form, detail from the
selected task to the Process Scheduling (PHTS) form, as shown in Figure 14.
Step 1. Use the Schedule Process to Run Next on fields to set the date and time you
want a task to run.
If the task is to run only once, you can leave the remaining fields blank. A
once-only process is termed unscheduled, and “No” is displayed in the Sched
field for the process on the OPRM form.
Enter Yes in the Schedule Process on Weekdays Only field to restrict the
runs to weekdays, or enter No to allow runs on Saturdays and Sundays.
Enter a time, using military (24-hour) format, or A and P to specify AM and
PM, for the runs to begin. Use this field only if the frequency is set to
Second, Minute, or Hour.
If you want scheduling to end on a specific date, enter the date in the Stop
Automatically Scheduling Process on field.
Handler (RSPH) form and restarted on the PRQM form. And you will again
have to make sure to set the Maximum Processes column to a value greater
than 1.
The Date, Time, Int, Frequency and Weekday fields are informational, and
cannot be edited on the PRSC form. You must detail to the Process
Scheduling (PHTS) form to edit individual process schedules.
To edit the scheduling of a task shown on the PRSC form, detail from the
selected task to the Process Scheduling (PHTS) form, as shown in Figure 17.
For information about using the PHTS form to edit a process schedule, see
“The Process Scheduling (PHTS) Form” beginning on page 98.
All processes for the user ID, both scheduled and unscheduled, are shown on
the MYPR form. When an unscheduled process runs to completion, its entry
is removed from the MYPR form. See the note on page 96 for the definitions
of scheduled and unscheduled processes.
The fields on the MYPR form are informational, and cannot be edited. To edit
individual process schedules, you must detail from the Mnemonic field to the
Process Scheduling (PHTS) form.
To edit the scheduling of a task shown on the MYPR form, detail from the
selected task to the Process Scheduling (PHTS) form, as shown in Figure 19.
For information about using the PHTS form to edit a process schedule, see
“The Process Scheduling (PHTS) Form” beginning on page 98.
Use the Process Status Report (PSTR) reporting form, described in “The
Process Status Report (PSTR) Form” beginning on page 105, to generate a
report showing completed processes.
Use the Process Status File Purge (PSFP) processing form, described in “The
Process Status File Purge (PSFP) Form” beginning on page 108, to purge
records from the Process Status file.
This form also allows you to generate a report for just the most recent runs of
all processes scheduled for the Envision Process Handler. When you choose
this option, the start and end date fields are inquiry only.
Step 1. In the Start Date field, enter the start date for selecting processes.
Processes are shown on this report only if they began on or after this start
date. However, a process may have been run one time, or may have been
repeated through the Envision Process Handler. If a process had repeated
runs, this report will show only those instances that began on or after this start
date.
Note: This field is a display only field if you set the Report Only Most
Recent Run field to "Yes."
Step 2. In the End Date field, enter an end date for selecting processes.
Processes are shown on this report only if they completed before or on this
end date. However, a process may have been run one time, or may have been
repeated through the Envision Process Handler. If a process had repeated
runs, this report will show only those instances that completed before or on
this end date.
Note: This field is a display only field if you set the Report Only Most
Recent Run field to "Yes."
Note: If the Start Date field is left blank, all records in the Process
Status file with start dates up to the date specified in the End Date field
are included in the report, subject to your selection criteria.
If the End Date field is left blank, all records in the Process Status file
with start dates on or after the date specified in the Start Date field are
included in the report, subject to selection criteria.
If both fields are left blank, all records in the Process Status file are
included in the report, subject to your selection criteria.
Step 3. In the User IDs field, enter User IDs for selecting processes. The User IDs
you enter will limit selection to only those processes that were submitted by
these User IDs.
Step 4. In the Mnemonics field, enter the mnemonics for selecting processes. The
mnemonics you enter will limit selection to only those processes that were
executed from these mnemonics.
Step 5. In the Report Only Most Recent Run field, enter Yes to report only the most
recent run of repeat processes.
A process may have been run one time, or may have been repeated through
the Envision Process Handler. If a process had repeated runs and this field is
set to “Yes,” this report will show only the most recent run of each process.
Processes that were run only once will also be displayed on the report,
provided they satisfy any criteria based on User ID, mnemonic, and additional
selection criteria. If you enter “Yes” in this field, the Start Date and End Date
fields will be inquiry only.
Yes. Enter Yes in the Additional Selection Criteria field. The Additional
Selection Criteria form is displayed, as shown in Figure 21. Use the
Add’l Connective, Field Name, Relation and Parameter/Value fields to
select additional criteria.
Figure 21: Process Status Report (PSTR) Addl Selection Criteria Form
Step 7. Update to the Process Submission form, as shown in Figure 8 on page 84, and
specify how you want the report to be printed or displayed.
Step 1. In the Start Date field, enter the start date from which to purge records. Only
processes run through the Envision Process Handler that started on or after
this date will be selected.
Step 2. In the End Date field, enter the end date from which to purge records. Only
processes run through the Envision Process Handler that ended before or on
this date will be selected.
Note: If the Start Date field is left blank, all records with start dates up
to the date specified in the End Date field are purged, subject to your
selection criteria.
If the End Date field is left blank, all records with start dates on or after
the date specified in the Start Date field are purged, subject to your
selection criteria.
If both fields are left blank, all records are purged, subject to your
selection criteria.
Step 3. In the User IDs field, enter the User IDs associated with the records to be
purged. Only those records submitted by these User IDs will be purged.
Step 4. In the Mnemonics field, enter the mnemonics to be purged. Only those
records executed from these mnemonics will be purged.
Yes. Enter Yes in the Additional Selection Criteria field. The Additional
Selection Criteria form is displayed, as shown in Figure 21 on
page 107. Use the Add’l Connective, Field Name, Relation and
Parameter/Value fields to select additional criteria.
Step 6. Update to the Process Submission form, as shown in Figure 8 on page 84, and
specify how you want the PSFP process to be run.
Use the Outstanding Processes (OPRI) inquiry form, as shown in Figure 23,
to view the available queues and their assigned tasks without the option of
editing the data.
Note: Use the Outstanding Processes (OPRM) form if you want to edit
the data shown in the OPRI form. See “The Outstanding Processes
(OPRM) Form” beginning on page 95 for more information.
Use the Running Processes (RPRI) inquiry form, as shown in Figure 24, to
view the active queues and running processes without the option of resetting
the queues.
Note: Use the Reset Process Queue Handler (RSPH) form if you
want to reset the active queues. For more information, see “The Reset
Process Queue Handler (RSPH) Form” beginning on page 94.
Customizing an Application
Features
As a part of your setup procedures, you have the option to customize several
aspects of your software and system. Procedures are provided for customizing
the following:
Header Blocks
Resolution Forms
Envision Menus
Standard Forms
Header Blocks
In Envision-based software, the header block is the set of fields at the top of
the form, above the double horizontal line. The fields in the header block
display information about the application and process with which you are
working. Standard header blocks are provided for Runtime and each Envision
application. The Runtime header blocks cannot be changed; however, the
header blocks can be changed within each application and must be set up for
the Correspondence Control module since a standard is not provided.
To change a header block, enter the application. Enter the Header Block
Definition (PHD) form. Specific options are provided within the form. See the
application administration guides for details.
Resolution Forms
A resolution form is a form that displays a list of all available items from
which you may select one or one of the items with which to work. Many
Envision-based applications use resolution forms. For example, if you enter
[[...]] in response to the Menu ID LookUp prompt on the Menu Definition
(SMD) form, Envision displays a list of all available Menu IDs. It may also
display certain characteristics about the records. We provide a default
characteristics which you can change by application.
Step 3. At the Resolution LookUp prompt, enter the primary file that the LookUp
process uses. To assist you in entering the remaining information, you may
want to get a hard copy of the dictionary of the primary file:
LIST DICT primaryfile LPTR
Step 4. To add the new specifications, detail on Set Defaults and Resolution
Specifications.
As system administrator, you may change the menus delivered with your
application or you can create new ones. Since the MENU file is a shared file,
any changes you make to a Datatel-defined menu will be overwritten the next
time you install a release. The release installation, of course, will not affect
the menus you have created.
Step 1. Enter the application for which you are defining the menu.
Step 2. Run the SMD form and enter a unique mnemonic for the new menu.
Valid process mnemonics are those mnemonics for which a Process Control
(PRCS.CTL) record is defined. The application file PRCS.CTL stores all the
mnemonics which are executable by the Envision Menu Processor, as well as
other records used by Envision Runtime. You can add new PRCS.CTL
records from the SMD form, or you can use the Process Control Maintenance
(PCM) form.
Define process control records for procedures, reports and Easy Screens so
that these processes can be run from a menu. Remember that mnemonics
cannot exceed four characters in length.
Step 2. Enter the application sub.appl and run the SMD form.
Step 3. Add any valid process mnemonics or menu mnemonics to your new menu or
delete existing mnemonics to customize the menu for your site.
Because you are defining the custom menu in your own subordinate
application, the new mnemonics for the menu can be the same as the model.
Just remember that calls to Response Line will be much easier if you define
unique mnemonics and avoid redefining mnemonics used in Datatel-defined
application.
If the program has the suffix -VER2 or .STD then change the name of the
program to the Colleague standard name.
Step 5. Determine if the program requires a catalog VOC record. If so, catalog the
program. In UniData, the program should be cataloged locally until it is
thoroughly tested.
Grouping Screens
Chaining Screens
You can group, or chain, Envision screens to handle a specific workflow. The
following are the key concepts related to screen chains. These are covered in
more detail in the remainder of this chapter.
Not all Datatel screens function properly in a screen chain. In general, Datatel
advises against using this feature.
You assign a unique mnemonic to each chain you define, and you may add
this mnemonic to any menu.
You may include up to 16 screens in a chain.
You may chain only true screens; that is, individual screens used for data
entry or inquiry.
You may not include procedure front-end screens, procedures, batch
processes, or other chains in a chain. In general, you can recognize
Envision procedures by the fact that they are usually listed on menus in the
Processing or Reporting quadrants; batch processes never appear on menus.
You can make individual screens within a chain required. If the user
bypasses required screens while working within a chain, those screens are
automatically displayed before the user can completely finish with the
chain.
You may specify a subroutine to be run after the user has finished with a
chain.
Chains are application-specific; that is, you define them from within the
application in which you want them used and in which the screens you want
to include are accessible.
When the user enters the chain mnemonic, the first screen in the chain is
displayed.
Each screen in a chain is displayed with the same screen title and
mnemonic that would be displayed if the screen were accessed directly
from the menu prompt.
The user’s work is saved only after the users finishes with the entire chain;
that is, the user’s work is not saved as the user moves from screen to screen
within the chain.
All screens within a chain take on the security rights specified for the chain.
The screens you include in a chain continue to be accessible individually, in
the normal way, unless you change your security class definitions to
prevent this.
The most seamless chain of screens is one where each screen would otherwise
prompt the user for the same thing. For example, in the Demographics
module, in the Core System, the following all prompt the user for a person ID:
Name and Address Maintenance (NAE)
Relation Information (REL)
If you were to chain these screens in the order shown above, the Person
LookUp prompt would be displayed, prompting the user for a person ID,
when the chain was accessed and the Name and Address Maintenance form
was displayed. When the user finished the Name and Address Maintenance
form, the Relation Information form would be displayed for the same person
with no further prompting, and when the user finished the Relation
Information form, the Emergency Information form would be displayed for
the same person without further prompting.
If you chain screens that would otherwise prompt the user for different things,
then the appropriate prompts are displayed when each screen is displayed.
You can, therefore, chain screens that are totally unrelated.
To restrict access to the SCSP form, Datatel has included it in the privileged
list in the ADMIN security class in UT, which includes screens that are
usually restricted to the system administrator.
If you go forward while the last screen in the chain is displayed, the system responds as if you
had Finished.
If you go back while the first screen in the chain is displayed, the system responds with a
beep.
JUMP Displays a mini-menu of all screens in the chain, from which you can select the screen you
want to display.
Field JUMP to make changes, cancel to discard changes to this screen only
Field JUMP to return to the screen without cancelling or cancel if you do no want to save the
work you have done on the current screen.
If you cancel the second time, your work on the current screen is discarded and you are asked
to further confirm the cancellation:
RETURN to redisplay the current screen with the original data or cancel to discard all changes
made on all screens in the chain. If you cancel this time, the first screen in the chain is
redisplayed and you are prompted for a new record ID.
Direct Invokes another screen from the current screen without returning to the menu. If the current
ACCESS screen has a LookUp prompt, you must respond to the prompt before pressing this key.
To save any changes you might have made and continue, press Enter. The following prompt is
then displayed:
Once you have accessed a chain, you may access only screens within that chain. You cannot
jump out of a chain using Direct ACCESS. Although you can move from screen to screen
within a chain using Direct ACCESS, it may be easier to move around within a chain using the
screen movement keys. See Table 3 on page 123 for further information on screen movement
keys.
Field JUMP to make changes, RETURN to confirm, cancel to abort this screen.
Field JUMP to return to the screen without cancelling, RETURN to save your work and exit to
the menu, or CANCEL if you do no want to save the work you have done on the current
screen.
If the chain includes required screens and if you EXIT before you have displayed the required
screens, each required screen is displayed before you return to the menu.
FINISH Exits from the current screen and returns you to the menu from which the chain was
accessed. If you used Direct ACCESS to access the chain, you are returned to the screen you
were on when you pressed Direct ACCESS.
Field JUMP to make changes, RETURN to confirm, CANCEL to abort this screen.
Field JUMP to return to the screen without cancelling, RETURN to save your work and return
to the menu or direct access screen, or CANCEL if you do no want to save the work you have
done on the current screen.
If the chain includes required screens and if you FINISH before you have displayed the
required screens, each required screen is displayed before you return to the menu or the
direct access screen.
UPDATE Exits from the current record, redisplays the first screen in the chain, and prompts for a new
record ID.
Field JUMP to make changes, RETURN to confirm, CANCEL to abort this screen.
Field JUMP to return to the screen without updating, RETURN to save your work and return to
the first screen in the chain, or CANCEL if you do no want to save the work you have done on
the current screen.
If the chain includes required screens and if you UPDATE before you have displayed the
required screens, each required screen is displayed before you return to the first screen in the
chain.
Short Help Provides a one-line message further describing the chain. The Optional
Message user can display this message by typing the chain mnemonic at a
menu prompt and accessing Process Help.
Long Help Text Provides a longer message describing the chain. The user can Optional
display this message by typing the chain mnemonic at a menu
prompt and accessing Process Help. If the chain has short help,
the short help message is displayed first. When the user Returns
after viewing the short help, the long help is displayed. If the chain
does not have short help, the long help is displayed immediately
after the user accessing Process Help.
Require Determines whether the user must display the screen before Optional
finishing with the chain. The default is No. See Table 4 on
page 124 for a description of what happens when there are
required screens in a chain.
Post-Commit Specifies the name of the subroutine that will be run after the user Optional
Subroutine has confirmed that her work should be saved. The specified
subroutine is run after all error checks are done and the records
used in the chain have been written to disk.
Step 2. Access the application in which you wish to define the chain. The
application’s main menu is displayed.
Step 4. Enter the chain mnemonic at the Chain Process LookUp prompt. The
following prompt is displayed:
Record not found -- Enter (A) to add or RETURN to
reenter
Step 5. Enter A at the prompt. The cursor moves to the Description field. Notice that
the code entered at the LookUp prompt is displayed in the header.
Step 6. Complete this form, using the field definitions in Table 5 on page 126 as a
guideline.
Step 7. FINISH to save your work and return to the menu. The screen chain is
immediately accessible to users unless you are using “Do Only These”
security. Continue with Step 8 if your security classes are set up as “Do Only
These.”
Step 8. Create a new security class containing the chain mnemonic or add the chain
mnemonic to an existing security class. If you create a new security class,
then add that security class to the appropriate users’ operator records.
See “Security and Chaining” on page 122 for a discussion of special security
issues with respect to screen chains.
See the documentation for the Security Class Definition (SCD) form for
information on defining security classes. See the documentation for the
Operator Definition (SOD) form for information on defining operator records.
If you created a new security class, then the chain is accessible to your users
after you have added that security class to their operator records.
If you added the chain to an existing security class, the chain is accessible to
your users as soon as you complete the update of the security class definition.
Security
Security
Security Overview
Introduction
The Security section of Runtime Administration contains the information you
need to secure Colleague programs, files, and data from unauthorized access.
Presented in the chapters are guidelines for operating system security,
securing the DBMS, and procedures for creating user remote accounts. Full
information for establishing process, record, and field security is also
provided. Worksheets to assist with the security setup are in “System Setup
Worksheets” beginning on page 295. There are three levels of security on the
system:
Operating System
Your application software combines the three levels, with an emphasis on the
Database Management System and Application Software, to create a secure
system for your site.
Logging In
When logging into the system, a user passes through the operating system, to
the data base management system, and to the application software. In detail,
the user goes through the following steps:
UNIX
Step 2. In your home directory, the following files, .login and .cshrc, are run if you
are executing the C SHELL. If you are executing the BOURNE SHELL then,
.profile is run.
ALERT! The .login and .cshrc files must be present in your home
directory.
The .cshrc is run first and then the .login file. There are many uses for these
files for a user that has access to UNIX. For an application software user, the
files are used to move the user to their user remote account and to invoke
UniData with the “exec” command.
The exec command is used with the udt command to prevent users from
entering UNIX upon logging out of UniData. When you precede a command
with exec, it tells the system to run only this process. When the user leaves
UniData, he has no other processes to run and is logged off of the system.
Step 3. On entering UniData at the user remote account, the system looks for a
LOGIN paragraph in the VOC file. For the UniData user, the paragraph must
contain ENV.INIT. You can customize the paragraph to bring up the
application menu.
Windows 2003/2008
Step 2. You are directed to the UniData account you last accessed, or prompted for
the path of the account you wish to access, depending on the way you are set
up in UniData.
Step 3. Upon entering UniData at the user remote account, the system looks for a
LOGIN paragraph in the VOC file. For the UniData user, the paragraph must
Step 1. Once the Device is established, the outermost layers of Envision Security
become active. Each device may potentially have a password and security
class associated with it. If a password is active, you are prompted for it. If a
security class is associated with it, it becomes active.
Step 2. The rest of Envision Runtime Security becomes active when you enter the
application.
Step 3. Envision looks for an OPERS record keyed by your login ID in each
application in your application tree. If an OPERS record is not found,
Envision informs you that you are not a valid user and runs LO.
Step 4. If your OPERS record is found, Envision Runtime uses the user definition
supplied by that record. In that record, an additional Envision password may
be defined. Envision Runtime prompts you for your Envision password. You
must correctly enter this password or Envision Runtime runs LO.
Step 5. To determine the application processes to which you have access, Envision
Runtime examines all of the security classes defined for you, taking into
consideration both device and operator security classes. Envision Runtime
starts with the “Do Only These” lists of processes. If any of the security
classes defined has a “Do Only These” list, that list becomes the global list of
processes to which you have access. If more than one security class has a “Do
Only These” list, the lists are combined, and the union of the several “Do
Only These” lists become the global access list for you. If none of the security
classes defined for the operator or the device has a “Do Only These” list, you
currently have access to every process in the current application and every
process in the applications above the current one in the application tree.
Step 6. Once the global access list has been defined, Envision Runtime then examines
the “Never Do These” lists for each security class. These processes are
removed from the global access list. If more than one security class has a
“Never Do These” list of processes, the lists are combined, and each process
in the union of the lists is removed from the global access list.
Step 7. Next, Envision Runtime checks to determine if any of the processes in the
global access list is defined as privileged in another class. If a process is
privileged, you must have the privileged class defined for him or the
privileged process is removed from the global access list. If a privileged
process is defined as privileged in more than one class, you must have at least
one of the privileged classes.
Step 8. Finally, Envision Runtime flags those processes listed in the “Inquiry Only”
list so that you may view but not add to or alter the data maintained in that
process. If more than one of your security classes has an “Inquiry Only” list,
then the lists are combined, and the processes in the union are flagged as
inquiry processes.
Step 9. Envision Runtime also sets up your record security characteristics. These
characteristics are used to evaluate selection criteria defined for a file. Values
for specific fields within a file are compared to selected user characteristics to
determine whether a user has access to a record from the file. If your
characteristics do not match the specified value in the record, your access to
that record is limited according to the record security specification.
Step 10. Envision Runtime then determines the process you can run first. The SOD
form allows you to define the initial application process to run. Since your
OPERS record comes from UT, this initial process should come from the UT
application. You can, however, make the initial process the main application
menu by specifying your initial process is an asterisk (*). Envision Runtime
then uses the main menu from the current application as the initial application
process. In this case, the user ADMIN is presented with the main menu for the
application XCF.
Logging Off
When the user logs off, the system looks for the paragraph LOGOUT and runs
it if it exists.
Within the operating system, you have two security areas to address:
Setting Up Login IDs and Passwords for Users
A login ID and password are required to gain access to the host system. Each
operating system provides different utilities for setting up IDs and passwords
for users. In general, these utilities establish the following information about
each user:
Login Id
Password
These utilities provide methods for adding, deleting, and modifying users’
login IDs and other user attributes.
Complete Restriction
Complete restriction from the database management system allows a user to
enter the application software that is applicable to the user’s job. When the
user logs in, only the menu options that the user is allowed to access appear on
the user’s menu.
Step 1. Create a user remote account. Log the user directory into this account.
Step 2. In the login paragraph of the remote account, enter the application or the
module from which the user will perform the user’s job. Enter LO as the last
line in the paragraph to prevent the user from entering the DBMS level.
Step 3. Assign a security class to a user that allows the user to run LO but not EX. EX
allows access to the DBMS level.
Limited Restriction
Limited restriction to the database management system allows a user to enter
the application software that is applicable to the user’s job and some level of
access to the Query language. Within the application software, there are two
processes that allow this:
Sequential File BROWSE Shell (UTFB) process
If neither one of these options will work for your user, you could create a
separate user remote account for the end user to log in to. This account would
contain only the Query language commands necessary to perform the user’s
job function and the limited files that you want the user to access with the
query language. However, you may want to consider limiting this method
since it could potentially create a multitude of accounts requiring
maintenance.
Step 1. Assign the user a security class that contains the mnemonic UTFB.
Step 2. Define the directories that the user is allowed to access through the BROWSE
File Authorization (UTFA) process in UT. These might include:
Command logs
Documentation directories
Word processing directories
If you do not define any directories, the user will be able to access the HOLD
directory only, which contains generated reports.
Locate a file directory to browse. The default system file is the Printer Hold
File. In most data screens, the LookUp prompt allows you to enter a value that
matches the key field value of a record in your database. The key field
contains a field value that uniquely identifies a record.
Public file security sends the output to the HOLD file, only using the default
security associated with the person creating the output. Public file security
means that the output can be viewed by anyone.
Note: In order to write, transfer, and delete PDF files for report
processes, permissions on private and shared _HOLD_ directories
allow access to the DMI listener. On Windows servers, this equates to
granting the SYSTEM user full access to these directories (because
DMI runs as a service). On UNIX and Linux servers, this translates to
granting global write access to these directories. (Read access
remains the same.)
Envision
4.8 only
Step 1. Use the Directory File Name LookUp to locate an existing file directory to
browse. The default is the Printer Hold File. In most data screens, the LookUp
prompt allows you to enter a value that matches the key field value of a record
in your database.
Step 3. Locate existing items that exist in the file directory to browse.
The name of the group will also be used in constructing the path to the HOLD
file subdirectory that contains the output files. The path will consist of a
subdirectory called SHARED within the HOLD file containing a further
subdirectory by the name of the group (containing the actual secured output
files). In addition, a VOC pointer named HOLD.SHARED.groupname will be
created, where groupname is the name of the group.
Provide a key indentifier for the hold shared security groups. This key will be
used for LookUp in places where shared hold security must be specified.
Associated with this identifier is a description, and also the operating specific
equivalent that will be issued to secure any files that are created using this
group.
Application Security
Types of Security
Envision Runtime security is based on the premise that what the end user sees
is what the user is allowed to use. Any menu, process, record or field for
which an end user has no security is never available as an option for that user
while in the Envision environment. Security in Envision is defined in three
layers:
Process Security
Record Security
Field Security
Each person that is to access the application must have an operator definition
record or OPERS record. The security class is then assigned to the individual
through the OPERS record.
Record and Field security allow you to secure certain records and even certain
fields from a user. Record and Field Security are covered in the last two
chapters of this section.
Security Classes
Security classes are structured after the work-flows of the application users.
For example, data entry clerks are allowed to use processes that allow data
entry. Office managers have a wider set of responsibilities and therefore have
fewer restrictions. There are also certain processes which only you as system
administrator should be able to run.
One of the system files for which Envision uses in tree reads is the security
class definition file called appl.SECLASS, where appl is the mnemonic for an
application. Consider, then, a security class called ADMIN.
Detail Forms in UI
In UI, when users detail from one form to another, they have the same access
rights to the detail form that they had on the form from which they detailed.
For example, if the user is currently in a form to which the user has only
inquiry-only rights, then all detail forms are also inquiry-only for the user. If
you want to change the security level when a user details, access rights to any
detail forms must be explicitly defined for the user. For example, the
following user has only one security class assigned, and it has the following
setup:
DO.ONLY.THESE: NAE
This user has full access rights to the Name and Address Entry (NAE) form
and to all forms to which the user can detail, either directly or indirectly. The
user could detail from the NAE form to the BIO form, and from there to the
Foreign Person Information (FINF) form, and have full access rights (be able
to change data) on any of those three forms.
Then when the user details from the NAE form to the BIO form, the user has
inquiry-only access. If the user then details from the BIO form to the FINF
form, the user is restricted to inquiry-only rights.
Note: Note that restricting the access of a user to a menu does not
restrict each process on that menu; you must restrict each process as
well.
On SCD, you can limit the range of processes that a class of users can run (Do
Only These), you can restrict a class of users from executing a list of processes
(Never Do These), you can restrict a class of users from modifying the data for
a list of processes (Inquiry Only), or you can restrict a list of processes to only
one class (Privileged).
Envision Runtime then removes any processes in the Never Do These process
list from the global list. If the restricted list is not defined, the global list
remains as is.
Any processes defined in the Inquiry Only process list are left in the global
list, but are flagged so that this class of users may not modify data maintained
on the processes in the inquiry list.
Finally, Envision Runtime verifies that each process in the current global list
is not defined as a Privileged process in another class. Privileged processes
are removed from the user’s list. If a user is in a class that has access to a
privileged process, that process will remain in the global list. If the process is
privileged in more than one class, the user must be a member of at least one
class for which the process is privileged in order to have access to the process.
The final list of processes defines those processes that a user may access. This
global list remains in effect until the user logs off of the system or until the
user leaves the database environment.
Step 1. With the department manager, determine the classifications for your end users
by job function. For example, data entry, managerial, or computer center staff.
Step 3. To add a new security class, enter the Security Class Definition (SCD) form
from UT. Fill in the appropriate fields according to your worksheet.
Step 4. Add the security class to the appropriate opers records through SOD.
Remember, you can assign the same security class to several opers records.
Operator Definition
Each person that is to access an application must have an Operator Definition
record. The record is stored in the application file OPERS. Each application
has its own OPERS file. The ID of the opers record should correspond to the
login ID of the person. If a login ID is shared, then the opers record will also
be shared. We recommend that each person have their own login ID.
The application file OPERS is subject to tree reads. Every operator does not
need an OPERS record in each application to which the operator has access. If
Envision Runtime does not find an operator definition in the current
application’s OPERS file then it will read the OPERS file in each of the
applications in the current tree. If an OPERS record is not found after
traversing the tree, then the operator is assumed to be unauthorized and is
logged out.
Envision Password
Security Classes
Use the Operator Definition (SOD) form to define operator records for all
individuals who are allowed access to Envision-based applications. Before
you define operator records, first define security classes in each application
using the Security Class Definition (SCD) form.
Step 2. The OPERS record ID must be the same as the operating system login ID.
Step 4. To add a new OPERS record, enter the system Operator Definition (SOD)
form in UT. Define the following fields:
User ID
Name (required)
Initial menu
Envision Password
Password Expiration Date
Security Classes
Maximum Login Retries
Step 5. Test the record. Log the user in to the system and access the application
software.
Step 1. Determine the application OPERS file that the obsolete operator definition
resides in.
Step 3. Run the Envision Runtime System Operator Definition (SOD) form.
Step 5. Press the [RECORD DELETE] key. Envision Runtime prompts you to press
the [RECORD DELETE] key a second time to confirm.
Step 6. Press [RETURN] at the final prompt to delete the operator definition from the
application’s OPERS file.
Step 7. Make sure to remove the user’s login privileges at the operating system level
to ensure the user can no longer access your system.
Use the PCSI form to inquire about the security classes that currently affect
the selected process. If a security class restricts a process, end users in that
class are unable to run or even see the process on a menu. End users can only
run the processes that their security classes allow.
The Access Only fields show the list of security classes that have exclusive
(privileged) rights to use the process. If a user does not belong to one of the
listed classes, the user cannot run the process.
The Inquiry Only fields show the list of security classes that may only use
the process in inquiry mode. Users belonging to any class in this list can view
the data, but cannot change it.
Technical Tip: This list is derived from the application’s SECLASS file.
The Denial field shows the security classes which are not permitted to view or
edit the contents of the selected field.
The Access field shows the security classes that have read/write access to the
selected field.
The Inquiry field shows the security classes that have read-only access to the
selected field. Users in these classes can view the contents of the selected
field, but cannot change it.
The No Change field shows the security classes that are not permitted to
change the contents of the selected field.
The No Delete field shows the security classes that are not permitted to delete
the selected field.
Lists all the security classes that reference this process, and identifies the
manner in which they reference it.
Lists all the Access Points related to the process (that is, from where can this
process be accessed, and to what other forms does it allow access?). This
contains several subsections:
Subsection 1: MENUS - Menus on which this process appears.
Subsection 2: Forms FROM - Forms that detail to this process.
This includes all forms that are either directly or indirectly accessible, starting
from the primary form.
Note: The list of forms shown in the Forms FROM and Forms TO
subsections may be larger than is possible at your institution. This is
true because a call to a detail form is often executed conditionally, and
it may be that the conditions that allow it to be executed will never
occur.
For example, the call statement may be in a block of code shared by many
forms (for example, in an insert file, or in hook code of a demanded CDD
element), and the conditions that allow it to execute might occur only in some
of those forms. Another possibility is that the conditions that allow it to
execute may depend on environment parameters (For example, it may depend
on the list of modules your institution has licensed, or how your system
parameters are set up).
If you specify that you want to see access rights for certain users, this section
lists all the security classes associated with the users, and displays the type of
access the users have (No access, Full access, Inquiry only, etc.) for the
process being reported on.
Process
DMSU22
In the “Show User Access Rights for” field, select one of the following
options if you want to include a “User Access Rights” section on the report:
All Users. Displays access rights for all users.
Users with Access. Displays access rights for all users with access.
Selected Users. Displays access rights for only the users you specify.
You can also select No Users to exclude the “User Access Rights” section
from the report.
User
If the “Show User Access Rights for” field has been set to Selected Users, use
this field to limit the report to show access rights for only those users you
specify.
Step 2. In the Process field, enter the form or procedure for which you want
information.
Step 3. In the “Show User Access Rights for” field, select the option for this report. If
you choose Selected Users, continue with Step 4; otherwise, skip to Step 5.
Step 4. In the User field, specify the users for whom you want to access rights to be
displayed on this report.
Appln Menu
------ --------------------------------------------------------------------------
ST CR - Cash Receipts
Access Points, Subsection 2: Forms FROM (forms that can detail to CSRP)
Appln Form
------ --------------------------------------------------------------------------
< none >
Access Points, Subsection 3: Forms TO (forms that CSRP can detail to)
---------------------------------------------------------------------------------
< none >
Security Layers
Record and field security are two additional layers of security available in
Envision-based software. They add a layer of complexity to your system so it
is best to keep the setup as simple as possible. Processes that are programmed
in Envision are currently the only processes that use record and field security.
Record Security
Envision Runtime’s Record Security allows you to limit the access to a class
of records in a file. Within the records that you wish to secure, there is usually
a value or values which either uniquely define the record or place the record
in a selected subset that includes records with the same value or values. For
example, a file called EMPLOYEES has a field called POSITION.CODE.
This field contains a value from a finite set of position codes. This field can be
used to break the records in the file into subsets, where each subset of records
has the same POSITION.CODE value.
User Characteristics
Record Security in Envision is based on defining user characteristics. Each
user characteristics is named and has associated with it an algorithm for
determining a value. The algorithm requires:
File name
Whenever a user tries to access a record in a file for which there is a record
security definition, Envision Runtime evaluates the definition against the
characteristics values to determine if the user can have access to the requested
record. A record security definition is comprised of selection-like criteria. For
example, the EMPLOYEES file has the following record security definition:
WITH POSITION.CODE EQ ACCESS.POS1 A
OR
POSITION.CODE EQ ACCESS.POS2 A
Step 1. Keep the number of records you secure to a minimum. Use field and/or
process security to keep users from seeing sensitive data if possible.
Step 2. For those cases that warrant or require record security, identify the field or
fields that can be used to classify records in the secured file into groups.
Usually status fields or code fields make the best candidates. Envision-based
files also have fields identifying the operator who created the record and the
operator who last changed the record. These fields are also good choices for
the security criteria comparison field.
Step 3. Store the values for the user characteristics in one file, if possible. As system
administrator, you can add an additional level of security to this file by
securing it from the operating system so that users may use or view the data in
the file but cannot change it.
Step 4. When specifying more than one security criteria for a security definition,
remember that the criteria are evaluated one at a time for single record access
and are concatenated when accessing more than one record. The highest
access calculated for a single record request is the access the user gets. When
more than one record is accessed, Envision Runtime performs a security
selection before the user even knows about the records available.
Step 5. Secured files can use fields from a co-file (the selection file) as the security
criteria comparison field.
Step 6. Changes to user characteristics do not take effect until Envision is re-
initialized.
Step 7. Changes to record security definitions do not take effect until Envision is re-
initialized.
The first field on the RSUC form is a window field in which you enter the
definition for each user characteristic. Begin by naming the user
characteristic. The name can be whatever meaningful string you want. For the
current example, enter “ACCESS.POS1”.
The next field in the window is the file from which to read the specified
record. This file must be defined as a file in the VOC file, but does not need to
be a file defined using Envision. For the current example, enter the name of
the non-Envision file “USERS”.
The next two fields in the window are used to specify which field in the file
contains the data we need. One prompts for the field name, the other for the
field’s position in the file, or attribute number. If you are using a non-Envision
file, you must specify the attribute number, since Envision does not know
what fields are in the file. If you are using an Envision-based file, you may
specify either the field name or the attribute number. For the current example,
Return through the field name prompt and enter “1” at the attribute number
prompt.
The last field in the window determines how the key for reading the record is
derived. There are four options for specifying the key derivation:
1. A keyword
2. A constant
3. A function expression
4. A previously defined Parameter Definition name.
Keywords
Following is a list of the valid keywords recognized for parameter definition
key derivations. Each keyword must be prefixed with an at-sign, @:
DEVICE.NAME. The user’s current device type
Constants
Constants are enclosed in either double or single quotation marks and are
evaluated literally. Record Security characteristics defined with constant key
derivations are, by definition, the same for each user on the system.
Function Expressions
In order to enter or modify a Function Expression, detail at a blank line at the
end of the list of the User Record Security Characteristic Definitions to run
the Key Derivation Function form.
Prompts for this form vary depending on the Key Derivation Function you
choose. The valid Key Derivation Functions are:
Concatenation. Concatenate two definitions separated by a delimiter
You can use any parameter definition name already defined in specifying a
key derivation or alone as a key.
For the current example, Envision Runtime will evaluate this characteristic to
the value in Field 1 of the record keyed by the operator’s login ID from the
file USERS.
Assuming that the other ACCESS.POS values are stored in consecutive fields
in a USERS record, the other three user characteristics would differ only by
the attribute numbers entered.
In the current example, each field in a USERS record contains a single code.
You may define user characteristics that evaluate to more than one value.
These values would be stored as a separated list. Envision Runtime recognizes
the following list separators:
Value Marks
Single Quotation Marks
If you use either of the quotation marks as value delimiters, the list of values
must also begin and end with the same quotation marks. Multi-valued lists,
that is, each value separated by a value mark, need only have delimiters
between values.
Logging off the system and starting the login procedure over again
For maintenance forms, the highest access to a record is all access, where the
user can add, modify, delete and view any data on the form.
A user has no access to a record when he fails to have inquiry access or all
access. For example, a user who has all access to a record can change data on
a maintenance form and view data on a report. A user who has inquiry access
can only view data on both a maintenance form and a report. If the criteria are
such that a user has neither all nor inquiry access, the user has no access to the
requested record.
For each file containing records you wish to secure, specify a Record Security
Definition on the Record Security Specification (UTMR) form.
UTMR allows you to base record security on either data in the current record
or data in a record from a co-file. A co-file is a file that contains data different
from the current file, but records in each file are keyed the same and the data
in each file, while different, is related. The first field on the UTMR form
allows you to specify a co-file to use in comparing the values in the record to
the values of the user characteristics. For example, you wish to secure a file
called PAYROLL, which contains payroll information for employees, keyed
by the employee’s ID. The field which determines whether a user can view the
data stored in the PAYROLL file is the field POSITION.CODE in the
EMPLOYEES file. To tell Envision Runtime to use the field
POSITION.CODE in the EMPLOYEES file when checking the user’s access
to a record in the PAYROLL file, enter “EMPLOYEES” as the select file on
the UTMR form. The default for this field is the secured file.
The next field on UTMR is a window field for the specification of the
security criteria for this definition. Each criteria has a connective, a
comparison field, a comparison operator, a comparison value and the
resulting access. There are three valid connectives:
As you can see, the WITH connective is an implied “and WITH”. For single
record access from a form process, Envision Runtime evaluates all the
criteria. The highest access code for that criteria that are true determines the
user’s access to the record. For example, four criteria are defined, two of
which are true for the current record. One has an access code of “I”, the other
“A”. The user will have “All” access to the record since “A” access is higher
than “I” access.
For access to more than one record (for example, a report, a resolution form or
a selection), Envision Runtime uses the security criteria to narrow the range of
records before any other selection takes place. Each of the security criteria is
used in building the security select statement. The connectives are used to
concatenate the criteria into a single select statement. This pre-selection of
records prevents the user from even knowing about records for which he has
no access.
Returning to the UTMR form, the second field in the window is the name of a
field in the selection file. The name of any valid field from the file you have
specified as the selection file is a valid entry for this field. For the example
stated above, the connective for your security criteria is “WITH” and the field
name is “POSITION.CODE”.
The next field in the window is where you enter the comparison operator for
the security criteria. Here is a list of the valid comparison operators for this
field:
NE Not Equal
EQ Equal
LT Less Than
EQ Equal
EQ Equal
GT Greater Than
LE Less than Equal
GT Greater Than
GT Greater Than
LT Less Than
LT Less Than
GT Greater Than
NE Not Equal
LT Less Than
The next field in the window is for the comparison value. The value stored in
the comparison field against the comparison value using the comparison
operator, yielding either true or false. The comparison value has three valid
formats:
A user characteristic defined on RSUC
A keyword
Your entry here is validated. Keywords begin with an asterisk, constants begin
with quotation marks. Anything else is considered a user characteristic and is
validated against the list of user characteristics defined on RSUC. Continuing
the above example, enter “ACCESS.POS1” in comparison value field to
compare POSITION codes with the value of ACCESS.POS for the current
user. If you specify constants in the comparison value field, the same test is
used for all users. If a user fails the test, he does not have access to the record.
If he passes the test, he has the access specified. All users will have access to
the same records and will be denied access for the same records.
The final field in the window is for the access code the user gets when he
passes the security criteria. There are only two valid entries; “A” for all access
or “I” for inquiry access. A user does not have access to a record if he does not
have either “all” nor “inquiry” access.
The final field on the UTMR form is a “Yes” / “No” field prompting if you
wish to activate the security definition. You list all of your criteria and leave
them turned off if you wish to do some research. Until you enter “Yes” in this
last field, record security for the current secured file is disabled.
Logging off the system and starting the login procedure over again
Field Security
Envision Runtime Field Security allows you to control the access that certain
classes of users can have to the data stored in specified fields. Only data
elements delivered with an Envision-based application can be secured by
Envision Runtime. Field Security works not only with form processes, but
procedures, reports and Query-by-Example (QBE) also obey field security
definitions.
Envision Runtime merges Process Security and Field Security so that the user
has the most restrictive access to the data in the field possible. For example, a
user is a member of a security class that restricts a form process to “Inquiry
Only” access. The user is also a member of a class that restricts a field to
“Privileged” (see below). Since “Inquiry Only” is more restrictive than
“Privileged”, Envision Runtime merges the two classes so that the user has
“Inquiry Only” access to the data in the field. Another example has a user
executing a form for which he does not have process security restrictions. A
field on the form, however, is secured so that the user is denied access.
Envision Runtime displays asterisks (*) in place of the data so that the user
cannot even see the data for which he is denied access.
The first field on the SCDF form prompts you for a security class. You may
use an already-defined security class from the Security Class Definition
(SCD) form or you may create a new security class. Field Security is simply
another attribute of a security class. A new security class you define on the
SCDF form may be assigned to operator definitions and device definitions.
Field Security class definitions are stored in the appl.SECLASS file just as
other security class definitions are. Enter the name of the security class with
which you wish to work or use the LookUp Processor to retrieve a name.
The second field on SCDF is a text window where you can describe the
security class you entered in the last field. If you are creating a new security
class, enter free-form text documenting the use and restriction of the new
security class. If you are using an existing security class, the previously
entered description displays in this window.
The third field on SCDF allows you to detail to the Security Class Definition
(SCD) form.
The next field on SCDF is a window field where you specify the fields for the
security class and the restrictions on those fields for users in the class. Enter
the name of the field or fields you want to restrict, or use the LookUp
Processor to retrieve the name. For each field you restrict, you must specify a
code defining the restriction. Below is the list of valid restriction codes:
P - Privileged Access. User must be a member of this class to have any
access to the data in the field
PI - Privileged Inquiry. User must be a member of this class to be able to
view the data in the field; can only view; cannot modify
PM - Privileged Modify. User must be a member of this class to be able to
modify the data in the field; cannot add new data
D - Denied Access. Users in this class do not have access to the data in the
field
I - Inquiry Only. Users in this class can only view the data in the field;
cannot modify data
M - Modify Data Only. User in this class can only modify the data in the
field; cannot add new data
Technical Tip: You must run the Build Application Security (BSEC)
process to rebuild all Envision security for an entire application if any
of the following conditions arise:
In This Chapter
This chapter provides information on the encryption capabilities available for
Colleague processes.
Troubleshooting 185
Colleague has several encryption schemes available from which you can
choose. These encryption schemes are determined by the encryption schemes
supported in UniData 6.1 and later. For more information about the
encryption scheme choices, see the UniData manual, UniBasic Extensions,
particularly the “Encrypting Data” section.
Key Concepts
There are several key concepts of which you need to be aware when
implementing Colleague encryption:
“Quiet” system. Change your encryption scheme only during a period of
no database activity. If queries are made to the database for elements that
are currently being encrypted, your users will encounter runtime errors and
you will corrupt your database.
Back up your database. Because you are manipulating data into an
encrypted format, if something goes wrong the data most likely would be
unrecoverable. It is very important to back up your database before
implementing encryption, as well as when changing your encryption
scheme.
Encryption process runs immediately. If you change either the
encryption scheme or the encryption key, a batch re-encryption process is
immediately started after saving from the UT Encryption (UTEP) form.
The process cycles through all of the fields listed in the Encrypted Fields
Registry table, converting them from the previous encryption scheme to the
new encryption scheme.
Form Used
Table 8 lists the form used in this section and a description of the form.
File Used
Table 9 lists the primary file used with Colleague encryption.
Under normal circumstances, the status will show INACTIVE. This status
means the re-encryption process is not running. If the encryption process
appears to be running, the status will show ACTIVE, and the entire form will
be inquiry-only.
If you believe that the status of ACTIVE is erroneous because the batch
process aborted, see “Troubleshooting” on page 185 for more information.
The data elements listed in the Encrypted Elements Registry field are the
elements that the system will update whenever you change your encryption
scheme.
Yes. In the Encryption Algorithm field, choose the encryption algorithm you
want to use. Changing the encryption algorithm will also change the
encryption key.
Step 4. Save from the UTEP form. The batch encryption process starts as soon as you
save from the UTEP form. You are finished with this procedure.
Step 5. If you want to change the encryption key, enter Yes in the Reset Key field.
Troubleshooting
The UT Encryption (UTEP) form is designed with a “must run perfectly”
philosophy. Before starting to process data records, the UTEP process does
extensive validations of the EDPARMS parameter record. Everything about
the record must be correct before the process starts. If anything unusual is
detected, the process throws an error and then ends. The error is logged to the
UT.THROWN.ERRORS file. Errors are also logged if the encryption process
encounters anything wrong while processing.
If the encryption process aborts in any other way, then the system
administrator will have to edit the parameter record and change that field to
ABORTED in order to be able to get the process to continue.
If the UTEP form displays the encryption status as ABORTED, fix the problem
(refer to the error in the UT.THROWN.ERRORS file), and then simply save
from the UTEP form. The encryption process will resume from where it
stopped. Restarting the encryption process when the UTEP form believes it is
currently running (the UTEP form displays a status of ACTIVE but the
encryption process has thrown an error and aborted) is a bit more tricky.
In order to restart the encryption process when the UTEP form believes it is
still running, you must first determine what the problem is, and then correct
that problem. Refer to the error in the UT.THROWN.ERRORS file to
determine the problem. After the problem is fixed, edit the value of the
EDPARMS.CONV.IN.PROGRESS field to ABORTED. This will cause the
UTEP form to recognize that the encryption process has aborted, and will
invoke the encryption process to resume when you save from the UTEP form.
Maintenance
Maintenance
Maintenance Introduction
This chapter covers the overall maintenance tasks that you must perform for a
Colleague site. A sample schedule is provided for system maintenance along
with DBMS tasks.
Guidelines for purging files and handling duplicate records is provided along
with the purpose of the utility programs and directions for running.
Policies for upgrading releases and the background information for Colleague
release loads are outlined.
Purges
Disk maintenance
Saves
Saves or backups should be performed daily. There are two types of saves:
Full backups. Save everything in a requested partition or directory whether
it has changed since the last save or not.
Incremental backups. Save just the files and directories that have changed
since the last full save. See your operating system documentation for
information on performing saves.
The example site recommends that you perform a full save everyday on your
partition that contains Colleague data files. This allows you to easily recover
an account without having to restore your full save and then overlaying it with
each incremental save performed since. This recommendation, however,
depends on your manpower, machine and tape resources.
The example site collects all of the como files from its directories and
appends them together, with headers, in one file for future reference, and then
deletes the original form the PH directory.
Purges
Reports run to the HOLD file, SAVEDLISTS generated by programs or users,
command stacks, and temporary files accumulate over time and use additional
disk space. Purge these files periodically. See Chapter Purging Files in this
manual for additional information.
The example site uses the following guidelines and naming conventions in
deciding which files to purge:
The HOLD file is archived daily and all records in it are deleted.
Any savedlist or command stack that hasn’t been modified for a month is
deleted, unless it is named, “PERM.xxx”.
Temporary files beginning with “T$...” are deleted.
Disk Maintenance
Each operating system provides disk maintenance utilities that you should
perform according to your vendor’s recommendations. Typically, you run
these after a full backup.
Notes
1. It is very important you run the processes in the order listed and only if the
previous process completed successfully. This ensures that files are saved
to tape before deletion.
2. Run each process early in the morning on the day indicated before
allowing users on the system. Perform the full save and disk maintenance
at any convenient time on the weekend. Be sure to perform the save before
running the disk maintenance utilities.
3. Do not allow users should not be on the system while these processes are
running.
4. These processes may be run interactively in the foreground by an operator
with a como file on, or in the background with a batch monitor with cyclic
features such as Batchmaster, or submitted daily to a batch queue by an
operator.
In This Chapter
This chapter provides information about file and index analysis utilities for
UniData. There are two utilities that are external UT programs to Envision
that can help you to maintain your system:
WEEKLY.UDT.FILE.ANALYSIS (WUFA)
WEEKLY.UDT.INDEX.ANALYSIS (WUIA)
Using WEEKLY.UDT.FILE.ANALYSIS
(WUFA)
The WEEKLY.UDT.FILE.ANALYSIS (WUFA) utility assists in monitoring
and maintaining the condition of your file system so that you can optimize
your UniData database, and is used to analyze your data files for overflows
and potential resizing. The state of your file system can have a significant
impact on system performance, especially if a file is sized too small.
Analyzes those file statistics and makes recommendations about the block
size and modulo for each file in an environment. These recommendations
are written to a paragraph to automate file system maintenance. You can
run this paragraph after the WUFA utility finishes running.
Builds a resize paragraph to automate file system maintenance.
Estimates the disk space savings or cost that will result if you run the resize
paragraph.
Builds a report paragraph with suggested update parameters.
Creates saved lists of either invalid VOC records that point to invalid files
or VOC records that could not be opened.
On completion, a file analysis report will be output to the default printer. The
report will be sorted in order of the condition of the files. Damaged files will
be listed first, then those files that have groups in level-two overflow, then in
descending order of “average bytes per group.” If a file is sized too small, it
will typically have a very large “average bytes per group.”
The WUFA utility will also create a resize paragraph to simplify the task of
correctly sizing your files. The resize paragraph is in the same order as the
report. You should modify this paragraph to include only those files that you
want to resize.
Datatel recommends that you try not to resize too many files at once, as any
file being resized will be unusable until the resize is complete. Many factors
determine how long a resize will take, including the size of the file, how
poorly sized the file currently is, and how much memory you allocate to the
command for memory resizing (memresize command).
Before you run the resize paragraph, execute the following statement to find
out the largest file that may need to be resized.
If you notice that a static file is approaching 2GB, you should convert the file
to dynamic since static files have a 2GB size limit. Datatel recommends
leaving your files static as much as possible as they are easier to tune.
Some of the benefits of running the WUFA utility on a weekly basis are:
Fewer files go into overflow each week. When they do, there is minimal
level-one overflow.
Fewer files process during the resize, allowing resizing to run quickly.
Note: For Colleague R18 on UniData, the WUFA utility should also be
run in the Local Product Repository (LPR) as UniData files should be
checked for damage and overflow there.
The –AD option allows a decrease in file size. The default behavior does not
allow a decrease in size of a file. The reasoning for this is that if a file grew
large enough to warrant its current size (such as a temporary work file), then
even if its current contents are small, the file may grow large again and cause
overflow problems (if resized based on its current contents). The –AD option
allows you to override that default behavior and allow a decrease in file size.
The –ED option allows you to exclude dictionaries of each file from
analysis. The default behavior is to analyze dictionaries of each file included.
For example, when analyzing PERSON, the dictionary D_PERSON will also
be analyzed. The –ED option allows you to override that default behavior
and exclude analysis of dictionaries of each file.
To monitor its progress by scanning the COMO file, enter the following:
:AE _PH_ O_FILE.MAINT
When the WUFA utility has completed, you should review the file analysis
report and the recommended block sizes and modulos. You should then
modify the resize paragraph to include only those files that you actually want
to resize.
ALERT! Before running the resize paragraph, all users must log
out of the system and the environment’s DMI listeners must be
stopped. After running the DATATEL.RESIZE.FILES paragraph,
you can restart the DMI listeners.
To run the resize paragraph, enter the following at the colon prompt:
:DATATEL.RESIZE.FILES
or
:PHANTOM DATATEL.RESIZE.FILES
Disk space estimates will be displayed when the WUFA utility is finished.
They will also be inserted into the resize paragraph
DATATEL.RESIZE.FILES. The disk space estimates are only
approximations, they do not account for overflow groups. They should give
you a reasonable estimate of how much disk space you will need or get back
after running the DATATEL.RESIZE.FILES paragraph.
Note: See AnswerNet Document 107.1437 for how to resize the VOC
file.
Using WEEKLY.UDT.INDEX.ANALYSIS
(WUIA)
You can use the utility WEEKLY.UDT.INDEX.ANALYSIS (WUIA) to
execute UniData’s guide_ndx command in order to analyze index files. The
WUIA utility creates paragraphs and saved lists that you can use to clean up
index files.
You will run the WUIA utility at the colon prompt or in a VOC paragraph.
Because the WUIA process does not clean up index files, it can be run on an
active system. However, you should run the resulting paragraphs and the
UTBA process only on a quiet system.
In this command, the “1” triggers physical checking of the index file.
This triggers logical checking of the index file for any non-null indexed fields,
by issuing this command:
guide_ndx -x 2, <list of non-null indexed fields> <file name>
In this command, the “2” triggers logical checking of the index file.
When you run this utility, the final statement shown will indicate whether or
not any problem index files were found. One of the following statements will
be displayed:
No problem index files found...
Using the WUIA utility to run guide_ndx on each file will populate a
GUIDE_XERROR.LIS record file with output such as shown in the following
examples:
PERSON
Checking index 'SSN' physically...
Checking index 'AARS' physically...
Checking index 'D01.CUSTOM.FLD' physically...
The index has not been built yet.
or
PERSON
Checking index 'SSN' logically...
Checking index 'AARS' logically...
Checking index 'D01.CUSTOM.FLD' logically...
Index D01.CUSTOM.FLD is not built or deleted.
Whenever text appears in that report, excluding the file name and the
“Checking...” phrase, the WUIA utility detects a problem with at least one
index for the file, and will then set up the deleting, recreating, and rebuilding
of all indexes for the file.
Example 1
Step 1. To run the WUIA utility for the PERSON file for physical checking, enter the
following at the colon prompt:
MIOSEL CORE.FILE.SPECS "PERSON"
Example 2
Step 1. To run the WUIA utility for the PERSON file for logical checking, enter the
following at the colon prompt:
MIOSEL CORE.FILE.SPECS "PERSON"
Example 3
Step 1. To run the WUIA utility for all files for physical checking, enter the following
at the colon prompt:
WEEKLY.UDT.INDEX.ANALYSIS
This saved list is created only if problems are found, and will contain a list of
files with indexing issues.
This paragraph is created if you are not in a Local Product Repository (LPR)
environment. If the saved list in Output Item 2 was created, the paragraph will
contain a series of DELETE.INDEX statements for the files in the saved list.
If the saved list was not created, the paragraph will contain a display
statement indicating there were no problem indexes.
When problem indexes are found, you can run this paragraph to clear out each
file’s indexing. You then run the Multiple File Indexing (UTBA) process
using the saved list in Output Item 2 to rebuild indexing for the files. On the
UTBA form, enter one of the following options in the Indexing Function
field:
B (Create & Build All)
Each run of the utility will save the previous run’s output paragraph as
DATATEL.PHYS.DEL.IDX.FILES.PREV.
Note: Running this utility deletes any custom indexes created for the
files in the paragraph. If the custom indexes are not defined to Envision
specifications, they are not recreated and rebuilt by the UTBA process.
In either case, you do not need to then run the UTBA process.
Each run of the utility will save the previous run’s output paragraph as
DATATEL.PHYS.DEL.RBD.IDX.FILES.PREV.
Note: Running this utility will initially delete any custom indexes
created for the files in the paragraph. However, it will then recreate and
rebuild any indexes that existed for each file when the WUIA utility was
run.
The list is not driven from RFSPECS, and therefore may not be
complete (from an RFSPECS, UTBI/UTBA perspective), but any
indexes that are deleted by the paragraph will be recreated by the
paragraph.
If created, this saved list contains a list of files that could not be opened using
their existing VOC pointer. This list is provided for your convenience in
cleaning up your VOC file.
If created, this saved list contains a list of logical view files that could be
opened with their logical name, but could not be opened with their physical
name. This could be due to a bad physical VOC entry, or it could be due to a
missing VOC entry for the physical file.
This report is created when you run a logical check on index files. It
concatenates the results of the GUIDE_XSTATS.LIS and
GUIDE_XERROR.LIS reports from the guide_ndx execution for each file
processed.
This saved list is created only if problems are found, and will contain a list of
files with indexing issues.
This paragraph is created if you are not in an LPR environment. If the saved
list in Output Item 2 was created, the paragraph will contain a series of
DELETE.INDEX statements for the files in the saved list. If the saved list was
not created, the paragraph will contain a display statement indicating there
were no problem indexes.
When problem indexes are found, you can run this paragraph to clear out each
file’s indexing. You then run the Multiple File Indexing (UTBA) process
using the saved list in Output Item 2 to rebuild indexing for the files. On the
UTBA form, enter one of the following options in the Indexing Function
field:
B (Create & Build All)
Each run of the utility will save the previous run’s output paragraph as
DATATEL.LOGI.DEL.IDX.FILES.PREV.
Note: Running this utility deletes any custom indexes created for the
files in the paragraph. If the custom indexes are not defined to Envision
specifications, they are not recreated and rebuilt by the UTBA process.
In either case, you do not need to then run the UTBA process.
Each run of the utility will save the previous run’s output paragraph as
DATATEL.LOGI.DEL.RBD.IDX.FILES.PREV.
Note: Running this utility will initially delete any custom indexes
created for the files in the paragraph. However, it will then recreate and
rebuild any indexes that existed for each file when the WUIA utility was
run.
The list is not driven from RFSPECS, and therefore may not be
complete (from an RFSPECS, UTBI/UTBA perspective), but any
indexes that are deleted by the paragraph will be recreated by the
paragraph.
If created, this saved list contains a list of files that could not be opened using
their existing VOC pointer. This list is provided for your convenience in
cleaning up your VOC file.
If created, this saved list contains a list of logical view files that could be
opened with their logical name, but could not be opened with their physical
name. This could be due to a bad physical VOC entry, or it could be due to a
missing VOC entry for the physical file.
If you want to do both physical and logical checking, two separate runs of the
WUIA utility must be executed. Also, you should run only one session using
the WUIA utility at a time. This means you should not enter
WEEKLY.UDT.INDEX.ANALYSIS in one session, while running
WEEKLY.UDT.INDEX.ANALYSIS -L in another session.
The reason for this is that both physical and logical checking rely on the
interim results UniData provides in GUIDE_XSTATS.LIS and
GUIDE_XERROR.LIS for each execution of the guide_ndx command.
Results from one session would likely skew the other session. So the two runs
of the utility should be performed sequentially, either manually or through a
paragraph.
The WUIA utility can be run on an active system. However, the following
paragraphs created by the utility should be run only on a quiet system:
DATATEL.PHYS.DEL.IDX.FILES
DATATEL.PHYS.DEL.RBD.IDX.FILES
DATATEL.LOGI.DEL.IDX.FILES
DATATEL.LOGI.DEL.RBD.IDX.FILES
Also, use a quiet system if you run the UTBA process with the Indexing
Function field set to B or M.
The following is an example VOC paragraph that can be created and used in
an LPR or in an apphome environment:
:AE VOC WUIA.DELETE.REBUILD
0001: PA
0002: COMO ON WUIA.DELETE.REBUILD
0003: DATE
0004: WEEKLY.UDT.INDEX.ANALYSIS
0005: DATATEL.PHYS.DEL.RBD.IDX.FILES
0006: WEEKLY.UDT.INDEX.ANALYSIS -L
0007: DATATEL.LOGI.DEL.RBD.IDX.FILES
0008: COMO OFF
Record Deletion
Tracking File Activity
Indexing
Add/Change Tracking
Add/Change Tracking for records in a file occurs automatically and is
completely transparent to the user. For almost every Envision file, there are
four fields defined which Envision Runtime uses to track additions and
changes:
filename.ADD.DATE
filename.ADD.OPERATOR
filename.CHANGE.DATE
filename.CHANGE.OPERATOR
Note: For Oracle support where shorter names are required with a
maximum of 28 characters, Datatel now also allows:
• filename.ADDDATE
• filename.ADDOPR
• filename.CHGDATE
• filename.CHGOPR
Any time a new part record is added to the PARTS file, Envision Runtime
date stamps the record with the date the record was added and the operator
who added it. Similarly, if the PARTS file also has the fields
PARTS.CHANGE.DATE and PARTS.CHANGE.OPERATOR, any time a
record in the PARTS file is modified, Envision Runtime automatically stamps
the record with the date that it was changed on and the operator who changed
it.
If any of the above fields are not defined for a file, Envision Runtime does not
maintain the data for that field. Date stamping information is not maintained
and this level of tracking is ignored.
You may not add or remove this tracking from a particular file. The existence
of the changed data fields in the dictionary of a file does not automatically
ensure date stamping. The date stamping fields must be defined through the
Envision Tool Kit in order for Envision Runtime to recognize them.
The relationships between entities in the database usually implies that certain
information is true only when the two entities are considered at the same time.
For example, the data stored for the date a person was hired by a company and
the person’s telephone extension at the company are valid only when you
consider the person and the company at the same time. When data about the
relationship between two entities is stored, that file is called a relation file. A
relation file is keyed by a combination of the IDs of the related entities. This
relational structure ensures that data is stored only once. The date two people
are married on is not stored in each of their demographic records: one relation
record provides the logical location, so that the data is stored only once.
Specifications about relation files are also stored in the CDD, automatically
becoming part of a program definition and ensuring the proper retrieval and
maintenance of a relation record. The generated and compiled program uses
Envision Runtime file management to retrieve the relation record and modify
the data stored, if appropriate. The relationship between entities in the
database and the relation record associated to the entities is defined through
the Envision Tool Kit and therefore cannot be changed by the end user.
Record Deletion
Record Deletion occurs on the Envision screen processes for which deleting
records is allowed. The ability to delete records is defined through the
Envision Tool Kit when the screen process is defined. You can not add or
remove the delete ability from the screen processes.
For those screens that allow record deletion, the user presses the RECORD
DELETE function key. Envision Runtime prompts the user to make sure he
really means it. If the user presses the RECORD DELETE function key a
second time, Envision Runtime removes the record from the file.
Transaction Logging
With the Transaction Logging function, Envision Runtime allows you to track
changes to, additions of and deletions of records in a specified file. For files
that contain sensitive data, this tracking allows an additional layer of security
and provides a mechanism for recovering from mistakes and disasters.
Whenever a record is written back to disk, Envision Runtime checks to see if
transaction logging has been requested for that file. If you have requested
transaction logging, Envision Runtime writes both the old and new version of
the changes in the record. For a changed or deleted field, only the values for
the fields that change are written to the log file in order to conserve disk
space. If a record is deleted or added, the entire record is written to the log
file. In addition, Envision Runtime tracks the date and time of the change and
the operator who made the change.
Step 2. Enter the filename. The file must have a corresponding UFSPECS record.
Currently, only Envision-based software meets this criteria.
Step 3. The current status of the file displays. Enter if you wish to change the status
from on to off or off to on.
Step 4. Indicate the date to which you wish to track file activity.
History Logging
History logging enables you to use field and file history to track changes and
view records as they existed at an earlier time.
Note: You can only view data in inquiry mode. History logging does
not allow you to change records or restore them to earlier versions.
To track changes made by users to the values in specific fields in a file, use
the Define Field History (DHST) form, described in “Define Field History
(DHST)” beginning on page 335.
To view an earlier version of a record from field history, use the Field
History Detail (FHDT) form, described in “Field History Detail (FHDT)”
beginning on page 340.
To view an earlier version of a record from a history value, use the Rebuild
Field History (RBFD) form, described in “Rebuild Field History (RBFD)”
beginning on page 368.
To view a record in a file as of a certain date, use the Rebuild File History
(RBFH) form, described in “Rebuild File History (RBFH)” beginning on
page 369.
File Indexing
Prior to using Colleague 18.0, you will have converted all files to database
indexing. Database indexing enables you to define indexes to Envision while
using the indexing capabilities of your database, rather than Envision, to store
and maintain index values. There are several advantages to database indexing:
Database queries can take advantage of Envision-defined indexes
The indexing processes are found in the System File Administration menu, as
shown in Figure 33.
The Constructing File Name field indicates the file for which you want to
define indexing. If you want to use an index that is defined and maintained
through another file, you can enter the name of the file in this field. This
enables you to use the index in read-only mode. Enter the name of the file
or use LookUp to retrieve its name. This file must already have a valid
UFSPECS record defined.
An indexing association is a field or list of fields which, when changed,
trigger indexing. A change to the value stored in any of the fields in the
association causes Envision Runtime to recalculate the index value and
update the corresponding index record.
Enter in the Index Association Data Elements fields the data elements that
comprise the indexing association. If a change to the value in only one data
element triggers indexing, enter the name of that data element as the only
member of the indexing association. If more than one data element triggers
indexing, enter the name of each data element on a separate line.
For example, a file called ORGANIZATIONS is indexed by the field
ORG.NAME. For this indexing association in ORGANIZATIONS,
ORG.NAME is the only data element and, whenever the name for an
organization changes, Envision Runtime uses the new value to calculate the
index record key. Another file, PERSON, is indexed by LAST.NAME,
FIRST.NAME and MIDDLE.NAME. Whenever any of these fields
changes, Envision Runtime compares the new values and the old values to
calculate the index record key.
Note: If you are using a subroutine, you must list here all elements
that are referenced by that subroutine in order to give the subroutine
access to the fields and ensure correct index updating.
Enter, or use LookUp to retrieve, the name of the file in which index IDs
are to be stored in the Target File for Index Records field. By convention,
this file is usually called INDEX.filename, where filename is the name of
the file for which Envision Runtime performs the indexing. The file
designated to store the indexing records must be a valid file defined in the
VOC. (This field is used in Envision 4.7 only.)
The default algorithm for determining the indexing key is simply to use the
value of the data element. When you specify more than one field in the
indexing association, the default algorithm concatenates the values in the
data elements together. This default indexing key is usually insufficient and
unwieldy. The Subroutine to Calculate Index Keys field allows you to
specify the name of a subroutine which can be used to transform the value
or values passed into a more efficient and concise indexing key. The
subroutine must have one argument: a list of values. It should return the
string or strings of characters to use as indexing record keys. If the
subroutine returns more than one indexing key, each value in the returned
list must be separated by a field mark (@FM).
Enter Yes in the Index Null Keys field if you want null values to be used in
indexing. If you enter “No” or leave the field blank, null values are not
used.
In the Primary File Storage Field Name field, enter the name of the field in
the main file that is designated for storage of intermediate index values, i.e.,
the calculated result from the associated subroutine that is defined for the
index.
If you designated an alternate storage file for intermediate index values,
specify the designated numeric field in the Alternate Storage File Position
field.
Enter the name(s) of the data field(s) to store in the index record in the Data
Elements to Store in Index fields.
Note: The default entry for a Data Elements to Store in Index field is
the key to the record in the primary file. If Envision uses a field other
than the record key to index a record, this field specifies which field of
the current record to store as the key for this record in the index file.
The Index Key Subroutine determines which field to use as the key.
If you want to delete this index association, enter Yes in the Delete this
Index Association field. Enter No or leave the field blank to retain the
association.
Step 1. Run the Batch Runtime RFSPECS Refresh (BRRR) utility, as shown in
Figure 35, on each application.
When you update from the BRRR form, the selected files are converted.
Step 2. If you have created custom Envision indexes that use a subroutine to calculate
index keys, you must run the Index Storage Field Report (ISFR), shown in
Figure 36, to identify the indexes that need additional storage fields, and to
specify the storage fields for values created by subroutines.
Do you want to run the report for every file in the application?
Yes. Leave the Report Limit List field blank.
No. Enter the name of a saved list in the Report Limit List field.
Step 3. Update to generate the Missing Index Storage Fields Report, as shown in
Figure 37.
Step 4. Use the User File Index Specification (UTMI) form, shown in Figure 38, to
define the additional storage fields.
For detailed general information about the UTMI form, see “User Defined
Indexing” beginning on page 223.
If you want to use an index that is defined and maintained through another
file, you can enter the name of the file in the Constructing File Name field.
This enables you to use the index in read-only mode.
In the Index Association Data Elements fields, enter the names of fields
that activate Envision indexing when they change.
Note: If you are using a subroutine, you must list here all elements
that are referenced by that subroutine in order to give the subroutine
access to the fields and ensure correct index updating.
Enter the name of the file in which index IDs are to be stored in the Target
File for Index Records field. (Envision 4.7 only)
In the Subroutine to calculate Index Keys field, enter the name of a
subroutine used for indexing.
By default, each field in the association is used as a key for a record in the
target file. To concatenate fields, use the subroutine that you designate in
this field.
Enter Yes in the Index Null Keys field if you want null values to be used in
indexing. If you enter “No” or leave the field blank, null values are not
used.
In the Primary File Storage Field Name field, enter the name of the field in
the main file that is designated for storage of intermediate index values, i.e.,
the calculated result from the associated subroutine that is defined for the
index.
The Primary File Storage Field Name field is a required field if you use a
subroutine for indexing.
If you have designated an alternate storage file for intermediate index
values, specify the designated numeric field in the Alternate Storage File
Position field.
Enter the name of the data fields to be stored in the index record in the Data
Elements to Store in Index fields.
The default entry for a Data Elements to Store in Index field is the key to
the record in the primary file. If Envision uses a field other than the record
key to index a record, this field specifies which field of the current record to
store as the key for this record in the index file. The Index Key Subroutine
determines which field to use as the key.
If you want to delete this index association, enter Yes in the Delete this
Index Association field. Enter No or leave the field blank to retain the
association.
If you use UniData and have already created database indexes, there is no
need to modify them. If you have indexed a field that is indexed by
Envision, the name of the index may change, but this should have no effect
on processing or the use of the index.
Step 5. Access the Envision Parameters Edit (EPED) form, shown in Figure 39, to
specify your current indexing mode.
Enter 5 in the MIO Indexing Mode field to set the mode to a combination
of Envision and database indexing.
When all files in the application have been successfully converted to database
indexing, set the MIO Indexing Mode to 4.
For information about the other fields on the EPED form, see “Using the
Envision Parameters Edit (EPED) Form” beginning on page 55.
Note: The DMI Print Server IP/Port fields are used in Envision 4.7
only. In Release 18.0,you can set up a DMI listener with a print server
role as described in Implementing Stylesheet Printing available on the
Datatel web site at:
http://www.datatel.com/support/documentation/colleague/
collr18doc.cfm.
Step 6. Use the File Indexing (UTBI) form, shown in Figure 40, to index your files
individually, or the Multiple File Indexing (UTBA) form, shown in Figure 41
on page 233, to index multiple files.
Envision 4.7
In the Indexing Function field, select the indexing function that you want to
run.
In the Saved List Name field, enter an optional saved list of files for
indexing. If computed index columns are calculated, only records in this
saved list are updated.
In the Indexes to Maintain fields, delete all indexes that you do not want to
maintain. You can also use these fields to enter any index associations that
you accidentally removed.
To maintain indexes on multiple files, use the Multiple File Indexing (UTBA)
form, as shown in Figure 41.
Step 7. In the Saved List Name field, enter a saved list of files for indexing.
Step 8. In the Indexing Function field, select the type of indexing function that you
want to run.
Step 1. Use the Envision Parameters Edit (EPED) form, shown in Figure 39 on
page 231, to switch the indexing mode parameter for the application to 4
(exclusively database indexing).
Step 2. When all files have been successfully converted to database indexing, you can
use the Delete Obsolete Index Files (DOIF) form, as shown in Figure 42, to
purge the Envision index files.
Note: Datatel recommends retaining the Envision index files until you
are confident that there are no problems with any of the converted
files. Once the Envision index files have been purged, you cannot
revert files to Envision indexing.
When you update from the DOIF form, the selected index files are deleted.
For each report documented, a brief description of the report and its fields
precedes the technical listing of the procedure definition for the report. While
reviewing the technical listings, remember that values that appear in square
brackets ([]) are variable, which are evaluated based on user entries at
runtime.
The JRPT report also lists the date/operator stamp for when the procedure was
added and when it was last changed.
The bottom section of the report shows each step defined for the procedure.
Each step has a mnemonic and can optionally have a label and a description.
Procedure steps that are “jobs” have listed the mnemonic and the calling
interface to the Procedure Generator. “User Screens” show the name of the
screen and the process name. “IF” and “STMT” steps show the detailed
information for the analyst-defined special statement. “List” specifications
show the criteria for generating the list, including sort and select options and
any branching on error.
The first section of the report shows the description of the resolution
definition and the file on which the template is operating. This section also
shows the key transformation subroutine if one has been specified.
The second section of the report describes each component part of a display
block. These display blocks show the user information to aid his choice of a
record ID. Each component part has displayed the character that represents it
in the block image, the line of the block on which it appears, the column of
that line in which it appears, the length and justification of the part and the
definition for what displays in that part.
The last section of the report shows how a block of resolution data would
appear. Each letter in the display block corresponds to a letter in the part
listing. This display block also shows the template text for the resolution
screen.
The second part of the report shows the current definition of record security
on the selected file. This definition includes the record security criteria shown
here as a select statement. The value shown in square brackets ([]) is the
access a user who meets that criteria has to a requested record: “I” is for
“Inquiry” and “A” is for “All”.
The first column of information on this report shows the particular job
statistics record used to generate the report. This column also shows the
description of the error, if applicable. The second column of this report shows
which step the report block is describing. Each step in an executed procedure
will have its own report block. The second column describes what the
procedure step was doing and what the status of the step is. A step can have
one of the following statuses:
[[S]] for started, still in progress
[[F]] for finished
The third report block column shows the accumulated totals for the procedure.
The last column shows the start time and duration for the procedure step.
Each report block this report shows one transaction for a record in the logged
file. The three transaction types (Added, Changed, Deleted) are shown in the
first column of each report, enter the date on which the transaction occurred.
The next column shows the time the transaction occurred and the operator for
the transactions, as well as all the fields which are affected by the transactions.
The next column shows the record in the logged file affected by the
transactions as well as the original values for the fields that changed. Finally,
UTXL shows the new values for the fields that changed.
Purging Files
To ensure that your system runs at peak performance, you should remove
obsolete records from heavily used files. The removal of obsolete records is
called purging. This chapter describes the types of files to purge and provides
procedures to remove records from several frequently used files.
The frequency of use for each file varies from site to site. The purging of these
files, therefore, occurs at different time intervals for each system
administrator. You should review the following files on a periodic basis:
Data files updated by the application software
Data Files
Purging, archiving, and condensing programs are provided within the
modules of your application software. Purging programs remove the data
from your system and often allow you to dump the data to tape. Archiving
programs allow you to move your data to a set of archiving files to allow more
space in your working files. You can still access the demographic information.
Condensing programs allow you to consolidate history information in its own
file.
See the user documentation for your modules for details on the programs
provided within that module.
Transaction Logging
Batch Status
Use the Job Statistics Purge (UTJP) procedure to purge data that is
automatically collected and stored when an end user runs a procedure. This
data is used not only to track the current status of a procedure while it is still
running, but is also used to generate the Job Statistics Report (UTJR). The job
statistics include the date the procedure was run, the start and end times of the
procedure, the records the procedure processed, as well as detailed statistics
for each step in the procedure.
These statistics are stored in the file appl.PPROCESS, where appl is the
mnemonic for the current application. The purge process clears the file of the
selected data.
To delete obsolete statistics records, run the application for which you wish to
purge the PPROCESS file. From the main menu of the application, run the
Job Statistics Purge procedure, UTJP.
As with most Envision procedures, the first step is to provide the Procedure
Generator with the values for its runtime parameters. For the Job Statistics
Purge procedure the front-end screen is used to gather the values of the
parameters.
Several options allow you to selectively delete a finite number of records. You
can specify a date range if the records you want to delete fall in a period of
unusually high activity. You can specify a time range if, for instance, your
important procedures are run at night and the statistics records you wish to
delete are all from daytime jobs. You can select to purge records for a list of
selected users or for a list of particular procedure mnemonics. The detail to
which you specify the records to delete is entirely up to you. You can even
specify no selection criteria to completely clear the job statistics file.
A final option on this front-end screen allows you to generate a detailed report
of the records deleted from the job statistics file. This report is run before the
purging is done. You can cancel out of the procedure before the records are
deleted if you do not want to purge the selected record. The purging batch
program, when run, automatically prints a report of the records it has deleted.
Transaction Logging
Use the TXLOG Purge (UTTP) procedure to purge data that is automatically
collected and stored for a file that has the transaction logging feature enabled.
The data includes the operator’s login ID and the date and time the transaction
was created. Transaction data includes all records added, changed, or deleted
within the file. Envision stores transaction data in the log file TX_filename,
where filename is the name of the file for which you are logging transactions.
This purge process clears the transaction log file of the records you select.
The TXLOG Purge procedure begins with a front-end screen which allows
you to select specific transaction records for deletion from the transaction
logging file. First select the file for which you would like to purge transaction
log records. If you specify no selection criteria, the procedure removes all of
the records from the selected transaction log file.
You can selectively delete records by specifying selection criteria. You delete
records:
Within a specific date range or time range
The batch program which performs the actual deletion of the selected records
automatically generates a report of the records it has purged from the selected
transaction log file.
PH
SAVEDLISTS
The HOLD file is the target file for any report or other procedure output
which the user selected to view at his terminal. The PH file stores the record
of procedure execution whenever a procedure is run as a background process.
The SAVEDLISTS file stores the lists of IDs whenever the report or
procedure requires the generation of a list.
_PH_
SAVEDLISTS
These files can affect the performance of your system if they become too
large. The time it takes to do backups is also affected by the size of these
directories. It is important, therefore, that you periodically clean out the
obsolete records from these files. While Envision Runtime does not provide
specific screen or batch processes to aid you in removing records from these
files, the following sections describe the procedures you can follow to remove
records from these files.
HOLD
The HOLD file is the database file in which Envision Runtime writes report
output for processing by the BROWSE utility. Some records in this file are
keyed by the date and time the user sent report output to the HOLD file. Other
records in the HOLD file have IDs that are strings the users entered. In order
to purge the HOLD file:
1. In the database environment, select the HOLD file, sorting by ID. Save
this list to the SAVEDLISTS file.
:SSELECT HOLD
:SAVE.LIST HOLD.LIST
2. Edit the list you just created. Determine the HOLD file records that you
want to save. Remove the line containing the name of the record that you
want to save from the list. When the list contains only those records you
wish to remove from the HOLD file, file the list back into SAVEDLISTS.
3. In the database environment, retrieve the list you just modified and delete
the records from the HOLD file:
:GET.LIST HOLD.LIST
:DELETE HOLD
The system prompts you to make sure you wish to delete records from the
file using a select list. Answer [[Y]] to this prompt.
PH
The PH file stores the record of all processes run in background mode. Each
record in the PH file has a multi-part key:
The ID of the VOC record run in background mode
The internal representation of the time the process was run
The internal representation of the date on which the process was run
Step 1. In the database environment, select the PH file, sorting by ID. Save this list to
the SAVEDLISTS file.
Step 2. :SSELECT PH
:SAVE.LIST PH.LIST
Step 3. Edit the list you just created. Determine the PH file records you want to save.
For each record that you want to save, remove the line containing the name of
the record from the list. When the list contains only those records you wish to
remove from the PH file, file the list.
Step 4. In the database environment, retrieve the list you just modified and delete the
records from the PH file:
The system prompts you to make sure you want to delete records from the file
using a select list. Answer [Y] to this prompt.
SAVEDLISTS
The SAVEDLISTS file stores any created list a user has saved using the
SAVE.LIST command. Envision Runtime also uses the SAVEDLISTS file to
temporarily store lists of record IDs for use in procedures. In order to purge
the SAVEDLISTS file:
Step 1. In the database environment, select the SAVEDLISTS file, sorting by ID.
Save this list to the SAVEDLISTS file.
:SSELECT SAVEDLISTS
:SAVE.LIST SAVEDLISTS.LIST
Step 2. Edit the list you just created. Determine the SAVEDLISTS file records you
want to save. remove the line containing the name of the record that you want
to save from the list. When the list contains only those records you wish to
remove from the SAVEDLISTS file, file the list back into SAVEDLISTS.
Step 3. Retrieve the list you just modified and delete the records from the
SAVEDLISTS file:
:GET.LIST SAVEDLISTS.LIST
:DELETE SAVEDLISTS
The system prompts you to make sure you want to delete records from the
file using a select list. Answer [Y] to this prompt.
Troubleshooting
Troubleshooting
Introduction to Troubleshooting
Recovery Guidelines
Occasionally application programs are interrupted because:
A user breaks out of a program or turns off a terminal,
Because the user remote account does not have the vocabulary to do the setup
for the recovery, this must be done from the main remote account. The actual
recovery, however, must be done from the user remote account that initiated
the process.
Troubleshooting Envision-Based
Software
In order to troubleshoot an interrupted program, it is helpful to understand the
steps that a program follows during execution. Below are these steps and the
utilities that allow you to view the status of each step.
Step 1. When you run a program, the program builds a paragraph containing the steps
that the program will follow. These steps may include programs, subroutines,
and select statements. This paragraph is written to the VOC and to the
JOBSTATS files with the key of mnemonic_loginID_time_date.
You can view the paragraph from the View Batch Process Status (VBS) form.
In addition, VBS shows the number of records processed and remaining, the
elapsed time, the time remaining, and the number of errors. Detail to View
Single Batch Job Step (VBSD) to view additional details for each step
including the last record read.
Step 2. As each step of the paragraph is run, the status in VBS changes from a blank
to “started”. When the step is complete, the status changes to “finished”.
Step 3. When the program has successfully completed, the VOC paragraph is deleted.
The completed steps remain in the JOBSTATS file and may be reviewed for
errors in VBS.
Step 4. If the program is interrupted, you can determine the step that the program
stopped on by looking at the VBS form. At this point, you have the
appropriate information to call Response Line to assist in recovery.
Step 5. You may be able to restart the process from the beginning depending on the
implications of the completed steps. Or you may be able to start the process
where it left off. In either case, the Rerun a Procedure (UTRR) form allows
you to either start the process from the beginning or recreate the VOC
paragraph with the process steps.
If you choose to restart the process from the beginning, you may do so within
UTRR.
If you want to restart the process where the process left off, in UTRR, choose
the option to recreate the VOC record. You may then edit the VOC record and
delete the steps from the paragraph that successfully completed. You can then
run the paragraph and it will pick up with the next step.
Problems in Envision
Applications
My terminal display is all messed up when I Missing or invalid display Check the user’s DEVICE record. For port-based systems, run
enter an application. table defined in the DEVICES SND and determine the DEVICES type from the user’s line
record. number. For switch-based systems, use the user’s login ID as the
DEVICES type. Run SDD from any application for the device
definition in question. Go to the display table field and use the
LookUp Processor to select a valid display table.
The function keys on my keyboard don’t do Missing or invalid keyboard Check the user’s DEVICE record. For port-based systems, run
what the template says they are supposed to. table defined in the DEVICES SND and determine the DEVICES type from the user’s line
record. number. For switch-based systems, use the user’s login ID as the
DEVICES type. Run SDD from any application for the device
definition in question. Go to the display table field and use the
Runtime Administration, March 10, 2010
A mnemonic does not show up on the menu. Insufficient security right for The Runtime Menu Processor does not show mnemonics for
the mnemonic. which a user has no security rights. If the user is supposed to
have access to the process, see the solution to the last problem.
I can’t enter data into a field on a screen. Insufficient Field Security Check the Field Security definition for the field in question on
Rights. SCDF. The security class assigned for field security. Then check
or
the user’s security classes on SOD. If the user should have
Data doesn’t show for a field; all I see are access to the data in the field, add the proper security class for
asterisks. the secured field.
When I enter an application, a screen runs and Initial application mnemonic If the user should have access to more than one process, check
then I exit from the application without seeing is a screen process, not a the initial menu mnemonic on SOD. If the user does not have an
I made changes to (Record Security User Changes to some Runtime Re-initialize Envision. A user can re-initialize the Envision
Characteristics, Record Security Criteria, screens do not take effect environment by:
Transaction Logging). When I run another until Envision is re-initialized.
• leaving the database environment entirely and returning
process, the changes don’t show up.
• logging off the system and starting the login procedure over
again
• returning to the database environment prompt and executing
the Envision initialization program ENVINIT.
255
Table 12: Problems With System Setup or Security (cont’d)
256
I had a COMO running while executing a The BROWSE utility cannot You must re-initialize Envision. A user can re-initialize the
screen. I tried to view the COMO record using process terminal display Envision environment by:
BROWSE and I was blown out. characters.
• leaving the database environment entirely and returning
• logging off the system and starting the login procedure over
again
• returning to the database environment prompt and executing
the Envision initialization program ENVINIT.
Table 13 lists common Envision initialization error messages with their causes and solutions.
• UPSPECS
• UFD
• HOLD
• PH
“FATAL security fault: Missing Renewal Missing or invalid renewal Call Datatel. The renewal codes control what Envision modules you
Code Record” codes detected. can run. There may have been a problem with your last release
installation or VOC pointers may be damaged.
“SYSTEM DATE current.date precedes The date stored as the last Reset the system date for your computer. If the message persists,
“Warning: Lease to module expired date (n The date on which your Call Datatel immediately. There may have been a problem with your
days grace)” software lease expires has last release installation or you may need to install a new release.
passed.
“Please contact Datatel”
“FATAL security fault: Bad Customer Damaged or missing renewal Call Datatel immediately. The renewal codes control what Envision
Number in code record. modules you can run. There may have been a problem with your
last release installation or VOC pointers may be damaged.
Renewal Code Record“
“FATAL: Network definitions not present.” Envision cannot read the Check the VOC pointer for the SYSDEFS file. It should be pointing
TASKLIST record in the to the current release account. If this record is damaged or missing,
SYSDEFS file. call Datatel immediately. If both the SYSDEFS VOC record and the
TASKLIST record in SYSDEFS are in order, call Datatel. There may
have been a problem with your last release installation or VOC
pointers may be damaged.
“Unauthorized access to secured terminal.” Incorrect password entered for If the password was misspelled, enter the correct spelling. If the
a secured terminal. password is not misspelled, you may think the password is one
thing while Envision thinks it is another. Check the device definition
on the Device Definition (SDD) form and make sure the device
password is correct.
Runtime Administration, March 10, 2010
© 2010 Datatel, Inc.
Table 14 lists common application initialization error messages with their causes and solutions.
© 2010 Datatel, Inc.
Runtime Administration, March 10, 2010
“Improperly set up user: login. See your Missing or invalid OPERS Check the user’s OPERS record. Start with the application the
system administrator.” record. user is trying to run. Enter the application and run the SOD form. If
the user’s OPERS record is not in the current application,
determine if the OPERS record is in an application higher up in
“Password expired on date” The user’s password has If the user’s need to access your system has ended, delete the
expired. user’s operator definition. If the user should still have access to
the application in question, check the password expiration date on
the SOD form.
“WARNING: Your password expires on The user’s access to the If the user’s access to the application should end on the date
date. application is near its end. specified, do nothing: the user will be unable to enter the
application on or after that date. If the user should continue to
See your security administrator“
have access to the application, change the password expiration
date on the SOD form.
Runtime Administration, March 10, 2010
“Access to appl has been denied” Invalid operator definition or If this message appears alone, the user has entered an incorrect
incorrect Envision password. Envision password. If the password was misspelled, have the
user type in the correct password. If the user has typed in what he
thought was the correct password, check the Envision password
on the SOD form. If this message appears with another message,
see above for the other message.
© 2010 Datatel, Inc.
Troubleshooting
Envision Diagnostics
In This Chapter
This chapter provides information that helps explain and demonstrate the
various diagnostic systems available in Envision. Table 15 lists the topics
covered in this chapter.
The errors are logged to the UT.THROWN.ERRORS file. The contents of the
UT.THROWN.ERRORS file can be examined by using the Thrown Errors –
List (TELI) form and purged with the Thrown Errors – Purge (TEPU) form.
System administrators have control over the amount of system resources that
the system devotes to self-diagnosis. By adding a "SET.CONFIRM.LEVEL"
statement to the LOGIN paragraph, they can increase or decrease this for a
given environment. System administrators should use
SET.CONFIRM.LEVEL 2
SET.CONFIRM.LEVEL 0
for the least amount of checking. (Deleting the command from the LOGIN
paragraph is equivalent to setting the level to 0.)
Datatel highly recommends that the level be set to the highest number in
every test and development environment.
It is also possible to temporarily change the level for just the login session,
without affecting other users. The Set Session Confirm Level (SSCL) form
can be used to do this. The online help for the SSCL form provides more
information.
You can also still use the UT Process Debug Activation (UTDB) form to
trigger diagnostic code that predates the GRDS system, but it is important to
understand that the GRDS system is backward compatible with the UTDB
process. By requesting any numeric GRDS service, all diagnostic codes that
predate the GRDS system will also be triggered. There is no need to use the
UTDB form for non-WebAdvisor debugging.
Both systems can help you determine possible sources of problems, however,
the GRDS system is the newer, improved system for debugging Envision.
Although you can still use the UTDB form to help you determine possible
sources of problems, the GRDS system is significantly more powerful and
easier to use.
Self-Diagnostic Services
GRDS supports Triggered Assertion Checking. The IT industry also refers to
this concept as “Embedded Self-diagnostics”, “Enforced Design by Contract”,
or similar terminology. For more information, see “System Integrity
Checking” on page 263.
The code generated for GRDS tends to be more efficient than what was hand-
coded for the UTDB form. This is true when debugging is inactive, and often
true even when it is active.
GRDS enforces using the process ID as the trigger string. To access GRDS
diagnostics for process X, then X is the process for which you request services
without exception.
GRDS log services can be classified into two types: automatically generated
and programmer-specified.
“Automatically Generated Services” beginning on page 279 are those that are
automatically embedded into a process by the generator. You do not need to
do anything in order for these services to be available. They are universally
available for every Envision-generated process except external (EGP)
processes.
---------------------------------------------------------------
GRAS.REQUEST.SET record used: SAMPLE
---------------------------------------------------------------
Service Requests
================
1) * / 1,PE,KS,CC,GS,AE,PX,AD,ET,NK,HE,HX,HS,SD
2) S.DEBUG.INIT /
3) S.CHECK.PROCESS.LEVEL /
---------------------------------------------------------------
2_\
2_3| pe} * MENU_PRCSR (from MENU.INIT @1710)
2_3| cc} 1=UT.INIT@52 2=MENU.INIT@1710 3=MENU_PRCSR@15
2_3| gs} GEN V4.8.1 / 02:08:38 Aug 22 2006 / SDW2K3APP / jgv / etk48grds
2_3| ks} No active select lists
2_3| ae} Arg 1: MENU.ID =UT
2_3| ae} Arg 2: POP.MENU =
2_3| ae} -------------<>-------------
2_3_\
2_3_4| pe} * ACCEPT_DATA (from MENU_PRCSR @1814)
2_3_4| cc} 1=UT.INIT@52 2=MENU.INIT@1710 3=MENU_PRCSR@1814 4=ACCEPT_DATA@15
2_3_4| gs} GEN V4.8.1 / 02:08:00 Aug 22 2006 / SDW2K3APP / jgv / etk48grds
2_3_4| ks} No active select lists
2_3_4| ae} Arg 1: PROCESS.ID =UT
2_3_4| ae} Arg 2: AR.VWVAR: MAT(25)
2_3_4| ae} (1) =1
2_3_4| ae} (12) =0010001111111011110011
2_3_4| ae} Arg 3: MAX.PRMPT =1
2_3_4| ae} Arg 4: V.BASE.LINE has 2 fields
2_3_4| ae} Arg 5: AR.CWVAR: MAT(50,25)
2_3_4| ae} (1,1) =MENU_PRCSR
2_3_4| ae} (1,7) =10
2_3_4| ae} (1,8) =10
2_3_4| ae} (1,9) =10
2_3_4| ae} (1,10) =20
2_3_4| ae} (1,20) has 2 fields
2_3_4| ae} <2> =1
2_3_4| ae} (1,21) =Enter Mnemonic or Selection Number, or press FINISH
2_3_4| ae} Arg 6: R.CWSTATE has 2 fields
2_3_4| ae} <1> =1
2_3_4| ae} <2> =1
2_3_4| ae} -------------<>-------------
2_3_4| 1} @123: XTEST1 =THIS HAS~A CONTROL CHARACTER IN IT !Contains non-printing characters!
2_3_4| 2} @124: XTEST2 =This has 200 trailing blanks<- +200 trailing spaces!
...
2_3| --------------------------------------------------------------
2_3| Closing GRDS session log "SAMPLE" at 00:04:31 Aug 23 2006
Chain Prefix
Every line begins with the call chain prefix. This is a series of integers that
represents the current call chain.
To reduce the size of the log (and because it never changes), process 1 is
omitted. Each integer stands for one process currently active in the chain.
Outliner
Service Code
Next, there is usually a space, the service code that caused that line to be
logged, a right brace "}", and the diagnostic text.
Process Entry
The process entry (pe) line is always preceded by a blank line. This makes it
easier to locate where a process started up.
A process entry line shows the ID of the process starting up, and how it was
invoked. In the example above, it shows that ACCEPT_DATA was called
from line 1814 of process MENU_PRCSR.
Process Exit
A process exit (px) line shows a process terminating, and shows where the
returned-to process resumes.
A line produced by the call chain (cc) service maps each of the integers in the
line’s prefix to a process ID.
Arguments
Process arguments are shown with the abbreviation "Arg". In the following
example, the process’ third argument’s name is MAX.PRMPT and its value is
"1".
Field Counters
Field counters are shown inside angle brackets. The following two lines show
that field 6 of R.CWSTATE has a value of "Bob".
Null Fields
Fields with no data are skipped (to minimize log size). In the previous
example, because field 6 was the first field shown, the first five fields of
R.CWSTATE were null.
Matrix Dimensions
The following two lines show that the process’ second argument is
AR.VWVAR, that it is a one-dimensional matrix of 25 cells, and that the third
cell contains the value “MD”:
In order to minimize the size of the log, matrix cells with no data are skipped.
Null Value
Leading Spaces
The presence of leading spaces can be seen following the equal sign.
In the following example, it is evident that there are three leading spaces:
Trailing Spaces
2_3_4| 2} @124) XTEST2 =This has 200 trailing blanks<- +200 trailing spaces!
A string (simple variable or individual matrix cell) that contains field marks is
identified as a multi-field entity. The field count is given, but null (empty)
fields are not shown.
Some of the many things that can be determined from the following example
are:
Neither of the two fields in the fourth argument have data.
Argument 6 contains three characters (an "X", a field mark, and a "Y").
AE/AD separator
The last line produced by the "ae" (Arguments at Entry) service is a line of
dashes. This serves to visually separate it from lines produced by the "ad"
(Argument Differences) service.
Current Location
Lines produced by SHOWA or SHOWC log their current location (the line
number in the generated source).
The example below shows a diagnostic line that was produced by line 60 of
the process.
Multi-valued Data
Fields are shown one per line, but multiple values of the same field are shown
on the same line.
Screen Hooks
Control Characters
2_3_4| 1} @123: XTEST1 =THIS HAS~A CONTROL CHARACTER IN IT !Contains non-printing characters!
^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
$TABLE
The effect of the $TABLE function of the SHOWA statement is shown below.
SHOWA $TABLE(GUSV.A1)
The system added GUSV.A2 and GUSV.A3, because it knew that GUSV.A1
was part of a subfile that also contained GUSV.A2 and GUSV.A3.
$TABLE(GUSV.A1,GUSV.A2,GUSV.A3)
Context Markers
In order to provide points of references in the log, the system will add Context
Markers whenever you select a mnemonic or enter data. These context
markers are designed to stand out in the log.
The lines shown below that start with "*" are a context marker. It shows that
the SOD mnemonic was selected at this point.
2_3_\
2_3_/ px} * RETURN to MENU_PRCSR @1732 (from S_MIO_READ)
*_3|
*_3| !!} ================================================================
*_3| !!} MNEMONIC: UT-SOD
*_3| !!} ================================================================
*_3|
2_/ px} * RETURN to MENU.INIT @2094 (from MENU_PRCSR)
The context marker below shows that "JGV..." was entered into the SOD
form’s LookUp prompt.
Gap Detection
When the system detects a gap in the call chain, it inserts extra lines as needed
in order to provide context to the diagnostic text being logged.
(The PE, CC, and PX services for processes UTOPRS and S_MIO_READ
only.)
You might end up with something like the following (line numbers 397-417
added for instructional purposes):
...
397] 2_3_4_\
398] 2_3_4_5| pe} * S_MIO_READ (from S.GET.RESOLUTN @145)
399] 2_3_4_5| cc} 1=UT.INIT@49 2=MENU.INIT@1981 3=UTOPRS@3072 ... 5=S_MIO_READ
400] 2_3_4_/ px} * RETURN to S.GET.RESOLUTN @145 (from S_MIO_READ)
401. 2_3_/ --} * RETURN to UTOPRS @12 (from S.GET.RESOLUTN)
402. 2_3_\ ++} * S.INPT.SEL.ID.LKUP (from UTOPRS @3072)
403. 2_3_4_\ ++} * S.LKUP.ID.PARSE (from S.INPT.SEL.ID.LKUP @335)
404. 2_3_4_5_\ ++} * S.SELECT.LISTS (from S.LKUP.ID.PARSE @154)
405. 2_3_4_5_6_\ ++} * S_MIO_EXECUTE (from S.SELECT.LISTS @594)
406. 2_3_4_5_6_7_\ ++} * S_MIO_SEL (from S_MIO_EXECUTE @473)
407] 2_3_4_5_6_7_8_\
408] 2_3_4_5_6_7_8_9| pe} * S_MIO_READ (from S_MIO_SEL @784)
409] 2_3_4_5_6_7_8_9| cc} 1=UT.INIT@49 2=MENU.INIT@1981 3=UTOPRS@3072 ... 9=S_MIO_READ
410] 2_3_4_5_6_7_8_/ px} * RETURN to S_MIO_SEL @784 (from S_MIO_READ)
411. 2_3_4_5_6_7_/ --} * RETURN to S_MIO_EXECUTE @473 (from S_MIO_SEL)
412. 2_3_4_5_6_/ --} * RETURN to S.SELECT.LISTS @594 (from S_MIO_EXECUTE)
413. 2_3_4_5_/ --} * RETURN to S.LKUP.ID.PARSE @154 (from S.SELECT.LISTS)
414. 2_3_4_5_\ ++} * UTRESO (from S.LKUP.ID.PARSE @565)
415] 2_3_4_5_6_\
416] 2_3_4_5_6_7| pe} * S_MIO_READ (from UTRESO @21)
417] 2_3_4_5_6_7| cc} 1=UT.INIT@49 2=MENU.INIT@1981 3=UTOPRS@3072 ... 7=S_MIO_READ
...
Note that the only service lines you actually requested were the ones marked
with a square bracket. The rest were filled in by the system when it detected
gaps.
CC CALL CHAIN: Log how process was invoked (show full call chain).
In Mid-Process
HS HOOK SEQUENCE: Log order in which screen hooks are (or would be)
executed.
SD SHOW DEMANDED: Show V., VL., KV., and KEY. vars when change
detected.
At Process Exit
Requesting AX and AD, but not AE, results in only AD being honored.
Note that AE, AX, and AD can also be associated with the SHOWA or
SHOWC statements. Often a process will pass data in or out via COMMON
rather than arguments defined to Envision. In that case, requesting the "AE"
(Arguments at Entry) service for that process will show you an incomplete
picture of the data flowing in and out of that routine. By allowing "@AE" as
part of the syntax of the SHOWA statement, you can add those "undefined to
Envision" arguments to be logged whenever the AE service is requested
(similarly for AX and AD).
The PX service decreases the logs indentation level, first logging a line
showing:
The ID of the process.
CC (Call Chain)
The CC service logs a single line showing the complete call chain, complete
with process IDs and line numbers.
GS (GEN Stamp)
The GS service logs a line showing information about the last time the
process was generated:
Date
Time
Account name
Server name
NK (Next Key)
The NK service provides diagnostics for processes that use the "FOR_...
SELECTED..." syntax. With each iteration of the loop, immediately after the
key is obtained from the active select list, its value is logged to the GRDS
buffer and the buffer is forced to flush (even if not yet full).
If there are more than 75 keys active then, in the interest of keeping the log
from becoming too large, the keys are copied to a savedlist, and the name of
the savedlist is provided in the log.
Value of active variable (only for the three hooks listed below)
• Input Source hook: INPUT.DATA
• Input Edit hook: EDITED.DATA
• Output Edit hook: OUTPUT.DATA
SD (Show Demanded)
The SD service checks the value of all V., VL., KV., KEY., and .ADD.MODE
variables for all demanded files and fields, and logs their value whenever they
have been changed. In both form and batch processes, the check is performed
after records are parsed (that is, after READ and after return from
CALL_SCREEN and CALL_SUBR). In form processes the check is also
performed at the start and end of every process and field hook.
One use for this service is to reveal invisible data (process data not shown on
screen):
The value of phantom fields.
The service also helps clarify when these variables are assigned (for a form
process, try combining the HS and SD services).
ET (Elapsed Time)
This provides a line indicating how many milliseconds the process took.
Programmer-Specified Services
Programmer-specified services are available only if you added supporting
code to your process.
A through Z Show manually added diagnostics for only the letter selected
The GRDS system keywords SHOWA and SHOWC allow you to easily
embed code into processes as required by these manual services.
The numeric codes are cumulative. Requesting one automatically requests all
lower-numbered services as well. Services A through Z are independent of
one other. They are not cumulative.
Accessing GRDS
Access the Envision Diagnostic Tools (EDT) menu in UT under the System
User (SU) menu.
The SSCL form allows you to set the session CONFIRM level.
The GRSS form allows you to define named sets of service requests.
The TAIL form mimics UNIX's tail command in that it allows you to monitor
an OS-level file as it grows. It does so in a platform-independent way. The
TAIL form can be used by person A to monitor person B’s GRDS diagnostic
log.
The TEDT form displays all information about one specific entry in the
UT.THROWN.ERRORS file.
The PRGR form allows you to define named groups of Envision process IDs.
These groups can then be referenced on the GRDS service request forms
(GRSS and its detail form GRSD) to quickly request the same set of services
for a collection of processes.
Example
IF DATATEL.DEBUG THEN
XL.DEBUG.MSG<-1> = "entering special process, v.id =":V.ID
XL.DEBUG.MSG<-1> = "v.last.name =":V.LAST.NAME
$INSERT I_DEBUG
END
Technical Tip: Use the fields in the upper part of this form for
debugging UI Desktop/web processes. The fields in the lower part of
the form are used to debug WebAdvisor processes. Information about
debugging WebAdvisor processes is available in WebAdvisor
documentation and online help for the UTDB form.
Step 1. To quickly remove all current debug strings for UI Desktop/web, enter Y in
the Clear String field. The entire string is reset to Null. This field does not
clear the WebAdvisor debug strings.
Step 2. Enter a process debug name for the process that you want to debug in the
Modify String field. When you enter text, the Debug String field is updated.
You may add multiple debug strings. Spaces in the text are ignored by the
debug string.
Note: You can also remove a string that already exists in the Debug
String field by entering that string in the Modify String field
Step 3. For processes with a large amount of debug information, you may want to see
only certain levels of output. You can set the level of debug information from
1 to 99; 1 showing the least amount of information, and 99 showing the most.
Envision defaults to 1.
Step 4. Enter Y to clear the read cache log that is generated when read-cache logging
is on. If your read cache size is a negative number, MIO logs all read requests
into the HOLD file under a key name of USERID.READ.CACHE, (where
USERID is an upper case version of your login id).
Step 6. Override the default cache size for this session by entering a number
between -1000 and 1000. The default read cache size is taken from the Read
Cache Size field on the Envision Parameters Edit (EPED) form (for Envision
4.7). (If no value exists on the EPED form, then 100 is used as the default.)
Enter zero to turn the cache off. Enter a negative number to turn a read log to
on. A record is written to the HOLD file, which is named
USERID.READ.CACHE (where USERID is an upper case version of your
login name). The log file notes each file and record read, along with the
number of times a cache hit occurred, and the number of physical reads that
occurred.
WebAdvisor debug mode remains active as long as the fields on this form
contain data.
Step 7. Enter the name of the process and ID of the WebAdvisor user you want to
debug. As it runs, debug messages are written to the
WWW.SCREEN.DEBUG files, which are keyed by
SenderControlID*counter*SecurityToken*[processID].
It is not necessary to visit both the UTDB and GRS1 forms to do this.
Everything can be done from within the GRS1 form (and its detail form
GRSS).
Whenever you use the GRS1 form to request any of the numeric services for a
process, the system automatically adds that process’ “ID” to the same system
common variable that the UTDB form maintains.
In other words, the system behaves as if, in addition to entering the GRS1/
GRSS forms, you had also gone to the UTDB form, entered the process ID
into the “debug string” field, and saved out of the UTDB form.
Note: If a legacy process uses something other than its process ID for
its debug string, you can still use the GRS1 form to trigger those old-
style diagnostics. Just pretend that debug string actually was a
process ID and request a numeric service for that "process". The
GRSS form will warn you that it is not a valid process ID, but you can
ignore the warning – it will still add the string to UTDB's system
common variable.
Appendices
Appendices
Previous Field
Jump to Field
Next Group
Previous Group
Jump to Group
Go to First Group
Go to Last Group
Scroll to Page #
Next Element
Previous Element
Exit
Finish
Update
Cancel
Delete Record
Detail
Direct Access
Process Help
Field Help
Refresh Screen
Function Start
Attention Characters
Cursor HOME
Cursor UP
Cursor RIGHT
Cursor DOWN
Cursor LEFT
TAB Cursor
Backspace
Delete Character
Insert Character
RETURN of ENTER
Delete Item/Line
LT Left T 5 21
VL Vertical Line 7 23
NB Normal Block 8 24
C Cross 9 25
RT Right T 10 26
HL Horizontal Line 11 27
LB Light Block 12 28
BT Bottom T 14 30
DB Dark Block 16 32
Hidden Video attributes Enter a [[1]] for hidden video attributes. Enter a [[0]] if 41
occupying a space attributes occupy a space.
Type of fill characters Enter a [[1]] for character attributes. Enter a [[2]] for 42
line attributes.
Upper case prompts Enter a [[1]] to convert all template and lookup 43
prompts to uppercase. Enter a [[0]] for all lookup
prompts to appear as upper and lower case.
Form Reference
This appendix provides a reference for all of the forms in Envision Runtime.
The forms are presented in alphabetical order by mnemonic. For each form,
the following is provided:
A process overview, which describes the general purpose of the form
A sample form
For data entry and inquiry forms, a query language table that lists the file
and data element names you use to create your own query reports. The table
provides information about the field and file names to use when you create
queries to retrieve data shown or entered on a form.
The ACSO form should be highly secured. Normally, a Colleague Studio user
would shelve or cancel the checkout of their own checked out resources from
within Colleague Studio. However, the ACSO form allows an authorized user
to perform those actions from Envision when the Colleague Studio user who
checked out the resource is not available.
For a SQL Server environment only, use the CC Reset for SQL Server
(CCRS) form to recreate all computed column functions.
To run this process, verify the path to the C# compiler on the application
server. This field will display the path information specified on the Computed
Column Parameters form in SA Valet. Next, enter Y in the Remove and Re-
deploy Computed Column Objects field to:
Remove all C# computed column support objects from the SQL Server
database.
Start a re-deploy of the Datatelx and Colleague assemblies.
When you save from this form, you see a warning message that reminds you
that all users should be logged out of the environment and that a backup of the
environment should be made. Click OK to continue and recreate all computed
column functions, or click Cancel. You can review the CCRS report at the end
of this process for any errors or warnings that were generated.
Note: Before you run the CCSR process, you must first run the CUSC
process.
The CCSR process will populate the SCAN.CODE.RESULTS file. This file
contains the problems found during the CUSC process on all custom
processes scanned. Each record in the SCAN.CODE.RESULTS file
corresponds to a process that was scanned. Whereas the CUSC process scans
selected or specific processes from within the application, the CCSR process
reports on only those particular scanned processes (and not all processes from
within the application). For example, if the CUSC process scanned only
twenty processes from within an application, then the CCSR process will
report only on those twenty processes, or a subset of those twenty, depending
on the selection criteria.
For information about the Custom Code Scanner (CUSC) process, see its
process help.
As you specify the items you want to declare, a list of all derived items is built
in the File/Record window, available when you detail to the Custom
Packaging Detail (CDED) form. This list is built by scanning the pieces you
specified and identifying all associated items. This list contains the computed
columns, records in any files that you specify in the Records From File group,
the File Specifications group, and all processes, files, and menus that you
specify.
The information you enter using this process is stored in a record in the
MOVEINFO file. If the Action field is set to CO (Save Custom Declaration
and Check Out Items), each item is marked for custom development in the
product repository. After you declare and check out custom items, you can use
the Custom Release Package Build (CPKG) form to create custom release
packages. You must check out a custom declaration before using it on the
CPKG form. The CPKG process builds the custom release package while also
checking in the custom declaration.
Before checking items out, the CDEC process verifies that an item is not
already checked out on another custom declaration in this or a sister
environment (other application environments connected to the same local
product repository as this application environment).
When populated from Colleague Studio custom code management, this form
is inquiry only.
When populated from the Custom Declaration (CDEC) form, entries are
automatically added to this list for each piece specified in the Computed
Columns, Records From File, File Specifications, Processes, and Menus
windows.
When populated from the Custom Declaration Objects (CDOB) form, entries
are automatically added to this list for each piece specified in the Entities and
ELF Spec Processes window.
A link is maintained automatically between each piece and the items derived
from it. However, you can choose whether to maintain this link by using the
Auto field. The codes in the Auto field also specify how items will be handled
on a rescan. In addition, you can use the Include field to choose whether to
prevent an item from being released. For further details, see field help.
The information you enter using this process is stored in a record in the
MOVEINFO file. Note that this record can only hold items from the
application currently being worked on. To make changes to an existing
MOVEINFO record, you must access the CDOB form from the application
where the MOVEINFO record was created. Rules and ELF processes are
always created in the CORE application.
If you set the Action field to CO (Save Custom Declaration and Check Out
Items), each item is marked for custom development in the product repository.
After you declare and check out custom items, you can use the Custom
Release Package Build (CPKG) form to create custom release packages. You
must check out a custom declaration from the CDOB form before using it on
the CPKG form. The CPKG process builds the custom release package while
also checking in the custom declaration.
Before checking items out, the CDOB process verifies that an item is not
already checked out on another custom declaration in this or a sister
environment (another environment associated with the same local product
repository).
You can detail to the Custom Declaration (CDEC) form (and then to the
Custom Packaging Detail [CDED] form) to view all items on the custom
declaration and their details. The bottom window on the CDPI form displays
any active custom declarations from sister environments. The CDPI form
displays all Colleague Studio objects that are currently Checked out, Shelved,
or Ready for build.
These reports can help you administer security for screen chains.
For output to the HOLD file, besides the name of the record specified via the
banner option, you are able to specify the output security of the created
record:
PB Public, in the HOLD file itself, with wide open security.
Note: You can run the CPKG process for any Colleague application,
regardless of the application that is currently opened.
When you save the CPKG form with the Execute Build field set to “Yes” and
the WorkGroups window populated, you can view:
Built Objects That May be Added. A list of Colleague Studio objects that
were previously Built in one of the WorkGroups.
Objects Excluded Due to Status. A list of Colleague Studio objects that
are Checked Out or Shelved in one of the WorkGroups.
New Objects on this Build. A list of Colleague Studio objects that are
Ready for Build in one of the WorkGroups that were not on a previous
build of this same custom release package.
If any of these lists contain Colleague Studio objects, the Custom Package
Rebuild Detail (CPKR) form appears where you can:
Specify whether or not to include previously Built Colleague Studio objects
in the rebuild.
View Colleague Studio objects that will be excluded from the rebuild.
View newly added Colleague Studio objects that will be included in the
rebuild.
If you attempt to rebuild using the Custom Release Package Build (CPKG)
form while in this state, a message will direct you to run the custom release
package through the CPKP process first.
The CPKP process also produces a report of the MOVEINFO records created,
updated, or left unchanged.Newly created or updated MOVEINFO records
are saved only if you enter “Yes” in the Update Mode field.
When saving from the Custom Release Package Build (CPKG) form, the
CPKR form appears if there is any data to display on the form. This
information includes the following:
Built Objects That May be Added. A list of Colleague Studio objects that
were previously Built in one of the WorkGroups.
Objects Excluded Due to Status. A list of Colleague Studio objects that are
Checked Out or Shelved in one of the WorkGroups.
New Objects on this Build. A list of Colleague Studio objects that are
Ready for Build in one of the WorkGroups that were not on a previous
build of this same custom release package.
Included on the rebuild because they were newly added to the custom
release package.
Primarily, the CUSC process identifies custom code that has non-columnar I/
O issues. However, code with such issues will still function in any database in
Release 18 and higher, with a few exceptions as noted below. You will
increase performance of your code by modifying it to comply with columnar
I/O. However, you must decide if the performance benefits are greater than
the cost of changing some of the code.
The CUSC process looks for the following items in your custom code's
specifications (appl.PRCS.DEF, .INSERTS, and so on):
The use of R-dots. These are variables such as R.VOUCHERS or
R.PERSON that contain the entire record for which they are named. For
instance, R.PERSON will have a person’s first name, last name, birth date,
and all other fields from the PERSON file. It is easy to understand why this
is not a best practice: multiple tables need to be opened in order to get all
the information, and it is possible and likely that only a few elements are
really needed. You should change these R-dots to use standard Envision V-
dots. R18 will still work with R-dots, but these processes cannot be flagged
to use columnar I/O.
Direct calls to @MIO, more specifically, calls to
@MIO.READ.RECORD and @MIO.WRITE.RECORD. Whenever
one of these two calls is used, the entire record is read. You should to
change them to use Envision as noted for R-dots above.
UDT IO - "Flat" reads and writes. Custom code that uses flat reads and
writes will not work in SQL Server or Oracle databases in R18. They will
also not work in R18 in a UniData database with distributed deployment.
These include calls to READ, WRITE, READV, WRITEV, OPEN, and a
few others. You should replace them with EBSL or, if not possible,
@MIO.READ.RECORD and @MIO.WRITE.RECORD.
Pre-Process Code and Subroutines. Routines that are specified as Pre-
Process Code or Pre-Process Subroutines (on the Batch Global Parameters
[BGP] form) cannot use Columnar I/O. You should change them to Main
and Subroutine types, respectively.
When the CUSC process has completed its scan, it will populate the
SCAN.CODE.RESULTS file. This file will contain all the problems for the
processes being scanned, one record per process. To produce a report for the
problems found, use the Custom Code Scanner Report (CCSR) process.
For example, if you specify the Core System (CORE) as the application you
wish to update, then all of the records in the CORE.VOC file with a type of
“F” (for File) are examined, and any dictionary items in any of those files that
have an ICONV or OCONV in the LOC field or a date format in the CONV
field are updated.
Since processing can occur fairly quickly, however, you may wish to obtain a
printout of this information. To obtain such a printout, enter C in the Execute
in Background Mode field to capture a record of the processing in a COMO
(command output) file. The output is captured in a record in the PH file under
the job statistics ID that is displayed on the Process Submission form,
prefaced by “O_”; for example, O_DDCV_EJR_40741_9733. After
processing is complete, exit and spool the COMO file to the printer.
Using the Envision Tool Kit, programmers can also specify fields to be
tracked using the Field History (FLDH) form. Using the DHST form, you
may be able to delete fields that a progammer has added to the list on the
FLDH form, depending on whether the programmer allowed deletions.
Note: The FLDH form is available only through the Envision Tool Kit.
Use the Edit Record (EDRC) form to enter an existing file name from which
you can then choose a record you want to edit. If you detail on the record, you
can use a text editor window to make your changes. You can also delete a
record.
Based on the information passed into the subroutine (see Table 18), the
subroutine must determine the current user’s access rights to the requested
record:
Full access
Modify-only access
Inquiry-only access
No access
For example, suppose the user's security class setup grants the user
inquiry-only access to the EDRC form. However, for a particular record
the XS.GET.RECORD.ACCESS.RIGHTS subroutine grants the user
full access. The user will still have just inquiry-only access to the
record.
1. Argument 1: Input only. Passes in the file name specified at the EDRC file
name LookUp.
2. Argument 2: Input only. Passes in the record ID specified at the EDRC
record ID LookUp.
3. Argument 3: Input only. Passes in a Boolean flag that indicates whether the
record already exists.
• A true value means that it already exists.
• A false value means it will be created (if this subroutine grants the user the
right to do so – see Argument 6).
4. Argument 4: Input only. Passes in two strings that identify the current user.
The two strings are separated (delimited) by a field mark (@FM).
• Field 1: The current user’s PERSON ID.
• Field 2: The current user’s login ID.
5. Argument 5: Input only. Passes in other lists of information about the user
to determine the rights the user should be given. Two lists are passed in.
The first list is separated from the second by a field mark (@FM).
• Field 1: An @VM-delimited list of the user’s ORG.ROLEs.
• Field 2: An @VM-delimited list of the user’s SECLASSes.
6. Argument 6: Output only. Must pass back information that defines this
user’s access rights.
If this is a new record (see Argument 3), then argument 6 must return a
boolean flag:
• A true value (1) means the user is allowed to create it.
• A false value (0) means the user is not allowed to create it.
If the record already exists, argument 6 must return one of the following to
specify this user’s access rights to the record.
• Null. No access rights (that is, cannot look at the data).
• Code “V” (View-only). Can view the data (but not modify or delete).
• Code “M” (Modify). Can view and modify the data, but cannot delete the
record.
• Code “A” (All). Can view, modify, and delete the data (full access).
The FHDT form is inquiry-only. You cannot use it to change a record or revert
it to an earlier state.
Table 19: Query Lang Retrieval Help for Field History Detail (FHDT) Form
Where Field History Detail (FHDT) Data Is Stored
To retrieve data from use this file and this field
Field HIST HIST.FIELD.NAME
Table 20: Query Lang Retrieval Help for GUI Function Button (GUIF) Form
Where GUI Function Button (GUIF) Data Is Stored
To retrieve data from use this file and this field
GUI Function Button Template GUI.FUNCTION GUIF.ID
After you complete the International Parameters form, use the Dictionary
Date Convert (DDCV) form to change your data dictionary formats for date
fields to reflect the date formats you indicate on this form. This will ensure
that query reports also display dates in the chosen format.
Note: The format for dates used in query report headings (the “D”
option) is independently controlled by the database management
system’s DATE.FORMAT command.
Table 21: Query Lang Retrieval Help for International Parameters (INTL) Form
Where International Parameters (INTL) Data Is Stored
To retrieve data from use this file and this field
Country Code INTL.PARMS HOST.COUNTRY
When an end user runs a procedure, Envision creates and runs commands
stored as a paragraph in the command language of your host computer. Most
of the parameters that govern a procedure are defined using other Envision
forms, but a procedure can accept arguments and prompt for input from an
end user. Based on this input, Envision can build the procedure differently
each time end users run it. Envision uses branching logic, which determines
the next step of the procedure from the results of previous steps.
End users may direct output data to a printer or other peripheral device. They
may also transfer data to a form process or batch program. Envision checks
each end user’s right to access data at the menu level, record level, and field
level. Envision only produces output for end users that are within their
security rights.
Envision checks each step to make sure it is a valid process or form before it
can be used within the procedure. User forms and batch processes must be
generated by the Process Generator (GEN) in the Envision Tool Kit before
Envision can use them at runtime.
User form step types are assigned to form processes that ask end users how to
run the procedure. These forms are used to specify options and to collect data
and selection criteria from an end user. End users indicate which steps of the
procedure to run and which data to select for processing.
Job step types are assigned to Batch, IF, STMT, and all other processes.
Envision uses batch processes to create reports and to provide special
processing needs. The procedure runs these processes if they are part of the
execution path. IF processes provide conditional statements to direct the
execution path. STMT processes provide a way to insert a database command
into the procedure.
List specification step types are either included within the application or are
created using the Procedure List Specification (JSEL) form. A list
specification creates a SSELECT command within a procedure to produce a
list of records based on the end user’s input entered from a user form.
Each time an end user runs a procedure, Envision creates a new paragraph to
run for that procedure. Envision includes in the paragraph only those steps
that are within the execution path.
All functions and features operate identically, and there are no limitations to
the types of procedures that Envision can generate. If a procedure is created
through the Envision Tool Kit, you or your end users usually can not modify it
from the Envision Runtime application. However, you can modify some
procedures when you need additional functionality for a particular
application. When a procedure is created in the Envision Tool Kit, analysts set
the option of whether to allow modifications to the procedure during runtime.
Table 22: Query Lang Retrieval Help for Procedure Specification (JDEF) Form
Where Procedure Specification (JDEF) Data Is Stored
To retrieve data from use this file and this field
Procedure ID LookUp PRCS.CTL PROCESS.MNEMONIC
Table 23: Query Lang Retrieval Help for Procedure Step Detail (JDET) Form
Where Procedure Step Detail (JDET) Data Is Stored
To retrieve data from use this file and this field
Procedure Description PRCS.CTL PROCESS.DESCRIPTION
You can also use the JSEL form to specify the sort and break criteria.
Depending on the list specifications you enter, end users may have the option
of altering the selection, sort, and break criteria.
Table 24: Query Lang Retrieval Help for Procedure List Specification (JSEL) Form
Where Procedure List Specification (JSEL) Data Is Stored
To retrieve data from use this file and this field
Procedure List LookUp PRCS.CTL PROCESS.MNEMONIC
You can also use the JSRT form to make certain fields mandatory for
inclusion in the sort and break sequence for the list and to specify whether end
users can modify the default criteria at runtime.
You can access this form by detailing in field 7 of the Procedure List
Specification (JSEL) form.
Table 25: Query Lang Retrieval Help for Procedure Sort Specification (JSRT) Form
Where Procedure Sort Specification (JSRT) Data Is Stored
To retrieve data from use this file and this field
Procedure List LookUp PRCS.CTL PROCESS.MNEMONIC
Use this form to specify the LookUp Resolution forms in this application for
which you want to create documentation.
For more information about the LookUp Resolution Specs (UTRD) form,
refer to “LookUp Resolution Specs (UTRD)” beginning on page 452.
Move all computed columns into the appl.CDD file. (Some computed
columns may have existed only in the RT.FIELDS file in R17.)
Run this process from each application (CORE, ST, etc.) in which you have
custom computed columns.
You only need to run this process one time, from the Envision Tool Kit for any
application.
Table 26: Query Lang Retrieval Help for PRCS.CTL Security Inquiry (PCSI) Form
Where PRCS.CTL Security Inquiry (PCSI) Data Is Stored
To retrieve data from use this file and this field
Process Control PRCS.CTL PROCESS.MNEMONIC
For added security when you choose either Hold/Browse File Output or PDF
Output (in the Output Device field), you can specify the storage location of
the output file. The following options are available:
Enter PB (public) if you want the output file to be written to the public hold
directory.
Enter PR (private) if you want the output file to be written to your own
private hold directory.
Enter SH (shared) if you want the output file to be written to a group hold
directory, then enter the group name into the security group field.
Table 27: Query Lang Retrieval Help for Peripheral Option Defaults (PDEF) Form
Where Peripheral Option Defaults (PDEF) Data Is Stored
To retrieve data from use this file and this field
Peripheral ID LookUp PRINTERS PRINTERS.ID
When browsing, the PDF files will be downloaded to your computer and
displayed automatically. The data transfer performance is affected by the
settings on the UI Administration Parameters (UIPR) form. If FTP is enabled
for the environment, then file transfers will be faster. Otherwise, the default
telnet data transfer is used, which can result in slower performance for large
PDF files. When browsing files using any interface other than UI desktop, the
UI Web Admin Parameters (UWPR) form must be filled in to transfer the files
to your computer.
Note: Shared HOLD directories are defined using the Output Security
Groups (OSGD) form and are accessible only by a specific operating
system group of users.
Note: The Point to Full Release Copy (PRTF) form is not used for
Envision 4.8 because of changes to the Envision architecture.
Note: If you do not have field history set up for a file, you will not be
able to retrieve the history for that file, since there is no history stored.
Define the fields whose history you want to track using the Define Field
History (DHST) form.
Table 28: Query Lang Retrieval Help for Rebuild File History (RBFH) Form
Where Rebuild File History (RBFH) Data Is Stored
To retrieve data from use this file and this field
Field PRCS.CTL PROCESS.FIELD.LIST
You can print the record security specifications for a subset of the stored data.
This form provides a way to create selection criteria for identifying the files
for which you want information printed.
For more information about the Record Security Specification (UTMR) form,
see page “Record Security Specification (UTMR)” beginning on page 448.
ALERT! You cannot access this form from the RSUC form if the
key derivation is not a function.
The following list of valid keywords defined in RSUC can be used in UTMR:
DEVICE.NAME. The end user’s current device type
You can also view these keywords and values for the current end user when
you detail at field 2 on the RSUC form.
If you change existing characteristics or add new characteristics, the end user
must reinitialize Envision Runtime before those changes or additions take
effect. There are two ways to initialize Envision Run- time:
Exit the database management system and reenter it, or
Run the program ENVINIT (by entering ENVINIT) from the database
management system prompt.
Table 29: Query Lang Retrieval Help for Rec Sec User Characteristics (RSUC) Form
Where Rec Sec User Characteristics (RSUC) Data Is Stored
To retrieve data from use this file and this field
Parameter Name RSPARAMS RS.PARMS.DEF.NAME
You may only access this form by detailing from field 2 on the Record
Security User Characteristics (RSUC) form.
A security class ID code identifies each security class. You can assign this
code to operator and device records, which means you can assign security by
operator or by device. Use the Operator Definition (SOD) and Device
Definition (SDD) forms to define operator and device records. For switch-
based systems, Envision assigns security according to an end user’s login ID.
For port-based systems, Envision assigns security classes according to a
terminal’s port number. Device security works only with port-based systems.
Four windows are available on the SCD form for establishing the appropriate
security. To create security classes, enter process or menu mnemonics in one
or more of the following windows, as appropriate:
1. Do Only These. End users in this security class have access only to the
items listed in this window. For information on how detail forms function
for the items you list, see “Restricting User Access for Detail Forms” on
page 150. Be sure to include all process/menu mnemonics, and EX (Exit)
or LO (Logoff) if you want these end users to have access to these options.
Remember that EX takes end users out of Envision and places them at the
database management system level.
2. Never Do These. End users in this security class never have access to the
items listed in this window. End users automatically have rights to all
processes except those listed in this window (and any listed as privileged
in another class; see below).
3. Inquiry Only. End users in this security class may only view field data for
the processes listed in this window. They cannot change, delete, or add
field data for these processes.
4. Privileged. End users in this security class have exclusive rights to the
items listed in this window. End users not assigned to this class cannot
access these items unless they are assigned as privileged in another class.
You can identify the same item as privileged in more than one security
class.
Remember that end users can have access to more than one security class. If
so, Envision merges the security settings of each class. See the description of
each window for an explanation of how Envision merges the settings for
multiple security classes.
Also remember that when you define security classes, you can only list
mnemonics in these windows that you have already marked as ones that are
subject to process-level security checks using the Menu Definition (SMD)
form. You cannot apply process-level security to a mnemonic that does not
already appear on a menu or to a mnemonic that is not subject to process-level
security checks.
For more information about Operator Definition (SOD), refer to page 409.
See page 388 for details on the Device Definition (SDD) form. For more
information about the Menu Definition (SMD) form, refer to page 401.
Table 30: Query Lang Retrieval Help for Security Class Definition (SCD) Form
Where Security Class Definition (SCD) Data Is Stored
To retrieve data from use this file and this field
Security Class ID SECLASS SYS.CLASS.ID
Field-level security allows you to secure data elements across entire files. For
example, if you want only the end users in the payroll office to see salary
figures, you can define a security class for those end users in the Payroll
Office that gives them exclusive access to the salary field. If any other users
attempt to access data from that field, regardless of the Envision form they
use, they see only asterisks in that field.
Table 31: Query Lang Retrieval Help for Field Security Definition (SCDF) Form
Where Field Security Definition (SCDF) Data Is Stored
To retrieve data from use this file and this field
Security Class ID SECLASS SYS.CLASS.ID
Table 32: Query Lang Retrieval Help for Record Security Setup (SCDR) Form
Where Record Security Setup (SCDR) Data Is Stored
To retrieve data from use this file and this field
Security Class ID SECLASS SYS.CLASS.ID
The scope of the report may be narrowed by selecting specific modules and/or
applications that processes may belong to.
The most seamless chain of screens is one where each screen would otherwise
prompt the user for the same thing. For example, in the Demographics module
in the Core System, the following forms all prompt the user for a person ID:
Name and Address Maintenance (NAE)
Suppose you chained these screens in the order shown above. When a user
accessed the chain, the Name and Address Maintenance form would be
displayed, and the user would be prompted to enter a person ID. When the
user finished the Name and Address Maintenance form, the Relation
Information form would be displayed for the same person with no further
prompt. When the user finished from the Relation Information form, the
Emergency Information form would be displayed for the same person with no
further prompt.
If you chain screens that would otherwise prompt the user for different things,
then the appropriate prompts are displayed when each screen is displayed.
You can chain screens that are totally unrelated.
You can define a screen chain from within any application. The screens you
include in a chain must be accessible from the application in which you are
working or from an application above it in the hierarchy. The chain itself will
be available to users of the application in which it is defined as well as to
users of applications that are below it in the hierarchy. For example, if you
define a screen chain in the Core System, you can include only screens that
are in the Core System or in Runtime. That same chain, once defined, is then
available to users in the Core System and to users in the Financial System and
its peer applications.
All screens within a chain take on the security rights specified for the chain. If
the security rights you specify for a screen differ from the security rights you
specify for a chain to which that screen belongs, the chain’s security rights
take precedence.
Use the Chain Usage Report (CHUS) to obtain reports on chains and the
screens they contain. These reports can help you administer security for
screen chains.
There are three function keys available to support movement among chained
screens: Screen FWD, Screen BACK, and Screen JUMP. In addition, some of
the existing function keys work differently for chained screens. See
“Grouping Screens” beginning on page 121for further information on this
topic.
Table 33: Query Lang Retrieval Help for Screen Chaining Specification (SCSP) Form
Where Form Chaining Specification (SCSP) Data Is Stored
To retrieve data from use this file and this field
Chain Process LookUp PRCS.CTL PROCESS.MNEMONIC
Keyboard definition
Display definition
Port-based system
On a port-based computer system, end users get the same port from the same
device every time they log on, regardless of their login IDs. On port-based
systems, Envision assigns devices according to the port number of the device,
as specified on the Network Definition (SND) form. This ensures that the
Envision display and keyboard tables are compatible with the hardware
associated with the device.
Device Security
You can assign process-level security--in the form of security classes--to each
device. Assign security classes to device records only for port-based devices.
You can then secure specific terminals from running certain processes,
regardless of the operator. If you are using switch-based devices, assign
security classes to each individual end user instead of to a terminal.
Remember that all applications share the same device definitions, so if you
assign a security class to a device, you must define it in all applications using
that device. Use the Security Class Definition (SCD) form to define security
classes.
When you make changes to an end user’s device definition, that end user must
log out and log back into the system before the changes take effect.
For more information on defining the access method for your computer, refer
to page 407. For more information on defining security classes, refer to
page 376.
Table 34: Query Lang Retrieval Help for Device Definition (SDD) Form
Where Device Definition (SDD) Data Is Stored
To retrieve data from use this file and this field
Device ID DEVICES SYS.DEVICE.ID
at DEVICES SYS.DEVICE.LAST.LOGIN.TIME
Defining a Keyboard
If a terminal table is not available for one or more of your terminals, use the
SKB forms to create one. First, decide on the keyboard layout. Determine
which function key or key sequence on the terminal keyboard you want to use
to perform each Envision function. Usually, the keyboard’s function keys and
editing keys perform the Envision functions. If the terminal does not have
function keys, however, you can use the Ctrl and Esc key sequences. When
you have established the keyboard layout, consult the reference
documentation for the terminal to find out the command sequence that each
key sends when pressed. Use this information to define the terminal table
through the SKB forms. After defining the table, create a template to match
the key sequence for the terminal.
Table 35: Query Lang Retrieval Help for Define Terminal Keyboard (SKB) Form
Where Define Terminal Keyboard (SKB) Data Is Stored
To retrieve data from use this file and this field
Keyboard Definition ID KEYDEFS KEYBOARD.ID
When end users press a key to perform a function, most terminals prefix, or
start, the command for the function by sending a special sequence to let the
host computer know that the next sequence it receives corresponds to a
function. For each Envision function, you must include this special sequence
as part of the key sequence.
Since this special sequence is usually the same for most keys, you may choose
to specify this special sequence on the Define Cursor Keys (SKB2) form.
Envision then automatically prefixes each command with this special
sequence for every Envision function. If the terminal sends commands using
escape sequences and you specify the special sequence using SKB2, prefix
each Envision key definition on this form with ESC. ESC is normally defined
on SKB2 as CTL [ . If the terminal sends commands through function key
sequences and you specify the special sequence using SKB2, prefix each
Envision key definition on this form with FKY. FKY is normally defined on
SKB2 as CTL A.
Table 36: Query Lang Retrieval Help for Define Function Keys (SKB1) Form
Where Define Function Keys (SKB1) Data Is Stored
To retrieve data from use this file and this field
Keyboard Definition ID KEYDEFS KEYBOARD.ID
Table 36: Query Lang Retrieval Help for Define Function Keys (SKB1) Form (cont’d)
Where Define Function Keys (SKB1) Data Is Stored
To retrieve data from use this file and this field
Next Element KEYDEFS KBD.ELEMENT.FWD
Table 37: Query Lang Retrieval Help for Define Cursor Keys (SKB2) Form
Where Define Cursor Keys (SKB2) Data Is Stored
To retrieve data from use this file and this field
Keyboard Definition ID KEYDEFS KEYBOARD.ID
If your native database is SQL-based, then you may specify the record
selection criteria using either UniQuery or SQL syntax. If your native
database is UniData, then only UniQuery syntax is allowed.
The saved list is created when you save from this form. If you do not want to
run the query and create the saved list, then you must cancel from this form.
When you access this form from the menu, you are prompted for the ID of the
saved list record that you want to modify. When you enter the name of an
existing saved list, the current contents of that saved list are loaded into the
form. You can then modify the information as needed. When you finish out of
the form, the new contents are saved.
When you access this form from the SLCR form, Colleague displays the
records selected by the select list you entered on that form. When you enter
the name of an existing saved list, the current contents of that saved list are
loaded into the form. You can modify the form as needed. When you finish
out of the form, the new contents are saved into the saved list record using the
name specified on the SLCR form. If you do not want to save the results of the
select statement, cancel out of the form.
Note: You should not modify the standard menus that are provided
with your Datatel software, because they may be overwritten with
future releases. To included Datatel processes on a menu, either
create your own menus and add Datatel processes to them, or use
security classes to restrict the processes to which a group of users has
access.
When you decide on the mnemonic, enter it at the LookUp prompt on the
SMD form. Then give the menu a title. Finally, specify the processes that
should appear on the menu.
After creating a new menu, you should add its mnemonic to another menu
using SMD. Remember that end users can enter any mnemonic from any
menu provided they have the appropriate security rights.
Datatel recommends that you change the default menu setup only after a great
deal of planning. You should leave the original setup intact and create new
menus that reflect any changes. By defining a new menu containing your
changes, you preserve its contents from one release to another.
If you need to remove a process from a menu, enter the mnemonic for the
menu at the LookUp prompt on the SMD form. At the window in field 3,
position the cursor on the item that you want to delete and press DEL twice.
See page 376 for details on the Security Class Definition (SCD) form.
Table 38: Query Lang Retrieval Help for Menu Definition (SMD) Form
Where Menu Definition (SMD) Data Is Stored
To retrieve data from use this file and this field
Menu ID MENU MENU.MNEMONIC
Determine the action to take when an end user enters that mnemonic
Control how the process appears on a menu
Note: You should NOT modify the process control records provided
with your application. If you need to modify them, consult with Datatel
before doing so. Release procedures overwrite any changed records
with the default version when you load a new release of Datatel
software.
If you use field-level security, you may also use this form to view the
fields that are secured in a particular file. If so, the files are keyed by
the name of the file.
Table 39: Query Lang Retrieval Help for Process Control Maintenance (SMD2) Form
Where Process Control Maintenance (SMD2) Data Is Stored
To retrieve data from use this file and this field
Process Control LookUp PRCS.CTL PROCESS.MNEMONIC
Technical Tip: Use this process only with host systems that are port-
dependent or host systems that run on a network.
Table 40: Query Lang Retrieval Help for Network Definition (SND) Form
Where Network Definition (SND) Data Is Stored
To retrieve data from use this file and this field
Data Switch Terminal Routing? NETDEFS NETDEFS.SYSTEM.TYPE
You may define operator records from within any application in the hierarchy;
however, Datatel strongly recommends that you define all operator records
from within Runtime (UT). Maintaining all operator records at the UT level
makes it easier for you to keep track of your operator definitions and reduces
the likelihood of users having problems accessing certain applications.
Before you define your operator records, you should first define your security
classes in each application (Security Class Definition [SCD] form).
Table 41: Query Lang Retrieval Help for Operator Definition (SOD) Form
Where Operator Definition (SOD) Data Is Stored
To retrieve data from use this file and this field
User ID OPERS SYS.USER.ID
at OPERS SYS.USER.LAST.LOGIN.TIME
Table 42: Query Lang Retrieval Help for Speed Entry Text Definition (SPDE) Form
Where Speed Entry Text Definition (SPDE) Data Is Stored
To retrieve data from use this file and this field
User ID OPERS SYS.USER.ID
In Colleague Studio, when you create a new Colleague Studio project against
this environment, you are prompted for a workgroup on the Colleague Local
Repository Provider form. The list of available workgroups in the Use
existing workgroup field includes all that have an Inactive Flag set to "N" or
null.
"S"helved
You can also access information about these objects from within Colleague
Studio. The SWGI form makes this information accessible when you are
working with Colleague Studio objects in UI – for example, when building a
release package on the CPKG form.
This form allows the modification of any short and long help that is stored in
the currently running application HELP and HELP.LONG files.
Table 43: Query Lang Retrieval Help for User Help Maintenance (UHLP) Form
Where User Help Maintenance (UHLP) Data Is Stored
To retrieve data from use this file and this field
SHORT.HELP.ID SHRTHELP SHORT.HELP.ID
Note: The Update Main Remote Accounts (UMRA) form is not used
for Envision 4.8 because of changes to the Envision architecture.
Because main accounts typically have their own copy of most data files,
UURA provides a step that logs any new files to be created and optionally
suspends creation of those files until the paths to where those files are to be
created have been reviewed and accepted via the Remote Account New Files
(UNFR) form. Using UNFR, it is possible to override the default paths
derived via rules given in the account’s REMOTES record.
Once the paths are as desired, processing can proceed and new files can be
created as requested. This process is primarily intended for updating an
existing main account where the volume of new files from a release are small
and easy to review file by file. When creating a new main account for
Colleague, the volume of new files make it reasonable to accept the normal
default paths for new files. You can manage the fine tuning of data
distribution at a later date.
Note: The UURA and UNFR forms are not used for Envision 4.8
because of changes to the Envision architecture.
For more information about the Update User Remote Accounts (UURA)
form, refer to page 471.
For more information about the Remote Account New Files (UNFR) form,
refer to page 420.
Note: The Remote Account New Files (UNFR) form is not used for
Envision 4.8 because of changes to the Envision architecture.
Note: The Remote Account New Files (UNFR) form is not used for
Envision 4.8 because of changes to the Envision architecture.
Generally, you would use the Update Main Remote Accounts (UMRA) to
update a Main account to a new release level. If you request UMRA to
compile a list of any new files that the account will receive as it is updated,
then you may review that list using this form. When you run UMRA and
request to review this list, the UNFR form appears before Envision creates
any files and updates the account in question. If the field for accepting the
paths for the new files is not marked Yes, then Envision has not yet created the
files. As long as the files have not yet been created, you can override the paths
by entering the desired path in the field provided. When you continue or re-
run UMRA and have marked the field Yes, Envision creates the files along the
paths specified.
Because User remotes do not generally have local copies of true application
files, you may update them through the Update User Remote Accounts
(UURA) form. UURA does not produce a list of new files that you may view
with this form.
Note: The UMRA and UURA forms are not used for Envision 4.8
because of changes to the Envision architecture.
For more information about the Update Main Remote Accounts (UMRA)
form, refer to page 417.
Table 44: Query Lang Retrieval Help for Remote Account New Files (UNFR) Form
Where Remote Account New Files (UNFR) Data Is Stored
To retrieve data from use this file and this field
Account LookUp REMOTES REMOTE.ID
Note: The Overwritten & Deleted Records (UODR) form is not used
for Envision 4.8 because of changes to the Envision architecture.
When you update a Main account to a new release level, certain obsolete
records are targeted for deletion or replacement. A series of select lists
controls which records to delete or replace; these select lists are delivered as
part of the release package. The contents of these lists represent default
modifications for updating the account.
You may modify the contents of these select lists to fit the needs of your
institution. After using UODR to produce a report showing the names and
default contents of these select lists, you can decide which records to add to or
subtract from these lists to fit your institution’s needs. To protect items from
deletion or replacement, remove them from the appropriate list using the
EDIT.LIST command. To overwrite or delete your own records in User
accounts during an update, use EDIT.LIST to add them to the lists.
Two select lists exist for each file or dictionary: one for deletion and one for
replacement (overwriting).
Use the Remote Account Report (URRA) form to produce a report that lists
information about your remote account definitions. You may use this report to
review the structure of the various accounts defined to Envision.
With URRA, you may produce a report for any type of account:
Main
User
Release
File
Template image
Envision stores these statistics in the file appl.PPROCESS, where appl is the
mnemonic of the current application. This report prints only the information
that you select.
When Envision runs a batch job, each step in the batch may produce one or
more errors. You can view these error messages while the batch job is
running, or use the VBS form to view them after the job runs.
UTBE gives you the option of producing printed copies of this information
for one or more batch runs. You can print the Batch Error Report for a subset
of the stored data. This form provides a way to create selection criteria for
identifying the records you want printed.
Before you run the UTBA process for a file, the file must already have
indexing parameters and specifications defined on either:
The File Index Definition (FIDX) form in the Envision Tool Kit
The User File Index Specification (UTMI) form (the runtime equivalent of
FIDX)
As the UTBA process maintains the indexes of each selected file, a bar graph
displays. Additionally, a second bar graph displays whenever a calculation of
computed index columns occurs.
At the end of the process, UTBA generates a report that lists all executed file
indexing operations for each file processed. For example, it will include a list
of any index structures that may have been deleted, created, or built for each
file.
Oracle Clients
In addition to the alternate key (IX_fieldname) indexes, the UTBA process
verifies that the primary key (PK_filename) and unique key (UQ_filename)
constraints are also defined using indexes. If the primary key and unique key
are missing, the supporting indexes are created. This ensures that the records
are unique and the performance of the database is optimal.
Before you run the UTBI process for a file, the file must already have
indexing parameters and specifications defined on either:
The File Index Definition (FIDX) form in the Envision Tool Kit
The User File Index Specification (UTMI) form (the runtime equivalent of
FIDX)
UTBI generates a report at the end of the process, which lists all of the
executed file indexing operations. For example, it will include a list of any
index structures that may have been deleted, created, or built.
For more information about the User File Index Specification (UTMI) form,
refer to page 444.
The information is keyed by the type of file, and you can specify defaults to
use for items such as the modulo or hash type. For more information about file
types, see the on-line documentation for your operating system.
If the data on this form is also incomplete, the file creation routines default to
hard-coded values. See each field description for these hard-coded default
values.
Table 45: Query Lang Retrieval Help for File Creation Type Defaults (UTCD) Form
Where File Creation Type Defaults (UTCD) Data Is Stored
To retrieve data from use this file and this field
File Type FILEDFLT FILEDFLT.TYPE
Table 46: Query Lang Retrieval Help for File Creation (UTCF) Form
Where File Creation (UTCF) Data Is Stored
To retrieve data from use this file and this field
User File Specifications LookUp UFSPECS UFSPECS.ID
Example
IF DATATEL.DEBUG THEN
X.DB.CTR = X.DB.CTR + 1
XL.DEBUG.MSG<X.DB.CTR> = "entering special process, v.id = ":V.ID
IF DATATEL.DEBUG.LEVEL GE 5 THEN
X.DB.CTR = X.DB.CTR + 1
XL.DEBUG.MSG<X.DB.CTR> = "v.last.name =":V.LAST.NAME
END ;* datatel.debug.level ge 5
$INSERT I_DEBUG
END ;* datatel.debug
To turn on the Envision debug mode for a process, you enter the process's
unique debug name into the appropriate fields on this form. The information
you enter on this form is appended to special variable UT.DEBUG.STRING.
The process continues to run in Envision debug mode for as long as you are
logged into the current session, or until you use the Clear String fields to clear
the debug string.
When you enter a process’s debug name on the UTDB form, and then run the
process needing debugging, the process runs in Envision debug mode.
Envision Debug mode displays the messages entered by the programmers to
help you determine possible sources of problems with the software or data.
Use the fields in the upper part of this form for debugging UI processes. Use
the fields in the lower part of the form to debug WebAdvisor processes.
For WebAdvisor debugging, enter the name of the process and the ID of the
WebAdvisor user you want to debug. As it runs, debug messages are written
to the WWW.SCREEN.DEBUG files, which are keyed by
SenderControlID*counter*SecurityToken*[processID].
Envision 4.8
Note: Regardless of the context in which you access this form, its
mnemonic is always UTED. Because, however, you do access this
form in a variety of contexts, its title changes to reflect the context in
which you are working. You will never actually see this form’s formal
title (Edit Comments). Instead, when you access this form from the
Vendor Maintenance form, its title might be “Vendor Comments,” and
when you access this form from the Fixed Asset Disposal Maint form,
its title might be “Fixed Asset Disposal Comments.”
If you do not list any directories on this form, the only directory that end users
can BROWSE is the HOLD directory, which contains generated reports.
Documentation directories
It is possible for end users to delete the directories they access with
BROWSE; therefore, do not allow them to access any directories that contain
source code.
Table 47: Query Lang Retrieval Help for BROWSE File Authorization (UTFA) Form
Where BROWSE File Authorization (UTFA) Data Is Stored
To retrieve data from use this file and this field
Authorized Directory File Name UTFBLIST UTFB.AUTH.FILE.LIST
Functions
Window Page UP. Backs up one page (goes from page 3 to page 2)
Window Page DOWN.Turns to the next page
Window FWD. Moves down 22 lines or to the bottom of the current page
Window BACK. Moves up 22 lines or to the top of the current page
CLEAR or REFRESH. Repaints the current form
Process HELP. Shows this Help information
CANCEL, EXIT, or FINISH. Stops Browsing.
Commands
Lnnn. Moves the BROWSE window to the left nnn columns
L. Moves the BROWSE window to the left 70 columns
Rnnn. Moves the BROWSE window to the right nnn columns
R. Moves the BROWSE window to the right 70 columns
Unnn. Moves the BROWSE window up nnn lines or to the top of the page
U. Moves the BROWSE window up 22 lines or to the top of the page
Dnnn. Moves the BROWSE window down nnn lines or to the bottom of
the page
D. Moves the BROWSE window down 22 lines or to the bottom of the page
P. Moves to the next page
PD. Moves down (next) one page
PU. Moves up (prior) one page
Pnnn. Moves to page nnn
@(c,x). Moves the BROWSE window so that the upper left corner is
positioned at column c, line x on the current page.
Envision stores these statistics in the file appl.PPROCESS, where appl is the
mnemonic for the current application. This purge process clears the file of the
selected data.
You can purge either all or only a subset of the statistical data stored for a
procedure. The Job Statistics User form provides a way to create selection
criteria for identifying the statistics that you want to purge.
Envision stores these statistics in the file appl.PPROCESS, where appl is the
mnemonic of the current application. This report prints the selected data for
review or documentation.
You may run the Job Statistics Report for a subset of the stored data. You can
create the selection criteria for identifying the statistics that you want to print.
If you leave the selection options blank, Envision prints all records in the
appl.PPROCESS file.
For more information about file types, see the file structure and file
maintenance sections of the reference guide for your operating system.
Table 48: Query Lang Retrieval Help for User File Information (UTMF) Form
Where User File Information (UTMF) Data Is Stored
To retrieve data from use this file and this field
File Name LookUp UT.VOC UT.VOC.ID
Indexing speeds up some file operations, such as selecting all records in a file
whose field(s) match certain value(s). For example, using LookUp on a file
containing only indexed fields is much faster than using it on a file containing
unindexed fields.
Note: After using the UTMI process to specify indexing, use the File
Indexing (UTBI) form to build the indexing information for any currently
existing data in the file.
For more information about the File Indexing (UTBI) form, refer to page 428.
Table 49: Query Lang Retrieval Help for User File Index Specification (UTMI) Form
Where User File Index Specification (UTMI) Data Is Stored
To retrieve data from use this file and this field
User File Specifications LookUp UFSPECS UFSPECS.ID
The transaction log file for a given file is named TXLOG_filename. Envision
creates this file in the same directory as the file that is being logged.
Table 50: Query Lang Retrieval Help for Transaction Log Specification (UTML) Form
Where Transaction Log Specification (UTML) Data Is Stored
To retrieve data from use this file and this field
User File Specifications LookUp UFSPECS UFSPECS.ID
If you add new record security criteria or change existing criteria for end
users, they must re-initialize Envision Runtime before the additions or
changes take effect. There are two ways to initialize Envision Runtime:
Leave the database management system and reenter it, or
For more information about the Record Security User Characteristics (RSUC)
form, refer to page 372.
Table 51: Query Lang Retrieval Help for Record Security Specification (UTMR) Form
Where Record Security Specification (UTMR) Data Is Stored
To retrieve data from use this file and this field
FileName LookUp UFSPECS UFSPECS.ID
The Key IDs of records in the REMOTES file should be the same as their
corresponding account names. Each record also contains the full path name
that explicitly defines the physical location of the VOC for the remote account
it describes.
Table 52: Query Lang Retrieval Help for Remote Account Specifications (UTRA) Form
Where Remote Account Specifications (UTRA) Data Is Stored
To retrieve data from use this file and this field
Account LookUp REMOTES REMOTE.ID
Displays the login ID of the person who most recently changed this resolution
form.
Table 53: Query Lang Retrieval Help for LookUp Resolution Specs (UTRD) Form
Where LookUp Resolution Specs (UTRD) Data Is Stored
To retrieve data from use this file and this field
Resolution LookUp RESOLUTN RESOLUTN.ID
Table 54: Query Lang Retrieval Help for File Resolution Defaults (UTRE) Form
Where File Resolution Defaults (UTRE) Data Is Stored
To retrieve data from use this file and this field
Resolution LookUp RESOLUTN RESOLUTN.ID
Table 55: Query Lang Retrieval Help for File Resolve Graphic Display (UTRG) Form
Where File Resolve Graphic Display (UTRG) Data Is Stored
To retrieve data from use this file and this field
Resolution LookUp RESOLUTN RESOLUTN.ID
Use the File Resolve Graphic Display (UTRG) detail form to change the
appearance of the resolution data on the resolution form.
For more information about the File Resolve Graphic Display (UTRG) form,
refer to page 456.
Table 56: Query Lang Retrieval Help for LookUp Resolution Options (UTRO) Form
Where LookUp Resolution Options (UTRO) Data Is Stored
To retrieve data from use this file and this field
Resolution LookUp RESOLUTN RESOLUTN.ID
Table 57: Query Lang Retrieval Help for User FileSuite Information (UTSF) Form
Where User FileSuite Information (UTSF) Data Is Stored
To retrieve data from use this file and this field
User File Specifications LookUp UFSPECS UFSPECS.ID
Use this form to purge logged transactions on a subset of the stored data. You
can specify selection criteria for identifying the statistics that you want to
purge. If you leave the selection options blank, Envision purges all records in
the selected file.
For more information about the Transaction Log Specification (UTML) form,
refer to page 446.
You only need to use this form if you want the Update Main Remote Accounts
(UMRA) or Update User Remote Accounts (UURA) processes to update files
that are specific to your institution along with Datatel files during the remote
account update process. Normally, UMRA and UURA automatically update
Datatel files for a new release.
Note: The UMRA and UURA forms are not used for Envision 4.8
because of changes to the Envision architecture.
Table 58: Query Lang Retrieval Help for Modify Appl VOC Files (UTVF) Form
Where Modify Appl VOC Files (UTVF) Data Is Stored
To retrieve data from use this file and this field
Application VOC Key UT.VOC UT.VOC.ID
A miscellaneous VOC item is any valid VOC item that is not a program or a
file. Valid miscellaneous VOC items include the following types:
K. keywords
M. menus
PA. paragraphs
S. sentences
V. verbs that are not programs
Use the Modify Application VOC Programs (UTVP) form to modify program
VOC items. Use the Modify Application VOC Files (UTVF) form to modify
file VOC items.
For more information about the Modify Application VOC Programs (UTVP)
form, refer to page 468.
For more information about the Modify Application VOC Files (UTVF) form,
refer to page 465.
Figure 144: Sample Modify Appl VOC Misc. Items (UTVM) Form
Table 59: Query Lang Retrieval Help for Modify Appl VOC Misc. Items (UTVM) Form
Where Modify Appl VOC Misc. Items (UTVM) Data Is Stored
To retrieve data from use this file and this field
Application VOC Key UT.VOC UT.VOC.ID
Table 60: Query Lang Retrieval Help for Modify Appl VOC Programs (UTVP) Form
Where Modify Appl VOC Programs (UTVP) Data Is Stored
To retrieve data from use this file and this field
Application VOC Key UT.VOC UT.VOC.ID
Note: This form is identical to the TXLOG Purge (UTTP) form. The
only difference between the two forms is that UTTP purges transaction
data, while UTXL prints transaction data.
For more information about the TXLOG Purge (UTTP) form, refer to
page 464.
Note: The Update User Remote Accounts (UURA) form is not used
for Envision 4.8 because of changes to the Envision architecture.
You cannot update Main accounts from UURA. Unlike the Update Main
Remote Accounts (UMRA) form, UURA does not make a list of new and
obsolete files for you to review. It uses the default paths for a given remote
account on the assumption that you have few, if any, new local files with non-
standard paths. If this is a problem, you can use UMRA. While intended for
Main accounts, UMRA may be used to update User accounts as well.
On the Update User Remote Accounts (UURA) form, you may enter a list of
one or more REMOTES record IDs for updating. The REMOTES records
used in the remote update process define four things:
1. the path to the VOC of a User account that you want to update
2. the source (Release) REMOTES record containing the release in question
3. application and module names to include in the update
4. the path to system and data filing areas (if used)
UURA accepts any User account REMOTES definitions and updates them in
the order presented on this form. To define REMOTES records, use the
Remote Account Specifications (UTRA) form.
If you are allowed to update a validation code table, you can use this form to
modify your codes. Some validation table files for an application contain
tables that you can customize to meet your institution’s unique needs.
You can disable some validation tables so that end users may enter anything.
To disable a validation table, enter three asterisks (***) as the first code in the
code field and delete all of the remaining codes.
Table 61: Query Lang Retrieval Help for Validation Codes (VAL) Form
Where Validation Codes (VAL) Data Is Stored
To retrieve data from use this file and this field
Validation Code ID VALCODES VALCODE.ID
Table 62: Query Lang Retrieval Help for View Batch Process Status (VBS) Form
Where View Batch Process Status (VBS) Data Is Stored
To retrieve data from use this file and this field
Job Start Time JOBSTATS JOB.START.TIME
Figure 149: Sample View Single Batch Job Step (VBSD) Form
Table 63: Query Lang Retrieval Help for View Single Batch Job Step (VBSD) Form
Where View Single Batch Job Step (VBSD) Data Is Stored
To retrieve data from use this file and this field
Process ID JOBSTATS JOB.STEP.NAMES
From this index you can click on any entry to access the information about the topic.
A Colleague modules
Defining parameter records for 55
ACCOUNT.PARAMETERS
System Parameters 55 Computed Column Library Dply (CCLD) form 306
ACSO form 304 Computed Columns Not Deployed (CCND) form
307
Action Checked Out Studio Obj (ACSO) form 304
Concepts 21
appl.PPROCESS file 440
CONFIRM level 263
Application hierarchy
and screen chains 123 CPAE form 86
Audit Trail Report (UTXL) form 470 CPDE form 320
Automatically generated services 279 CPIE form 322
CPKG form 324
B CPKP form 326
Batch Error Report (UTBE) form 425 CPKR form 328
Batch Runtime RFSPECS Refresh (BRRR) form CPRP form 330
226
Create Printer Control Record (CPRP) form 330
BROWSE File Authorization (UTFA) form 436
CUSC form 331
BRRR form 226
Custom Code Scanner (CUSC) form 331
BSEC form 177
Custom Declaration (CDEC) form 312
BTRR form 305
Custom Declaration Objects (CDOB) form 316
Build Application Security (BSEC) form 177
Custom Development in Progress (CDPI) form 318
C Custom Package Import/Export (CPIE) form 322
CC Reset for SQL Server (CCRS) form 308 Custom Package Rebuild Detail (CPKR) form 328
CCLD form 306 Custom Packaging Detail (CDED) form 314
CCND form 307 Custom Paragraph Entry (CPAE) form 86
CCRS form 308 Custom Release Package Build (CPKG) form 324
CCSR form 310 Custom Release Package Build (CPKP) form 326
CDEC form 312 Custom Scanner Report (CCSR) form 310
D
CDED form 314
CDOB form 316
DDCV form 333
CDPI form 318
Define Cursor Keys (SKB2) form 397
Chain Usage Report (CHUS) 129
Define Field History (DHST) form 335
Chain Usage Report (CHUS) form 319
Define Function Keys (SKB1) form 394
Change Peripheral Defaults (CPDE) form 320
Define Key Functions (RS2) form 371
CHUS form 319
Define Terminal Keyboard (SKB) form 392
Delete Obsolete Index Files (DOIF) form 234 Forms, Datatel software (cont’d)
Device Definition (SDD) form 388 BROWSE File Authorization (UTFA) 436
Build Application Security (BSEC) 177
DHST form 335 CC Reset for SQL Server (CCRS) 308
Dictionary Date Convert (DDCV) form 333 Chain Usage Report (CHUS) 319
DIFF form 336 Change Peripheral Defaults (CPDE) 320
Computed Column Library Dply (CCLD) 306
Difference Engine (DIFF) form 336
Computed Columns Not Deployed (CCND) 307
DOIF form 234 Create Printer Control Record (CPRP) 330
E
Custom Code Scanner (CUSC) 331
Custom Declaration (CDEC) 312
Edit Comments (UTED) form 435 Custom Declaration Objects (CDOB) 316
Edit Record (EDRC) form 337 Custom Development in Progress (CDPI) 318
Custom Package Import/Export (CPIE) 322
EDRC form 337 Custom Package Rebuild Detail (CPKR) 328
EGP (External Global Parameters) 337 Custom Packaging Detail (CDED) 314
Element, Window 30 Custom Paragraph Entry (CPAE) 86
Custom Release Package Build (CPKG) 324
Envision Parameters Edit (EPED) form 55, 231
Custom Release Package Build (CPKP) 326
EPED form 55, 231 Custom Scanner Report (CCSR) 310
External Global Parameters (EGP) 337 Define Cursor Keys (SKB2) 397
Define Field History (DHST) 335
F Define Function Keys (SKB1) 394
FHDF form 340 Define Key Functions (RS2) 371
Define Terminal Keyboard (SKB) 392
FHDT form 340 Delete Obsolete Index Files (DOIF) 234
Field History Detail (FHDT) form 340 Device Definition (SDD) 388
Field Label 30 Dictionary Date Convert (DDCV) 333
Difference Engine (DIFF) 336
Field Security Definition (SCDF) form 379
Edit Comments (UTED) 435
File Creation (UTCF) form 432 Edit Record (EDRC) 337
File Creation Type Defaults (UTCD) form 430 Envision Parameters Edit (EPED) 55, 231
Field History Detail (FHDT) 340
File indexing 222
Field Security Definition (SCDF) 379
database 226
File Creation (UTCF) 432
when conversion is complete 234
File Creation Type Defaults (UTCD) 430
File Resolution Defaults (UTRE) form 453 File Resolution Defaults (UTRE) 453
File Resolve Graphic Display (UTRG) form 456 File Resolve Graphic Display (UTRG) 456
Files GUI Function Button (GUIF) 342
ACCOUNT.PARAMETERS 55 International Parameters (INTL) 343
appl.PPROCESS 440 Job Statistics Purge (UTJP) 440
converting static to dynamic 196 Job Statistics Report (UTJR) 441
resizing 194 LKUP Resolution Specs (LPRT) 356
SYSDEFS 67 LookUp Resolution Options (UTRO) 458
UT.THROWN.ERRORS 263 LookUp Resolution Specs (UTRD) 452
Menu Definition (SMD) 401
Forms, Datatel software Migrate Computed Columns (MGCC) 357
Action Checked Out Studio Obj (ACSO) 304
Migrate IS-Type Subroutines (MGIS) 358
Audit Trail Report (UTXL) 470 Modify Appl VOC Files (UTVF) 465
Batch Error Report (UTBE) 425
Modify Appl VOC Misc. Items (UTVM) 466
Batch Runtime RFSPECS Refresh (BRRR) 226 Modify Appl VOC Programs (UTVP) 468
R
RPRT form 370
RS2 form 371
RBFD form 368
RSPH form 94
RBFH form 369
RSUC form 372
Rebuild Field History (RBFD) form 368
RSV form 374
Rebuild File History (RBFH) form 369
RTST form 375
Rebuild File Indexing (UTBI) form 428
Running Processes (RPRI) form 111
Rec Sec User Characteristics (RSUC) form 372
Record Security List Specs (RPRT) form 370 S
Record Security Setup (SCDR) form 381 SCD form 376
Record Security Specification (UTMR) form 448 SCDF form 379
Record Security Test Specs (RTST) form 375 SCDR form 381
Recovery SCOR form 383
general guidelines 249 SCPR form 384
general procedures 249
Screen
Refresh RFSPECS (BTRR) form 305 External Global Parameters (EGP) 337
Remote Account New Files (UNFR) form 420
V
VAL form 473
Validation Codes (VAL) form 473
VBS form 476
VBSD form 478
View Batch Process Status (VBS) form 476
View Single Batch Job Step (VBSD) form 478
W
WEEKLY.UDT.FILE.ANALYSIS (WUFA) utility
193
benefits 196
excluding files 200
functions 194
output items 195
resizing files 194, 196
workflow 196
WEEKLY.UDT.INDEX.ANALYSIS (WUIA)
utility 193, 201
output items of logical check 209
output items of physical check 206
recommendations 212
setting up paragraphs 213
understanding 201
Window Element 30
Window Group 29
Window Label 30
WUFA utility 193
benefits 196
excluding files 200
functions 194
output items 195
resizing files 194, 196
workflow 196