# Compaq ACMS for OpenVMS
Getting Started

Previous | Contents | Index

To refer to a CDD object, specify a dictionary anchor and a path name. An anchor specifies the OpenVMS directory in which the CDD hierarchy is stored. The given name of a dictionary directory, subdirectory, or object is separated from the name of its parent by a period.

group workspace: A workspace that holds information needed by tasks in an ACMS task group. A group workspace is made available when a terminal user selects the first task in a group that uses that workspace. Once allocated, a group workspace remains available to all tasks in the group until the application stops.

See also task workspace and user workspace.

image: A file consisting of procedures and data that have been bound together by the linker. There are three types of OpenVMS images: executable, shareable, and system. When not otherwise stated, image refers to an executable image.

initialization procedure: In ACMS, a procedure that runs when a procedure server process starts and that opens files or readies a database for the server process.

interactive transaction: A transaction that contains one or more exchange steps within the bounds of the transaction.

ISO (International Standards Organization): The international, industry-wide standards committee responsible for proposing standards. ISO proposes software standards for programming languages, databases, and other software products.

See also ANSI and CODASYL.

isolation: A characteristic of a transaction. A transaction has isolation if it behaves the same running serially or concurrently. If a transaction is processed concurrently with other transactions, it behaves as if it were the only transaction executing in the system.

journaling: The process of recording information about operations on a database or file onto a recoverable resource. The type of information recorded depends on the type of journal being created.

keyword: A word reserved for use in certain specified syntax formats, usually in a command or a statement.

Language-Sensitive Editor (LSE): A multilanguage editor designed for software development. LSE assists you in developing definitions or programs with its text editor by providing templates. LSE support is available for ACMS, DECforms, other software products developed by Digital Equipment Corporation, and CDD DMU dictionaries.

linker: A program that creates an executable program, called an image, from one or more object modules produced by a language compiler or assembler. Programs must be linked before they can be executed.

literal: A value expression that represents a constant. A literal is either a character string enclosed in quotation marks or a number.

logical name: A specified name for any portion or all of a file specification. Logical name assignments are user-specified and are maintained in logical name tables for each OpenVMS process, each group, each job, and the OpenVMS system.

LSE: See Language-Sensitive Editor.

MDB: See menu database.

menu: A list of entries, from which a user selects one for processing. A menu entry can direct a user to a task or another menu.

In ACMS, you define the list of items on a menu and other menu characteristics using the ADU.

menu database (MDB): In ACMS, a binary file containing information derived from menu definitions. ACMS uses the information in the menu database for displaying menus. ADU creates the menu database when it builds menu definitions. The menu database has the file type .MDB.

menu definition: In ACMS, the specification of the characteristics of an ACMS menu, including the list of items on the menu and the description of each item. You write a menu definition using ADU. After creating the definition, you use ADU to build the menu database, which is the binary version of the definition file.

message file: A file that contains a table of message symbols and their associated text.

multiple-step task: An ACMS task defined in terms of a block step. The task contains one or more exchange and processing steps.

See also block step, exchange step, processing step, and step action.

multithreaded process: A single process that handles many simultaneous users.

object module: The binary output of a language processor, such as an assembler or compiler. The linker accepts object modules as input.

See also linker.

OpenVMS Cluster network: A highly integrated organization of OpenVMS systems that communicate over a high-speed communications path. OpenVMS Cluster networks have all the functions of single-node OpenVMS systems, plus the ability to share CPU resources, queues, and disk storage. Like a single-node system, the OpenVMS Cluster organization provides a single security and management environment. Member nodes can share the same operating environment or serve specialized needs.

OpenVMS Debugger: An OpenVMS debugging tool for debugging procedures called by ACMS processing steps.

OpenVMS image: See image.

OpenVMS process: See process.

OpenVMS user: A person or account authorized by an OpenVMS system manager to access an OpenVMS system. The user is assigned a user name, a password, a UIC, a default OpenVMS directory, a default command language, quotas, limits, and privileges.

operator command: See ACMS operator command.

Oracle Trace: A programmer productivity tool used with ACMS to collect and create detailed reports on events that occur when an ACMS application runs.

nested block step: A block step contained within another block step.

See also block step.

nonrecoverable exception: An error from which the task cannot recover.

panel: A DECforms element consisting of the information and images that are displayed on the user's terminal screen. A panel is composed of such items as fixed background information (literals), fields, attributes, function key control, and customized help messages.

parent block step: A block step that contains one or more nested block steps.

See also block step and nested block step.

parent task: A task that includes a call to another task. A task can be both a parent task and a called task.

See also called task.

path name: A unique CDD designation that identifies:

- Dictionary directories
- Subdictionaries
- Object

The full path name combines the given names of directories and an object. Full path names begin with CDD$TOP or the anchor, and end with the given name of the object or directory you want to specify (including the given names of the intermediate subdictionaries and directories). The names of the directories and objects are separated by periods. The specification DISK1:[CDDPLUS]APPLA.RECORDS.AFIELD is an example of a path name.

See also given name.

phase: In DECforms, one of several steps the Form Manager follows when it processes an external request.

presentation service: Forms management software such as DECforms, which handles the gathering of input from the user.

privilege: A characteristic assigned to a user or program that determines what operations that user or program can perform.

See also access control list (ACL).

procedure: A general purpose routine, entered by means of a call instruction, that uses an argument list passed by a calling program and uses only local variables for data storage. A procedure is entered from and returns control to the calling program.

See also DCL command procedure, initialization procedure, step procedure, termination procedure, and cancel procedure.

procedure object library: A collection of object modules for procedures.

See also linker and object module.

procedure server: In ACMS, a set of user-written procedures, the procedure server image created when the procedures are linked, and the procedure server process that ACMS creates to execute the procedure server image.

See also procedure server image and server process.

procedure server definition: In ACMS, the part of a task group definition that describes the server procedures and the server image included in a procedure server.

procedure server image: The image that is loaded into a server process when the process is started by the ACMS Application Execution Controller. The procedure server image is created when the procedures handled by the server are linked together with the procedure server transfer module for that server.

See also Application Execution Controller (EXC), DCL server image, and procedure server transfer module.

procedure server process: See server process.

procedure server transfer module: The object module created for a procedure server as a result of building an ACMS task group definition. When a task group is built, the ADU produces a procedure server transfer module for each procedure server defined in the task group. The procedure server transfer module is linked together with all the procedures handled by the server to produce the procedure server image.

process: The entity scheduled by the OpenVMS system software that provides the context in which an image runs. A process consists of an address space and both hardware and software context.

process context: See server context.

processing step: One of three kinds of steps that define the work of an ACMS task. The work of a processing step is handled by a server and can consist of computations, data modification, or file and database access.

See also block step and exchange step.

QTI: See Queued Task Initiator.

qualifier: A portion of a command string that modifies a command verb or command parameter. A qualifier follows the command verb or parameter to which it applies and has the following format:

/qualifier[=option]

queue: See task queue.

queued task: A task executed by the queuing facility. Queued tasks cannot perform exchange steps to collect input data, but they are otherwise the same as any other ACMS tasks.

queued task element: A data element in a task queue. A queued task element includes the task name, application name, and workspaces associated with a transaction. A queued task element is placed in a task queue by the ACMS$QUEUE_TASK programming service and removed from the queue by the ACMS QTI.

See also Queued Task Initiator and queued task services.

Queued Task Initiator (QTI): The component of the ACMS queuing facility that dequeues task elements from a task queue and initiates their execution in a specified application.

queued task services: The component of the ACMS queuing facility that provides the ACMS$QUEUE_TASK and ACMS$DEQUEUE_TASK programming services for queuing and dequeuing task elements and their data to and from task queues. You can call these services either from a procedure server in an ACMS task or from a user-written program.

See also procedure server.

Queue Manager Utility (ACMSQUEMGR): The component of the ACMS queuing facility that you use to create and manage task queues.

queuing facility: The ACMS utility, programming services, and run-time process that allow you to design applications that can place transactions in a temporary storage area for deferred processing of data. The queuing facility includes the Queue Manager Utility (ACMSQUEMGR), ACMS$QUEUE_TASK and ACMS$DEQUEUE_TASK programming services, and QTI.

See also application, Queued Task Initiator, queued task services, Queue Manager Utility, and transaction.

Rdb: A relational database management 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. Rdb is based on the relational database model as defined by the Digital Standard Relational Interface (DSRI).

See database management system.

record definition: A CDD dictionary definition that typically consists of a grouping of field definitions.

Record Management System (RMS): A set of OpenVMS operating system procedures that programs can call to process files and records within files. RMS lets programs issue GET and PUT requests at the record level (record I/O), as well as read and write blocks (block I/O). RMS is an integral part of the OpenVMS system software and is used by high-level languages, such as COBOL and BASIC, to implement their input and output statements.

recovery: In Rdb, DBMS, and RMS resource managers, the process of restoring a database to a known condition after a system or program failure.

In ACMS, you can define recovery as a characteristic for a multiple-step task that uses Rdb, DBMS, or RMS.

See also journaling and transaction.

recovery unit: A series of operations that exchange information with a database or file and are treated as a group; either all of them are completed at once, or none of them is completed. A recovery unit is equivalent to a transaction.

Relational Database Management System (Rdb): See Rdb.

remote server: The part of ACMS, DBMS, Rdb, and VIDA that lets you access data on other computers on your DECnet network.

request: In ACMS, a set of instructions used by ACMS tasks to display TDMS forms on a terminal and gather information from a terminal user.

Request Interface (RI): A method that allows you to use interfaces other than DECforms or TDMS for I/O functions that do not require more than one user per process. ACMS provides the means, with the Request Interface, to use forms products such as FMS (Forms Management System), SMG (Screen Management Facility), terminal interface products from other vendors, and menus in an ALL-IN-1 office integration system.

request library file (RLB): An OpenVMS file that contains TDMS requests and the form and record information necessary to execute those requests. When you use the TDMS Request Definition Utility (RDU) to build a request library file, RDU reads the definitions in CDD and puts information in the request library file so that the program can execute the requests. A request library file that contains the request named in a TDMS call must be opened before a program can use a request. Request library files have the default file type .RLB.

resource manager: An operating system service or layered product software that controls shared access to a set of recoverable resources (Rdb, DBMS, and RMS all include resource managers). A single distributed ACMS transaction can use more than one resource manager.

response: In DECforms, an optional part of the IFDL source code with which you can define how the Form Manager works with the terminal operator, the form, and the ACMS application.

RLB: See request library file.

RMS: See Record Management System.

rollback: A process that cancels any changes made to a resource during a database or distributed transaction.

root block: The outermost block step in a task definition. A task can include only one root block.

See also block step and nested block step.

root processing step: The processing step in a single-step task.

See also single-step task.

server context: In ACMS, information local to a server process, such as record locks and file pointers. Server context can be retained from one step to another in a block step, but cannot be passed between servers or tasks.

server image: An OpenVMS image that the ACMS run-time system loads into a server process. The two types of server images are procedure server images and DCL server images.

server procedure: In ACMS, programs or subroutines that are written in a programming language that conforms to the OpenVMS Calling Standard. There are two types of server procedures:

- Step procedures
- Cancel procedures, initialization procedures, and termination procedures

See also cancel procedure, initialization procedure, step procedure, and termination procedure.

server process (SP): An OpenVMS process created according to the characteristics defined for a server in an ACMS application and task group definition. Server processes are started and stopped as needed by Application Execution Controllers.

See also Application Execution Controller (EXC) and task group database (TDB).

shadow workspace: A workspace that you can use in exchange steps that use DECforms. There are two types of shadow workspaces: SEND shadow workspace and RECEIVE shadow workspace. The SEND shadow workspace can contain an indicator that instructs the Form Manager whether to update last-known values of form data items. The RECEIVE shadow workspace contains indicators about which fields in the receive workspace have changed as a result of the exchange with the form.

single-step task: An ACMS task that has only a single processing step. Single-step tasks can be defined in a task group or a separate task definition.

See also multiple-step task, root processing step, and task group.

Software Event Logger (SWL): The process that records ACMS software events that occur during the running of an application program. To see the events logged by the SWL, you must use the Software Event Log Utility Program (SWLUP).

See also Software Event Log Utility Program (SWLUP).

Software Event Log Utility Program (SWLUP): The ACMS utility you use to list selected ACMS events that are logged by the SWL.

SQL: See Structured Query Language.

step: A part of an ACMS task definition that identifies one or more operations to be performed. Task definitions can have three kinds of steps: block steps, processing steps, and exchange steps. Each step contains clauses that describe the work to be done in that step, the action that follows the work, and the exception handler action that is performed if an exception occurs in the step.

See also block step, exchange step, processing step, step action, step attributes, step exception, step label, step procedure, and step work.

step action: In a task definition, the part of a step that tells ACMS what to do after completing the work for that 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.

step attributes: In a task definition, the part of the step that tells ACMS the attributes of the step, such as the type of I/O to use.

step exception: An error that you can handle in the exception part of the step on which the exception occurs or in an exception handler on an outer block step.

step label: A name assigned to a step in a multiple-step ACMS task.

See also multiple-step task.

step procedure: A type of procedure called in a processing step of an ACMS task. Step procedures handle computations, data modification, and file and database access for processing steps that use procedure servers. Normally, step procedures do not handle input from or output to a terminal.

step work: The part of an ACMS step definition that describes terminal interactions, processing, or both.

stream: In ACMS, data passed between an agent program and an EXC. A stream allows communication between a terminal or nonterminal task submitter and ACMS.

See also Systems Interface (SI).

Structured Query Language (SQL): A structured language for accessing and manipulating records stored in a relational database.

submitter node: In a distributed transaction processing system, the front end of a transaction processing system, from which users can select tasks that are submitted over the network to a back-end system for data manipulation and computation.

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

SWL: See Software Event Logger.

SWLUP: See Software Event Log Utility Program.

Systems Interface (SI): The ACMS Systems Interface is a group of system services that enable a programmer to interface a wide range of external devices and systems (such as ATMs and bar-code readers) with the ACMS run-time environment.

system workspace: A task workspace whose record definition is provided by ACMS. ACMS provides three system workspaces. At run time, ACMS fills in the contents of the system workspaces for each selected task. These workspaces, like other task workspaces, last only for the duration of a task instance.

See also group workspace, task instance, task workspace, user workspace, and workspace.

table: In a relational database, a collection of rows (records) and columns (fields). Also called a relation.

task: In ACMS, a unit of work that performs a specific function and can be selected for processing by a terminal user or another task. Every task belongs to a task group. Some tasks are defined in the task group they belong to; other tasks have separate task definitions. In either case, they are defined with ADU. The work of a task can be defined as a single processing step or a block step, which consists of a series of exchange and processing steps.

See also exchange step, multiple-step task, processing step, single-step task, and task group.

task attributes: The part of a task definition that tells ACMS the characteristics for the task as a whole, such as what workspaces to use.

task definition: In ACMS, the specification of the steps involved in the exchange of data between a user and the application, and in the processing of data against a database or file. You write a task definition using the task definition language.

task element: See queued task element.

task group: One or more ACMS tasks that have similar processing requirements and that are gathered together so they can share resources. A task group definition, created with ADU, defines the servers used by the tasks that belong to the group. It also defines other characteristics and requirements for the tasks in the group, such as workspaces, request libraries, and message files.

See also task group database (TDB) and task group definition.

task group database (TDB): In ACMS, a binary file containing information derived from task and task group definitions. The Task Debugger uses the TDB when debugging tasks; ADU uses the TDB when building an application database. ACMS also uses the TDB to execute a task.

The TDB is created as a result of building a task group definition with ADU. Task group database files have the default file type .TDB.

task group definition: In ACMS, specifies the processing requirements and application resources shared by a group of tasks. The task group definition can include information about shared procedures, workspaces, servers, and messages. You write a task group definition using ADU. After creating the definition, you use ADU to build the task group database, which is the binary version of the definition file.

task instance: In ACMS, the occurrence of the processing of a task. Each selection of a task is a task instance. Every task instance is given a unique identifier by the ACMS run-time system.

See also task.

task I/O: In ACMS, the communication between a task submitter and a task instance. This communication can consist of OpenVMS terminal I/O, DECforms requests, TDMS requests, stream I/O, or I/O with other terminal or nonterminal interfaces using the Request Interface or Systems Interface.

See also request, Request Interface, Systems Interface, and task instance.

task queue: An area of storage where transactions can be placed as queued task elements for deferred processing. A task queue is created and managed using the ACMS Queue Manager Utility. Queued task elements are placed in the queue using the ACMS$QUEUE_TASK programming service and removed from the queue by the ACMS Queued Task Initiator.

See also queued task element, Queued Task Initiator, queued task services, queuing facility, and Queue Manager Utility.

task selection string: In ACMS, the string of characters a terminal user types, in addition to or in place of a selection keyword or number, when making a selection from a menu.

task step: See step.

task submitter: Any authorized ACMS user who selects tasks for processing, provides input for that processing, and receives the results of that processing. Task submitters must also be authorized OpenVMS users.

task workspace: A workspace used mainly to pass information between steps in an ACMS multiple-step task. A task workspace is allocated when a terminal user starts a task, and keeps its contents only for the duration of the task instance.

See also multiple-step task and task instance.

TDB: See task group database.

TDMS: See Terminal Data Management System.

Terminal Data Management System (TDMS): A transaction processing product that uses forms to collect and display information on the terminal. TDMS provides data independence by allowing data used in an application to be separated from the application program. ACMS multiple-step tasks use TDMS services to manage terminal input and output.

See also multiple-step task.

Terminal Subsystem Controller (TSC): The process that controls which terminals have access to ACMS, controls the creation/deletion of Command Processes, and assigns terminals to Command Processes.

termination procedure: A procedure that closes files and releases databases. Termination procedures run when a server process is run down.

TP monitor: See transaction processing monitor.

transaction: See database transaction and distributed transaction.

transaction exception: An error that causes a distributed transaction to fail.

transaction manager: In a distributed transaction, the DECdtm transaction coordinator that communicates with the resource managers and implements the two-phase commit protocol.

transaction processing (TP): An environment that addresses large, corporate-level applications that support many users for critical business functions. In a transaction processing application, many users simultaneously perform predefined (query and update) functions on a collection of shared data, generally a database. Results are usually expected immediately (real time).

Previous | Next | Contents | Index