Figure 8-1 • Multiple-Step Task Definition
Multiple-step tasks use workspaces to pass information between steps. In the definition shown in Figure 8-1, the workspace named ADD-EMPLOYEE-WORKSR\CE passes information from the exchange step to the processing step.
Thsks devdoped using ACMS can use either VAX databases, (VAX DBMS or VAX RdbNMS), or RMS files. If a task uses VAX DBMS recovery actions can be con-trolled by the task definition, further simplifying the devdopment and mainte-nance of the application. ACMS uses VAX DBMS facilities to provide automatic journaling and recovery.
Structuring the task into terminal I/O steps and processing steps makes the task definition easier to understand and maintain. In addition, the separation of ter-minal I/O from processing lets ACMS dedicate different, specialized VAXNMS processes to each kind of work. ACMS system processes can be used to handle the terminal I/O for many users. Another kind of process, called
a
server, is defined to handle the processing steps. A server can be dedicated to computa-tion, database interaccomputa-tion, or other processing work.Server proces~es can be used by many processing steps without having to be started and stopped for each task. A server process can handle the processing step for one task while other tasks do terminal I/O; the same server process can handle processing for a second task while the first task does terminal I/O.
8-6 • VAX ACMS
There are two kinds of servers:
• DCL servers handle images, DCL commands~ TlATATRIEVE commands, DAThTRIEVE procedures, and other processing that can be run froni DCL
command mode. ..
• Procedure servers handle only subroutines written in VAX COBOL, VAX BASIC or other VAX languages.
Procedure servers are more efficient than DCL servers. For example, procedure servers let the application perform work common to many tasks, such as open-ing @es, just once when the server process is started.
Because servers can be used by many tasks, they are defined in a task group definition. The task group defines resources that can be shared by many tasks.
These resources include TDMS request libraries, VMS message files, ACMS workspaces, and servers.
In addition to the ADU clauses for defining tasks and task groups, ACMS pro-vides two facilities to help the application programmer develop ACMS applica-tions. The Task Debugger (ACMSDBG) lets the programmer debug tasks without setting up applications and menus. With the 'Thsk Debugger, an application programmer can start servers and tasks. While a task is running, the program-mer can set breakpoints, examine and change workspace contents, and use the VAX SymbolicDebugger to control processing steps. The commands and quali-fiersare similar to those of the VAX Symbolic Debugger.
Runtime Control and Management
ACMS also provides tools for defining, monitoring, and controlling on-line applications. Although designed to supply the operational environment for tasks defined in ACMS's application development phase, the runtime control and management portion of the product can also be used to monitor and con-trol existing applications running under VAXNMS. So while use of the "full ACMS" product is recommended in the majority of situations, the runtime con-trol and management portion alone is· frequently used to create a runtime sys:
tern on a target node to execute applications developed on a central node.
Using VAX.ACMS involves the following:
• Using menus for. easy access
• Controlling application availability
• Controlling access to applications
• Monitoring application use and performance
8-7
• USING MENUS FOR EASY ACCESS
The central ACMS control and management facility is the Application Defini-tion Utility (ADU). This utility provides a set of English-like clauses for defining menus and for defining the operational characteristics of ACMS applications.
For example, one of the characteristics definable with ADU is which users can select which tasks in an application. These access control lists can be the same for all tasks in an application or can differ from task to task.
Application definitions are stored in the VAX Common Data Dictionary (CDD) so they can be easily maintained and controlled.
• CONTROLLING APPLICATION AVAILABILl1Y
ACMS includes an Operator Facility, a set of commands for controlling applica-tions. For example, with these commands an ACMS operator can start an appli-cation, making its tasks available to users. Or the operator can stop the application so that the tasks are not available and the application does not tie up any system resources. Other ACMS Operator commands display information about applications, tasks, users, and ACMS components. The commands are similar to the VAX/VMS Digital Command Language (DCL) commands an operator would already know.
• CONTROLLING ACCESS 10 APPLICATIONS
The User Definition Utility defines which authorized VAX/VMS users can log in to ACMS. It also defines which menu the user sees upon logging in to ACMS or, alternatively, defines the user as an experienced one who sees a selection prompt rather than a menu after logging in.
The Device Definition Utility specifies which terminals can access ACMS and whether or not those terminals log directly in to ACMS. With these utilities, users and terminals can be restricted to ACMS, restricted to VAXlVMS, or given access to both ACMS and VAXlVMS. The utilities are similar to the AUTHOR-IZE Utility, the system management tool provided by VAXlVMS for authorizing VMS users.
Although ACMS provides a standard menu format, the format can be modified to suit the needs of different terminal users. In addition, terminal users can select tasks by typing entry names after the "Selection:" prompt, without dis-playing menus. Certain terminal user commands provided as part of the termi-nal user interface let users display or bypass menus. Other termitermi-nal user commands let users get help on using ACMS menus, cancel active tasks, and exit
fromACMS.·-~~8 • VAX ACM5
• MONITORING APPLICATION USE AND PERFORMANCE
This ACMS component helps ACMS operators and application managers moni-tor the use of ACMS. An Audit 1laillogging facility gathers information about task selections, user logins, and other events. It records this information in a log file. You can then use the Audit 1lail Report Utility to take information from the log file and format it into a report. The report can include all information from the file; it can also be selective, including information about only one user, for example. Similarly, the information gathered by the Audit Trail logging facility can include all applications or can be restricted to one or more applications ..
Another component integral to ACMS, ACMSGEN lets system managers change ACMS system parameters, such as how many users can log in, the user names under which ACMS processes run, and the priorities of those processes .
• ACMS RUNTIME SYSTEM
The final major component of VAX ACMS is the runtime system itself, which uses specialized VAX/VMS processes to handle the menus and tasks in ACMS applications.
Chapter 9
0VAX DECgraph
VAX DECgraph is the VAX Information Architecture's interactive, menu-driven tool for generating graphs from data. It is designed to be used by experienced computer users and novices alike, offering a wide spectrum of capabilities for producing professional quality graphs.
With VAX DECgraph, you can:
o Begin creating your own graphs successfully in approximately one hour.
o See the results of your graph designing immediately - make changes interac-tively at any point in the design process.
o Obtain data for your graphs in anyone of three ways: from a database, from a formatted ASCII file, or through keyboard data entry.
o Produce six different basic types of graphs.
• Enhance your graphs with additi~nal "fine-tuning" features.
o Print, photograph, or send your output to other graphics terminal users.
o Use your graphs for reports, presentations, or "on the spot" decision support.