Runtime Administration Reissued Manual as of July 7, 2009 This is a new edition of the Runtime Administration manual for Release 4.7/4.8. This edition replaces the previous edition dated June 19, 2008.
The Primary Changes Made Section
Pages
Changes Made
Envision Application Files
46
The description of appl.PRCS.GEN was updated.
MIO Level Check Disable
61
The Envision Parameters Edit (EPED) form was modified to no longer accept the ALL option. For more information, see AnswerNet document 39958.15.
Header Blocks
113
Information for Header Blocks was updated to resolve AnswerNet document 38514.56.
HOLD File Security
143, 145, and 146
Information for HOLD shared file security was updated to resolve AnswerNet document 31504.78.
Restricting User Access on the Security Class Definition (SCD) Form
149 – 150, 344
Information was updated on the Security Class Definition (SCD) form to resolve AnswerNet document 32638.48.
Creating/Deleting Operator Definition Records
154 – 155
Information was updated for new functionality:
Defining Field Security
176
Problems in Envision Applications
254 and 259
Form Reference
344 – 345, 347 and 377
Using the Process Security Summary (PSCS) Form
159 – 164
A new form, Process Security Summary (PSCS), was added that allows you to generate a security-related report for a process you specify. This resolves AnswerNet document 219.36.
Updating and Maintaining Security
177
Information for the Build Application Security (BSEC) form was included to resolve AnswerNet document 40119.04.
Envision Diagnostics
261 – 294
Information on Envision diagnostics was updated to include the Generated Runtime Diagnostic Services (GRDS) system.
Savedlist Creation (SLCR)
367
The description of the Savedlist Creation (SLCR) form was updated.
Remote Account Report (URRA)
389
A note was added that the URRA form is not used for Envision 4.8
• The Security Class Definition (SCD) form allows you to detail to the Field Security Definition (SCDF) form. • The SCDF form allows you to detail to SCD. • The Operator Definition (SOD) form allows you to detail to SCD.
Envision®
Runtime Administration Release 4.7/4.8 July 7, 2009
For last-minute updates and additional information about this manual, see AnswerNet page 2103.81.
Runtime Administration © 2009 Datatel, Inc. All Rights Reserved The information in this document is confidential and proprietary to and considered a trade secret of Datatel, Inc., and shall not be reproduced in whole or in part without the written authorization of Datatel, Inc. The information in this document is subject to change without notice. Colleague and ActiveCampus are registered trademarks of Datatel, Inc. ActiveAlumni and ActiveAdmissions are trademarks of Datatel, Inc. Other brand and product names are trademarks or registered trademarks of their respective holders. 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 19 20
In This Chapter Who Should Read This Manual? How This Manual is Organized
21
Basic Envision Concepts
21 21 22 22 23 23 23 24 24 25 25 26 26 27 28 28 29 30 30 30 31 32 32 32
What is Envision? Structure of Envision Envision Tool Kit Envision Runtime Envision Forms Form Layout Header Block Data Area LookUp Area Types of Envision Forms Menus Process Forms Detail Forms Envision Fields Basic Concepts What is a Window? Terminology Types of Windows Vertical Windows Horizontal Windows Processing Windows General Purpose Forms Change Peripheral Defaults Sort/Break Criteria
33
Runtime Features and Terminology
33 35 35 35 36 36
Features Terminology Application Application Trees Tree Reads Module
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
5
Table of Contents
37 38 38 39 39 40 40 41
6
Process Forms Batch Programs Procedures Operator Device Peripheral Security
43
Envision File Overview
43 47 48 48 50
Envision Application Files Trans-Application Files Shared and Protected Files Shared Files Protected Files
51
Setup
53
Introduction to Setup
55
Defining System Parameters
55 55 56 57 57 57 57 58 58 59 59 59 59 60 60 60 61 61 61
In This Chapter Using the Envision Parameters Edit (EPED) Form MIO Indexing Mode (Envision 4.7 Only) Oracle I/O Off (Envision 4.7 Only) Disable Full OCI (Envision 4.7 Only) SQL Select Off (Envision 4.7 Only) Read Cache Size (Envision 4.7 Only) Read Cache Log State (Envision 4.7 Only) Clear Cache Off (Envision 4.7 Only) Execute Log On Numeric Precision Subscription Enabled Inbound EDX TX Enabled Use Passive FTP Windows Clients Error Stamping MIO Level Check Disable UT Debug String DMI Print Server IP/Port (Envision 4.7 Only)
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Table of Contents
63
Defining Validation Codes
63 63 64 64 65
In This Chapter Code Files Code Tables Maintaining VAL Codes Disabling Valcode Tables
67
Editing UNIX_CONTROL Records
67 67 68 70 73
In This Chapter Form Used Editing a UNIX_CONTROL Record Noteworthy Fields on the UCRE Form Procedure for Editing a UNIX_CONTROL Record
75
Printing
75 75 75 75 76 76 76 78
79
Understanding Levels of Printing Operating System Database Management System Software LPTR SETPTR Application Software Change Peripheral Defaults Form Defining Printers to Envision for Windows NT and Windows 2003/2008 For All Printers Defined On The Same Local Server as Colleague For a Network Print Server
83
Using the Envision Process Handler
83 84 84 86 87 87 88 89 91 94 95 95 98
What is the Envision Process Handler? Submitting a Task to the Envision Process Handler Submitting a Batch Process or Report Submitting a VOC Paragraph Viewing and Editing Task Schedules The System Administrator’s Role Setting Up the Process Handler and Managing Queues The Process Handler Setup (PHSU) Form The Process Queue Management (PRQM) Form The Reset Process Queue Handler (RSPH) Form Managing Processes The Outstanding Processes (OPRM) Form The Process Scheduling (PHTS) Form
78
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
7
Table of Contents
8
100 102 104 105 108 110
The Process Scheduling (PRSC) Form The My Processes (MYPR) Form Working with Process Status File Records The Process Status Report (PSTR) Form The Process Status File Purge (PSFP) Form Using Inquiry Forms
113
Customizing an Application
113 113 113 114 115 115 116 116 118 118
Features Header Blocks Resolution Forms To Change a Resolution Form Adding/Changing Envision Menus Creating a New Menu in the Same Application as the Model Creating a New Menu Creating a Menu Based on a Model in a Higher Application STANDARD.FORMS (Release 17.0 only) Modifying a Program in STANDARD.FORMS
121
Grouping Screens
121 122 123 123 126 127 129
Chaining Screens Security and Chaining Application Hierarchy and Chaining Function Keys and Chaining Components of a Screen Chain Definition Procedure for Chaining Screens Procedure for Reporting on Chained Screens
131
Security
133
Security Overview
133 133 134 134 135 137
Introduction Logging In UNIX Windows 2003/2008 For All Platforms Logging Off
139
Operating System Security
139 139
Setting Up Login IDs and Passwords for Users Setting Up Users in UNIX
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Table of Contents
140 140 141 141 141 142 142 143 143 143 143 145
Operating System Security in UniData Accessing the Database Management System Complete Restriction Guidelines for Complete Restriction Limited Restriction Guidelines for Limited Restriction Using the Sequential File BROWSE Shell (UTFB) Process HOLD File Security Public file security (PB) Private file security (PR) Shared file security (SH) Output Security Groups
147
Application Security
147 148 149
Types of Security Security Classes Restricting User Access on the Security Class Definition (SCD) Form Restricting User Access for Detail Forms Guidelines for Defining Security Classes for an Application Procedure for Creating Security Classes Operator Definition Creating/Deleting Operator Definition Records Procedure for Creating an Operator Definition Record Procedure for Deleting an Operator Definition Record Using the PRCS.CTL Security Inquiry (PCSI) Form Process Security Classes Field Security Classes Using the Process Security Summary (PSCS) Form Noteworthy Fields on the PSCS Form Procedure for Using the Process Security Summary Report
150 151 152 153 154 155 155 157 158 158 159 161 162
165
Record and Field Security
165 165 165 166 166 167 168 169 169
Security Layers Record Security User Characteristics Evaluation by Envision Runtime Guidelines for Specifying Record Security Defining Record Security User Characteristics Keywords Constants Function Expressions
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
9
Table of Contents
10
169 171 175 175 177
Previously Defined Parameter Definitions Record Security Definitions Field Security Defining Field Security Updating and Maintaining Security
179
Encrypting Colleague Data
179 179 180 180 181 181 182 183 183 184 185 186
In This Chapter Before You Begin Understanding Colleague Encryption Encryption Algorithm and Encryption Key Key Concepts Form Used File Used Defining Colleague Encryption Noteworthy Fields on the UTEP Form Procedure for Changing an Encryption Parameter Troubleshooting Troubleshooting a Failed Encryption Process
187
Maintenance
189
Maintenance Introduction
189 189 190 190 190 191 191
Scheduling System Maintenance Saves Consolidation of Job Histories Purges Disk Maintenance Sample Daily Schedule Notes
193
Using File and Index Analysis Utilities
193 194 195 196 197 200 201 201 203 206
In This Chapter Using WEEKLY.UDT.FILE.ANALYSIS (WUFA) Output Items from the WUFA Utility Workflow for Using the WUFA Utility Running the WUFA Utility Excluding Files from Analysis Using WEEKLY.UDT.INDEX.ANALYSIS (WUIA) Understanding the WUIA Utility Examples of Running the WUIA Utility Results of Running a Physical Check on Index Files
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Table of Contents
209 212 213
Results of Running a Logical Check on Index Files Recommendations When Running the WUIA Utility Setting up Paragraphs for the WUIA Utility
215
Envision File Services
216 217 219 220 220 221 222 223 223 226 234
Add/Change Tracking Record Link Management Record Deletion Transaction Logging Requesting Transaction Logging History Logging File Indexing Datatel Defined Indexes User Defined Indexing Converting Files to Database Indexing When File Conversion Is Complete
237
Envision Runtime Reports
237 238 238 239 239 240
Procedure Rules Documentation Lookup Resolution Specifications Record Security Specifications Batch Error Report Job Statistics Report Audit Trail Report
241
Purging Files
241 242 242 243 244 244
Data Files Background System Files Batch Status Transaction Logging Database Management Files Database Management System Files Naming Conventions HOLD PH SAVEDLISTS
245 245 246
247
Troubleshooting
249
Introduction to Troubleshooting
249 250
Recovery Guidelines Troubleshooting Envision-Based Software
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
11
Table of Contents
253
Problems in Envision Applications
253 257
System Setup or Security Issues Runtime Error Messages
261
Envision Diagnostics
261 262 263 264 264 264 265 265 265 266 267 267 268 268 270 279 280
In This Chapter Overview of the GRDS System System Integrity Checking Envision On-demand Diagnostic Systems Advantages of Using the GRDS System Auto-generated Logging Services Self-Diagnostic Services Log Saved to Disk Easy to Use, Efficient, and Consistent On-demand Diagnostics Using GRDS Sample GRDS Log Part 1: Runtime Environment Information Part 2: Services Requested Part 3: Diagnostic Text How to Read a GRDS Log Automatically Generated Services AE, AX & AD (Process Argument Services: Entry, Exit, Difference) PE & PX (Process Entry & Process Exit) CC (Call Chain) GS (GEN Stamp) NK (Next Key) NS & KS (Number Selected & Keys Selected) HS, HE, & HX (Hook Services: Sequence, Entry, Exit) SD (Show Demanded) ET (Elapsed Time) Programmer-Specified Services Accessing GRDS On-demand Diagnostics Using the UTDB Form Research the Debug String Specify UT Process Debug Activation (UTDB) Parameters Run the Debugged Form GRDS and UTDB: Do They Interact?
280 281 281 281 282 283 283 284 285 286 288 288 289 291 292
12
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Table of Contents
293
Appendices
295
System Setup Worksheets
295 296 297 298 299 300 301
Worksheet for Device Definition (SDD) Worksheet for System Operator Definition (SOD) Worksheet for Security Classes Worksheet for Function Keys (SKB1) Worksheet for Cursor Keys (SKB2) Worksheet for Graphic Characters Worksheet For Special Purpose Characters
303
Form Reference
304 305 306 306 308 309 310 312 313 315 318 320 320 320 322 324 326 327 328 329 331 333 335 336 337 338 339 340 342 343 344
Chain Usage Report (CHUS) Create Printer Control Record (CPRC) Dictionary Date Convert (DDCV) Running the Process in Background Mode Define Field History (DHST) Difference Engine (DIFF) Field History Detail (FHDT) GUI Function Button (GUIF) International Parameters (INTL) Procedure Specification (JDEF) Procedure Step Detail (JDET) Procedure Rules Documentation (JPRT) Specifying Output Options Running the Process in Background Mode Procedure List Specification (JSEL) Procedure Sort Specification (JSRT) LKUP: Resolution Specs (LPRT) Migrate Computed Columns (MGCC) Migrate IS-Type Subroutines (MGIS) Mag Tape Option Defaults (MTOD) PRCS.CTL Security Inquiry (PCSI) Peripheral Option Defaults (PDEF) Point to Full Release Copy (PRTF) Rebuild Field History (RBFD) Rebuild File History (RBFH) Record Security: List Specs (RPRT) Define Key Functions (RS2) Rec Sec User Characteristics (RSUC) Security Parameter Values (RSV) Record Security: Test Specs (RTST) Security Class Definition (SCD)
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
13
Table of Contents
347 349 351 352 353 356 356 357 357 357 357 360 360 362 365 367 368 369 369 369 370 370 372 375 377 379 380 382 384 385 387 389 390 391 393 393 395 397 398 400 401 403
14
Field Security Definition (SCDF) Record Security Setup (SCDR) Operator Security Report (SCOR) Process Security Report (SCPR) Screen Chaining Specification (SCSP) Device Definition (SDD) Computer Access Strategies Assigning Devices on a Switch-based System Assigning Devices on a Port-based System Combining Features of Switch-Based and Port-Based Systems Device Security Define Terminal Keyboard (SKB) Defining a Keyboard Define Function Keys (SKB1) Define Cursor Keys (SKB2) Savedlist Creation (SLCR) Savedlist Edit Contents (SLED) Menu Definition (SMD) Defining a New Menu Adding a Process to a Menu Removing a Process from a Menu Adding a Custom Program to a Menu Process Control Maintenance (SMD2) Network Definition (SND) Operator Definition (SOD) Speed Entry Text Definition (SPDE) User Help Maintenance (UHLP) Update Main Remote Accounts (UMRA) Report on New/Obsolete Files (UNFP) Remote Account New Files (UNFR) Overwritten & Deleted Records (UODR) Remote Account Report (URRA) Batch Error Report (UTBE) File Indexing (UTBI) Multiple File Indexing (UTBA) Oracle Clients File Creation Type Defaults (UTCD) File Creation (UTCF) UT Process Debug Activation (UTDB) Edit Comments (UTED) BROWSE File Authorization (UTFA) Sequential File BROWSE Shell (UTFB)
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Table of Contents
404 404 405 406 407 409 411 413 415 417 419 421 423 425 426 428 429 430 432 434 436 437 439 442 444
447
Functions Commands Job Statistics Purge (UTJP) Job Statistics Report (UTJR) User File Information (UTMF) User File Index Specification (UTMI) Transaction Log Specification (UTML) Record Security Specification (UTMR) Remote Account Specifications (UTRA) LookUp Resolution Specs (UTRD) File Resolution Defaults (UTRE) File Resolve Graphic Display (UTRG) LookUp Resolution Options (UTRO) ReRun a Procedure (UTRR) User FileSuite Information (UTSF) Set Printer Characteristics (UTSP) TXLOG Purge (UTTP) Modify Appl VOC Files (UTVF) Modify Appl VOC Misc. Items (UTVM) Modify Appl VOC Programs (UTVP) Audit Trail Report (UTXL) Update User Remote Accounts (UURA) Validation Codes (VAL) View Batch Process Status (VBS) View Single Batch Job Step (VBSD)
Index
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
15
Table of Contents
16
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Runtime Administration
Overview
Overview
About This Manual
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.
Who Should Read This Manual? Runtime Administration provides system administrators with an accurate and up-to-date document to use as a reference tool while installing and operating Datatel application software. The manual is intended to be useful to the new system administrator, as well as to those who have worked with Colleague for longer periods of time. Because the manual contains sensitive information that affects the performance of Colleague modules, the material contained here should not be made available to the average user of those modules.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
19
Overview: About This Manual
How This Manual is Organized Runtime Administration is organized to take you through the normal process of operating the software. Below is a list of the parts and a summary of each. Overview. Contains chapters explaining the Envision Concepts and terminology. In addition, the Overview summarizes the software and the tools used to develop each module. An overview of the account structure and Colleague file structure is provided. The section ends with an explanation of Cataloging and the Colleague Control files. Setup. Contains chapters on setting up your terminals, system parameters, and defining Validation Codes and Address default sequences. It also explains printer setup and gives guidelines for customizing your system and writing conversion programs. Security. Contains an overview of operating system, database management system and application software security. In addition, procedures for limiting access to the database management system and application software are provided. Maintenance. Contains an explanation of Envision file services including tracking records, record link management, record deletion, tracking file activity and indexing. A chapter on runtime reporting is provided. In addition, guidelines for loading releases and maintaining your system are provided. The section ends with a chapter on system utilities. Troubleshooting. Contains guidelines for troubleshooting MSP- and Envision-based software. A chapter on common Envision problems and solutions is also provided. Appendices. Contain system setup worksheets and form reference information.
20
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Overview
Basic Envision Concepts
What is Envision? Envision is one of a category of computer programs referred to as computeraided software engineering (CASE) tools. CASE tools are programs that automate the development, design, implementation, installation, and maintenance of computer applications. Envision consists of a set of tools, each of which performs a specific function or set of functions. The same basic concepts form the foundation for all applications throughout the system. For instance, all applications perform their functions through menus for selecting functions and data forms for entering or retrieving the data required for the functions. This chapter explains the basic concepts underlying all Envision applications. Please read and become familiar with this information before you begin using Envision. There are many advantages to developing applications with a CASE tool. CASE tool programs are easier to maintain because the generated code is already debugged. They are easier to support because the CASE tool automates the production of prompts, help messages, and documentation. All programs generated by a specific CASE tool have a standard user interface. The fact that menu selection and navigation are standard makes it easier to learn the application. The use of a central data dictionary saves computer resources. In addition, the CASE tool automatically cross-references to data elements and pre-coded routines.
Structure of Envision Envision consists of two components: Envision Tool Kit (ETK) Envision Runtime (UT)
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
21
Overview: Basic Envision Concepts
Envision Tool Kit The Envision Tool Kit (ETK) is the software used to create Envision-based applications. The two main components of ETK are the Painter and the Process Generator. The Painter is used to design application forms, and the Process Generator generates the code for the application, based on the parameters specified during its design. Other ETK processes are listed below: Painter Support Batch Process Support 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. Some UT processes include the following: Validation code table definition Device and keyboard definition Operator and security definition Menu definition Peripheral option defaults LookUp resolution specifications View batch status Query-by-Example procedure generator BROWSE shell Remote account specification Field and table definition
22
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Envision Forms
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
23
Overview: Basic Envision Concepts
Figure 1: Sample Form with Header Block
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.
24
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Envision Forms
Types of Envision Forms Creating an application with Envision consists, for the most part, of using a collection of forms and menus to specify parameters for the application. Envision uses the following types of forms: Menus Process forms Detail forms Online help Envision Menus display a list of Envision processes. When you select a process from the menus, or enter the process mnemonic, Envision displays the form associated with that process. 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. Processing. Numbered sequentially from 20 to 29. Inquiry. Numbered sequentially from 30 to 39. Reporting. Numbered sequentially from 40 to 49.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
25
Overview: Basic Envision Concepts
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. The fields on a process form may or may not be preceded by a number. Usually a numbered field is a field for which you can enter or change data. There is an exception: display-only window fields are numbered to provide viewing access to the data in the window. For more information on windows, see “Basic Concepts” on page 28.
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.
26
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Envision Fields
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
27
Overview: Basic Envision Concepts
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 multivalued 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. An example of a single-valued window is a window that contains a list of names only. An example of a multi-valued window is a window containing a list of names where each name is accompanied by other information, such as an address and phone number. Windows make it possible to display more information on a single form than is possible with a single-valued field. Consider a field called Schools Attended, which might be used in the Colleague system to display information about an applicant. The applicant may have attended more than one school before applying to a college. If the form shows the Schools Attended field as a single-valued field, you would see information about only one value for a data element – that is, only one of the many schools that the applicant attended. If the form shows the Schools Attended information as a multi-valued field, then you could view all information about each school on a single line of a window. You could also scroll vertically or horizontally through all entries in the list. Envision numbers each value or set of related values, and you can retrieve information using special window movement keys and commands.
28
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Basic Concepts
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 openended; 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
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
29
Overview: Basic Envision Concepts
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.
30
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Basic Concepts
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. WNDW.controller.MOVEMENT. Determines the next data element to be processed. CALC.WNDW.DSPLY.controller. Calculates the current group number and specifies which group appears on the current page. Envision also uses two variables when processing windows: WNDW.controller.INDX. Determines the current group number. WNDW.controller.LNE.COL. Determines the current display line. For each list in a window, Envision keeps track of two variables: VL.fieldname. Contains all values defined for the data element. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
31
Overview: Basic Envision Concepts
General Purpose Forms In addition to the application-specific menus, process forms, and detail forms, Envision also provides some forms that you may use from any application: Change Peripheral Defaults form View Reports on the Terminal Using BROWSE form Additional Selection Criteria form Sort/Break Criteria form Process Submission form Run a Batch Process form Run a Report form
Change Peripheral Defaults The Change Peripheral Defaults form displays options for specifying processing parameters and the destination of the report (either printed to hardcopy or displayed on the form). The options on the Change Peripheral Defaults form reflect the specific options that your operating system supports.
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.
32
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Overview
Runtime Features and Terminology 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: Direct Access. Envision Runtime allows the designer to establish whether processes are called by a numeric menu selection, by a direct access mnemonic, or by both. Using both allows the novice user to begin with selfexplanatory menu selections and proceed to direct access mnemonics with more experience. Of course, selection by mnemonic has implications on system performance because it provides much faster access to the desired data by the terminal user. Tools. Several tools aid the implementation of software systems. One particularly useful feature is a terminal definition file that allows the user to set up files for any unique terminals being used on the system. The actual programs only deal with a “virtual” terminal. The terminal file is completely external to the application software routines so that the software is completely adaptable to the installed terminal environment. Security. A complete security system is included in Envision Runtime. The System Administrator may define security at the process, record and field level. This security can define whether the login ID has create, update, or read-only capabilities. One important feature of the security system is that only those processes that the login ID is authorized to perform appear on the form. This greatly simplifies implementation and training procedures. Recovery. Envision Runtime provides an optional recovery/security feature called transaction logging. A transaction logging process for each file is selectable by the System Administrator. Before and after values of the data elements in a file are logged to a transaction file. In addition to the old and new value, the time, date, and operator ID are captured. If a system failure occurs and database recovery is required, updates can be made to the database by reentering data that is missing. Reports can be generated from the log that displays the information that must be recovered. This capability can also be used as a training tool to ensure that the operators are entering the data correctly.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
33
Overview: Runtime Features and Terminology
Form Processes. The Runtime application is comprised of both interactive form processes and on-demand utility programs. Form processes allow users to enter system parameters and characteristics through user friendly interactive prompts. These standard Envision forms help the user define new terminal types, operator characteristics, customized menus and ad-hoc database queries. 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. Samples of the functions provided by these utilities include: Envision Menu Processor. Controls the listing of options available to a user and the security access a user has to a selected process; Envision Help Processor. Displays both one-line help messages and windows of help text, providing the user with an on-line reference manual; Envision Error Processor. Provides the user with specific messages concerning erroneous entries; Envision Manage Input/Output (MIO) Suite. Set of programs which centrally manage disk I/O and disk files; Envision Procedure Generator. Takes predefined process steps to define a series of database environment commands to fulfill the desired function. These utility programs provide a seamless environment in which a user encounters familiar form displays and can navigate within the application using familiar key strokes. Every Envision-based application has the same “look and feel” because the Envision Runtime utility application drives every one of them.
34
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Terminology
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. Functional areas, however, sometimes have fundamental characteristics in common. The modularity of the application structure does not provide for the sharing of these characteristics directly across applications. The characteristics could be defined in more than one application, but such a definition requires redundant storage and maintenance.
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 Envisionbased 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
35
Overview: Runtime Features and Terminology
Example: Consider a fund raising, a human resources, and a demographics application. Each application has characteristics specific to its own functional area. Fund raising has programs for maintenance of donation information, while human resources has programs for hiring new employees. Each application contains common characteristics: a person’s name, address, date of birth, social security number and so on. These common characteristics are defined in an application to which both applications are subordinate; the demographics application. Each subordinate application can use the definitions common to each that reside in one place.
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. Tree reads provide another benefit: shared characteristics may take on a special meaning in a subordinate application. You may redefine a characteristic in a subordinate application, where permitted, so that when Envision performs a tree read for that characteristic, it finds the customized definition in the subordinate application. While this feature seems to negate the benefit of unique characteristic definitions, Envision provides the flexibility to redefine characteristics as circumstances dictate.
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. Datatel considers each module within an application as a separately deliverable part of the application. For each application, there is at least one base module and many optional modules. A base module is a module on
36
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Terminology
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 Envisionbased application is initialized and remains active until the user leaves the application. There are three kinds of processes in Envision: Forms Batch Programs Procedures
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
37
Overview: Runtime Features and Terminology
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. A special case of a batch program is an Envision Report. Envision Reports are defined as read-only batch programs which display the data the user specifies in the way he specifies. Sophisticated front-end forms allow the analyst to control the flexibility and appearance of a report, yet still provide the end user with options and features to customize the report. Since batch programs usually work on selected groups of records, they usually do not stand alone as executable processes from a menu. Batch programs are usually incorporated into Envision Procedures.
38
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Terminology
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. Features such as conditional branching and database statement inclusion allow the analyst to tailor the execution of the procedure to the options and parameters specified by the user. Procedures allow the analyst to “link” together distinct processes with pre-defined Runtime forms.
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
39
Overview: Runtime Features and Terminology
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. The device definitions are shared among all Envision-based applications. These definitions include security restrictions for users of the device and passwords associated with the device.
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.
40
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Terminology
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
41
Overview: Runtime Features and Terminology
3. Field Security allows the system administrator to selectively control access to the data stored in certain data elements no matter how those elements are used in an Envision process. Field security uses the same security class definitions as do Menu and Process Security. The class restrictions for field security provide several options which tailor the user’s access to data to the needs of both the user and the system administrator. 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.
42
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Overview
Envision File Overview
Envision Application Files Every Envision-based application requires certain files in order to run the processes of the application. These required files are called Envision files. Each application has its own suite of files called application files. Listed below is a sample of the application files in the suite: appl.CDD 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 Note: Each filename is prefixed by appl, where appl is the mnemonic for the application. This suite of files stores the information pertinent to the application. Each Envision-based application on your system has this suite of files defined.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
43
Overview: Envision File Overview
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. Following is a description of each of the application files: appl.CDD. Stores the records of the Central Data Dictionary. Each data element defined for the application has a record in the CDD. The Envision Code Generator in the Envision Tool Kit uses these definitions, along with the definitions from FILE.SPECS and PRCS.DEF to create programs. appl.DOC. Stores handwritten technical documentation on selected topics for the application. appl.ENV. Stores the Runtime definition of an Envision form process. These tables control what fields are processed on a form and where the data for the fields appears on the form. Each table is keyed with the process name that uses it. The ENV file is populated each time a form process is generated, and cannot be modified by end users. appl.ERROR. Stores standard application error messages that are shared among Envision processes. Each standard error message has a unique key which is the concatenation of the module in which the error message was first used and a sequential number. The ERROR file is populated via the Error Message Definition (EMSG) form and may be modified by end users. appl.FILE.SPECS. Stores the definitions of files created with the Envision Tool Kit. These definitions provide the physical mapping between the Central Data Dictionary and actual storage. The Envision Code Generator uses these definitions, along with those from the CDD and PRCS.DEF files, to create programs. appl.HELP. Stores the one-line help messages end users see when they access help. There are three kinds of help messages: • process help • general field help • form-specific field help Process help records are keyed by the process name for which they are used. General field help records are keyed by the data element which they document. Form-specific field help records are keyed by a concatenation of the process name and the data element name. General field help records also contain database information such as the file for the data elements, the data element’s position in the file, and a list of processes that use the data element. The HELP file is populated via the Process/Help Message Definition (HLP) form and may be modified by end users, although modifications of help messages are overwritten when subsequent Envision-
44
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Envision Application Files
based applications are loaded. appl.HELP.LONG. Stores the help text which end users see after pressing the [RETURN] key when viewing the short help message. The HELP.LONG records are keyed in the same way that the HELP records are, and contain the lines of text which make up the long help messages. The HELP.LONG file is populated via the Process/Help Message Definition (HLP) form, and may be modified by end users, although modifications of help messages are overwritten when subsequent Envision-based applications are loaded. appl.INSERTS. Stores the blocks of code that are shared among the programs in the application. These blocks are called insert modules. appl.MENU. Stores the menu definition records which control the appearance of menus for the application. In addition to a list of processes and menus which appear when the menu is run, MENU records also contain the menu’s title. The MENU file is populated via the System Menu Definition (SMD) form. Menu records included with the delivery of an application should not be modified, but new menu records may be added by end users. appl.OBJ. Stores the compiled version of all generated programs. These object code records are what Envision Runtime uses to run the processes of the application. appl.OPERS. Stores the definition of each user who has access to the application. Operator security, initial application menu, and Envision password are among the parameters stored in each OPERS record. The OPERS file is populated via the System Operator Definition (SOD) form and is defined entirely by your site. appl.PARMS. Stores application level parameters such as resolution form definitions and Easy Screen definitions. appl.PPROCESS. Stores the procedural step statistics for the application. Each procedure run has a record in this file. appl.PRCS.CTL. Stores the control records for each process and file in the application. Process records are keyed by the mnemonic for the process, and are used to determine in which menu quadrant the process is displayed on a menu, to define process security, and to determine the program to run when the process is selected by an end user. File records are keyed by the file’s name and define the fields that Envision Runtime knows about for the file. The PRCS.CTL file is populated via the System Menu Definition (SMD) form. Do not modify process control records included with the delivery of an application. New process control records may be added by end users. appl.PRCS.DEF. Stores the definition for each process in the application. The Envision Tool Kit records are the real source code for Envision processes. The Envision Code Generator uses these process definitions,
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
45
Overview: Envision File Overview
46
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 nongenerated 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Envision Application Files
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 A description of each follows: APPL.CTL. Stores information about each application defined on a development account, and how those applications interact. In addition to informational parameters such as the name and purpose of an application, APPL.CTL is where the application tree for each application is stored. An application tree provides the hierarchy of an application structure and how information is shared among the applications in the tree. See page 35 for a more detailed discussion on applications and application structures. DEVICES. Stores the definitions of terminals. These definitions, in addition to specifying the display and keyboard tables to use for a particular terminal, also specify global security classes which restrict end users using this device definition, a device password which must be specified when an end user attempts to use the device, and date and time stamping information, including the last end user to use the device. RFSPECS. The Runtime file specifications file stores the parameters which control how Envision processes records when they are written to files. These Datatel-defined parameters include indexing algorithms (see page 222), record link management (see page 217), and record add/change tracking (see page 216). RFSPECS also stores information that the System Administrator specifies for a file, including transaction logging (see page 220) and user-specified indexing. STRATEGIES. All files have a STRATEGIES record. They are used by Colleague to map each field belonging to a file to the column in SQL Server or Oracle, or the file and DICT in UniData. SYSDEFS. Stores many different kinds of global parameter records. Among these global parameters are the display and keyboard tables used in device definitions and the network definition for your system. UFSPECS. The UFSPECS or user file specifications file stores the userdefined parameters which control how Envision processes records when they are written to files. The parameters specified in the UFSPECS file are
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
47
Overview: Envision File Overview
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 and Protected Files An Envision file, whether application or trans-application, falls into two categories: shared and protected.
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 Envisionbased 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.
48
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Envision Application Files
Shared Application Files
ERROR* MENU* OPERS PARMS* PPROCESS PRCS.CTL* PRCS.GEN* PRINTERS* QBEDEF SECLASS VALCODES* VOC*
Shared Trans-application Files
APPL.CT* DEVICES* REMOTES RFSPECS* SYSDEFS* UFSPECS*
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
49
Overview: Envision File Overview
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.
50
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Runtime Administration
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. Complete instructions for setting up user interfaces are outlined, which includes defining your type of system to Envision, defining terminal tables for users, setting up terminal parameters, creating custom terminal tables, and setting up the User Interface. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
53
Setup: Introduction to Setup
54
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Setup
Defining System Parameters
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.
Using the Envision Parameters Edit (EPED) Form Use the Envision Parameters Edit (EPED) form shown in Figure 2 and Figure 3 on page 56, to control various system-wide options of Envision. These include the type of indexing to use, whether various performance enhancing features are active, and data logging options. Since most of the options can have very wide ranging effects, some undesirable, use extreme caution when making changes from the defaults. Figure 2: Envision Parameters Edit (EPED) Form (Envision 4.8)
Envision 4.8 only
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
55
Setup: Defining System Parameters
Figure 3: Envision Parameters Edit (EPED) Form (Envision 4.7)
Envision 4.7 only
MIO Indexing Mode (Envision 4.7 Only) Control the type of record indexing used by Envision. This value can be a number from 0 to 5; however, options 0, 1 and 2 are obsolete and should never be used. Here is a description of each option: 0 - (OBSOLETE) Original database indexing 1 - (OBSOLETE) Original Envision file based indexing 2 - (OBSOLETE) Enhanced original Envision file based indexing 3 - Current Envision file based indexing 4 - Current database indexing 5 - Either database or Envision file based indexing, determined file-by-file 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.
56
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
In This Chapter
Oracle I/O Off (Envision 4.7 Only) In an Oracle environment, Envision attempts to satisfy I/O requests via direct SQL statements for those processes that are generated with support for such operations. If you do not want to use this optimization, enter Yes in the Oracle I/O Off field. The default for this field is “No”. Note: The Oracle I/O Off flag is valid only in Oracle environments
Disable Full OCI (Envision 4.7 Only) In an Oracle environment, MIO does full record I/O using custom OCI SQL I/ O instead of relying on SQLator. If problems occur with full record logic, you can enter Yes here to use SQLator I/O instead of OCI full record I/O. The default for this field is “No”. Note: The Disable Full OCI flag is active only in Oracle environments.
SQL Select Off (Envision 4.7 Only) In an Oracle environment, execution of UniData-type SELECT commands is mapped to equivalent SQL selects. This mapping can dramatically decrease the time required for such operations. If you do not want to use this optimization, enter Yes in the SQL Select Off field. The default for this field is “No”. Note: The SQL Select Off flag is valid only in Oracle environments.
Read Cache Size (Envision 4.7 Only) Enter in the Read Cache Size field the maximum number of records, up to 999, that can be stored in the cache before old entries must be removed. If no read cache size is specified, the value defaults to 100. The larger the value, the
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
57
Setup: Defining System Parameters
better the caching performance. However, larger values take up more resources in each session, and more overhead is required to maintain the cache. To disable read caching, enter 0 in the Read Cache Size field.
Read Cache Log State (Envision 4.7 Only) The Read Cache Log State field gives you the option of tracking the performance of the Envision read cache by generating a record in the HOLD file. Enter Yes or -1 to generate a record of the format userid.READ.CACHE, where userid is the login ID of a specific session. Enter 1 to generate a record of the format userid.READ.CACHE.instance, where instance is a counter that is advanced each time the cache is cleared. This log contains information on each record read, not including records that are locked for update, along with statistics on the number of times the record was read from cache instead of the number of times it was read from disk. This setting is primarily intended for diagnostic purposes and is not recommended for general use. Enter No—the default value—if you do not want to log read caching.
Clear Cache Off (Envision 4.7 Only) The MIO read cache accelerates I/O by storing frequently accessed read-only data in a memory cache. The cache is cleared whenever the MIO process level is zero, for instance, when returning to the primary key prompt on a form, or around major record processing loops in batch processes. Enter Yes in the Clear Cache Off field to obtain additional acceleration by preventing the cache from clearing. The default for this field is “No”. Note: When the cache is prevented from clearing, a desirable change made in one session may not benefit another session until the user logs out and logs in again. For this reason, we do not recommend using the Clear Cache Off option.
58
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
In This Chapter
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. Note: The system default is 4; however, Envision overrides it with a default of 9 (the maximum supported). Datatel recommends keeping the Envision default of 9.
Subscription Enabled Enter Yes in the Subscription Enabled field to enable DMI transaction transmission. The default for this field is “No”. Note: Datatel recommends modifying this field only if specific application software requires it.
For more information about CampusCruiser, see Using the CampusCruiser Interface.
Inbound EDX TX Enabled Enter Yes to allow DMI_DISPATCH to accept EDX transactions from DMI. For example, enter Yes to use EDX to import grades into Colleague that were entered in e-learning software.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
59
Setup: Defining System Parameters
If you enter “No”, then DMI_DISPATCH does not accept EDX transactions from DMI, and returns an error message. Note: This field enables or disables EDX transmittals from all publishers. If you want to enable or disable transmittals from one publisher, use the settings in the publisher software.
Use Passive FTP Enter No or leave this field blank if you do not want to use passive FTP. Not all FTP clients support passive FTP (standard Windows software does not yet support passive FTP). 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.
60
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
In This Chapter
MIO Level Check Disable Error checking logic generated into all processes verifies that the MIO process level is the same coming out of a routine as it is going in. This helps to catch potential data corruption as early as possible. It is possible, though rare, for a routine to produce a legitimate mismatch. If you have such a routine and want to avoid the forced logout that occurs on a mismatch, enter the names of the routines in the MIO Level Check Disable field.
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.
DMI Print Server IP/Port (Envision 4.7 Only) Enter the IP address and port number for the Windows print server on which DMI is installed. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
61
Setup: Defining System Parameters
62
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Setup
Defining Validation Codes
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 Provide consistent values and descriptions of those values on forms and in reports Allow for special processing for certain values of codes Envision supports two types of validation codes: Code files Code tables
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
63
Setup: Defining Validation Codes
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 The minimum character string needed to identify the code Two special processing parameters 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.
Maintaining VAL Codes To define validation codes for an application, run the VAL form. 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.
64
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Code Tables
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.
Disabling Valcode Tables To disable a validation table, enter an asterisk (*) as the first code and delete the rest of the fields and codes from the table. When Envision Runtime encounters a table with just an asterisk, users can enter anything for the value of the data element that uses the table.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
65
Setup: Defining Validation Codes
66
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Setup
Editing UNIX_CONTROL Records
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. Table 1 lists the topics covered in this chapter. Table 1: Topics in This Chapter Topic
Page
Form Used
67
Editing a UNIX_CONTROL Record
68
Procedure for Editing a UNIX_CONTROL Record
73
Form Used Table 2 lists and describes the form used in this chapter. Table 2: Form Used in This Chapter Form UNIX_CONTROL Record Editing (UCRE)
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Purpose View or update a UNIX_CONTROL record in the SYSDEFS file.
67
Setup: Editing UNIX_CONTROL Records
Editing a UNIX_CONTROL Record Use the UNIX_CONTROL Record Editing (UCRE) form to view or update your UNIX_CONTROL record in the SYSDEFS file. The UCRE process detects what operating system you have, and then displays the values from the appropriate template for the UNIX_CONTROL record for your reference. The available templates are: UNIX_CONTROL_AIX 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.
68
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Editing a UNIX_CONTROL Record
Figure 4: UNIX_CONTROL Record Editing (UCRE) Form
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
69
Setup: Editing UNIX_CONTROL Records
Noteworthy Fields on the UCRE Form The fields described in this section are important for viewing or updating a UNIX_CONTROL record.
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. Entering “Yes” assigns a value of 1 to field 20 in the UNIX_CONTROL record; entering “No” assigns a value of 0.
Template Value for NOMESSAGE Option 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 references field 13 in the UNIX_CONTROL record.
Template Value for Host Type This field displays the template value for your UNIX_CONTROL record.
70
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Editing a 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). Note: If you are using QPRINT/USAM, then you need to enter S_QPRINT_PRINT_INFO or S_USAM_PRINT_INFO. The routine must return two arguments in the calling list: – The list of valid printers. – The list of valid forms.
The name of the subroutine you enter will be validated. You can use LookUp to view a list of available subroutines. This field references field 6 in the UNIX_CONTROL record.
Template Value for Printer Subroutine 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. In addition to several platform-specific versions, there is also a generic UNIX version, and a version that supports third-party QBATCH. The name of the subroutine you enter will be validated. You can use LookUp to view a list of available subroutines. This field references field 7 in the UNIX_CONTROL record.
Template Value for Batch Subroutine This field displays the template value for your UNIX_CONTROL record.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
71
Setup: Editing UNIX_CONTROL Records
Command for Defining Terminal Characteristics 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 references field 4 in the UNIX_CONTROL record.
Template Value for Terminal Characteristics Cmd This field displays the template value for your UNIX_CONTROL record.
Command for Retrieving Phantom Processes 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. A typical definition for a System V implementation of UNIX is: ps -aef | fgrep PHANTOM | fgrep -v fgrep | tr -s ' ' '\011' | cut -f3 | sort This is similar to the command string for UNIX.GET.UDT.PROCESSES, except that the search finds the keyword PHANTOM, instead of UDT. This relies on the fact that UniData distinguishes phantom processes from interactive processes by using a command line argument of PHANTOM when starting the udt process. A typical definition for a BSD implementation of UNIX is: ps -aux | fgrep PHANTOM | fgrep -v fgrep | tr -s ' ' '\011' | cut -f2 | sort This references field 10 in UNIX_CONTROL.
Template Value for Phantom Processes Command This field displays the template value for your UNIX_CONTROL record.
72
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Editing a UNIX_CONTROL Record
Procedure for Editing a 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.
Step 3. Save and exit from the UCRE form.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
73
Setup: Editing UNIX_CONTROL Records
74
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Setup
Printing
Understanding Levels of Printing There are three levels of printing to understand in order to print your output in your application software. The levels are: Operating System Database Management System Software Application Software
Operating System Refer to your operating system documentation for information about configuring the printing on your operating system. See the following sections, “Database Management System Software” immediately below, and “Application Software” on page 76 for additional information. See your operating system documentation for information on the lpr command and printer definitions.
Database Management System Software 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
75
Setup: Printing
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 In UniData, formname is synonymous with the printer name in the printcap file. All reports with formname will print at the printer with the corresponding name. We recommend that you enter the SETPTR command in the LOGIN paragraphs of your user remote accounts to direct output from the query language to the desired printer. Otherwise all output will be queued without a printer destination and will go the system printer. Note: A SETPTR command remains in effect until another SETPTR command is run, or until a user logs off the system, or until a user ends the current UniData session.
Application Software Change Peripheral Defaults Form Envision-based software uses the Change Peripheral Defaults form to direct its output. It allows the user to change the form name. In addition, the user can change the number of copies, the margins, add a defer time, and designate a mode. Typically, the user accepts the options and chooses to change the form name and mode. The mode determines if the output is sent to the printer, terminal or tape. 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.
76
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Understanding Levels of Printing
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. Figure 5: Example Peripheral Default Form (PDEF) Form
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
77
Setup: Printing
Defining Printers to Envision for Windows NT and Windows 2003/2008 The procedure for defining a printer to Envision in Windows NT or Windows 2003/2008 is different from the procedure for UNIX. To identify the printer handling routine to be used, add the printer routine name to the first field of the OS_CONTROL record in the SYSDEFS file. 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.
For All Printers Defined On The Same Local Server as Colleague If all printers are defined on the same local server as Colleague, place S_NT_PRINT_INFO in field 1 of the OS_CONTROL record in the SYSDEFS file, as shown below: AE SYSDEFS OS_CONTROL 1: S_NT_PRINT_INFO This routine reads the Registry on the Windows NT or Windows 2000/2003 server and recognizes any printers that have been defined to the server. Note: You must exit the account completely and log back into it in order to reset common with the new print routine.
78
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Defining Printers to Envision for Windows NT and Windows 2003/2008
For a Network Print Server If you are using a network print server, you must place S_VALCODES_PRINT_INFO in field 1 of the OS_CONTROL record in the SYSDEFS file, as shown below: AE SYSDEFS OS_CONTROL 1: S_VALCODES_PRINT_INFO This routine uses a UT.VALCODES table called VALID.PRINTERS to determine the valid system printers. 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. When using the S_VALCODES_PRINT_INFO routine as the printer control program, you must take great care in the construction of the entries in the VALID.PRINTERS valcode file in UT. You will probably want to put a familiar printer name in the code field on the VAL form, and then put the real path to the printer in the Special Processing 1 field. To accomplish this when the S_VALCODES_PRINT_INFO routine is being used, enter information on the VAL form in the VALID.PRINTERS valcode table as in Figure 6 on page 80. In the example, the familiar printer name is hpfirst, and its UNC path is \\pdc\hpfirst.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
79
Setup: Printing
Figure 6: Defining a Printer in the VALID.PRINTERS Valcode Table
Complete the entry in the VALID.PRINTERS table as follows: Enter the familiar name of the printer in the Code field. Enter optional descriptive information in the Description field. Enter the familiar name of the printer in the Min Entry field, exactly you entered it in the Code field. Enter the UNC path to the printer in the Special Processing field. 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: For the settings in the VALID.PRINTERS valcode table to take effect, you must exit and re-access the UniData account. In addition, you must exit and re-access the account in order to reset common with the new print routine when the OS_CONTROL record has been updated.
80
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Defining Printers to Envision for Windows NT and Windows 2003/2008
For more information about the S_VALCODES_PRINT_INFO routine, see AnswerNet pages 196.848 and 215.1569. Refer to AnswerNet page 733 for a technical over view of EasySpooler.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
81
Setup: Printing
82
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Setup
Using the Envision Process Handler What is the Envision Process Handler? The Envision Process Handler resides in the UT module and provides the means for storing, maintaining, scheduling, and running processes that have been selected to run in background mode. Stored sentences and paragraphs can also be run as background tasks. It is available with Colleague Release 17 or higher. The Process Handler menu is shown in Figure 7. Figure 7: Envision Process Handler Menu
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
83
Setup: Using the Envision Process Handler
Submitting a Task to the Envision Process Handler Users can submit tasks—including batch processes, reports and VOC paragraphs—to the Envision Process Handler for background processing.
Submitting a Batch Process or Report When a user submits a batch process or report to Envision, the Process Submission form is displayed, as shown in Figure 8. This form allows the user to specify whether the task should run in background mode and, if so, whether it should run immediately or be submitted to the Envision Process Handler. Figure 8: Example Process Submission Form
84
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Submitting a Task to the Envision Process Handler
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.
Step 2. In the Background Execution Type field: If the user selects I(mmediate Execution), the task runs immediately. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
85
Setup: Using the Envision Process Handler
Submitting a VOC Paragraph The Custom Paragraph Entry (CPAE) form, shown in Figure 9, enables users to submit a custom paragraph to the Process Handler. Figure 9: Custom Paragraph Entry (CPAE) Form
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. Note: For information about defining Process Handler queues, see “The Process Handler Setup (PHSU) Form” beginning on page 89.
86
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Submitting a Task to the Envision Process Handler
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.
Viewing and Editing Task Schedules Access the My Processes (MYPR) maintenance form to view and schedule all processes submitted under the currently logged in user ID. For more information, see “The My Processes (MYPR) Form” beginning on page 102.
The System Administrator’s Role As System Administrator, you can manage queues and tasks in the Process Handler as follows: Define processing queues. Assign specific security classes, security class characteristics, and/or user IDs to queues. Specify how many tasks are allowed to run concurrently on a queue. Start, stop, suspend, and reset processing queues. Generate reports of completed processes from the Process Status file. Purge records from the Process Status file. Modify the queue assignment and scheduling of any task that has been submitted to the Process Handler. Note: Datatel recommends that only the System Administrator have the necessary permissions to maintain the Process Handler. Typically, end users have access only to the Custom Paragraph Entry (CPAE) form, shown in Figure 9 on page 86, and the My Processes (MYPR) form, shown in Figure 19 on page 103. You may also want to allow end users access to the Process Handler inquiry forms (see “Using Inquiry Forms” beginning on page 110).
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
87
Setup: Using the Envision Process Handler
Setting Up the Process Handler and Managing Queues Three forms enable you to set up and manipulate Process Handler queues: Use the Process Handler Setup (PHSU) maintenance form, described in “The Process Handler Setup (PHSU) Form” beginning on page 89, to identify the available process queues and to assign security classes, security class characteristics, and/or user IDs to specific queues. Use the Process Queue Management (PRQM) processing form, described in “The Process Queue Management (PRQM) Form” beginning on page 91, to start and stop Process Handler queues either globally or individually, to set the maximum number of concurrent tasks per queue either globally or individually, and to schedule times when specific running queues are to be suspended. Use the Reset Process Queue Handler (RSPH) processing form, described in “The Reset Process Queue Handler (RSPH) Form” beginning on page 94, to stop all running queues and reset the Process Handler. Note: When a queue is stopped, all currently processing tasks continue to run to completion. No new tasks are started.
88
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Setting Up the Process Handler and Managing Queues
The Process Handler Setup (PHSU) Form The Process Handler Setup (PHSU) maintenance form, shown in Figure 10, is used to identify the available process queues and to assign security classes, security class characteristics, and user IDs to specific queues. Figure 10: Example Process Handler Setup (PHSU) Form
The Processing Queue Names fields display the available queues. You can add or edit queue names in these fields.
Step 1. Whenever a task is submitted to the Envision Process Handler, it is assigned to a queue. If you do not specify a queue for a task, the Process Handler automatically selects the DEFAULT queue.
Step 2. To assign a security class or security class characteristic to a specific queue, enter the name of the security class or characteristic in the Security Class Queues Class field.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
89
Setup: Using the Envision Process Handler
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. Note: Queue assignment by security class is overridden by the direct assignment of a queue to a specific user ID in the User Specific Queues User ID and Queue fields.
Step 4. To assign a user ID directly to a specific queue regardless of the user’s associated security classes, enter the user ID in the User Specific Queues User ID field. In the User Specific Queues Queue field, enter one of the queue names shown in the Processing Queue Names fields. The Queue field is validated against the list of available queues in the Processing Queue Names fields. 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.
90
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Setting Up the Process Handler and Managing Queues
The Process Queue Management (PRQM) Form Use the Process Queue Management (PRQM) processing form, shown in Figure 11 on page 92, to start and stop Process Handler queues. Each process queue runs tasks in the order in which they appear in the Outstanding Process listing (see “The Outstanding Processes (OPRM) Form” beginning on page 95). The queue accepts tasks up to the Maximum Processes per queue, and then waits until one of the tasks is completed before starting a new task. 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. Process Handler processing is executed in the background. If for any reason it fails to execute or is prematurely aborted, you must use the Reset Process Handler (RSPH) process to reinitialize the records used in processing. Note: Because only one instance of the Process Handler processor can run at a time, until you reset the Process Handler by using the RSPH form, the system regards the Process Handler as still running and will not allow you to restart it.
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. If the Process Handler is unexpectedly stopped, the queue statuses stored in Envision may be out of sync. This means that they may show as “Running” when they are no longer active. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
91
Setup: Using the Envision Process Handler
Figure 11: Example Process Queue Management (PRQM) Form
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. Note: When data is entered in the global fields, it automatically populates the Start Date/time, Stop Date/time, and Maximum Processes fields for all the queues in the lower portion of the PRQM form,
92
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Setting Up the Process Handler and Managing Queues
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.
Note: If no number is entered in the Maximum Processes field for a queue, the default maximum is 1. This means that the queue waits for each task to be completed before accepting another task.
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
93
Setup: Using the Envision Process Handler
The Reset Process Queue Handler (RSPH) Form If the Process Handler does not run or prematurely terminates, use the Reset Process Handler (RSPH) form to re-initialize the records. Only one instance of the Process Handler can run at a time. Until the Process Handler is reset, the system does not allow you to restart it. Use the Reset Process Queue Handler (RSPH) processing form, shown in Figure 12, to stop all queue processing and to reset the Process Handler. Figure 12: Example Reset Process Handler (RSPH) Form
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.
94
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Managing Processes
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 Outstanding Processes (OPRM) Form The Outstanding Processes (OPRM) maintenance form, shown in Figure 13, enables you to manipulate queues and reorder tasks within queues. You can also edit individual process schedules by detailing from the OPRM form to the Process Scheduling (PHTS) form, as shown in Figure 14 on page 97. Figure 13: Example Outstanding Processes (OPRM) Form
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
95
Setup: Using the Envision Process Handler
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. Note: A process that runs repeatedly is termed scheduled, and Yes is displayed in the Sched field for the process on the OPRM form. A once-only process is termed unscheduled, and No is displayed in the Sched field for the process on the OPRM form.
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 1. The specified queue must be running.
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.
96
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Managing Processes
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. Figure 14: Outstanding Processes (OPRM) Form Detailed to Process Scheduling (PHTS) Form
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
97
Setup: Using the Envision Process Handler
The Process Scheduling (PHTS) Form You can detail to the Process Scheduling (PHTS) form, as shown in Figure 15, from the Outstanding Processes (OPRM) form, the My Processes (MYPR) form, or the Process Scheduling (PRSC) form. Figure 15: Example Process Scheduling (PHTS) Form
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.
98
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Managing Processes
Step 2. To schedule repeated runs, complete the remaining fields as follows: Schedule Process to Run Every/From. This field has three parts: • In the first field, enter the interval. This number is used with the second field, frequency. For example, to have a process repeat bi-weekly, enter 2 in this field, and then select Week in the second field. • In the second field, enter a frequency. The process will be scheduled to run at specific intervals for specific seconds, minutes, hours, days, weeks, or months. • In the third field, enter the next scheduled occurrence of this job. Use this field only if the frequency is set to Second, Minute, or Hour. This field determines whether the interval and frequency (such as 30 seconds, or 8 minutes, or 5 hours) is added to the start time/date or from the end time/ date of the previous run. Technical Tip: To immediately restart a scheduled job, enter 10 as the interval, the frequency as Seconds, and then set the job to start after the previous run has ended.
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.
A process that runs repeatedly is termed scheduled, and “Yes” is displayed in the Sched field for the process on the OPRM form. The Process Paragraph displays the generated paragraph saved in VOC that was created by the original run of the process. This paragraph will be rerun according to the schedule you enter. It is not editable. If you plan to schedule jobs through the Process Handler to repeat continuously, such as every x number of seconds after the end of the previous job, the process handler queues that may be used for those jobs should be set up on the Process Queue Management (PRQM) form with the Maximum Processes column set to a value greater than 1. This is needed because you don't want the continuously repeating job to tie up the entire queue, preventing any other repeat jobs from getting invoked through that queue. If the Process Handler stops abruptly or prematurely, such as by the Listener getting stopped and restarted or the database getting stopped and restarted, then the Process Handler will have to be reset on the Reset Process Queue
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
99
Setup: Using the Envision Process Handler
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 Process Scheduling (PRSC) Form The Process Scheduling (PRSC) maintenance form, shown in Figure 16, displays only scheduled processes, such as processes that are set to run more than once. Figure 16: Example Process Scheduling (PRSC) Form
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.
100
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Managing Processes
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. Figure 17: Process Scheduling (PRSC) Form Detailed to Process Scheduling (PHTS) Form
For information about using the PHTS form to edit a process schedule, see “The Process Scheduling (PHTS) Form” beginning on page 98.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
101
Setup: Using the Envision Process Handler
The My Processes (MYPR) Form The My Processes (MYPR) maintenance form, as shown in Figure 18, is typically available to end users, allowing them to view and schedule the processes that they have submitted under the currently logged in user ID. To edit a process schedule, detail to the Process Scheduling (PHTS) form, as shown in Figure 19 on page 103. Figure 18: Example My Processes (MYPR) Form
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.
102
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Managing Processes
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. Figure 19: My Processes (MYPR) Form Detailed to Process Scheduling (PHTS) Form
For information about using the PHTS form to edit a process schedule, see “The Process Scheduling (PHTS) Form” beginning on page 98.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
103
Setup: Using the Envision Process Handler
Working with Process Status File Records Two forms enable you to work with the records in the Process Status file: 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.
104
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Working with Process Status File Records
The Process Status Report (PSTR) Form The Process Status Report (PSTR) reporting form, shown in Figure 20, enables you to generate a report from the Process Status file listing all processes completed through the Envision Process Handler. Selection criteria may be limited by start date, end date, User ID, mnemonic, and any additional criteria you select. 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. Figure 20: Process Status Report (PSTR) Form
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
105
Setup: Using the Envision Process Handler
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.
106
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Working with Process Status File Records
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.
Step 6. Do you want to limit the selection of processes by specifying additional selection criteria?
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.
No. Enter No in the Additional Selection Criteria field. The Additional Selection Criteria form is not displayed, and all records in the specified date range are included in the report. Figure 21: Process Status Report (PSTR) Addl Selection Criteria Form
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
107
Setup: Using the Envision Process Handler
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.
The Process Status File Purge (PSFP) Form The Process Status File Purge (PSFP) processing form, shown in Figure 22, enables you to purge selected records from the PHANTOM.STATUS and PHANTOM.STATUS.DTL files. The PSFP form also purges any COMO files in the _PH_ directory created for the selected process runs. Figure 22: Process Status File Purge (PSFP) Form
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.
108
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Working with Process Status File Records
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.
Step 5. Do you want to limit the selection of records by specifying additional selection criteria?
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.
No. Enter No in the Additional Selection Criteria field. The Additional Selection Criteria form is not displayed, and all records in the specified date range are purged from the Process Status file.
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
109
Setup: Using the Envision Process Handler
Using Inquiry Forms Two inquiry forms are available in the Process Handler. 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. Figure 23: Example Outstanding Processes (OPRI) Form
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.
110
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using Inquiry Forms
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. Figure 24: Example Running Processes (RPRI) Form
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
111
Setup: Using the Envision Process Handler
112
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Setup
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 Note: The STANDARD.FORMS directory file is no longer supported in Release 18.0.
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
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
113
Setup: Customizing an Application
(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. To obtain a list of all of the resolution specifications that Datatel provides, enter the LKUP: Resolution Specs (LPRT) from the application that you would like a report on. See “LKUP: Resolution Specs (LPRT)” on page 326, for further information.
To Change a Resolution Form Step 1. Enter the application.
Step 2. Enter the LookUp Resolution Specs (UTRD) form.
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.
114
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Adding/Changing Envision Menus
Adding/Changing Envision Menus The Envision Menu Processor uses menu definitions stored in the application file MENU to generate menu forms. These forms display to the user the options available on the menu, including both the mnemonic of the process and a description. While a process can be run from any menu prompt using the process’ mnemonic, a menu form displays a description of the process as well as allowing the user to enter a number instead of the mnemonic. 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. To prevent losing your customized menus at each release installation, create new menus using the delivered menus as models. The simplest way to create a new menu is to copy the menu you wish to use as a model.
Creating a New Menu in the Same Application as the Model 1. Run the command: COPY FROM appl.MENU model.menu, new.menu where appl is the mnemonic for the application, model.menu is the mnemonic for the model menu and new.menu is the mnemonic for the menu you are creating. 2. Enter the application appl and run the Menu Definition (SMD) form. 3. Add any valid process mnemonics or menu mnemonics to your new menu or delete existing mnemonics to customize the menu for your site. When copying the new menu record, remember to choose a unique mnemonic for the new menu. Do not use a mnemonic defined for any Envision-based application or a custom mnemonic already created at your site. Remember that no Envision application delivered from Datatel will ever have a mnemonic which begins with the letter “X”. If you prefix your new menu mnemonic with the letter “X”, you can be sure that the mnemonic does not duplicate any Datatel-defined Envision mnemonic.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
115
Setup: Customizing an Application
Creating a New Menu 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.
Step 3. Add valid process mnemonics to the 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. You can also redefine a menu from a higher application in a subordinate application. Since the application file MENU is subject to tree reads, Envision Runtime finds and uses the definition for the menu in the subordinate application. The Envision Tool Kit is required to define your own custom applications. You can prevent the loss of custom menus from a Datateldefined application by creating your own custom menus in your subordinate application.
Creating a Menu Based on a Model in a Higher Application Step 1. Run the following command: COPY FROM appl.MENU TO subappl.MENU model.menu, new.menu where appl is the higher application in the application tree, sub.appl is the subordinate application, model.menu is the menu you wish to customize and new.menu is the mnemonics for the new menu you are creating.
116
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Adding/Changing Envision Menus
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
117
Setup: Customizing an Application
STANDARD.FORMS (Release 17.0 only) STANDARD.FORMS is a directory file that contains the source code and form images for programs you can modify. The source code has no prefix. This gives you a choice on some of the forms programs and allows you to change them even if you have not leased source code. Note: STANDARD.FORMS is no longer supported in Release 18.0.
If you wish to make changes to a program in STANDARD.FORMS, identify the program that you wish to change. LIST STANDARD.FORMS gives you a list of the programs you can modify. Determine the program that you want to change, make the changes, and then test the program in your test account before you make the changes in your live account.
Modifying a Program in STANDARD.FORMS Following is the procedure for changing STANDARD.FORMS programs. How to program is not covered.
Step 1. Copy the program from STANDARD.FORMS to CUSTOM.SOURCE. You will make the actual changes to the program once it is in CUSTOM.SOURCE. :COPY FROM STANDARD.FORMS TO CUSTOM.SOURCE programname
If the program has the suffix -VER2 or .STD then change the name of the program to the Colleague standard name. :CNAME CUSTOM.SOURCE programname,standardname
Step 2. Make the appropriate modifications. You should investigate the SOURCE.INSERTS that are inserted into the print routine. These will be prefaced by the $INSERT command. The SOURCE.INSERTS file holds the COMMON variables that are used throughout Colleague programs. Never modify the SOURCE.INSERTS file! :edit CUSTOM.SOURCE programname
118
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
STANDARD.FORMS (Release 17.0 only)
Step 3. Copy the modified program to the module.SOURCE or application.SOURCE file. :COPY FROM CUSTOM.SOURCE TO module.SOURCE programname
Step 4. Compile the program. :BASIC module.SOURCE programname
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. :edit VOC programname
If line 1 is a V for verb, then catalog the program. :CATALOG module.SOURCE programname
Step 6. If there is a form image, copy it to FORM.IMAGES. :COPY FROM STANDARD.FORMS TO FORM.IMAGES form_image
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
119
Setup: Customizing an Application
120
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Setup
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
121
Setup: Grouping Screens
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) Emergency Information (EMER) 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.
Security and Chaining 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 security rights specified for the chain take precedence. It is important to ensure that you limit access to the Screen Chaining Specification (SCSP) form. Otherwise, someone could use the SCSP form to add an otherwise inaccessible screen to an accessible chain. 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.
122
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Chaining Screens
Application Hierarchy and Chaining You define screen chains from within the application in which you want them used. Like operator records and security classes, chains that are defined at the top of the application hierarchy (for example, in the Core System), are visible to applications lower in the hierarchy. Chains defined in peer applications, such as the Human Resources System and the Financial System, are not visible in both; that is, if a chain is defined in the Human Resources System, it is not visible in the Financial System. Only screens that are otherwise visible to an application—that is, those within and above the application in the hierarchy—may be included in a chain.
Function Keys and Chaining To support movement among chained screens, use the following three function keys: Table 3: Movement Function Keys Function FWD
Function Description Displays the next screen in the chain. If you go forward while the last screen in the chain is displayed, the system responds as if you had Finished.
BACK
Displays the previous screen in the chain. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
123
Setup: Grouping Screens
As shown in Table 4, some of the existing function keys work a little differently for chained screens, although they perform essentially the same functions they always have. The behavior of all other existing function keys remains unchanged. Table 4: Existing Function Keys and Chained Screens Function CANCEL
Function Description Cancels changes made to the current record. When you cancel, the following prompt is displayed: 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 continue, cancel to discard all changes in chain 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 ACCESS
Invokes another screen from the current screen without returning to the menu. If the current screen has a LookUp prompt, you must respond to the prompt before pressing this key. When you press Direct ACCESS, the following prompt is displayed: Field JUMP to make changes, return to confirm or cancel to abort. To save any changes you might have made and continue, press Enter. The following prompt is then displayed: Enter mnemonic of process to run or cancel. 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.
124
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Chaining Screens
Table 4: Existing Function Keys and Chained Screens (cont’d) Function EXIT
Function Description 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 menu from which you accessed the screen you were on when you pressed Direct ACCESS. When you EXIT, the following prompt is displayed: 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. When you FINISH, the following prompt is displayed: 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. When you UPDATE, the following prompt is displayed: 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
125
Setup: Grouping Screens
Components of a Screen Chain Definition Use the Screen Chaining Specification (SCSP) form to define a group of screens in a way that mimics the flow of screens in Colleague processes. Figure 25: Example Screen Chaining Specification (SCSP) Form
Use Table 5 to guide you in completing this form. Table 5: Fields on the Screen Chaining Specification (SCSP) Form Field
Required/ Optional
Usage
Description
Describes the group of screens. The description is displayed next to the mnemonic on any menus to which you add the chain.
Optional
Short Help Message
Provides a one-line message further describing the chain. The user can display this message by typing the chain mnemonic at a menu prompt and accessing Process Help.
Optional
Long Help Text
Provides a longer message describing the chain. The user can 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.
Optional
126
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Procedure for Chaining Screens
Table 5: Fields on the Screen Chaining Specification (SCSP) Form (cont’d) Field
Usage
Required/ Optional
Mnemonic
Lists the mnemonics of the screens in the chain in the order in which they will be displayed. 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.
Required
Require
Determines whether the user must display the screen before 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.
Optional
Post-Commit Subroutine
Specifies the name of the subroutine that will be run after the user 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.
Optional
Procedure for Chaining Screens Follow these steps to define a new screen chain and make it available to your users:
Step 1. Choose a mnemonic for the chain.
Step 2. Access the application in which you wish to define the chain. The application’s main menu is displayed.
Step 3. Enter SCSP at the menu prompt.
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
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
127
Setup: Grouping Screens
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.
128
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Procedure for Reporting on Chained Screens
Procedure for Reporting on Chained Screens Follow these steps to report on screen chains: 1. Access the application on which you wish to report. 2. The application’s main menu is displayed. Enter CHUS at the menu prompt. 3. The Chain Usage Report is displayed. You wish to list all of the chains defined in an application along with the screens that belong to those chains. Enter C in the Report by Chains or by screens field. You wish to list all of the screens in an application that belong to a chain along with the chains to which they belong. Enter S in the Report by Chains or by screens field. 4. RETURN twice. 5. The Change Peripheral Defaults form is displayed. 6. Complete the Change Peripheral Defaults form as desired. FINISH and RETURN. 7. The Process Submission form is displayed. 8. Complete the Process Submission form as desired. FINISH and RETURN to run the report. The report is sent to the peripheral device you specified on the Change Peripheral Defaults form.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
129
Setup: Grouping Screens
130
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Runtime Administration
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 Database Management System Application Software 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:
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
133
Security: Security Overview
UNIX Step 1. The Operating system login ID and password are validated.
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 1. The Operating system login ID and password are validated.
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
134
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Logging In
contain ENV.INIT. You can customize the paragraph to bring up the application menu.
For All Platforms 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. Technical Tip: Device Security Classes are ignored for Switch-based systems.
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
135
Security: Security Overview
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.
136
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Logging Off
Logging Off When the user logs off, the system looks for the paragraph LOGOUT and runs it if it exists.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
137
Security: Security Overview
138
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Security
Operating System Security
Within the operating system, you have two security areas to address: Setting Up Login IDs and Passwords for Users Setting Rights on Directories and Files
Setting Up Login IDs and Passwords for Users Refer to the documentation for your operating system for full details on adding users to your host system. 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 Initial attach point (home directory) Operating system security rights Command environment attributes Note: You must be logged in to your host system as the system administrator to use these utilities.
These utilities provide methods for adding, deleting, and modifying users’ login IDs and other user attributes.
Setting Up Users in UNIX In the UNIX operating system, use the adduser utility to set up user attributes. In UNIX, setting up new user accounts and setting up remote accounts are closely related.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
139
Security: Operating System Security
Operating System Security in UniData UniData’s security, in combination with Colleague’s setup procedures, adequately covers most security needs. Datatel recommends that you devise an uncomplicated and straightforward user authorization file setup. Usually, this means setting user authorization files on the master file directory (MFD) and user file directory (UFD) levels and allowing those rights to default to subsequent files and subdirectories.
Accessing the Database Management System Every site must decide whether to allow end users access to the database management system. Several levels of security exist within the database management and application software that restrict what end users can do. There are basically three levels of restriction that a site can choose for each of its users: Complete restriction to the database management system Limited restriction to the database management system Access to the database management system Degrees of restriction exist within each of the above.
140
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Complete Restriction
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.
Guidelines for Complete Restriction 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 Query Builder (User Interface) 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
141
Security: Operating System Security
Guidelines for Limited Restriction Follow “Guidelines for Complete Restriction” beginning on page 141 for Complete Restriction. To add Browse:
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 Vocabulary (VOC) records If you do not define any directories, the user will be able to access the HOLD directory only, which contains generated reports. Technical Tip: BROWSE has a delete capability and allows a user to delete records from the directory. Use discretion in deciding the files the user can access and never allow the user access to a source code directory.
Using the Sequential File BROWSE Shell (UTFB) Process The UTFB process allows users to view data records in a file directory. In the BROWSE process, the screen acts as a 22-line, 80-character window into a record. 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.
142
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Limited Restriction
HOLD File Security In Release 18.0, Envision 4.8 allows you to select the security you want to associate with your file output. Locate a file directory to browse. The default system file is the Printer Hold File.
Public file security (PB) 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.
Private file security (PR) Private file security sends the output to a subdirectory using the User ID of the person creating the output. This subdirectory is located in a PRIVATE subdirectory within the HOLD file. A VOC pointer is also created named HOLD.PRIVATE.userid, where userid is the ID of the person who creates the output. Private file security means that the output can be viewed only by the person who creates the output.
Shared file security (SH) Shared file security sends the output to a subdirectory, whose name is the same as the group name. You must specify the group name. This subdirectory is located in a SHARED subdirectory within the HOLD file. A VOC pointer is also created named HOLD.SHARED.groupname, where groupname is the name of the group. Shared file security means that the output can be viewed only by members of a pre-approved group. See also “Output Security Groups” beginning on page 145. Note: This version of the UTFB form (including Security Type) is available in Release 18.0 for Envision 4.8 only.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
143
Security: Operating System Security
Figure 26: Sample Sequential File BROWSE Shell (UTFB) Form
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 2. Select the security to associate with your file output. Public file security (PB) Private file security (PR) Shared file security (SH)
Step 3. Locate existing items that exist in the file directory to browse.
144
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Limited Restriction
Step 4. Enter a browse file option: S - Spool the item to the line printer (132x60). B - Browse the item at your terminal. D - Delete the item from the file. You may enter one, two, or all three options: BS - Browse the item and then spool it to the line printer. SD - Spool the item and then delete it from the file. BSD - Browse the item, spool it, and then delete it from the file.
Output Security Groups When you are creating output to a hold file, as selected on the Change Peripheral Defaults (CPDE) process, you can specify a group type security. This type of security limits access to the document to only those accounts that are members of the group. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
145
Security: Operating System Security
Figure 27: Sample Output Security Groups (OSGD) Form
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.
146
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Security
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 Process Security is based on security classes. Security classes assign groups of users security rights for specified menus and processes. Before allowing users to run an Envision-based application, define the security classes for your system so that the work-flow for each user can be controlled. 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. Operator definition is covered in the next chapter. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
147
Security: Application Security
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. Remember to consider the Envision application structure when defining your security classes. At the top of every application’s application tree is the Runtime application (UT). When examining the system files, Envision Runtime first checks the current application’s system files for the record requested. If the record is not found, Envision Runtime begins to traverse the application tree, searching each subsequent set of system files for the requested record. If Envision finds the requested record in an application higher in the tree, it will use the data from that record. Envision continues to traverse the application tree until it reaches the UT application. If the requested record is not found after examining the UT application, then the record does not exist in the current application’s tree structure. Example: Consider the following application tree: at the base of the application tree is the current application, a user defined application called XCF. This application is defined as a subordinate application to the Datatel application CF. Completing the application tree are the Datatel application CORE and the Runtime application UT. 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. As system administrator, you have access to the Envision Runtime application (UT). Since UT is an application with associated forms and files, you can run UT just like any other application. In the Envision application structure, the UT application is at the top of every other application’s tree. What this structure means to you is that, for all Envision files, Envision Runtime will examine the UT system files if the requested record is not found in lower applications of the application tree. As system administrator, therefore, you can define one OPERS record, for example, which will be used by all applications that do not have an OPERS record with the same key.
148
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Security Classes
Restricting User Access on the Security Class Definition (SCD) Form The Security Class Definition (SCD) form allows you to define security classes based on the work-flows of your application’s end users. The four categories of processes provide four different ways of restricting user access. Do Only These. The Do Only These category limits the end user’s access to the application to the finite list of menus and processes included in this list. When combining security classes, the Do Only These list from each class is combined into one list. If a Do Only These list exists, this list of processes and menus becomes the global access list for the user. If the user has not defined Do Only These lists, the user’s global access list is every process in the current application and every application above it in the application tree. Never Do These. The Never Do These category allows you to prevent end users from accessing a finite list of processes and menus. If an end user can have access to all but a few processes, it is easier to define which processes the user cannot access rather than list the numerous processes which the user can access. Each process or menu listed in the Never Do These list is removed from the end user’s global access list, thereby preventing user access to that process or menu. If the end user has more than one security class, the Never Do These lists are combined and the menus and processes in the union of these lists are removed from the user’s global access list. If the user does not have Never Do These lists defined, the user has access to all menus and processes left after determining the global access list defined by the Only Do These category. Inquiry Only. The Inquiry Only category allows you to let users in the security class access the processes listed, but these users may only view the data maintained on these forms; they may neither add nor modify this data. Processes defined as Inquiry Only for a security class remain in a user’s global access list, but are flagged so that Envision Runtime will prevent any changes. If the user has more than one security class, the Inquiry Only list for each class is combined and processes in the resulting list are marked as inquiry in the global access list. Privileged. The Privileged category allows you to restrict access to a finite list of processes and menus so that only members of certain security classes can access them. If a user is not a member of a security class for a Privileged process or menu, that user may not access that process or menu. If the Privileged process or menu is not in the user’s current global access list, the user may not access that process or menu. If a process or menu is defined as Privileged in more than one security class, a user need only be a member of one of those classes to potentially have access to that process or menu.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
149
Security: Application Security
Restricting User Access for Detail Forms It is important to note that if a form in a list allows detailing to other forms, the UI and WebAdvisor interfaces act differently in how they handle these detail forms.
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. However, if the security class were set up as follows: DO.ONLY.THESE: NAE INQUIRY ONLY: BIO 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: See AnswerNet document 5166.75 for an issue when users have “Inquiry Only” access to a PERSON-based detail form, and the user selects “A” to add from a Resolution screen. Unless the user cancels at this point, a bogus PERSON record is created when the user saves.
Detail Forms in WebAdvisor WebAdvisor works differently. In WebAdvisor, each time a user details, the access rights are evaluated independently of where the user came from. There is no concept of inheriting access rights from another form. For WebAdvisor forms, each form should be explicitly referenced in a security class.
150
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Security Classes
Guidelines for Defining Security Classes for an Application For each work-flow you have defined for your application users, create a security class. Keep the security classes simple. Envision security is a simple concept to grasp if the classes you define are remain simple. In the following discussion, menus as well as processes can be listed on the Security Class Definition (SCD) form. The use of the word process implies menus as well. 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). At the initialization of the application, Envision Runtime builds a list of the processes to which a user has access. This list begins as a list of all processes defined for the application. Envision Runtime then compares the global list to the list of Do Only These processes. If this restricted list is defined, it becomes the global list of processes to which the user has access. If this restricted list is not defined, the user still has access to all application processes. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
151
Security: Application Security
Use the worksheet included in “System Setup Worksheets” beginning on page 295 to define the processes that each class of users may access. Check the list of processes for an application in the user documentation for that application. Also use the list of Runtime mnemonics included in the Appendices. The work-flows of each class of users determine the processes each class needs to run. Be sure that every work-flow of every possible user of the application is defined by a security class. Also be sure that each work-flow has one and only one class so that you need not worry about the ramifications of combining security classes.
Procedure for Creating Security Classes 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 2. Complete the security class worksheet in “System Setup Worksheets” beginning on page 295.
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.
152
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Operator Definition
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. The main information that is associated with an operator record is: User ID (must be the same as the login ID) Envision Password Security Classes Initial mnemonic to run when the operator enters the application
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
153
Security: Application Security
Creating/Deleting Operator Definition Records You may define operator records from within any application in the hierarchy. Datatel recommends that you define all operator records from within Runtime (UT). This makes it easier for you to keep track of your operator definitions and reduces the likelihood of users having problems accessing certain applications. 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. Figure 28: Example Operator Definition (SOD) Form
154
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Creating/Deleting Operator Definition Records
Procedure for Creating an Operator Definition Record Step 1. Create a unique OPERS record for each user.
Step 2. The OPERS record ID must be the same as the operating system login ID.
Step 3. Complete the Worksheet in “System Setup Worksheets” beginning on page 295.
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.
Procedure for Deleting an Operator Definition Record Step 1. Determine the application OPERS file that the obsolete operator definition resides in.
Step 2. Run the application.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
155
Security: Application Security
Step 3. Run the Envision Runtime System Operator Definition (SOD) form.
Step 4. Enter the ID of the obsolete operator definition.
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.
156
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using the PRCS.CTL Security Inquiry (PCSI) Form
Using the PRCS.CTL Security Inquiry (PCSI) Form The PRCS.CTL Security Inquiry (PCSI) form, shown in Figure 29, is a useful tool for security troubleshooting. This inquiry form allows you to verify at a glance which security classes are denied access, permitted access, or permitted inquiry-only access to a process or a field. Figure 29: PRCS.CTL Security Inquiry (PCSI) Form
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
157
Security: Application Security
Process Security Classes The Denial fields show the list of classes which are not permitted to use the process. 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. Note: An empty list implies all classes.
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.
Field Security Classes The Secure Fields fields show the list of fields in the selected process that have some form of field security. 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.
158
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using the Process Security Summary (PSCS) Form
Using the Process Security Summary (PSCS) Form Use the Process Security Summary (PSCS) form to generate a security-related report for a process you specify. Figure 30: Process Security Summary (PSCS) Form
This report contains the following sections:
Section 1: Security Classes Referencing the Process Lists all the security classes that reference this process, and identifies the manner in which they reference it.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
159
Security: Application Security
Section 2: Process Access Points 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. Subsection 3: Forms TO - Forms that this process can detail to. 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).
Section 3: User Access Rights 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. Note: If you are reporting on a procedure that may be accessed by both its mnemonic and its procedure name (such as CSRP in ST, which may also be accessed via CRJ011), then an additional Section is produced for the CRJ011 procedure access.
160
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using the Process Security Summary (PSCS) Form
Noteworthy Fields on the PSCS Form The fields described in this section are important for generating a securityrelated report for a process you specify.
Process In the Process field, specify a form or procedure for which information is wanted. You can specify it as either a mnemonic or a process ID. To specify a mnemonic, prefix the mnemonic with “;M ”. For example, to specify CORE's Name and Address Entry (NAE) form, enter one of the following: ;M NAE DMSU22
Show User Access Rights for 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
161
Security: Application Security
Procedure for Using the Process Security Summary Report Step 1. Access the PSCS form.
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.
Step 5. Save from the PSCS form.
162
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using the Process Security Summary (PSCS) Form
Example of the Process Security Summary Report
July 02 2009 Page 1
Process Security Summary Report
Procedure CSRP (Cash Receipt Print) ================================================================================= Mnemonic...: CSRP / CRJ011 Process....: CRJ011 Application: ST Type.......: Procedure ---------------------------------------------------------------------------------
Section 1: Security Classes Referencing the Process --------------------------------------------------Appln -----ST ST ST ST
Class -------------------ALLOW.CRJ011 ALLOW.CSRP BLOCK.CRJ011 BLOCK.CSRP
Usage ----------------------------------------------------Do Only These Do Only These Never Do These Never Do These
July 02 2009 Page 2
Process Security Summary Report
Procedure CSRP (Cash Receipt Print) ================================================================================= Section 2: Process Access Points -------------------------------Access Points, Subsection 1:
MENUS
(Menus on which CSRP appears)
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 >
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
163
Security: Application Security
July 02 2009 Page 3
Process Security Summary Report
Procedure CSRP (Cash Receipt Print) ================================================================================= Section 3: User Access Rights for CSRP -------------------------------------User Access Rights / Security Classes - --------------------------------- --------------------------------------------F GUEST1 - GUEST 1 ................ Full access > ADMIN, ADMIN.1, GL.ADMIN, BUDADMIN, FA.ADMIN, > AP.ADMIN,PU.ADMIN, HR.ADMIN, PC.ADMIN
July 02 2009 Page 4
Process Security Summary Report
Procedure CSRP (Cash Receipt Print) ================================================================================= Section 4: User Access Rights for CRJ011 ---------------------------------------User Access Rights / Security Classes - --------------------------------- --------------------------------------------F GUEST1 - GUEST 1 ................ Full access > ADMIN, ADMIN.1, GL.ADMIN, BUDADMIN, FA.ADMIN, > AP.ADMIN,PU.ADMIN, HR.ADMIN, PC.ADMIN
164
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Security
Record and Field Security
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 The field in that file to retrieve The key to use when reading a record from the file. Example: If you have a non-Envision file called USERS, which contains information about each user who can login to the system. Each USERS record is keyed by the user’s login ID. In the USERS file is a list of position codes that the user is allowed to view on an employment information form. You can then define user characteristics which evaluate to the user’s accessible employment codes.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
165
Security: Record and Field Security
Evaluation by Envision Runtime Envision Runtime evaluates each of the user characteristics defined when a user enters an Envision-based application. This evaluation provides Envision Runtime a list of user characteristic names and their associated values. For example, the user ADMIN logs in and enters the Envision-based application “XCF”. The system administrator has defined four user characteristics: ACCESS.POS1, ACCESS.POS2, ACCESS.POS3 AND ACCESS.POS4. In the USERS file are four fields, each of which contains a position code for which the user may access EMPLOYEE records. These four fields contain “MGT”, “CLERK”, “STAFF” and “AIDE”, respectively. Envision Runtime assigns these values to the ACCESS.POS characteristics in order: ACCESS.POS1 is “MGT”; ACCESS.POS2 is “CLERK”; ACCESS.POS3 is “STAFF”; and ACCESS.POS4 is “AIDE”. 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 Envision Runtime compares the characteristic values in ACCESS.POS1 and in ACCESS.POS2 against the data stored in the POSITION.CODE field. If each of the record security criteria are true, the user has “A”, or “All”, access to the record. If either of the record security criteria is false, the user does not have access to the record, assuming no other record security criteria are defined.
Guidelines for Specifying Record Security As with all Envision security, keep the definition of record security simple. They provide better Runtime performance and are easier to understand and troubleshoot.
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.
166
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Record Security
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 reinitialized.
Step 7. Changes to record security definitions do not take effect until Envision is reinitialized.
Defining Record Security User Characteristics Use the Record Security User Characteristics (RSUC) form to define characteristics for each user. This form also allows you to see the values Envision Runtime would use for you, the current user. The first step to define Envision Runtime Record Security is to determine where the data about each user is stored. The RSUC form requires a file and a record key in order to extract data for a user characteristic. As an example, let’s see how you would specify the user characteristics from the previous example.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
167
Security: Record and Field Security
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 USERID. The user’s login ID APPL.NAME. The current application STARTUP.PROCESS. The menu or process the user runs upon entering current application TERMINAL.USER. Whether the current user is terminal user (1) or a background process (0)
168
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Record Security
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 Field Extraction. Choose a part of a multi-part key using a delimiter to determine which part Substring Extraction. Specify the start character and string length for the substring
Previously Defined Parameter Definitions You can use any parameter definition name already defined in specifying a key derivation or alone as a key. To begin the user characteristic specification, it is best to use a keyword. For the current example, enter [[@USERID]] to request the current operator’s login ID as the key to the file for the first user characteristic. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
169
Security: Record and Field Security
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 Double 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. More complicated user characteristics use Key Derivation Functions to generate more complex record keys. For example, the file USERS contains special records that allow different access codes when a user enters different applications. These special records are keyed by the concatenation of the user’s login ID and the application he has entered. The key derivation in this cause would concatenate @USERID with @CURRENT. APPLICATION with an asterisk (*). Similar modifications to either keywords or previously defined user characteristics allow you to link user characteristics together to form complex and intricate chains of records and characteristic values. Remember, however, that Envision Runtime must evaluate these chains, at the expense of Runtime performance.
Note: Remember that changes or additions to the current user characteristics do not take effect until a user re-initializes the Envision environment.
A user can re-initialize the Envision environment by: 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.
170
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Record Security
Record Security Definitions Record Security Definitions are selection-like statements that determine if a user can have access to a requested record. There are three levels of access a user may have: 1. All access. The user has the highest access available for the process from which he requests the record. 2. Inquiry access. The user may view data in the record for the process from which he requests the record. 3. No access. The user is denied access to the record for any purpose for the process from which he requests the record. 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. For inquiry forms, reports, procedures and Query-by-Example, the highest access to a record is inquiry, where the user can only view the data. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
171
Security: Record and Field Security
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: WITH - and WITH AND - and WITH OR - or WITH 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”.
172
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Record Security
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 LE Less than Equal GE Greater than Equal EQ Equal GT Greater Than LE Less than Equal GT Greater Than GE Greater than Equal LE Less than Equal GT Greater Than LT Less Than GE Greater than Equal LT Less Than GT Greater Than NE Not Equal LT Less Than NOT Not Equal 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 A constant enclosed in quotation marks 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
173
Security: Record and Field Security
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. Note: Remember that changes or additions to the current record security definition do not take effect until a user re-initializes the Envision environment.
A user can re-initialize the Envision environment by: 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.
174
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Field Security
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.
Defining Field Security To define Field Security for Envision Runtime, run the Field Security Definition (SCDF) form. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
175
Security: Record and Field Security
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 As mentioned before, Field Security is honored by all Envision-based processes in the application. Remember than, since the Field Security definitions are stored in the Application file SECLASS, Envision Runtime checks the current application and all applications in the current application tree for security class definitions.
176
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Updating and Maintaining Security
Updating and Maintaining Security The Envision Release system, the Envision Toolkit, and Colleague Studio have been enhanced to keep mnemonic, field, and record security up-to-date as soon as a mnemonic is changed, or a form or reporting process is either installed or generated, or a security class is changed on the Security Class Definition (SCD), Field Security Definition (SCDF), or Record Security Setup (SCDR) forms. If you add or change a mnemonic on a UI or web form, or on a process flagged as a report, any existing security class that may already have the old and/or new mnemonic will immediately be updated by the mnemonic change. These changes are monitored on the Screen Process Definition (SCRN), Batch Global Parameters (BGP), External Global Parameters (EGP), and Screen Global Parameters (SGP) toolkit forms; as well as when exporting (or checking custom code in) via Colleague Studio for UI form processes, web form processes, and report processes. Also, if a developer adds a field (such as SSN) to a UI form, web form, or report process, and the field is secured by an existing field security definition; then when the process is generated (and the field is added to the newly generated process), the field security for the new process will updated to reflect the existing field security. In addition, as software updates are installed into an environment (either Datatel-delivered updates or custom software update packages), the Release System will track each modified UI/web/report process definition record installed and update its corresponding mnemonic, field and record security. This means that any new software being installed will immediately be aligned with the environment’s defined Envision security. 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: – Mnemonics or field changes are made outside Envision and Colleague Studio. – Envision object code is installed outside the Envision Release System. – Immediately after a new Colleague environment is built (see Installation Procedures for Colleague R18). This should be done on a quiet system, as the BSEC process clears the security information, and then rebuilds it, one security class at a time.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
177
Security: Record and Field Security
178
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Security
Encrypting Colleague Data
In This Chapter This chapter provides information on the encryption capabilities available for Colleague processes. Table 6 lists the topics covered in this chapter. Table 6: Topics in this Chapter Topic
Page
Before You Begin
179
Understanding Colleague Encryption
180
Defining Colleague Encryption
183
Troubleshooting
185
Before You Begin Table 7 lists the actions that must be complete before you can continue with the procedures in this chapter. Table 7: Before You Begin Action
Reference
Live on UniData 6.1 or higher.
The encryption schemes used by Colleague are not available in earlier UniData versions.
Load software updates for Colleague encryption.
AnswerNet document 16990.15.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
179
Security: Encrypting Colleague Data
Understanding Colleague Encryption In cryptography, encryption is the process of obscuring information to make it unreadable without special knowledge. The “special knowledge” includes which encryption algorithm is used and what encryption key was used to encrypt the data. Either piece of information is useless without the other, because proper decryption cannot occur without both the encryption algorithm and the encryption key. An encryption scheme is comprised of the encryption algorithm and the encryption key. Determining which encryption scheme to use will depend on your institution’s particular needs. You may have to meet certain minimum requirements for encryption in order to process credit card transactions, for example.
Encryption Algorithm and Encryption Key An encryption algorithm is a formula used to turn ordinary data into a secret code, sometimes referred to as ciphertext. Each algorithm uses a string of bits known as an encryption key to perform the translation from regular data to encrypted data. The larger the key (the more bits), the greater the number of potential patterns can be created, thus making it harder to break the code and descramble the contents. For example, two encryption algorithms available in Colleague are R2-40CBC, which is 40-bit strength (a 40-bit key), and R2-CBC, which is 128-bit strength (a 128-bit key). Roughly speaking, 128-bit encryption is 309,485,009,821,345,068,724,781,056 times stronger than 40-bit encryption. 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. Technical Tip: Due to the amount of terminology and dense concepts regarding cryptography, interested readers may refer to the following publications: Applied Cryptography by Bruce Schneier, and Internet Cryptography by Richard E. Smith. Both publications expound upon the UniData documentation and the encryption schemes supported by UniData.
180
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Understanding Colleague Encryption
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. Table 8: Form Used to Implement Colleague Encryption Form UT Encryption (UTEP)
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Purpose Define the encryption scheme used to encrypt predefined CDD elements.
181
Security: Encrypting Colleague Data
File Used Table 9 lists the primary file used with Colleague encryption. Table 9: File Used with Colleague Encryption File EDPARMS
182
Description Stores data from the UTEP form, including encryption scheme and encryption status information.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Defining Colleague Encryption
Defining Colleague Encryption Figure 31 shows an example of the UT Encryption (UTEP) form, available from the UT application. Use the UTEP form to change encryption parameters and to start the encryption process. Figure 31: The UT Encryption (UTEP) Form
Noteworthy Fields on the UTEP Form The fields described in this section are particularly important for using Colleague encryption. See online help for information about other fields on this form.
The “Status” Field Note: The “Status” field refers to the large, unnamed informational field at the top of the UTEP form.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
183
Security: Encrypting Colleague Data
The “Status” field is a single block of inquiry-only status information. It indicates whether the system believes that the batch re-encryption process is running, and provides additional instructions and warnings. 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 Encrypted Elements Registry Field The data elements listed in the Encrypted Elements Registry field are the elements that the system will update whenever you change your encryption scheme.
Procedure for Changing an Encryption Parameter Use this procedure to change the encryption scheme or encryption key. ALERT! Before changing the encryption scheme or key, you must make sure your database is not currently in use. Failure to do so can result in database corruption.
Step 1. Back up your database.
Step 2. Access the UT Encryption (UTEP) form.
Step 3. Do you want to change the 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.
No. Skip to Step 5.
184
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Troubleshooting
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.
Step 6. Save from the UTEP form.
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 gracefully (it is able to detect a problem, throw the error, and shut down), then it will write ABORTED into the EDPARMS.CONV.IN.PROGRESS field of the EDPARMS parameter record. This allows the UTEP form to recognize that the encryption process aborted, and enables the process to attempt a graceful restart when the UTEP form is saved. Figure 32: Example of the UTEP Form with an ABORTED Status
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
185
Security: Encrypting Colleague Data
Troubleshooting a Failed Encryption Process An aborted encryption process can leave the UTEP form in two states: ABORTED. The encryption process aborted cleanly and will resume from where it stopped after the UTEP form is saved. ACTIVE. If the encryption process has thrown an error (logged to the UT.THROWN.ERRORS file) but did not abort cleanly, the UTEP form will believe that the process is still running, and will return the current status as ACTIVE. 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. ALERT! Datatel strongly recommends contacting the Solution Center for assistance to restart the encryption process when it does not abort cleanly.
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.
186
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Runtime Administration
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.
Scheduling System Maintenance Scheduling system maintenance is a challenge and differs from site to site. Below is an example of how one site handles their maintenance activities. The maintenance activities include: Saves Consolidation of job histories 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
189
Maintenance: Maintenance Introduction
Consolidation of Job Histories Many programs create job histories or como files to record events during execution to disk. Batch or background mode processes in Colleague and the data base management system create these files in the PH file of the current directory. These files take up considerable disk space over time and should be deleted. You may wish to keep them in a consolidated file for future reference. 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.
190
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Sample Daily Schedule
Sample Daily Schedule Below is the example site’s daily schedule. Table 10: Sample Daily Schedule Sample Daily Maintenance Schedule Time and Task performed
Days 3:00 am
5:45 am
6:00 am
Monday
Incremental save
Job history
Purge
Tuesday
Incremental save
Job history
Purge
Wednesday
Incremental save
Job history
Purge
Thursday
Incremental save
Job history
Purge
Friday
Incremental save
Job history
Purge
Saturday
Full save
Job history
Disk maintenance
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
191
Maintenance: Maintenance Introduction
192
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Maintenance
Using File and Index Analysis Utilities 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) Although these utilities are most beneficial to institutions using UniData, institutions using SQL Server or Oracle should also run the utilities. There are some application server files that always reside in UniData that should be analyzed regularly through these utilities. For example, UT.THROWN.ERRORS is an application server file that contains errors programatically invoked when an unusual and/or fatal event occurs. If this file grows too large, the WUFA utility will set up a resize for the file. Similarly, if indexing on that file is corrupted for any reason, the WUIA utility will set up a delete, create, and rebuild of the indexes for that file. Table 11 lists the topics covered in this chapter. Table 11: Topics in This Chapter Topic
Page
Using WEEKLY.UDT.FILE.ANALYSIS (WUFA)
194
Using WEEKLY.UDT.INDEX.ANALYSIS (WUIA)
201
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
193
Maintenance: Using File and Index Analysis Utilities
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. The WUFA utility performs the following functions: Checks for damaged files. Gathers file statistics for all hashed files in an environment. 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).
194
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using WEEKLY.UDT.FILE.ANALYSIS (WUFA)
Output Items from the WUFA Utility When you run the WUFA utility, the following five output items are created: UDT_GUIDE. This file contains all of the file statistics for all hashed files in the environment where the WUFA utility is run. If you want to use your own formula to calculate the correct modulo/block size, you can use the statistics in this file. This file is cleared and repopulated every time that you run the WUFA utility. UDT_GUIDE.RPT. This report paragraph is run on completion of the utility. This report may be used as an example for any other reports that you might want to build from the UDT_GUIDE file. DATATEL.RESIZE.FILES. This paragraph will only resize those files that require resizing. The first time that you run the WUFA utility, a number of files may need to be resized. After subsequent scans, only those files that have changed significantly in size since the last resize will be included in the paragraph. Further, after running this utility several times, you will begin to see which files tend to change in size as they will migrate to the top of both the file statistics report and the resize paragraph. BAD.FILES.IN.VOC. A saved 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. BAD.VOC.FILES. A saved 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. For example, when trying to analyze SPOUSE (a logical view of PERSON), if the VOC entry for SPOUSE is correct, but the VOC entry for PERSON is either missing or incorrect, then the BAD.VOC.FILES saved list will be populated with both SPOUSE and PERSON.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
195
Maintenance: Using File and Index Analysis Utilities
Workflow for Using the WUFA Utility Datatel recommends that you run the WUFA utility weekly. You may want to consider running the WUFA utility overnight, and then review the report in the morning, or simply execute the following statement to check for any damaged files: :LIST UDT_GUIDE FILE_NAME DATATEL.DAMAGED ID.SUP WITH DATATEL.DAMAGED GT " " Note: See AnswerNet Document 156.19 for information on how to fix damaged files.
The WUFA utility also creates the paragraph DATATEL.RESIZE.FILES. For example, you might want to modify the DATATEL.RESIZE.FILES that was created on a Thursday night and run it on Friday night, after backups are completed, so that it has the entire weekend to process. Before you run the resize paragraph, execute the following statement to find out the largest file that may need to be resized. :LIST UDT_GUIDE BY.DSND SIZE FILE_NAME SIZE ID.SUP 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. Note: See AnswerNet document 147.992 for more information on whether to use static or dynamic UniData files in Colleague.
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. No severe level-one or level-two overflows should occur, unless you perform a massive conversion. In this case, run the WUFA utility immediately after the conversion. Improved performance of file operations, as most files are overflow free. 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.
196
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using WEEKLY.UDT.FILE.ANALYSIS (WUFA)
Running the WUFA Utility Datatel recommends that you run the WUFA utility overnight, as a background process, by executing the following command: :PHANTOM WEEKLY.UDT.FILE.ANALYSIS To achieve this, you can create the following paragraph: :AE VOC FILE.MAINT 0001: PA 0002: COMO ON FILE.MAINT 0003: DATE 0004: SELECT VOC WITH F1 LIKE ‘F...’ AND F2 UNLIKE '@UDTHOME...' 0005: WEEKLY.UDT.FILE.ANALYSIS 0006: DATE 0007: COMO OFF The following two arguments can be appended to the WEEKLY.UDT.FILE.ANALYSIS command: -AD -ED 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. Note: Files listed on the WebAdvisor File Maintenance (WAFM) form are not affected by this option. Running the WUFA utility on the files specified on that form will always set up a MEMRESIZE statement in DATATEL.RESIZE.FILES, based on the modulo and block size specified on the WAFM form for each file.
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
197
Maintenance: Using File and Index Analysis Utilities
To run the WUFA utility as a background process, enter the following: :PHANTOM FILE.MAINT 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. The resize paragraph, DATATEL.RESIZE.FILES, has been set up to use the UniData memresize command, which is faster than the ECL RESIZE command. The memresize command uses a memory buffer and writes to disk only when the buffer is full. This causes fewer writes to disk; thus, performance can be significantly enhanced. ALERT! You must have a complete backup of your system before running the resize paragraph. If your system experiences a power failure or any other problem while it is in the middle of resizing a file, the file can be left in an incomplete or broken state. The only recourse if this happens is to restore the file from backup.
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 DATATEL.RESIZE.FILES will turn on a COMO file called O_DATATEL.RESIZE.FILES when it is executed so that you can monitor its progress. 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.
198
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using WEEKLY.UDT.FILE.ANALYSIS (WUFA)
Note: In order to run the memresize command, you must have enough disk space within the partition where the temporary copy of the file will be created. For static files, this is the /tmp directory in UNIX or \temp in Windows. You can override this default by setting the TMP environment variable. For dynamic files, this is the same partition as the file being resized.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
199
Maintenance: Using File and Index Analysis Utilities
Excluding Files from Analysis You can maintain a list of files to be skipped by adding the name of each file to a SAVEDLISTS record called RESIZE.EXCLUDE. Any file name found in this list by the WUFA utility will be analyzed, but will not be included in the resize paragraph DATATEL.RESIZE.FILES. The excluded files will be flagged in the analysis report by prefixing the file name with a '*'. :EDIT.LIST RESIZE.EXCLUDE The VOC file will always be excluded, whether or not it is specifically included in the RESIZE.EXCLUDE saved list, as it must be resized from the operating system level (that is, outside of the UniData environment). You can look for any excluded file in the DATATEL.RESIZE.FILES paragraph to see what the recommended block size and modulo would be, and then resize the file manually. It is very important for performance to keep the VOC file sized properly. Note: See AnswerNet Document 107.1437 for how to resize the VOC file.
200
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using WEEKLY.UDT.INDEX.ANALYSIS (WUIA)
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. If cleanup is necessary, you can either use a paragraph alone, or combine a paragraph with the Multiple File Indexing (UTBA) process. If you use the UTBA process, you enter a saved list (created by the WUIA utility) to rebuild indexing for the files, then enter one of the following in the Indexing Function field: B (Create & Build All) M (Create & Build Missing) 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.
Understanding the WUIA Utility The WUIA utility can be run with an active list of files you have selected, or on all files. The WUIA process will determine if each of the files has any UniData indexing associated with it. If so, any problems or corruption found with the indexing is reported. When you enter WEEKLY.UDT.INDEX.ANALYSIS at the colon prompt or in a VOC paragraph, the default mode of the WUIA utility runs the following command on each file analyzed: guide_ndx -x 1, ALL In this command, the “1” triggers physical checking of the index file. You can also enter the following: WEEKLY.UDT.INDEX.ANALYSIS -L
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
201
Maintenance: Using File and Index Analysis Utilities
This triggers logical checking of the index file for any non-null indexed fields, by issuing this command: guide_ndx -x 2, 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... Saving list of problem index files in SAVEDLISTS... 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.
202
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using WEEKLY.UDT.INDEX.ANALYSIS (WUIA)
Examples of Running the WUIA Utility Three examples of running the WUIA utility are shown below.
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" The following displays: 1 record selected to list 0. >
Step 2. Enter the following: WEEKLY.UDT.INDEX.ANALYSIS The following displays: Running physical check only. To run a logical check, use option '-L' Weekly UniData Index Analysis utility, version '03/04/2008' Analyzing indexing for PERSON... No problem index files found for this physical check. :
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
203
Maintenance: Using File and Index Analysis Utilities
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" The following displays: 1 record selected to list 0. >
Step 2. Enter the following: WEEKLY.UDT.INDEX.ANALYSIS -L The following displays: Running logical check only. Empty index files will be skipped. Weekly UniData Index Analysis utility, version '03/04/2008' Analyzing indexing for PERSON... No problem index files found for this logical check. :
204
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using WEEKLY.UDT.INDEX.ANALYSIS (WUIA)
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 The following displays: Running physical check only. To run a logical check, use option '-L' Weekly UniData Index Analysis utility, version '03/04/2008' Selecting all physical files in account, please wait... Saving list of bad file pointers in SAVEDLISTS 'PHYS.BAD.FILES.IN.VOC' Saving list of bad VOC pointers in SAVEDLISTS 'PHYS.BAD.VOC.FILES' Analyzing indexing for ACAD.CREDENTIALS... Analyzing indexing for ACAD.LEVELS... Analyzing indexing for privilege... Saving list of problem index files in SAVEDLISTS 'PHYS.BAD.INDEX.FILES'. :
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
205
Maintenance: Using File and Index Analysis Utilities
Results of Running a Physical Check on Index Files When you run the WUIA utility in default mode to run a physical check on index files, there are six possible output items. Each of these items is cleared at the start of the utility, so that if the output item exists after a run, it was created by the most recent run.
Output Item 1: PHYS.IDX.STATS.AND.ERRORS in _HOLD_ This report is created and concatenates the results of the GUIDE_XSTATS.LIS and GUIDE_XERROR.LIS reports from the guide_ndx execution for each file processed.
Output Item 2: PHYS.BAD.INDEX.FILES Record in SAVEDLISTS This saved list is created only if problems are found, and will contain a list of files with indexing issues.
Output Item 3: DATATEL.PHYS.DEL.IDX.FILES Paragraph in VOC 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) M (Create & Build Missing) 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.
206
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using WEEKLY.UDT.INDEX.ANALYSIS (WUIA)
Output Item 4: DATATEL.PHYS.DEL.RBD.IDX.FILES Paragraph in VOC This paragraph is always created; however, the content depends on the following: If the saved list in Output Item 2 was created, the paragraph will contain a series of DELETE.INDEX, CREATE.INDEX, and BUILD.INDEX statements for the files in the saved list. Running the paragraph clears out each file’s indexing and recreates and rebuilds it. If the saved list was not created, the paragraph will contain a display statement indicating there were no problem indexes. In either case, you do not need to then run the UTBA process. This paragraph can be used in LPR environments, (which do not have Colleague or Envision, so the UTBA process is not available). For apphome environments, this can be used instead of the paragraph in Output Item 3 and 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.
Output Item 5: PHYS.BAD.FILES.IN.VOC record in SAVEDLISTS 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
207
Maintenance: Using File and Index Analysis Utilities
Output Item 6: PHYS.BAD.VOC.FILES record in SAVEDLISTS 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. For example, when trying to analyze SPOUSE (a logical view of PERSON), if the VOC entry for SPOUSE is correct, but the VOC entry for PERSON is either missing or incorrect, then the saved list will be populated with both SPOUSE and PERSON.
208
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using WEEKLY.UDT.INDEX.ANALYSIS (WUIA)
Results of Running a Logical Check on Index Files When you run the WUIA utility with the optional logical check on index files (by adding -L), there are six possible output items. Each of these items is cleared at the start of the utility, so that if the output item exists after a run, it was created by the most recent run.
Output Item 1: LOGI.IDX.STATS.AND.ERRORS in _HOLD_ 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.
Output Item 2: LOGI.BAD.INDEX.FILES Record in SAVEDLISTS This saved list is created only if problems are found, and will contain a list of files with indexing issues.
Output Item 3: DATATEL.LOGI.DEL.IDX.FILES Paragraph in VOC 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) M (Create & Build Missing) Each run of the utility will save the previous run’s output paragraph as DATATEL.LOGI.DEL.IDX.FILES.PREV.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
209
Maintenance: Using File and Index Analysis Utilities
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.
Output Item 4: DATATEL.LOGI.DEL.RBD.IDX.FILES Paragraph in VOC This paragraph is always created; however, the content depends on the following: If the saved list in Output Item 2 was created, the paragraph will contain a series of DELETE.INDEX, CREATE.INDEX, and BUILD.INDEX statements for the files in the saved list. Running the paragraph clears out each file's indexing and recreates and rebuilds it. If the saved list was not created, the paragraph will contain a display statement indicating there were no problem indexes. In either case, you do not need to then run the UTBA process. This paragraph can be used in LPR environments, (which do not have Colleague or Envision, so the UTBA process is not available). For apphome environments, this can be used instead of the paragraph in Output Item 3 and 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.
Output Item 5: LOGI.BAD.FILES.IN.VOC Record in SAVEDLISTS 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.
210
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using WEEKLY.UDT.INDEX.ANALYSIS (WUIA)
Output Item 6: LOGI.BAD.VOC.FILES Record in SAVEDLISTS 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. For example, when trying to analyze SPOUSE (a logical view of PERSON), if the VOC entry for SPOUSE is correct, but the VOC entry for PERSON is either missing or incorrect, then the saved list will be populated with both SPOUSE and PERSON.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
211
Maintenance: Using File and Index Analysis Utilities
Recommendations When Running the WUIA Utility Datatel makes the following recommendations for using the WUIA utility.
How to Run Both Physical and Logical Checking 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.
Running on an Active versus a Quiet System 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.
212
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Using WEEKLY.UDT.INDEX.ANALYSIS (WUIA)
Setting up Paragraphs for the WUIA Utility You may want to set up paragraphs to execute regular runs of the WUIA process and its cleanup paragraphs. Although the WUIA utility may be run on an active system, the cleanup paragraphs and the UTBA process must be run on a quiet system. This means that any paragraphs you set up should also be run on a quiet system. 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 However, remember that the DATATEL.PHYS.DEL.RBD.IDX.FILES and DATATEL.LOGI.DEL.RBD.IDX.FILES paragraphs simply recreate and rebuild the indexes that previously existed. They do not recreate and rebuild the indexes specified in Envision. So you may want to use a paragraph like the following in an apphome environment: :AE VOC WUIA.DELETE.ONLY 0001: PA 0002: COMO ON WUIA.DELETE.ONLY 0003: DATE 0004: WEEKLY.UDT.INDEX.ANALYSIS 0005: DATATEL.PHYS.DEL.IDX.FILES 0006: WEEKLY.UDT.INDEX.ANALYSIS -L 0007: DATATEL.LOGI.DEL.IDX.FILES 0008: COMO OFF After you execute this paragraph: If the saved list PHYS.BAD.INDEX.FILES exists, run the UTBA process with the Indexing Function field set to “B” or “M” for that saved list. If the saved list LOGI.BAD.INDEX.FILES exists, run the UTBA process with the Indexing Function field set to “B” or “M” for that saved list.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
213
Maintenance: Using File and Index Analysis Utilities
214
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Maintenance
Envision File Services
Envision Runtime automatically provides certain services for files in the application’s database. While these services occur at runtime, each service is defined by the analyst who created the specification for the files and the data elements within those files. These specifications are defined through the Envision Tool Kit and are not modifiable by the end users. The automatic file services include: Add/Change Tracking for records Record Link Management Record Deletion Tracking File Activity Indexing
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
215
Maintenance: Envision File Services
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
If these fields are present in the dictionary of a file accessed by an Envision process, the corresponding data is automatically maintained. For example, consider a file PARTS with the fields PARTS.ADD.DATA and PARTS.ADD.OPERATOR. 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.
216
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Record Link Management
Record Link Management Some fields within the database files of your application do not store data. These fields store the keys to other records either in the same file or in other files. The fields which store record IDs are named pointer fields and the record IDs stored in these fields are named record links. Pointer fields can either be single or multivalued. Single-valued pointer fields are called X-pointers and multi-valued pointer fields are called Q-pointers. The X in X-pointer refers to a field that is a cross-reference (xref) to another record. The Q in Q-pointer originated from the original PICK programming term Qselect, which allows you to select a list of record IDs from a field within a record. Example of an X-pointer is a person’s spouse. The Spouse field in one person’s demographic record contains an ID for the demographic record of the person’s spouse. Since the relationship “spouse” is a reciprocal relationship, the spouse’s demographic record in turn contains a link to the original person’s demographic record. When a record contains a link to another record which in turn has a link to the original, these links are called return links. The link defined for a person’s spouse has a return link of the spouse’s spouse. Example of a Q-pointer is a person’s address. Many people have more than one address. A person’s demographic record, therefore, may contain a list of IDs to records in an address file. The address record additionally may have a list of person IDs for those people who live or work at the address. The person record, therefore, has a multi-valued return link to the address file, the return link being the residents of the address. Record links play an important part in maintaining the integrity of your database. The relationships between records in the database fall into four categories: One-to-one (person to spouse) One-to-many (employer to employees) Many-to-one (person to political party) Many-to-many (children to parents) The management of these record links is performed automatically by Envision Runtime each time a record is updated. The specifications for record link management are encoded in the Runtime File Specifications file RFSPECS for the file in which a pointer field resides. The record link specifications are defined by the analyst(s) who creates the structure of the database. Record link specifications, therefore, cannot be modified by the end user.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
217
Maintenance: Envision File Services
Envision Runtime ensures that the integrity of these record links in maintained and does not rely on either the programmer who defines a new form process or the end user of that form. The specifications for record link management are stored in the Central Data Dictionary (CDD) for the application and therefore become part of any program definition. These specifications are encoded into the RFSPECS file for use at runtime. 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.
218
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Record Deletion
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
219
Maintenance: Envision File Services
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. Requesting transaction logging, while providing additional security and peace of mind, comes at the cost of disk I/O performance and disk space requirements. Once the transaction logging information has served its purpose, purge it using the TXLOG Purge (UTTP) form.
Requesting Transaction Logging Step 1. Run the Transaction Log Specification (UTML) form.
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.
220
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
History Logging
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 308. 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 310. 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 336. 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 337.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
221
Maintenance: Envision File Services
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 Calculated indexes are stored as data rather than derived Database indexing is more efficient and more robust. The indexing processes are found in the System File Administration menu, as shown in Figure 33. Figure 33: System File Administration Menu
222
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
File Indexing
Datatel Defined Indexes Certain files for applications are delivered by Datatel. You are not able to change these delivered definitions. You may add your own definitions, but those defined by Datatel cannot be modified.
User Defined Indexing To define your own indexing for selected files, run the User File Index Specification (UTMI) form, as shown in Figure 34. This form stores the indexing definitions you enter in the user file specifications file UFSPECS. Each time the indexing definitions for a file are stored in UFSPECS, Envision Runtime “compiles” these specifications into runtime file specifications stored in the runtime specifications file RFSPECS. Envision Runtime uses these compiled versions of the indexing definitions whenever a record for that file is written to disk. Index records are created in the specified target file for each index definition associated with the file. Figure 34: Example User File Index Specification (UTMI) Form
Envision 4.7 only
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
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
223
Maintenance: Envision File Services
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).
Note: 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.
224
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
File Indexing
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
225
Maintenance: Envision File Services
Converting Files to Database Indexing Perform the following steps to convert a group of files or an entire application to database indexing.
Step 1. Run the Batch Runtime RFSPECS Refresh (BRRR) utility, as shown in Figure 35, on each application. Figure 35: Batch Runtime RFSPECS Refresh (BRRR) Form
The BRRR form contains information on various functions that need to be performed on a file when writes occur, including indexing. The information in this file is generated from the appl.FILE.SPECS file in the Tool Kit, and from UFSPECS on the runtime side. You can specify one of three ways to define which files to process. If you want to do one of the following: Convert the files in a saved list, enter a saved list name that contains the file names you want to convert in the Rebuild Saved List field. Manually select a group of files to convert, enter a manual list of files to process in the Rebuild File List fields. Convert all files in the current application, leave all fields blank. When you update from the BRRR form, the selected files are converted.
226
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
File Indexing
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. Note: If you have not created custom indexes, skip to step 5 on page 231.
Figure 36: Index Storage Field Report (ISFR) Form
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
227
Maintenance: Envision File Services
Step 3. Update to generate the Missing Index Storage Fields Report, as shown in Figure 37. Figure 37: Example Missing Index Storage Fields Report
228
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
File Indexing
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. Figure 38: Example User File Index Specification (UTMI) Form
Envision 4.7 only
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
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
229
Maintenance: Envision File Services
230
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
File Indexing
Step 5. Access the Envision Parameters Edit (EPED) form, shown in Figure 39, to specify your current indexing mode. Figure 39: Envision Parameters Edit (EPED) Form (Envision 4.7)
Envision 4.7 only
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. Note: Datatel recommends choosing 5 (combined Envision and database indexing) during the conversion period. If any problems arise with a database indexed file, you can revert to Envision indexing for that file. When conversion is complete, you can select 4 to change to exclusively database indexing.
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
231
Maintenance: Envision File Services
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. Figure 40: File Indexing (UTBI) Form
Envision 4.7
Complete the File Indexing (UTBI) form as follows: In the File field, enter the name of a file for which indexing needs to be maintained. The Indexing Type field displays the type of indexing to use with the file that you specified (used in Envision 4.7 only). Technical Tip: If your account is set up for Envision/Database Indexing, you can change the default target type by using the dropdown list. You cannot make this change with any other type of accountwide indexing.
232
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
File Indexing
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.
ALERT! Some files, such as Express Load files, are shared between your install account and your main accounts. When converting these files from Envision indexing to database indexing, you will need to run UTBI on the file in the install account and again in each main account to make sure all accounts can access the file correctly. For example, when converting EXPL.PATCH.CTL from Envision indexing to database indexing, run UTBI in the install account, and then run it again in each main account linked to the install account.
To maintain indexes on multiple files, use the Multiple File Indexing (UTBA) form, as shown in Figure 41. Figure 41: Multiple File Indexing (UTBA) Form
Step 7. In the Saved List Name field, enter a saved list of files for indexing.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
233
Maintenance: Envision File Services
Step 8. In the Indexing Function field, select the type of indexing function that you want to run.
When File Conversion Is Complete Complete the following steps after all files have been converted to database indexing.
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.
Figure 42: Delete Obsolete Index Files (DOIF) Form
234
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
File Indexing
If you want to do one of the following: Delete the Envision index files in a saved list, enter a saved list name that contains the file names you want to delete in the Delete Saved List field. Manually select a group of Envision index files to delete, enter a manual list of files to delete in the Delete File List fields. Delete all Envision index files in the current application, leave all fields blank. When you update from the DOIF form, the selected index files are deleted.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
235
Maintenance: Envision File Services
236
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Maintenance
Envision Runtime Reports
A number of reports and documentation features are included with Envision Runtime and therefore are available to every Envision-based application. The seven Runtime reports documented in this section allow you to retrieve valuable information, including the following: How procedures are defined What results did a given procedure produce when run 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.
Procedure Rules Documentation The Procedure Rules Documentation (JPRT) report lists the specifications for an Envision procedure. The first section of the report describes global information for the procedure. The description is free-form text. For reports, the procedure class is always “R” for “Report”; for procedures that are not reports, the procedure class is “P” for “Process”. This procedure class determines the menu quadrant the Menu Processor places the procedure’s mnemonic. The securable flag determines if users in the field can modify Datatel-defined procedure. The phantom allowed flag determines if the procedure is executable as a background process. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
237
Maintenance: Envision Runtime Reports
Lookup Resolution Specifications The Lookup Resolution Specifications (LPRT) report lists the definitions for a resolution screen called when the LookUp Processor finds more than one record ID match to a user’s input. 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.
Record Security Specifications The Record Security: List Specs (RPRT) report lists the record security definitions for a particular file. The first part of this report shows the file for which you are securing records and whether the security definition is currently enforced. This first part also shows who last changed the security definition and when it was changed. 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”.
238
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Batch Error Report
Batch Error Report The Batch Error Report (UTBE) details the step-by-step results of selected procedures. 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 [[C]] for canceled by the user 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.
Job Statistics Report The Job Statistics Report (UTJR) lists all the information available about executed procedure. The first section of this report shows information concerning the overall procedure. The next section shows the results of each step for the procedure. Next, any error messages from the procedure steps are shown. Finally, UTJR shows the actual paragraph created by the Procedure Generator to run the procedure.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
239
Maintenance: Envision Runtime Reports
Audit Trail Report The Audit Trail Report (UTXL) lists the changes, additions and deletions for a file based on the records stored in the file’s transaction log file. 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.
240
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Maintenance
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 Background system files Database management files
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
241
Maintenance: Purging Files
Background System Files The following processes store data about a process in background system files as your users run programs. Batch Status 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.
242
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Background System Files
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 For specified users or records By type, including old and new values for changed transactions 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
243
Maintenance: Purging Files
Database Management Files Three database files are used by Envision Runtime whenever a procedure is run: HOLD 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.
Database Management System Files Naming Conventions UniData and SQL Server _HOLD_ _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.
244
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Database Management 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 In order to purge the PH file:
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
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
245
Maintenance: Purging Files
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:
Step 5. :GET.LIST PH.LIST :DELETE PH 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.
246
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Runtime Administration
Troubleshooting
Troubleshooting
Introduction to Troubleshooting
The Troubleshooting section of Runtime Administration provides information you need to understand how to troubleshoot the software. The final chapter outlines common problems and their corresponding solution.
Recovery Guidelines Occasionally application programs are interrupted because: A user breaks out of a program or turns off a terminal, The system has forced a logout of a terminal, There has been a power failure, or The system has halted. As system administrator, you should take precautions to guard against some of these interruptions. Train users not to turn terminals off during a process and not to break out of programs. In fact, you should consider disabling [BREAK]. Keep terminal cables out of the way; and if necessary, secure the cables to the floor. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
249
Troubleshooting: Introduction to Troubleshooting
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.
250
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Troubleshooting Envision-Based Software
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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
251
Troubleshooting: Introduction to Troubleshooting
252
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Troubleshooting
Problems in Envision Applications System Setup or Security Issues This chapter lists some commonly encountered problems, followed by the cause of the problem and its solution. Problem statements are shown in italics and causes are underlined.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
253
Table 12: Problems With System Setup or Security Problem I get logged out when I try to enter an application.
Cause Invalid or missing OPERS record.
Solution Check the user’s OPERS record. Start with the application the user is trying to run. Enter the application and run SOD. If the user’s OPERS record is not in the current application, determine if the OPERS record is in an application higher up in the tree. If the user should only access the current application, create a new OPERS record through SOD. Make sure the Name field has data entered.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
My terminal display is all messed up when I enter an application.
Missing or invalid display table defined in the DEVICES record.
Check the user’s DEVICE record. For port-based systems, run SND and determine the DEVICES type from the user’s line 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 what the template says they are supposed to.
Missing or invalid keyboard table defined in the DEVICES record.
Check the user’s DEVICE record. For port-based systems, run SND and determine the DEVICES type from the user’s line 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. You may need to define the desired keyboard table.
Troubleshooting: Problems in Envision Applications
254
Table 12 lists common problems with system setup or security, with their causes and solutions
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Table 12: Problems With System Setup or Security (cont’d) Problem
Cause
Solution
Invalid mnemonic or insufficient security rights.
Check the spelling of the entered mnemonic. If spelled incorrectly, enter the correct spelling. If the user has insufficient security rights for a mnemonic, check if the user is supposed to use that process and check the security class definition on SCD for the secured mnemonic. If the user should have access to the process, check the user’s security class for the current application on SOD. If the user has a specific operator definition for the current application, make sure the operator definition includes the security class for the secured mnemonic. If the user does not have an operator definition for the current application, either add a specific operator definition for the current application or check the operator definition for the next higher application in the tree.
A mnemonic does not show up on the menu.
Insufficient security right for the mnemonic.
The Runtime Menu Processor does not show mnemonics for 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 Rights.
Check the Field Security definition for the field in question on SCDF. The security class assigned for field security. Then check the user’s security classes on SOD. If the user should have access to the data in the field, add the proper security class for the secured field.
When I enter an application, a screen runs and then I exit from the application without seeing a menu.
Initial application mnemonic is a screen process, not a menu.
If the user should have access to more than one process, check the initial menu mnemonic on SOD. If the user does not have an operator definition for the current application, check the operator definition in the next higher application. Make sure the initial menu mnemonic for the user is a menu.
I made changes to (Record Security User Characteristics, Record Security Criteria, Transaction Logging). When I run another process, the changes don’t show up.
Changes to some Runtime screens do not take effect until Envision is re-initialized.
Re-initialize Envision. A user can re-initialize the Envision environment by:
or Data doesn’t show for a field; all I see are asterisks.
• 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.
255
System Setup or Security Issues
My terminal just beeps when I enter a mnemonic at a menu prompt.
Problem
Cause
Solution
I left my terminal for a while and now the system prompts me for a password.
Envision has “timed out” the terminal.
The operator definition has a lapsed time specified. The user must re-enter his Envision password defined on SOD.
I had a COMO running while executing a screen. I tried to view the COMO record using BROWSE and I was blown out.
The BROWSE utility cannot process terminal display characters.
You must re-initialize Envision. A user can re-initialize the Envision environment by: • 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. To prevent a user from BROWSEing a COMO file, you may consider removing the &UFD& directory file from the BROWSE file authorization list on UTFA.
Troubleshooting: Problems in Envision Applications
256
Table 12: Problems With System Setup or Security (cont’d)
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Runtime Error Messages Table 13 lists common Envision initialization error messages with their causes and solutions. Table 13: Envision Initialization Error Messages Message “FATAL: bad.file is not present”
Cause One of the following transapplication files is missing: • SYSDEFS • DEVICES • VOC • SAVEDLISTS • REFSPECS
Solution Check the VOC file definitions for each file ENVINIT cannot open. If the VOC file is the bad file, make sure you are attached to a valid database account in which an Envision-based application has been installed. If the bad file is a database file (one with “&” in its name), create the file on your account. If the bad file is an Envision file (SYSDEFS, DEVICES, RFSPECS or UFSPECS), call Datatel if the VOC record for the file seems in order. There may have been a problem with your last release installation or VOC pointers may be damaged.
• UPSPECS • UFD • HOLD • PH Missing or invalid renewal codes detected.
Call Datatel. The renewal codes control what Envision modules you can run. There may have been a problem with your last release installation or VOC pointers may be damaged.
“SYSTEM DATE current.date precedes previous login date”
The date stored as the last login date precedes the system date on your computer. Since the stored last login date is based on the current system date, the system date on your computer is incorrect.
Reset the system date for your computer. If the message persists, call Datatel.
“Envision not initialized”
257
Runtime Error Messages
“FATAL security fault: Missing Renewal Code Record”
Message
Cause
Solution
“Lease for module expired date. module not operable.”
The current date is past the date defined as the expiration date for the specified module.
Call Datatel immediately. There may have been a problem with your last release installation or you may need to install a new release.
“Warning: Lease to module expired date (n days grace)”
The date on which your software lease expires has passed.
Call Datatel immediately. There may have been a problem with your last release installation or you may need to install a new release.
Damaged or missing renewal code record.
Call Datatel immediately. The renewal codes control what Envision modules you can run. There may have been a problem with your last release installation or VOC pointers may be damaged.
“FATAL: Network definitions not present.”
Envision cannot read the TASKLIST record in the SYSDEFS file.
Check the VOC pointer for the SYSDEFS file. It should be pointing to the current release account. If this record is damaged or missing, 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 a secured terminal.
If the password was misspelled, enter the correct spelling. If the 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.
“Please contact Datatel” “FATAL security fault: Bad Customer Number in Renewal Code Record“
Troubleshooting: Problems in Envision Applications
258
Table 13: Envision Initialization Error Messages (cont’d)
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Table 14 lists common application initialization error messages with their causes and solutions. Table 14: Application Initialization Error Messages Message “Missing file: appl.bad.applfile All base application files must be present.”
Cause Missing or invalid application file.
“Session not established.”
Solution Check the VOC pointers for each of the application files for the current application (an asterisk (*) means is subject to tree reads): • CDD
• PPROCESS*
• DOC
• PRCS.CTL*
• ENV*
• PRCS.DEF
• ERROR*
• PRCS.GEN*
• FILE.SPECS*
• PRINTERS*
• HELP*
• QBEDEF*
• HELP.LONG*
• SECLASS*
• INSERTS
• SOURCE
• MENU*
• SUBROUTINES
• OBJ
• VALCODES*
• OPERS*
• VOC
• PARMS* “Improperly set up user: login. See your system administrator.”
Missing or invalid OPERS record.
Be sure the Name field has data. If there is no data in the field, the OPERS record is invalid.
259
Runtime Error Messages
Check the user’s OPERS record. Start with the application the 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 the tree. If the user should only access the current application, create a new OPERS record through SOD.
Message
Cause
Solution
“Invalid startup menu of bad.menu. See your system administrator“
Mnemonic defined for the initial menu mnemonic on SOD is invalid.
Check the spelling of the entered mnemonic. If spelled incorrectly, enter the correct spelling. If the user has insufficient security rights for a mnemonic, check if the user is supposed to use that process and check the security class definition on SCD for the secured mnemonic. If the user should have access to the process, check the user’s security class for the current application on the SOD form. If the user has a specific operator definition for the current application, make sure the operator definition includes the security class for the secured mnemonic. If the user does not have an operator definition for the current application, either add a specific operator definition for the current application or check the operator definition for the next higher application in the tree.
“Password expired on date”
The user’s password has expired.
If the user’s need to access your system has ended, delete the 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 date.
The user’s access to the application is near its end.
If the user’s access to the application should end on the date specified, do nothing: the user will be unable to enter the application on or after that date. If the user should continue to have access to the application, change the password expiration date on the SOD form.
Invalid operator definition or incorrect Envision password.
If this message appears alone, the user has entered an incorrect 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.
See your security administrator“
“Access to appl has been denied”
Troubleshooting: Problems in Envision Applications
260
Table 14: Application Initialization Error Messages (cont’d)
Runtime Administration, July 7, 2009 © 2009 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. Table 15: Topics in this Chapter Topic
Page
Overview of the GRDS System
262
System Integrity Checking
263
Envision On-demand Diagnostic Systems
264
On-demand Diagnostics Using GRDS
266
Automatically Generated Services
279
Programmer-Specified Services
285
Accessing GRDS
286
On-demand Diagnostics Using the UTDB Form
288
GRDS and UTDB: Do They Interact?
292
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
261
Troubleshooting: Envision Diagnostics
Overview of the GRDS System The Generated Runtime Diagnostic Services (GRDS) system encompasses two different runtime functionalities: 1. System Integrity Checking. This enables the system to continually perform integrity checks as it runs. This functionality runs continuously and does not require anyone to manually activate it. Among other things, this functionality employs: The following Envision-Based Software Language (EBSL) statements: CONFIRM and THROW_ERROR. The following forms: • Set Session Confirm Level (SSCL) • Thrown Errors – List (TELI) • Thrown Errors – Detail (TEDT) • Thrown Errors – Purge (TEPU) 2. Diagnostic Logging. This enables logging of runtime diagnostic output. This is an on-demand feature. It must be manually turned on and off by a developer or support staff whenever they need such information for training, development, or troubleshooting. Among other things, this functionality employs: The following EBSL statements: SHOWA and SHOWC The following forms: • Turn GRDS Logging On (GRS1) • Turn GRDS Logging Off (GRS0) • GRDS Services Set (GRSS) • GRDS Service Detail (GRSD) • Process Group Definition (PRGR) • Monitor tail end of OS file (TAIL)
262
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
System Integrity Checking
System Integrity Checking The GRDS system facilitates the embedding of self-diagnostic code into Envision processes. This code tests for required (expected) conditions and values, and displays and logs an error if the test fails. (The display is suppressed when running in background mode or in WebAdvisor). These types of errors are usually an indication of either a bug or data corruption. 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 for the greatest amount of checking, and use 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. See the statements CONFIRM and THROW_ERROR in the Envision Basic Commands Reference manual for more information on how developers add integrity checks to their processes.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
263
Troubleshooting: Envision Diagnostics
Envision On-demand Diagnostic Systems There are two on-demand diagnostic systems for Envision: the Generated Runtime Diagnostic Services (GRDS) system and the older UT Process Debug Activation (UTDB) form. The Generated Runtime Diagnostic Services (GRDS) is a subsystem of Envision that uses the generator to embed diagnostic code into processes. The GRDS system is designed to make it easier and quicker to debug and analyze Envision-generated processes. 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.
Advantages of Using the GRDS System Auto-generated Logging Services GRDS provides services that are not available using the UTDB form. Among these are automatically generated (thus universally available) services. For more information see “Automatically Generated Services” on page 279.
264
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
Envision On-demand Diagnostic Systems
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.
Log Saved to Disk The UTDB process does not save its diagnostics. The text is displayed, one piece of information at a time, and then disappears. You cannot easily collect the diagnostics into a seamless, cross-process picture of the entire session. GRDS collects an entire session’s diagnostics into a single chronological view, and into a log file. The log file is written to disk, which allows you to review the log later, or transmit the log via e-mail. For more information, see the “Sample GRDS Log” beginning on page 267.
Easy to Use, Efficient, and Consistent GRDS diagnostics do not interfere with (corrupt or hide) your currently displayed screen. You (or someone at another work station) can view the diagnostics in real time in a separate window. It is easier to embed additional diagnostics into your processes using GRDS, because the generator takes over as much of the work as possible. See “Automatically Generated Services” on page 279 and “Programmer-Specified Services” on page 285. The code generated for GRDS tends to be more efficient than what was handcoded for the UTDB form. This is true when debugging is inactive, and often true even when it is active. Because GRDS is generated code, it provides more consistency. For example, various inserts and macros have been developed to initialize DATATEL.DEBUG in the UTDB process. GRDS is implemented the same way in all processes. 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.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
265
Troubleshooting: Envision Diagnostics
On-demand Diagnostics Using GRDS The main components of the Generated Runtime Diagnostic Services (GRDS) system are: Dormant blocks of code embedded in Envision-generated source code files. Many types of diagnostic services are available, each associated with its own service code. • These blocks of code provide GRDS “services.” • Each block of code is wrapped in a conditional statement that allows it to execute only when its related service code is requested for a process. • The generator creates most of this code. However, GRDS allows you to create additional service code blocks manually. Envision-Based Software Language (EBSL) statements that allow you to manually add GRDS service code blocks to a process with minimal effort. A trigger mechanism for requesting GRDS services. • You specify the service(s) you want to activate for each process or collections of processes. • You can see a list of available service codes by accessing validation code GRDS.SERVICES on the Validation Codes (VAL) form. You can request these services using the Runtime Analytic Services ON (GRS1) form. Figure 43: View Service Codes on VAL
266
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
On-demand Diagnostics Using GRDS
GRDS allows you to activate a specified set of diagnostic services. These services produce diagnostic text at runtime. All of the text is collected in chronological order into a single log file. You can request services for all processes, selected groups of processes, or specific processes. 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. “Programmer-Specified Services” beginning on page 285 are available only if you have added supporting code to a process. Although these services require you to embed code into a process, the GRDS system introduces two keywords that make this easy to do: SHOWA and SHOWC. See the Envision Basic Commands Reference manual for more information.
Sample GRDS Log This section explains the features of a GRDS log.
Part 1: Runtime Environment Information The top of a GRDS log shows runtime environment information, as shown in the following example.
Log ID.....: SAMPLE Started....: 00:04:16 Aug 23 2006 User.......: jgv Server.....: SDW2K3APP Environment: D:\dev\etk48dev OS.........: Windows NT UniData....: 6.1 Build: (5150) UDT.OPTIONS ON: 41 U_UDT_SERVER ON 46 U_UNFLUSHDATA ON 88 U_CALLC_CDECL ON
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
267
Troubleshooting: Envision Diagnostics
Part 2: Services Requested The next section shows what was requested. --------------------------------------------------------------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 / ---------------------------------------------------------------
Part 3: Diagnostic Text The snippets below are selected segments of a single log file. See “How to Read a GRDS Log” on page 270 for more information about the diagnostic text portion of the log. 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} =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 2_3_4| ae} =1 2_3_4| ae} --------------------------
268
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
On-demand Diagnostics Using GRDS
2_3_4| ad} Arg 2: AR.VWVAR: MAT(25) 2_3_4| ad} (2) =XGUS 2_3_4| ad} (12) =001000111111101111001100100011111110111100111011110111000000 2_3_4| ad} (16) =0 2_3_4| ad} Arg 5: AR.CWVAR: MAT(50,25) 2_3_4| ad} AR.CWVAR: 2_3_4| ks} No active select lists 2_3_4| et} ACTUAL=2063 CPU=16 (milliseconds) 2_3_/ px} * RETURN to MENU_PRCSR @1814 (from ACCEPT_DATA) 2_3| ad} 2_3| ks} No active select lists 2_3| et} ACTUAL=2078 CPU=16 (milliseconds) ... 2_3| 2_3| 2_3| 2_3| 2_3| 2_3| 2_3| 2_3| 2_3| 2_3| 2_3| ...
1} 1} 1} 1} 1} 1} 1} 1} 1} 1} 1}
@60: X.TEST.STRING has 10 fields: =THIS =IS =A} 2 {TEST} 3 {OF} =MULTI-FIELD =SHOWA =WITH =3rd =fld =having =3values
2_3| hs} -->Enter FLD_ENTRY hook of F5 (GUS.FILE.ID) 2_3| hx} Enter FLD_ACCEPT hook of F5 (GUS.FILE.ID) 2_3_\ 2_3_4| pe} * ACCEPT_DATA (from S_GUS @1916) 2_3_4| cc} 1=UT.INIT@52 2=MENU.INIT@2045 3=S_GUS@1916 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 =S_GUS ... 2_3_4| 2_3_4| ...
1} 2}
@123: XTEST1 =THIS HAS~A CONTROL CHARACTER IN IT !Contains non-printing characters! @124: XTEST2 =This has 200 trailing blanksEnter FLD_ENTRY hook of F5 (GUS.FILE.ID) Enter FLD_ACCEPT hook of F5 (GUS.FILE.ID)
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
On-demand Diagnostics Using GRDS
Control Characters Non-printing characters are replaced by the tilde character, and a warning is issued: 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. The developer specified the following: SHOWA $TABLE(GUSV.A1)
And the system logged the following: 2_3| 2_3| 2_3| 2_3| 2_3|
1} 1} 1} 1} 1}
@542: SHOWA $TABLE(GUSV.A1,GUSV.A2,GUSV.A3) GUSV.A1 GUSV.A2 GUSV.A3 ======= ======= ======= 1) F G H 2) I J K
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. The net result was that it behaved as if $TABLE(GUSV.A1,GUSV.A2,GUSV.A3)
had been specified.
Runtime Administration, July 7, 2009 © 2009 Datatel, Inc.
275
Troubleshooting: Envision Diagnostics
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.
2_3_/ px} * RETURN to UTOPRS @2990 (from S_MIO_READ) *_3| *_3| !!} =================================================================== *_3| !!} INPUT.DATA: --> JGV...
