| Previous | Contents | Index |
Users select and run ACMS tasks from menus similar to those shown in Figure 2-3. Menus can include two types of entries: tasks and other menus. Tasks do the work of an application; menus display other tasks and other menus. Because a user can select one menu from another, application programmers can build menu hierarchies or trees. One menu tree can make tasks from many applications available, so users can access many applications from a single menu.
ACMS uses two presentation services, DECforms and TDMS, to display menus. The ACMS software kit includes a DECforms form and a TDMS form for displaying standard menus. You can easily revise the standard format to customize it to your application. You can also use the ACMS Request Interface to include other menu formats in your applications, such as menus in an ALL-IN-1 office integration system.
You create a menu definition for each menu you want to display. The definition describes the characteristics of the menu, including the list of items on the menu and a description of each item.
In the standard DECforms and TDMS formats, the only information required in a menu definition is the list of entries that appears on the menu. The menu definition includes an entry name for each entry as it appears on the menu, and an entry type, which tells ACMS whether the entry is a task or another menu. In Figure 2-7, the entry names are Sale, Inventory, Cancel, Return, and Complaint. The entry type is indicated by the letters T, for task, and M, for menu, following the entry name. You can include additional information in a menu, such as a menu title and text describing the entries.
Figure 2-7 Retail Transaction Menu with Task and Menu Entries
A menu can include tasks from more than one application. To execute a task from a menu, you can select a task by:
Depending on the design of your application, you can supply additional information to a selected task following the task name or number in a menu. In Figure 2-7, for example, you can specify the Inventory task followed by an inventory item number at the Selection: prompt.
For more information on ACMS menus, see Compaq ACMS for OpenVMS Writing Applications.
2.6 Debugging and Testing
Before you include a task group in your application, use the ACMS and OpenVMS debugging tools to test and debug the task group, its member tasks, and procedures called by the tasks. The ACMS Task Debugger allows you to examine individual tasks and find out how ACMS manages the branching from one task to another. You use the OpenVMS Debugger to check whether or not procedures and forms are correct.
The ACMS Task Debugger is the primary tool for debugging tasks because it lets you control tasks while they are running. For example, you can pause at each step in a task. You can look at the values in the task workspaces, change these values if necessary, and resume task execution where you left off.
The ACMS Task Debugger helps you verify:
The ACMS Task Debugger uses the OpenVMS Debugger to debug procedures in processing steps. You use the OpenVMS Debugger to check whether or not procedures execute and variables contain the values you expect. For example, you can pause after a procedure reads a record, check the values in a task workspace, and then resume task execution.
ACMS also provides a way to debug running applications. You can debug servers while they are running and obtain server process dumps for servers that stop unexpectedly.
For information on testing and debugging, see Compaq ACMS for OpenVMS Writing Server Procedures. For a step-by-step introduction to developing an ACMS application, see Part 2.
ACMS applications run under the control of the ACMS run-time system. The run-time system executes tasks according to the control characteristics in the application definition.
This chapter describes what happens as ACMS executes the series of
steps that make up a task. Each part of the task is discussed in terms
of the OpenVMS and ACMS run-time processes and their functions.
3.1 ACMS Processes
The ACMS run-time system is made up of eight specialized processes. Four processes manage the processing of a transaction; four monitor and control the run-time system. Figure 3-1 shows the processes that make up the ACMS run-time system. The following sections explain these specialized processes.
Figure 3-1 ACMS Run-Time Processes
The ACMS processes that manage the work of an ACMS transaction are:
A Command Process (CP) manages logins and interaction between terminals and ACMS. CPs display menus, accept and interpret terminal user commands, and communicate with the Application Execution Controller. An ACMS system can include more than one CP.
A CP separates an application's interactions with the terminal from its processing work. This separation makes it possible to distribute the application, off-loading forms and menus to a front-end, or submitter node, and concentrating computations and data processing on one or more back-end, or application nodes.
The ACMS Queued Task Initiator (QTI) dequeues task elements that were placed in a queue by an ACMS programming service, and initiates tasks in an application. For example, you can design a task that places another task in a queue, allowing users and the application to continue working without waiting for the queued task to complete. The QTI later executes the queued task.
The Application Execution Controller (EXC) processes the definitions of the tasks in an application, managing all the tasks in an application simultaneously. The EXC is responsible for task security, allocating workspaces, and scheduling, creating, and communicating with servers. The EXC accepts messages from the CP or QTI (which invoke tasks on behalf of the user), passes forms for exchange steps to the CP, creates server processes that call procedures in processing steps, and creates workspaces for sharing data by tasks.
Each application on an ACMS system has its own execution controller. You can run more than one application on a node and have more than one active EXC at a time.
The server process (SP) carries out the high-level programming language routines or DCL routines that handle a task's processing work and database or file I/O. The SP calls the appropriate subroutine for a task. The EXC uses the results to determine what to do next and passes the final task results to the CP or QTI. Each application can use more than one server process.
The CP uses the menu database to display menus for a user. The EXC uses
the task group database to determine flow control for tasks and which
server to call for a particular task. The EXC uses the application
database to determine such information as the process characteristics
for server process and security through an access control
list (ACL) for a task. The ACL specifies which users can
execute a task.
3.1.2 Monitoring and Controlling Processes
The ACMS processes that monitor and control the run-time system are:
The ACMS Central Controller (ACC) is the central control point for the ACMS run-time system. It starts and controls the Terminal Subsystem Controller, the QTI, the EXC, and the Audit Trail Logger (ATL).
The Terminal Subsystem Controller (TSC) is responsible for creating and controlling the number of active CPs and for assigning terminals to CPs. The TSC starts and stops CPs as needed within limits that you define. It also controls which terminals can access ACMS.
The Audit Trail Logger (ATL) is responsible for writing information about a running ACMS system to the audit trail log file. The ATL keeps a record of when the ACMS system starts and stops, when users log in, and when applications and tasks start and stop. The ACC always starts the ATL when the ACMS system is started. With the Audit Trail Report Utility (ATR), you can create summary reports based on information recorded by the ATL.
The Software Event Logger (SWL) records all software
errors and event messages that occur during the execution of ACMS
application programs. The Software Event Log Utility Program (SWLUP)
allows you to create reports containing selected information recorded
by the SWL.
3.2 Run-Time Processing of Tasks
When users log in to the OpenVMS operating system, OpenVMS starts a process for each of them. However, when users sign in to the ACMS TP monitor, they share a single ACMS Command Process (CP). The CP first confirms that a user is authorized to access ACMS; then it displays the user's menu and accepts task selections.
When a user selects a task, the CP:
If a user does not have access to the task, the execution controller passes an error message to the CP for display on the user's terminal.
After determining that a user has access to a task, the EXC:
The EXC starts and stops SPs as needed within limits set by the application definition. The task definition and the kind of processing the task does determine when and how long an SP is allocated.
Compaq ACMS for OpenVMS Writing Applications provides more detailed information on the run-time
processing of ACMS tasks.
3.3 Run-Time Processing in a Distributed Environment
With ACMS, you can separate terminal and menu functions from the run-time processing of an application. This separation lets you run applications on a single computer, in an OpenVMS Cluster, or across the nodes of a network. In a distributed environment, the presentation service providing the terminal or device interface resides on a front-end processor, while the application managers and databases reside on a back-end processor.
Separating an ACMS application's functions using a front end that manages terminal functions and a back end that manages data processing has many benefits. For example, you can distribute your work among several applications, each running on its own back-end process and each available to users from a single menu. Users can select tasks and access the applications from a single menu on the front end. By distributing the run-time processing of tasks, you can improve system performance and the use of system resources.
Figure 3-2 shows the run-time processing of an application with terminal I/O shifted to a separate front-end computer or OpenVMS Cluster.
At run time, ACMS handles user logins and task requests for applications running on a network in much the same way it handles them for a single-node application. When a user enters ACMS, the CP controls the user's terminal, managing logins and the display of menus.
For details on applications with separate front-end processing, see Compaq ACMS for OpenVMS Managing Applications, Compaq ACMS for OpenVMS Writing Applications, and Compaq ACMS for OpenVMS ADU Reference Manual.
Figure 3-2 Run-Time Processing with a Separate Front End
The ACMS system manager is responsible for the administration, performance, and operation of the ACMS system. After an application is defined and tested, the system manager can make it available to users by:
This chapter provides an overview of managing the ACMS system and
applications, and describes the tools ACMS provides for this work. For
a more detailed explanation of these features, see Compaq ACMS for OpenVMS Managing Applications.
4.1 Authorizing Access to ACMS
When many users share one OpenVMS system, it is important to control the facilities each user can access. For example, some users might need access only to ACMS, while others need access to the OpenVMS operating system as well as to ACMS.
An ACMS system manager uses three tools to control access to the ACMS system:
See Compaq ACMS for OpenVMS Managing Applications for information on how to use DDU and UDU. See your
OpenVMS system management documentation for more information about the
OpenVMS Authorize Utility.
4.2 Authorizing ACMS Applications
After application definitions are created and application databases are produced with the Application Definition Utility (ADU), the system manager installs the application databases in ACMS$DIRECTORY (a privileged directory). The system manager defines the location of this directory.
To ensure that only valid application databases are stored in
ACMS$DIRECTORY, the ACMS system manager uses the ACMS
Application Authorization Utility (AAU) to create an
application authorization. This authorization describes characteristics
of an application, such as who can install the application database in
ACMS$DIRECTORY and what names are valid for the application.
4.3 Controlling ACMS Applications
The ACMS operator commands let you install, start, stop, or modify applications, as well as control which applications are available to which users. Starting and stopping applications individually helps you control the use of resources and the availability of required files and databases.
When you start an application, ACMS allocates the resources the
application needs. The tasks in the application are then ready for
users to select. When you stop an application, ACMS releases the
resources used by the application, and the tasks in the application are
no longer available.
The following sections explain the types of information you can collect
about the ACMS system, applications, and users.
4.3.1 Displaying System and Application Information
Information about the current state of the ACMS system and active applications can be useful when you are controlling the overall operations of an ACMS application. Before you start an application, you can use the ACMS operator commands at DCL level to check whether or not the application is already running, which users are signed in to ACMS, and what tasks are running. With ACMS operator commands, you can display information about:
ACMS sends status and other operational messages to terminals that are assigned as ACMS operator terminals.
An operator terminal receives messages from ACMS if an application, the
Audit Trail Logger (ATL), or the Terminal Subsystem Controller (TSC)
stops unexpectedly. The operational messages are also logged in the
software event log (SWL) file. An ACMS operator, who
is authorized to use ACMS operator commands, can find and correct
problems more quickly with an authorized operator terminal than with an
error log file only.
4.4 Monitoring ACMS Applications
An important part of managing an ACMS application is keeping track of its activity. For example, you might want to account for the computer resources that an application uses. You might also want to keep track of who uses the applications and what tasks they run. Monitoring an application helps you keep a system running efficiently.
The important tools for monitoring ACMS applications are:
The following sections discuss the ATL, Oracle Trace, and the SWL. For
more information about the ATL, Oracle Trace, and the SWL, see
Compaq ACMS for OpenVMS Managing Applications.
4.4.1 Using the Audit Trail Logger
The audit log includes information about system and application starts and stops, user sign-ins and sign-outs, processing errors, user task selections, and task completions. You can use this information to determine who is using ACMS, what applications and tasks they are running, and what tasks have been completed or canceled.
The Audit Trail Report Utility (ATR) generates a report containing information recorded by the ATL. The ATR lets you specify the type and extent of information you want in a report, which can be either displayed on a terminal or written to a file. For example, you can produce a report containing a list of all tasks selected and all logins attempted between 9 a.m. and noon. Each record in the report includes:
Oracle Trace reports on events that occur when an application is in use. The data Oracle Trace collects includes process statistics and performance information, such as the working set size at the time an application event occurs. With Oracle Trace, you can collect information about:
| Previous | Next | Contents | Index |