The default format for ACMS menus is set by the MENU_REQUEST request, which is included in the SYS$LIBRARY:ACMSREQ.RLB request library file. You must change the menu request if you want to:

• Change the names of fields in the form
• Add or remove input or output fields in the form
• Change the number of entries on the form
• Define program request keys available to users from the menu

Suppose you want to include a company logo on the menu and restrict that form to 12 entries. You also want to provide a program request key that would be equivalent to the terminal user MENU and NOMENU commands. First redefine the form, keeping the output fields for the entry information as an indexed array. If you kept the form field names the same, the new request, called NEW_MENU_REQUEST, would be like the one shown in Example B-6.

Example B-6 Customized Menu Request

CREATE REQUEST NEW_MENU_REQUEST RECORD IS MENU_HEADER_RECORD; RECORD IS MENU_ENTRY_12_RECORD; RECORD IS MENU_CONTROL_RECORD; RECORD IS MENU_SELECTION_RECORD; FORM IS NEW_MENU_FORM; FORM IS EXPERT_MENU_FORM; KEYPAD IS APPLICATION; PROGRAM KEY IS KEYPAD "0" NO CHECK; RETURN "$MENU" TO SELECTION_STRING_1; END PROGRAM KEY; PROGRAM KEY IS KEYPAD "." NO CHECK; RETURN "$NOMENU" TO SELECTION_STRING_1; END PROGRAM KEY; CONTROL FIELD IS CTL_EXPERT_MENU "T": USE FORM EXPERT_MENU_FORM; DEFAULT FIELD SELECTION_STRING_1; DEFAULT FIELD SELECTION_STRING_2; INPUT SELECTION_STRING_1 TO SELECTION_STRING_1; INPUT SELECTION_STRING_2 TO SELECTION_STRING_2; NOMATCH: CONTROL FIELD IS CTL_NEW_ENTRIES "T": DISPLAY FORM NEW_MENU_FORM; OUTPUT MENU_HEADER_1 TO MENU_HEADER_1; OUTPUT MENU_HEADER_2 TO MENU_HEADER_2; CONTROL FIELD IS ENTRY_FLAG [1 TO 12] " ": WAIT; NOMATCH: OUTPUT ENTRY_NUMBER [%LINE] TO ENTRY_NUMBER [%LINE]; OUTPUT ENTRY_KEY [%LINE] TO ENTRY_KEY [%LINE]; OUTPUT ENTRY_FLAG [%LINE] TO ENTRY_FLAG [%LINE]; OUTPUT ENTRY_TEXT [%LINE] TO ENTRY_TEXT [%LINE]; END CONTROL FIELD; CONTROL FIELD IS CTL_MULTI_PAGE "T": CONTROL FIELD IS CTL_LAST_PAGE "T": OUTPUT " ....... Press <RET> for first page ......." to MENU_MORE; NOMATCH: OUTPUT " ....... Press <RET> for more ......." to MENU_MORE; END CONTROL FIELD; END CONTROL FIELD; INPUT SELECTION_STRING_1 TO SELECTION_STRING_1; INPUT SELECTION_STRING_2 TO SELECTION_STRING_2; NOMATCH: USE FORM NEW_MENU_FORM; DEFAULT FIELD SELECTION_STRING_1; DEFAULT FIELD SELECTION_STRING_2; INPUT SELECTION_STRING_1 TO SELECTION_STRING_1; INPUT SELECTION_STRING_2 TO SELECTION_STRING_2; END CONTROL FIELD; END CONTROL FIELD; END DEFINITION;

The changes to the menu request are:

• Replacing MENU_FORM by NEW_MENU_FORM throughout the definition
• The NEW_MENU_FORM definition should include only 12 indexed fields
• Changing the indexed array output from 16 records to 12 records
• Changing the keypad to APPLICATION and adding two program request keys

If you want all menus in the ACMS system to use the revised menu format, use the name MENU_REQUEST for the revised request and MENU_FORM for the revised form. In the definition for every menu using this new request you must include the clause:

REQUEST IS MENU_REQUEST WITH 12 ENTRIES;

Including this clause in the menu definition tells ACMS to display the menu using the request for the customized menu. You must also rebuild the request library, as explained in Section B.2.8.

However, if you want some menus to use the default ACMS format and others use the new format, you must:

1. Create the new form, assigning a name other than MENU_FORM to the form you have created.
2. Create a copy of the menu request, assigning a name other than MENU_REQUEST.
3. Replace the FORM IS MENU_FORM instruction in the new menu request with an instruction that names your new form.
4. Include the new request in the menu library definition and rebuild the request library, as explained in Section B.2.8.

Then use the REQUEST clause in the definitions for any menus that you want to use the new format, declaring the name of the new request. Also declare the number of entries for the menu if the number is other than the default value of 16. The next section explains the REQUEST clause.

B.2.6 Using the REQUEST Clause

When you use the REQUEST clause in a menu definition, you are telling ACMS to use a request other than MENU_REQUEST for that menu.

Example B-7 shows an example of a menu definition that uses the REQUEST clause.

Example B-7 Menu Definition Using REQUEST Clause

CREATE MENU PERSONNEL_MENU HEADER IS " P E R S O N N E L M E N U"; REQUEST IS PERSONNEL_MENU_REQUEST WITH 12 ENTRIES PER SCREEN; DEFAULT APPLICATION IS "PERSONNEL"; ENTRIES ARE ADD : TASK IS ADD_EMPLOYEE; TEXT IS "Add a new employee record"; . . . END ENTRIES; END DEFINITION;

In the REQUEST clause, you must include the given name of the request you want ACMS to use for that menu. This is not the CDD path name of the request, but the name by which the request is listed in the request library definition.

If you want more or less than 16 entries on each screen, you must use the WITH ENTRIES PER SCREEN phrase to define the number of entries you want. You must also define a request to handle that many entries. You can change the number of entries only if you have defined a request that is different from the ACMS-supplied request. You cannot use the WITH ENTRIES PER SCREEN phrase to change the number of entries that display on the menus supplied by ACMS, unless you modify the request.

You can include more entries in the menu definition than the number you specify in the WITH ENTRIES PER SCREEN phrase. For example, you could include 13 or more entries in the menu definition shown in Example B-7 even though the WITH ENTRIES PER SCREEN phrase specifies 12 entries for each screen. In this case, when ACMS displays the menu it also displays the message:

"....... Press <RET> for more .......".

If the user presses [Return], ACMS displays the additional entries listed in the menu definition.

You can include the REQUEST clause in any menu definition. If you want two menus with the same format, and that format is different from the ACMS default format, you must include the REQUEST clause in both definitions.

You can also use different menu requests in different menu definitions. There is no restriction on the number of menu requests for each ACMS system, but using different menu requests for different menu definitions can decrease ACMS system performance.

B.2.7 Changing the MENU_ENTRY_RECORD

If you decrease the number of entries displayed by the request, you do not have to change any of the records passed to the request. However, if you increase the number of entries, you must also change the definition for the record, MENU_ENTRY_RECORD, that ACMS passes to the request.

The number used in the LINE STRUCTURE statement in the record definition must be the same as or larger than the number of entries displayed by the request. ACMS passes only as many entries in MENU_ENTRY_RECORD as the menu definition specifies, regardless of the size of MENU_ENTRY_RECORD. However, if MENU_ENTRY_RECORD is smaller than the number of entries specified by the menu definition, the request can get access violation errors when it tries to read the record.

The MENU_ENTRY_RECORD description is included in the ACMSREQ.BAK file. When you restore that file to the CDD, the MENU_ENTRY_RECORD description is loaded into the same directory as MENU_FORM and MENU_REQUEST. Extract that description from the CDD, putting it in a text file. Then change the record description to match the number of entries in the menu request. Example B-8 shows the record description for a MENU_ENTRY_RECORD containing 12 entries.

Example B-8 Record Definition for MENU_ENTRY_RECORD with 12 Entries

DEFINE RECORD MENU_ENTRY_RECORD DESCRIPTION IS /* RECORD FOR THE ACMS MENU ENTRY INFO */. MENU_ENTRY_RECORD STRUCTURE. LINE STRUCTURE OCCURS 12 TIMES. ENTRY_NUMBER DATATYPE TEXT 2. ENTRY_KEY DATATYPE TEXT 10. ENTRY_FLAG DATATYPE TEXT 1. ENTRY_TEXT DATATYPE TEXT 50. END LINE STRUCTURE. END MENU_ENTRY_RECORD STRUCTURE. END MENU_ENTRY_RECORD.

The only item you should ever change in this record definition is the decimal number in the "LINE STRUCTURE OCCURS n TIMES" statement.

When you have edited the file, use the Common Data Dictionary Data Definition Language (CDDL) Utility to write the new record definition into the CDD. Use a different name for the new record definition and in the request definition; in that case, you must use the same name when referring to the record definition from the request. If all your menus use the same or fewer entries than the number used in the new record definition, you can delete the existing MENU_ENTRY_RECORD definition from the CDD and use the same name for the new record. You can then use the CDDL Utility to write the new MENU_ENTRY_RECORD definition into the CDD. For information on storing definitions in the CDD, refer to the CDD documentation.

Although you can change the name of MENU_ENTRY_RECORD, you cannot include additional records in a menu request. Each menu request must use only four records, in the order in which they occur in MENU_REQUEST. Do not change the definitions for the other menu records. However, you can include additional forms in the request, such as when you use a conditional request.

If you change the name of the MENU_ENTRY_RECORD in the CDD, be sure to change the name in the request as well. Also, when you modify the menu form and request definition, or when you reload the record description into the CDD, be sure that you use the same CDD directory for all three definitions.

B.2.8 Modifying and Building the ACMS Menu Request Library

Once you have changed the menu form and, if necessary, the menu request and record, you have to rebuild the menu request library.

If you have created a new menu request, use the TDMS Request Definition Utility (RDU) to add to MENU_LIBR the request you have created. Example B-9 shows a MENU_LIBR request library definition that includes all the requests that ACMS supplies and an additional menu request called NEW_MENU_REQUEST.

Example B-9 MENU_LIBR Request Library Definition

REQUEST IS COMD_REQUEST; REQUEST IS MENU_REQUEST; REQUEST IS RESET_SCREEN; REQUEST IS CLEAR_SCREEN; REQUEST IS NEW_MENU_REQUEST; END DEFINITION;

The request name you use in the REQUEST clause of the menu definition must be the name of the request in the run-time version of the request library. By default, the run-time name of the request is the same as the CDD given name of the request as it is used in the request library definition. However, in the REQUEST IS instructions of the request library definition you can include a WITH NAME phrase to assign a unique name to the new menu request. In this case, you must use the same unique name in the REQUEST clause of the menu definition.

To edit the request library definition, either modify the definition directly in the CDD or extract the definition, revise it, and then reload it into the CDD. Once you have edited the request library definition, you can build the request library.

Before building the library, make sure that the request definition, form definition, record definition, and request library definition are all in the CDD directory in which you restored the contents of the ACMSREQ.BAK file. Then use the RDU BUILD command from TDMS :

$ RUN SYS$SYSTEM:RDU RDU> BUILD LIBRARY MENU_LIBR ACMSREQ.RLB /LIST=ACMSREQ.LIS RDU> EXIT

For explanations of the BUILD command and of the error messages you get, see VAX TDMS Request and Programming Manual.

If the BUILD command is successful, move the new menu request library to the SYS$LIBRARY directory. Instead of putting the request library into SYS$LIBRARY, you can redefine the logical name ACMS$REQLIB to point to the request library. This name must be defined either as a system logical name or as a group logical name, in the same group as the user name under which the ACMS Command Process (CP) is running. (See Compaq ACMS for OpenVMS Getting Started for an explanation of the command process.) Redefining ACMS$REQLIB makes it easy to switch back to the existing menu request library if you discover problems with the new one.

You can then build the menu definition pointing to the new request and try using the new menu. In order to make the new version of the menu request library available to the command process, you must stop and restart the ACMS terminal subsystem, as by using the ACMS/START TERMINALS and ACMS/STOP TERMINALS commands. Make sure your ACMS user definition points to the menu database containing the menu that uses the new menu format. Then sign in to ACMS and check whether or not:

• You can select the menu.
• The menu has the correct number of entries.
• You can select the entries.
• The fields are in the correct places.
• The cursor moves from field to field in the correct order.

If ACMS cannot display the new menu, you get this error message when signing in to ACMS:

Error while trying to display menu -- bad MDB.

If you get this message, make sure you have put the request library in SYS$LIBRARY or that the system logical name ACMS$REQLIB is pointing to the directory that contains the menu request library. If the library is there, check the record, form, request, and library definitions for unmatched names, unmatched CDD locations, inappropriate file protection, or differences in the number of entries.

B.3 Disabling the SELECT Command in the ACMS Command Menu

The SELECT command appears on the ACMS Command Menu and permits a user to select tasks by application and task name. In order to disable the SELECT command, you need to remove it from the ACMS Command Menu by editing and replacing the command menu definitions, and rebuilding the command database, as follows:

1. Rename the file SYS$LIBRARY:ACMS$MENU_CUST.COM to ACMSMENU.COM. This file contains the ACMS command menu and the ACMS default menu.
2. Edit the file ACMSMENU.COM and delete or comment out the SELECT command entry. The exclamation points (!) in the following example mark the lines you need to comment out or delete.

   REQUEST IS COMD_REQUEST WITH 8 ENTRIES; HEADER IS " ACMS Command Menu"; ENTRIES ARE "Continue": TEXT IS "Continue interrupted operation"; COMMAND 3; "Exit": TEXT IS "Leave the ACMS menu environment"; COMMAND 8; "Help": TEXT IS "Display ACMS help information on the terminal"; COMMAND 17; "Menu": TEXT IS "Display selection and command menus"; COMMAND 18; "Nomenu": TEXT IS "Do not display selection and command menus"; COMMAND 19; !"Select": ! TEXT IS "Select task by application name and task name"; ! COMMAND 20; END ENTRIES; END DEFINITION;

3. Change the CDD path names specified in ACMSMENU.COM to be the CDD path name of your choice.
4. Use the following ADU commands to insert the definition file ACMSMENU.COM in the CDD:

   $ ADU ADU> @ACMSMENU.COM

5. Use the following ADU commands to rebuild the ACMS command menu database:

   $ ADU ADU> BUILD MENU COMMAND$ROOT ACMS$DIRECTORY:ACMSCMD.MDB ADU> EXIT

Chapter 1 describes using the ADU utility to place ACMS definitions in the CDD. In some ACMS applications, you may want to track relationships among ACMS entities in the CDD.

C.1 Overview of Dictionary Object Types

The CDD dictionary allows you to see the relationships among entities. You can only create relationships for ACMS entities that are in CDO format. You cannot track DMU format objects. Some relationships are established automatically; for example, if you create an Rdb record entity, the relationship between the record and each of its fields is defined for you. For ACMS entities, you must define the relationships using the CDO Utility.

To define relationships you need to know more about the three distinct types of dictionary objects in CDD:

• Entity
  An entity is the dictionary object that contains the definition of, for example, an ACMS task definition or an Rdb record. You use ADU commands to create entities for ACMS applications, menus, tasks, and task groups. Use the CDO Utility to create any other ACMS dictionary entities needed to create relationships. You must create dictionary entities for your ACMS definitions and for the database objects required by your ACMS applications.
• Relationship
  A relationship is the dictionary object that links two entities, modeling a functional link between the application objects those entities describe. For example, you can create a relationship that links a task group to an application, and one that links the task group to a task. You can create relationships only with the CDD CDO Utility. If you do not want to do pieces tracking, you do not need to create relationships.
• Attribute
  An attribute describes a specific characteristic of a CDD entity or relationship. Attributes are the basic units of information contained in a CDD dictionary. You do not need to create attributes for ACMS dictionary entities or relationships.

Within the dictionary, each particular entity is identified by the name you give it and by a predefined protocol name for each type of entity.

Protocols govern the use of the dictionary objects. A protocol is a set of rules controlling the entities, relationships, and attributes of an item in the dictionary (for example, an ACMS task definition or an Rdb record). If you plan to use the dictionary without pieces tracking, you need not concern yourself with protocols; the dictionary automatically associates your ACMS definition with the appropriate protocol. However, if you plan to do pieces tracking, you must use protocols as you:

• Create ACMS entities needed for pieces tracking that cannot be created from ADU
• Define relationship between entities for which relationship protocols exist

Section C.2 describes how to use CDO to create relationships for pieces tracking.

The CDO DIRECTORY command lists the entities within the current dictionary directory. The left column lists the specific entities by name. The right column lists the protocol for each type of entity listed to the left. For example:

1. Use the ADU REPLACE TASK command to create a dictionary entity for your TASK_ADD definition, and one for your TASK_UPDATE definition.
2. Use the CDO DIRECTORY command at the dictionary directory where you placed TASK_ADD. CDO lists the entity name on the left and the protocol for that type of entity on the right:

   . . . . . . TASK_ADD ACMS$TASK TASK_UPDATE ACMS$TASK . . . . . .

CDD contains protocols for all ACMS entity types and ACMS relationship types. When you use an ADU command to place an ACMS definition in CDD, the dictionary automatically associates the entity with one of the following four protocols:

• ACMS$APPLICATION --- for an ACMS application definition
• CDO$MENU --- for an ACMS menu definition
• ACMS$TASK --- for an ACMS task definition
• ACMS$TASK_GROUP --- for an ACMS task group definition

Although ADU commands create application, menu, task, and task group entities, you may need other ACMS dictionary entities to create relationships. If you want to do pieces tracking, you must use the CDO Utility to:

1. Define all other entities needed to establish a relationship, associating each entity with a predefined protocol for that entity type.
   For example, if you use the command ADU REPLACE GROUP MYGROUP, MYGROUP automatically enters CDD as the MYGROUP entity, based on the ACMS$TASK_GROUP protocol. In this example, you establish relationships between the MYGROUP entity and:
   • Server entities, based on the ACMS$SERVER protocol
   • Record entities, based on the CDD$DATA_AGGREGATE protocol
   • A .TDB or .RLB file entity, based on the CDD$FILE protocol
   • Task entities, based on the ACMS$TASK protocol
   
   In this example, only the task and group entities can be created through the ACMS ADU commands. You must create the other entities through the CDO Utility.
   Use CDO DEFINE GENERIC to create an ACMS dictionary entity other than the four that are created automatically (that is, other than application, menu, task, and task group).

   CDO> DEFINE GENERIC ACMS$SERVER MYSERVER CDO> CDD$PROCESSING_NAME 'MYSERVER'. CDO> END ACMS$SERVER MYSERVER.

   
   Refer to the CDD documentation for complete syntax for this command.

2. Define relationships between entities for which relationship protocols exist.
   You must define all relationships through the CDO Utility. Each relationship consists of an owner and a member. For example, a task entity is the owner and a task procedure item is the member in a relationship between a task and a task procedure item. You can create relationships only between entities for which CDD supplies a relationship protocol. See Table C-1 for a list of all the protocols used to create relationships between ACMS entities, and the entities which can be connected by these relationships.
   You use the CDO DEFINE GENERIC or CDO CHANGE GENERIC commands to create relationships between specific instances of ACMS dictionary entities. DEFINE GENERIC allows you to create both the entity and the relationship to another entity. CHANGE GENERIC creates a relationship between already existing entities, or changes the relationship to connect to a different member entity. The CDO CHANGE GENERIC syntax is:

   CDO> CHANGE GENERIC protocol-name entity-name. DEFINE relationship-name cont> relationship-mbr END relationship-name DEFINE.

   
   For example:

   CDO> CHANGE GENERIC ACMS$TASK_GROUP MYGROUP. DEFINE cont> ACMS$TASK_GROUP_SERVER MYSERVER. END cont> ACMS$TASK_GROUP_SERVER DEFINE. cont> END MYGROUP ACMS$TASK_GROUP

   
   See the CDD documentation set for complete syntax and for the CDO CHANGE GENERIC command.
   A description of the parts of this command follows:

   • ACMS$TASK_GROUP is the protocol name of the owner entity in the relationship.
   • MYGROUP is the name you gave the task group entity. This entity was created and associated with ACMS$TASK_GROUP when you placed the MYGROUP task group definition in the dictionary.
   • ACMS$TASK_GROUP_SERVER is the CDD protocol for a relationship between a task group entity and a server entity in that task group.
   • MYSERVER is the name of an ACMS server entity you created with the CDO DEFINE GENERIC command. MYSERVER is the member entity in the relationship. MYSERVER must be based on the ACMS$SERVER protocol. Only an entity based on the ACMS$SERVER protocol can be used to create a relationship between the task group and server entities.

Relationships are always one-to-one, but you can establish multiple relationships for any entity. For example, you can create a relationship between an ACMS menu entity and an ACMS task entity, or between the same task entity and a DECforms form entity. You can then use CDO commands such as SHOW USES and SHOW USED_BY to do pieces tracking.

If you create a relationship and subsequently change the member entity, CDD assigns a message to the owner entity. At the next use of the owner entity, ADU informs you that there are messages pending for the owner entity. This situation can occur after you create a relationship between a task and a task group. For example, if you change a task in task group RMS_GROUP and then build the group, ADU issues the message:

Object RMS_GROUP has CDD messages

See the CDD documentation set for complete information about these commands.

The left column of Table C-1 lists all the dictionary protocols for ACMS entities. The table also lists the protocols for entities eligible for relating to any entities of each protocol in the left column. Finally, the table lists the relationship protocols you can use to relate the eligible entities.

Table C-1 CDD Protocols for ACMS Entity and Relationship Objects

Protocol for Entity of This Type
ACMS$APPLICATION	Entities of this protocol defined by ADU commands in ACMS application definition.
	Owns Entities with Protocol:	By Relationship:
	ACMS$APPL_TASK_ITEM	ACMS$APPLICATION_TASK
	ACMS$TASK_GROUP	ACMS$APPLICATION_TASK_GROUP
	ACMS$APPL_SERVER_ITEM	ACMS$APPLICATION_SERVER
	$CDD$FILE	ACMS$APPLICATION_ADB_FILE
	Member of Entity with Protocol:	By Relationship:
	ACMS$MENU_TASK_ITEM	ACMS$MENU_TASK_APPL
ACMS$APPL_SERVER_ITEM	Entities of this protocol defined through CDD CDO Utility. Defined by server and group that server is in.
	Owns Entities with Protocol:	By Relationship:
	ACMS$SERVER	ACMS$APPLICATION_SRV_SRV
	ACMS$TASK_GROUP	ACMS$APPLICATION_SRV_GRP
	Member of Entity with Protocol:	By Relationship:
	ACMS$APPLICATION	ACMS$APPLICATION_SERVER
ACMS$APPL_TASK_ITEM	Entities of this protocol defined through CDD CDO Utility. Defined by task name and group in which task appears.
	Owns Entities with Protocol:	By Relationship:
	ACMS$TASK	ACMS$APPLICATION_TASK_TSK
	ACMS$TASK_GROUP	ACMS$APPLICATION_TASK_GROUP
	Member of Entity with Protocol:	By Relationship:
	ACMS$APPLICATION	ACMS$APPLICATION_TASK
	ACMS$MENU_TASK_ITEM	ACMS$MENU_TASK_TASK
CDD$MENU	Entities of this protocol defined by ADU commands in ACMS menu definition.
	Owns Entities with Protocol:	By Relationship:
	ACMS$MENU_TASK_ITEM	ACMS$MENU_TASK
	CDD$FILE	ACMS$MENU_MDB_FILE
	CDD$MENU	ACMS$MENU_CONTAINS
	Member of Entity with Protocol:	By Relationship:
	CDD$MENU	ACMS$MENU_CONTAINS
ACMS$PROCEDURE	Entities of this protocol defined through CDD CDO Utility.
	Owns Entities with Protocol:	By Relationship:
	CDD$EXECUTABLE_IMAGE	ACMS$PROCEDURE_ENTRY_PT
	CDD$PROCEDURE	ACMS$PROCEDURE_ENTRY_PT
	Member of Entity with Protocol:	By Relationship:
	ACMS$SERVER	ACMS$SERVER_ABORT_PROCEDURE
	ACMS$SERVER	ACMS$SERVER_ACTION_PROCEDURE
	ACMS$SERVER	ACMS$SERVER_EXIT_PROCEDURE
	ACMS$SERVER	ACMS$SERVER_INIT_PROCEDURE
	ACMS$TASK_PROCEDURE_ITEM	ACMS$PROCEDURE_PROCEDURE
Protocol for Entity of This Type
ACMS$SERVER	Entities of this protocol defined through CDD CDO Utility.
	Owns Entities with Protocol:	By Relationship:
	ACMS$PROCEDURE	ACMS$SERVER_ABORT_PROCEDURE
	ACMS$PROCEDURE	ACMS$SERVER_ACTION_PROCEDURE
	ACMS$PROCEDURE	ACMS$SERVER_EXIT_PROCEDURE
	ACMS$PROCEDURE	ACMS$SERVER_INIT_PROCEDURE
	ACMS$SERVER	ACMS$SERVER_BASED_ON
	CDD$COMPILED_MODULE	ACMS$SERVER_MODULE
	Member of Entity with Protocol:	By Relationship:
	ACMS$APPL_SERVER_ITEM	ACMS$APPLICATION_SRV_SRV
	ACMS$SERVER	ACMS$SERVER_BASED_ON
	ACMS$TASK_GROUP	ACMS$TASK_GROUP_SERVER
	ACMS$TASK_PROCEDURE_ITEM	ACMS$_PROCEDURE_SERVER
ACMS$TASK	Entities of this protocol defined by ADU commands in ACMS task definition.
	Owns Entities with Protocol:	By Relationship:
	ACMS$TASK	ACMS$TASK_BASED_ON
	ACMS$TASK_TASK_ITEM	ACMS$TASK_TASK
	ACMS$TASK_PROCEDURE_ITEM	ACMS$TASK_PROCEDURE
	CDD$VIDEO_DISPLAY	ACMS$TASK_VIDEO_DISPLAY
	CDD$DATA_AGGREGATE	ACMS$TASK_DATA_AGGREGATE
	Member of Entity with Protocol:	By Relationship:
	ACMS$APPL_TASK_ITEM	ACMS$APPLICATION_TASK_TSK
	ACMS$TASK	ACMS$TASK_BASED_ON
	ACMS$TASK_GROUP	ACMS$TASK_GROUP_TASK
	ACMS$TASK_TASK_ITEM	ACMS$TASK_ITEM_TASK
Protocol for Entity of This Type
ACMS$TASK_GROUP	Entities of this protocol defined by ADU commands in ACMS task group definition.
	Owns Entities with Protocol:	By Relationship:
	ACMS$TASK	ACMS$TASK_GROUP_TASK
	ACMS$TASK_GROUP	ACMS$TASK_GROUP_BASED_ON
	ACMS$SERVER	ACMS$TASK_GROUP_SERVER
	CDD$FILE	ACMS$TASK_GROUP_MSG_FILE
	CDD$FILE	ACMS$TASK_GROUP_TDB_FILE
	CDD$VIDEO_DISPLAY	ACMS$TASK_GROUP_VIDEO_DISPLAY
	CDD$DATA_AGGREGATE	ACMS$TASK_GROUP_DATA_AGG
	Member of Entity with Protocol:	By Relationship:
	ACMS$APPLICATION	ACMS$APPLICATION_TASK_GROUP
	ACMS$APPL_SRV_ITEM	ACMS$APPL_SRV_GRP
	ACMS$APPL_TASK_ITEM	ACMS$APPLICATION_TASK_GRP
	ACMS$TASK_GROUP	ACMS$TASK_GROUP_BASED_ON
Protocol for Entity of This Type
ACMS$TASK_PROCEDURE_ITEM	Entities of this protocol defined through CDD CDO Utility. Defined by procedure and server for that procedure.
	Owns Entities with Protocol:	By Relationship:
	ACMS$PROCEDURE	ACMS$PROCEDURE_PROCEDURE
	ACMS$SERVER	ACMS$PROCEDURE_SERVER
	CDD$DATA_AGGREGATE	ACMS$PROCEDURE_DATA_AGGREGATE
	Member of Entity with Protocol:	By Relationship:
	ACMS$TASK	ACMS$TASK_PROCEDURE
ACMS$TASK_TASK_ITEM	Entities of this protocol defined through CDD CDO Utility. Defined by task renamed in group, and task arguments.
	Owns Entities with Protocol:	By Relationship:
	ACMS$TASK	ACMS$TASK_ITEM_TASK
	CDD$DATA_AGGREGATE	ACMS$TASK_ITEM_DATA_AGGREGATE
	Member of Entity with Protocol:	By Relationship:
	ACMS$TASK	ACMS$TASK_TASK
CDD$COMPILED MODULE	Entities of this protocol defined through CDD CDO Utility.
	Owns Entities with Protocol:	By Relationship:
	CDD$EXECUTABLE_IMAGE	CDD$IMAGE_DERIVED_FROM
	Member of Entity with Protocol:	By Relationship:
	ACMS$SERVER	ACMS$SERVER_MODULE
Protocol for Entity of This Type
CDD$EXECUTABLE_IMAGE	Entities of this protocol defined through CDD CDO Utility.
	Owns Entities with Protocol:	By Relationship:
	none
	Member of Entity with Protocol:	By Relationship:
	ACMS$PROCEDURE	ACMS$PROCEDURE_ENTRY_PT
	CDD$COMPILED_MODULE	CDD$IMAGE_DERIVED_FROM
CDD$FILE	Entities of this protocol defined through CDD CDO Utility.
	Owns Entities with Protocol:	By Relationship:
	none
	Member of Entity with Protocol:	By Relationship:
	ACMS$APPLICATION	ACMS$APPLICATION_ADB_FILE
	CDD$MENU	ACMS$MENU_MDB_FILE
	ACMS$TASK_GROUP	ACMS$TASK_GROUP_TDB_FILE
	ACMS$TASK_GROUP	ACMS$TASK_GROUP_MSG_FILE
CDD$PROCEDURE	Entities of this protocol defined through CDD CDO Utility.
	Owns Entities with Protocol:	By Relationship:
	none
	Member of Entity with Protocol:	By Relationship:
	ACMS$PROCEDURE	ACMS$PROCEDURE_ENTRY_PT
CDD$VIDEO_DISPLAY	Defined by
	Owns Entities with Protocol:	By Relationship:
	CDD$VIDEO_DISPLAY	ACMS$VIDEO_DISPLAY_BASED_ON
	Member of Entity with Protocol:	By Relationship:
	ACMS$TASK	ACMS$TASK_VIDEO_DISPLAY
	ACMS$TASK_GROUP	ACMS$TASK_GROUP_VIDEO_DISPLAY
CDD$DATA_AGGREGATE	Defined by
	Owns Entities with Protocol:	By Relationship:
	CDD$DATA_AGGREGATE	CDD$DATA_AGGREGATE_BASED_ON
	Member of Entity with Protocol:	By Relationship:
	ACMS$TASK	ACMS$TASK_DATA_AGG
	ACMS$TASK_GROUP	ACMS$TASK_GROUP_DATA_AGG
	ACMS$TASK_PROCEDURE_ITEM	ACMS$TASK_PROCEDURE_ITEM_DATA_AGG
	ACMS$TASK_TASK_ITEM	ACMS$TASK_ITEM_DATA_AGG
	CDD$DATA_AGGREGATE	CDD$DATA_AGGREGATE_BASED_ON