Compaq ACMS for OpenVMS
Getting Started

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.

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.