This appendix lists the source files created in the tutorial application in Part 2 and describes how to access the online versions of these files. You can view the online source files to verify those that you create in the tutorial, or you can copy the online source files instead of typing them yourself.

B.1 Source Files

The following list contains the names of each source file created in the tutorial. The files are listed in the order that they appear in the manual.

• EMPLOYEE_FIELDS.CDO
• EMPLOYEE_INFO_RECORD.CDO
• EMPLOYEE_INFO_WKSP.CDO
• EMPLOYEE_INFO_FORM.IFDL
• EMPLOYEE_CONTROL_FIELDS.CDO
• EMPLOYEE_CONTROL_WKSP.CDO
• EMPLOYEE_QUIT_FIELD.CDO
• EMPLOYEE_QUIT_WKSP.CDO
• EMPLOYEE_INFO_ADD_TASK.TDF
• EMPLOYEE_INFO_ADD.COB
• EMPLOYEE_INFO_PROMPT_FORM.IFDL
• EMPLOYEE_INFO_UPDATE_TASK.TDF
• EMPLOYEE_INFO_UPDATE_GET.COB
• EMPLOYEE_INFO_UPDATE_PUT.COB
• EMPLOYEE_INFO_INIT.COB
• EMPLOYEE_INFO_TERM.COB
• EMPLOYEE_INFO_CANCEL.COB
• EMPLOYEE_INFO_TASK_GROUP.GDF
• EMPLOYEE_INFO_APPL_XXX.ADF
• EMPLOYEE_INFO_MENU.MDF

The source files are installed by the ACMS installation procedure if your system manager chooses to install the ACMS samples. These files are located in ACMS$EXAMPLES, a logical that points to the actual directory. The following command displays the contents of that directory:

$ DIRECTORY ACMS$EXAMPLES

The following command displays the file named EMPLOYEE_FIELDS.CDO:

$ TYPE ACMS$EXAMPLES:EMPLOYEE_FIELDS.CDO

You may wish to copy these files to your default directory instead of typing them yourself. Copying the source code files saves time in performing the tutorial, but you may gain more by typing them in progressive steps while reading about what the code does. Moreover, copying the two DECforms IFDL files means that your forms and panels are already created, nullifying the portion of the tutorial that illustrates how to create them interactively within the DECforms environment.

You can copy single files using the normal method. However, if you want to copy all the source files, you can perform a wildcard copy with one command. Use the following commands to locate yourself in your default directory (filling in your disk and user name) and to copy all the tutorial source files to this directory:

$ SET DEFAULT udisk:[uname] $ COPY ACMS$EXAMPLES:EMPLOYEE*.* *.*

If you copy the online source files, rename the application definition file EMPLOYEE_INFO_APPL_xxx.ADF, filling in your initials or other unique characters for the xxx part of the name. Using a unique application name avoids conflicts with applications created by others who may be entering this tutorial on your system. When you rename this file, you must also edit this file to make the same name change in the first line of the file (see Section 10.1.1); you must also edit the file EMPLOYEE_INFO_MENU.MDF to make the same name change there (two occurrences).

If you copy the online source files, you must edit the files that contain the logical xxx_FILES and replace that logical with the one that you defined for your directory in Section 7.6. Those files that contain the xxx_FILES logical are the six .COB files (one occurrence each), EMPLOYEE_INFO_TASK_GROUP.GDF (three occurrences), and EMPLOYEE_INFO_APPL_XXX.ADF (one occurrence).

This glossary contains terms from all books in the ACMS documentation set.

AAU: See Application Authorization Utility.

ACC: See ACMS Central Controller.

access control list (ACL): A table that lists the users allowed access to an object and indicates the kind of access they are allowed. For example, you can use ACLs on ACMS tasks to control user access to that task.

See also privilege.

ACID: An acronym for the four properties of legal database transactions and distributed transactions. The four properties are atomicity, consistency, isolation, and durability.

ACL: See access control list.

ACMS: ACMS software, a transaction processing monitor that is layered on the OpenVMS operating system, defines, runs, and controls transaction processing applications. You can use ACMS to control existing applications and applications developed with ACMS. It provides a task implementation method that uses high-level definitions to replace complex application code. These definitions reduce the programming time and maintenance costs of traditional application programs that do comparable work. ACMS supports offloaded terminal processing, which allows the execution of ACMS tasks on remote nodes.

See also distributed transaction processing and transaction processing.

ACMS Central Controller (ACC): The ACMS process that serves as the central control point for the ACMS run-time system.

ACMSCFG: See ACMS Remote Manager Configuration Utility.

ACMSDBG: See ACMS Task Debugger.

ACMSGEN Utility: An ACMS utility that lets system managers change ACMS system parameters, such as the number of users who can log in, the user names under which ACMS processes run, and the priorities of these processes. This utility is similar to the OpenVMS SYSGEN Utility.

ACMSMGR: See ACMS Remote Manager.

ACMS operator: An ACMS user authorized to use the ACMS operator commands to control the daily operations of ACMS system software and applications.

ACMS operator command: One of a number of DCL commands provided by ACMS to control the operations of the ACMS system software and applications. Many ACMS operator commands require the OpenVMS OPER privilege.

ACMSQUEMGR: See Queue Manager Utility.

ACMS Remote Manager: An ACMS process that enables system managers to monitor and tune ACMS systems remotely. ACMSMGR is the DCL command-line interface to this process.

ACMS Remote Manager Configuration Utility (ACMSCFG): A utility that enables system managers to configure the initial startup values for the Remote Manager process.

ACMS Task Debugger (ACMSDBG): An ACMS debugging tool that allows you to move through a task to examine how a task branches from one task step to the next. The Task Debugger uses task group databases and procedure server images; it does not require application definitions, menu definitions, or a running ACMS system.

See also multiple-step task and procedure server.

action: See step action.

ADB: See application database.

ADU: See Application Definition Utility.

agent: An OpenVMS process through which one or more ACMS task submitters access the ACMS run-time system. All ACMS users access tasks through an agent. ACMS provides the Command Process (CP) as an agent for terminal users.

An ACMS request interface agent allows users to write and use terminal interfaces other than DECforms to access ACMS. An ACMS systems interface agent allows users to write and use nonterminal interfaces such as badge or barcode readers to access ACMS.

See also Command Process (CP).

agent program: A program that invokes a task that executes in an ACMS application.

ANSI (American National Standards Institute): The American industry-wide standards committee responsible for proposing standards. ANSI proposes software standards for programming languages, databases, and other software products.

See also CODASYL and ISO.

application: In ACMS, a set of tasks that are related by the business activity they support and that are controlled as a single unit. An ACMS application is defined with the ACMS Application Definition Utility (ADU) and runs under the control of the ACMS run-time system. An application definition specifies operational characteristics for the tasks and servers of the task groups that make up the application.

application authorization file: A file, ACMSAAF.DAT, created by and maintained with the Application Authorization Utility (AAU). This file contains a list of applications authorized for installation, and definitions describing what characteristics are allowed for those applications and who is authorized to install them.

Application Authorization Utility (AAU): An ACMS utility that allows a system manager to define which applications can be installed, what characteristics the applications can have, and who can install them.

application database (ADB): In ACMS, a binary file accessed at run time that describes the operational characteristics of all tasks and servers in an application. You generate an application database by building an application definition with ADU. The ACMS run-time system uses application databases to determine which processes to start, when to start them, and which users have access to which tasks.

See also application definition.

application definition: In ACMS, the specification of the run-time characteristics for an ACMS application and its servers and tasks. You write an application definition using the ADU. After creating the definition, you use ADU to build the application database, which is the binary version of the definition file.

See also application database.

Application Definition Utility (ADU): The primary tool for creating ACMS applications. The Application Definition Utility provides the commands and clauses for defining tasks, task groups, applications, and menus.

Application Execution Controller (EXC): The ACMS component that controls task execution for all the tasks in an application. Each application has its own Application Execution Controller. Application Execution Controllers start up and control the server processes needed to handle processing work for tasks. They also handle exchange steps, step actions, and the sequencing of steps for tasks defined with ACMS. Application Execution Controllers reference application databases, task databases, form files, request libraries, and message files.

application node: The back end of a distributed transaction processing system, on which data manipulation and computation are handled. The application resides on the application node. Resource managers that perform data processing can also reside on the application node, or may reside on other remote nodes.

See also back end, front end, and submitter node.

application specification: A specification for an ACMS application that can consist of an application name, a logical name, a node name and file name, or a logical name and file name. Use application specifications in ADU clauses to identify applications on single-node or multiple-node ACMS systems.

See also Application Definition Utility (ADU).

atomicity: A characteristic of database transactions and distributed transactions. If an atomic transaction fails, any changes made to a database, file, or ACMS queue are rolled back to their original state.

See also database transaction, distributed transaction, and recovery unit.

Audit Trail Logger (ATL): In ACMS, a monitoring tool that has a recording facility and a utility for generating reports. The recording facility gathers information about a running ACMS system, including information about system and application starts and stops, user sign-ins and sign-outs, processing errors, user task selections, task completions, and task cancellations. The report utility (ATR) generates summary reports of this information.

back end: The data and computational processes in a transaction processing system in which terminal and menu functions are handled by separate processes. The back-end processes include the EXC and server processes.

Front-end processes can be shifted to a separate computer, OpenVMS Cluster network, or Local Area OpenVMS Cluster network to increase system performance.

See also front end.

block conditional clause: One of four statements of a task definition language. You can use a block conditional clause in an ACMS task to make initial exchange and processing work dependent on the values of workspace fields.

block step: One of three kinds of steps used to define the work of a multiple-step task. A block step definition has three parts: attributes, work, and action.

See also exchange step and processing step.

called task: A task that is invoked, or called by, another ACMS task. The task that calls the called task is known as a parent task.

See also parent task.

cancel action: A procedure or image called by an ACMS task when the task is canceled. The cancel action does cleanup work for the task, such as recovering from incomplete operations. It does not release locks or perform other work specific to a server.

cancel procedure: A procedure called by ACMS to clean up any context held by a task in a server. The cancel procedure does cleanup work for the server process, such as releasing record locks, so that the process can be used again without being restarted. When a cancel procedure is called, it runs in the server process allocated to the task, whether or not the task is using the server process at the time of the cancellation.

CDD (Common Data Dictionary): See CDD data dictionary system.

CDD data dictionary system: A data dictionary system consisting of a hierarchy of directories that contain definitions used by VAX and Alpha transaction processing products. The CDD dictionary contains descriptions of data, not the data itself. CDD objects are stored hierarchically and accessed by reference to dictionary path names.

centralized transaction processing: A TP system in which all TP components run on the same computer.

cluster: See OpenVMS Cluster network.

CODASYL (Conference on Data Systems Language): The industry-wide standards committee responsible for proposing standard data definition and data manipulation languages for databases conforming to the network model. The CODASYL committee is also responsible for proposing the Form Interface Management System (FIMS) standard.

See also ANSI, Form Interface Management System, and ISO.

Command Process (CP): The ACMS process that handles user logins and the interaction between terminals and ACMS.

See also agent.

commit: To make permanent changes to a resource during a database or distributed transaction.

composable task: A task written in such a way that it can be called to participate in a distributed transaction started by a parent task or an agent.

See also distributed transaction and parent task.

concurrency: The method of controlling conflicts and contention when simultaneous updates to a database occur.

conditional clause: One of four statements of the task definition language. You can use conditional clauses in an ACMS task to make exchange, processing, or action clauses dependent on the values of workspace fields.

consistency: A characteristic of a transaction. A transaction has consistency if it successfully modifies the system and the database from one valid state to another.

CP: See Command Process.

database management system: A system for creating, maintaining, and accessing a collection of interrelated data records that can be processed by one or more applications without regard to physical storage. Data is described independently of application programs, providing ease in application development, data security, and data visibility.

Note that the acronym DBMS is often used to mean database management system. Do not confuse this generic use of the term DBMS with references to the specific Oracle CODASYL DBMS software product. a CODASYL-compliant database management system.

database manager: See resource manager.

database transaction: A set of updates to recoverable resources, such as files and databases. Database transactions have the properties of atomicity, consistency, isolation, and durability.

See also atomicity, distributed transaction, recovery unit, and resource manager.

data resource: A collection of data items that represent business information.

DBMS: A CODASYL-compliant database management product. You can use DBMS to access and administer databases ranging in complexity from simple hierarchies to complex networks with multilevel relationships.

Note that the acronym DBMS is often used to mean database management system. Do not confuse this generic use of the term DBMS with references to the specific Oracle CODASYL DBMS software product.

See also database management system.

DCL: See DIGITAL Command Language.

DCL command procedure: A sequence of DIGITAL Command Language (DCL) commands stored in a file; sometimes referred to as a DCL procedure.

DCL server: One of two types of servers used to handle processing work for ACMS tasks. A DCL server handles images, DCL commands, and command procedures.

See also DCL server image, procedure server, and server image.

DCL server image: The image provided by ACMS that is loaded into a DCL server process when the process is started by the EXC. The DCL server image lets you use images, DCL commands, and procedures to implement processing for tasks.

See also Application Execution Controller (EXC) and procedure server image.

DCL server process: See server process.

DDU: See Device Definition Utility.

deadlock: A situation in which two or more processes request the same set of resources and there is no method for resolving the conflict, except to reject all but one of the processes. For example, if process A has record 1 locked and requests record 2, while process B has record 2 locked and is requesting record 1, a deadlock occurs between processes A and B.

DECdtm services for OpenVMS: A collection of OpenVMS services providing management of distributed transactions. DECdtm services implement a two-phase commit protocol. ACMS uses DECdtm services as its transaction manager.

See also distributed transaction and two-phase commit (2PC) protocol.

DECforms: A forms product running on the OpenVMS operating system that integrates text and graphics into forms and menus, and displays them on a terminal screen. DECforms also provides extensive facilities for specifying full control of the user interface from within the form rather than in the application program.

DECnet/VAX: The DIGITAL software facility that implements the DIGITAL Network Architecture (DNA) to let a user access information on a remote computer through telecommunications lines. DECnet/VAX enables an OpenVMS system to function as a network node.

See also DIGITAL Network Architecture (DNA).

default: The value of an argument, field, or part of a command line assumed by a program if the specific value is not supplied by the user.

default directory: The directory from which the OpenVMS system reads and to which it writes all files that you create unless you explicitly name a directory.

See also directory.

device definition file: A file, created and maintained with the ACMS Device Definition Utility (DDU), that contains a list of terminals from which users can access ACMS, and information specifying whether the terminals can access both ACMS and OpenVMS, or only ACMS.

Device Definition Utility (DDU): The ACMS tool for defining which terminals have access to ACMS and what characteristics those terminals have.

dictionary object: A data definition stored in a CDD dictionary.

See also CDD data dictionary system.

DIGITAL Command Language (DCL): A command interpreter for the OpenVMS system.

DIGITAL Network Architecture (DNA): A description of network structure, operation control, and protocols (rules) developed by Digital Equipment Corporation.

directory: A file that catalogs a set of files stored on disk or tape. The directory includes the name, type, and version number of each file in the set.

See also default directory.

directory anchor: In CDD, the specification of the OpenVMS directory where the CDD hierarchy is stored. The anchor is followed by the dictionary path. The specification DISK1:[CDDPLUS] is an example of a directory anchor.

distributed application: An application that uses a network for remote access to a database or another application.

distributed transaction: The grouping of operations on files and databases into a single transaction. Distributed transactions have the properties of atomicity, consistency, isolation, and durability and can include more than one type of resource manager.

See also atomicity, database transaction, recovery unit, and resource manager.

distributed transaction processing: The processing of ACMS tasks on two separate nodes: a front end for offloading terminal or device I/O, and a back end for processing against the database. An ACMS user or task submitter signed in to an ACMS system on one node can select tasks in an application on an ACMS system on another node. ACMS uses DECnet to communicate transparently among nodes without rewriting applications or tasks, and can distribute processing between nodes in an OpenVMS Cluster network, a local area network, a wide area network, or any combination of the three.

See also ACMS, DECnet/VAX, transaction processing, and OpenVMS Cluster network.

durability: A characteristic of a transaction. A transaction has durability if all the changes that it makes to the database become permanent when the transaction is committed.

escape unit: In DECforms, a subroutine that you can call to perform actions outside the form, such as data validation or database lookup. DECforms escape units provide only a synchronous interface.

EXC: See Application Execution Controller.

exception: An event or an error condition that interrupts the normal flow of an executing task.

exception handler: An optional part of an exchange, processing, or block step that lets you control task execution when an exception is raised in the work or action part of the step.

exception handler action: The part of a step definition that tells ACMS what to do if an exception occurs during the step. These instructions can consist of a single unconditional action or a series of conditional actions based on one or more conditions, such as the value of a field in a workspace.

exchange step: One of three kinds of steps that define the work of an ACMS multiple-step task. An exchange step handles input and output between the task and the task submitter.

See also block step and processing step.

execution controller: See Application Execution Controller.

external request: A service in DECforms that can be called from outside a form. The ACMS interface to DECforms consists of six calls to corresponding external requests: ENABLE, DISABLE, CANCEL, SEND, RECEIVE, and TRANSCEIVE.

field definition: A CDD dictionary definition that describes the data that can be stored in a specific field of an application. Field definitions typically include information such as data type and size.

file name: The name you choose to identify a file. The file name can be from 1 to 39 characters in length, selected from the letters A through Z, the numbers 0 through 9, the underscore (_), and the dollar sign ($).

file specification: A name that uniquely identifies a file. A full file specification identifies the node, device, directory name, file name, file type, and version number under which a file is stored.

file type: The part of a file specification that describes the nature or class of file. The file type follows the file name in a specification and is separated from the file name by a period. A file type can be from 1 to 39 characters. The OpenVMS operating system and software products developed by Digital Equipment Corporation recognize many default file types used for special purposes. For example, .ADB is the default file type for an ACMS application database.

FIMS: See Form Interface Management System.

form: In DECforms, a set of instructions that govern the user interface to an ACMS application. The form describes all the screen interactions with the data that is transferred between the form and the application.

form data items: Variables associated with a DECforms form.

Form Interface Management System: A system for interaction between applications and display devices proposed by the CODASYL Form Interface Management System Committee.

See also CODASYL and DECforms.

form manager: A run-time component of a presentation service that provides the interface between the terminal display and an ACMS application. The form manager controls the terminal display, user input, and transfer of data between the terminal and ACMS.

form record: A structure that controls how data is transferred between ACMS and a DECforms form.

front end: The processes controlling terminal and menu functions in a transaction processing system in which data manipulation and computation are handled by separate processes. The front-end processes include the CP and the Queued Task Initiator (QTI).

Front-end processes can be shifted to a separate computer, OpenVMS Cluster network, or Local Area OpenVMS Cluster network to increase system performance.

See also back end.

function key: In DECforms, a key that you can define to perform a specific function. You define function keys in the layout part of a DECforms IFDL source file.

For example, you might define the PF4 key for DECforms to instruct ACMS to cancel the current task when the terminal operator presses PF4.

function response: In DECforms, a statement in the IFDL source file that instructs the Form Manager how to process a form when the user presses a function key.

See also function key.

given name: The name assigned to a CDD dictionary directory, subdictionary, or object. A given name can be from 1 to 31 characters in length selected from the letters A through Z, the numbers 0 through 9, the underscore (_), and the dollar sign ($). The first character must be a letter, and the last character cannot be an underscore or a dollar sign. If you are using a VT200- or VT300-series terminal, you can use 8-bit alphabetic characters.