Establishes a connection to a stream and returns a connect ID. Before using this service, you have to create a stream with ACMS$CREATE_STREAM.
ACMS$CONNECT_STREAM (stream.id.rq.r,
mode.rl.r,
connect.id.wq.r,
[submitter.id.rq.r])
ACMS$CONNECT_STREAM_A (stream.id.rq.r,
mode.rl.r,
connect.id.wq.r,
[comp_status.wq.r],
[efn.rbu.r],
[astadr.szem.r],
[astprm.rz.v],
[submitter_id.rq.r])

4.4.3 ACMS$CREATE_STREAM

4.4.4 ACMS$DELETE_STREAM

4.4.5 ACMS$DISCONNECT_STREAM

4.4.6 ACMS$OPEN_RR

Figure A-1 illustrates the phases of application development for ACMS, from the initial design of an application to the actual production of the application. Figure A-1 is followed by a more detailed checklist of the phases of application development you can use with the figure.

Figure A-1 ACMS Application Design, Development, and Use

1. Design application
   • Analyze business
   • Design application
   • Create preliminary definition and other specifications
2. Set up data
   RMS:
   • Define the records (CDO)
   • Create the files (RMS utilities or DCL commands)
   
   DBMS:
   • Define the schema, subschema, storage schema (DDL)
   • Create the database (DBO)
   
   Rdb:
   • Define the records and their relationships (SQL or RDO)
   • Create the database (SQL or RDO)
3. Define tasks
   • Create task definitions (ADU)
4. Create workspaces
   • Create a file containing record definition (editor)
   • Store the definition in the data dictionary (CDO)
5. Create DECforms forms
   • Create the panel using the panel editor (FDE)
   • Edit the IFDL file
   • Translate the IFDL file to the FORM file (IFDL translator)
6. Create TDMS forms
   • Define background text, input and output fields (FDU)
   • Define the help form (FDU)
7. Create TDMS requests
   • Define a request (RDU)
   • Define a request library (RDU)
   • Build the request library (RDU)
8. Write procedures
   • Write and compile step procedures
   • Write and compile initialization and termination procedures for each procedure server
   • Write and compile cancel procedures
9. Create message files
   • Create message source files (editor or DCL)
   • Generate object modules (OpenVMS Message Utility)
   • Generate executable message files (DCL LINK command)
10. Create task groups
    • Define the task group including tasks and servers (ADU)
    • Build the task group using the /DEBUG qualifier (ADU)
11. Create the procedure server image
    • Link the task group transfer module, the message file object module, and the object modules for step procedures, cancel procedures, and initialization and termination procedures (LINK/DEBUG command)
12. Debug
    • Run tasks under ACMS Task Debugger and OpenVMS Symbolic Debugger
    • Revise definitions and programs and test again
13. Set up the application
    • Create the application definition (ADU)
    • Build the application database (ADU)
14. Move the application database to ACMS$DIRECTORY
    • Use the DCL COPY command
    • Or, create the application authorization definition (AAU) and use the ACMS/INSTALL command
15. Set up menus
    • Create menu definitions (ADU)
    • Build the menu database (ADU)
16. Test the application
    • Start the application and run tasks to test implementation
17. Authorize users
    • Authorize users for access to OpenVMS (OpenVMS Authorize Utility)
    • Authorize users for access to ACMS, assign the menu database and initial the menu (UDU)
18. Authorize terminals
    • Authorize terminals for access to ACMS (DDU)
    • Define whether terminals are controlled by ACMS or OpenVMS (DDU)
19. Manage and tune the application
    • Start and stop application
    • Monitor and tune application
    • Modify application, servers, tasks, and menus as necessary

Application development is a cyclical process. Omissions or problems in the analysis or design might not show up until implementation is complete. To correct these omissions or problems, you might need to redo part of the design and implementation. For this reason, it is helpful to understand what parts of an application have to change if you change some other part.

Table B-1 summarizes these relationships between different parts of ACMS applications.

Table B-1 Changing ACMS Applications

Changed Component	Changes to Related Components	When Change Takes Effect
Menu database name (.MDB)	User definitions (in ACMSUDF.DAT file) pointing to menu database must be changed.	Next time user signs in to ACMS.
	Menu definitions should be changed if they include a clause naming database file.	When user signs in after menu database is rebuilt.
Menu definition	Menu database containing that definition must be rebuilt. New database must be put in directory pointed to by ACMSUDF.DAT records (usually ACMS$DIRECTORY).	When user signs in after menu database is rebuilt.
Application database name (.ADB)	Menu definitions pointing to tasks in that application must be changed and menu database rebuilt.	When user signs in after menu database is rebuilt.
	Application authorization definitions must be modified to reflect new application name.	When application database is reinstalled with ACMS/INSTALL command.
Application definition	Application database must be rebuilt. Menu definition database does not need to be changed unless name of task is changed in application definition.	When application is stopped and restarted.
	If changes to application definition conflict with existing authorization for application in ACMSAAF.DAT, authorization must be modified and application database reinstalled with ACMS/INSTALL command.	When application is moved to ACMS$DIRECTORY with ACMS/INSTALL command.
Task group database name (.TDB)	Application definition must be changed and rebuilt. Task group definition should be changed and rebuilt if it points to task group database file.	When application is stopped and restarted.
Task group definition	Task group database must be rebuilt.	When application is stopped and restarted.
	If a task was added or removed, the application database must be rebuilt, even if no change is required in application definition.
	If a task is removed or a task name changed, menu definition pointing to task must be changed. In addition, the menu database and application database must be rebuilt. If the task removed from the task group was also named in application definition, application definition must be changed and rebuilt.
	If default control attributes of a task are changed, and these attributes are not overridden in application definition, application database must be rebuilt.
	If changes to task group definition conflict with existing authorization for application in ACMSAAF.DAT, authorization must be modified and application database reinstalled with ACMS/INSTALL command.	When application is moved to ACMS$DIRECTORY with ACMS/INSTALL command.
Task definition	Task group database must be rebuilt.	When application is stopped and restarted.
	If default control attributes of task are changed, and these attributes are not overridden in application definition, application database must be rebuilt.
	If task name is changed, task group definition must be changed to reflect new name.
Request	Request library (.RLB) must be rebuilt.	When application is stopped and restarted.
	If number of records or if record definitions used by request are changed, task group database must be rebuilt.
	If request name is changed, task definition must be changed.
	If request library name is changed, task group definition must be changed.
Form definition	Request library (.RLB) must be rebuilt.	When application is stopped and restarted.
	If form name is changed, request definition must be changed.
Form panel	FORM file must be back-translated to produce a source IFDL file. Object module must be extracted and relinked with or without escape units.	When application is stopped and restarted.
Form record	IFDL file must be translated to produce a new FORM file. Object module must be extracted and relinked with or without escape units.	When application is stopped and restarted.
Step procedure	Step procedure must be recompiled and server image (.EXE) relinked	When application is stopped and restarted, or when server is replaced.
	If number of workspaces or if record definitions that the procedure uses for workspaces are changed, task must be redefined and task group database rebuilt.
	If procedure name is changed, procedure server definition in task group must be changed. Task definition must be changed.
Message source file	File of message texts (.EXE) must be relinked.	When server using message is restarted after relink.
	If message was added or removed or order of messages changed, new message object module must be generated. Server image must be relinked with the new module.	Stop and restart application to ensure that changes are available.
Workspace definition	If task definition, form record, request, or procedure refers to fields that have changed name, definition or program must be changed. Task group database or request library must be rebuilt, or procedure relinked.	When application is stopped and restarted after rebuild.
	Both task group and form file or request library must also be rebuilt and program relinked if order of fields in workspace or other characteristics have changed, even if requests, task definitions, and procedures are not affected by change.
	If name of workspace definition is changed, procedure, task definition, and form record or request must also be changed. Task group and request library must be rebuilt. Procedure must be recompiled and relinked.
Application authorization (with AAU)	If using ACMS/INSTALL command, reinstall application database.	When application database is moved into ACMS$DIRECTORY with ACMS/INSTALL command.
	If changes to authorization place further restrictions on application, remove old application from ACMS$DIRECTORY and reinstall application database.
User or device authorization (with UDU or DDU)	If change does not affect access control lists or menu names, no other change is required.	Next time user signs in to ACMS.
	If change affects access control lists in application definition, application must be redefined and rebuilt.
	If change affects names of menus, menus must be redefined and rebuilt.
	If change affects which terminals are controlled by ACMS, no other change is required.	After ACMS/RESET TERMINALS command is issued, or after ACMS is stopped and restarted.

Table B-2 describes the files needed to run a task with the ACMS Task Debugger.

Table B-2 Files Used to Debug ACMS Tasks

File	Description
Data files or database files for task group	Created and populated using either RMS, DBMS, or Rdb.
Message file or files for task group	Created with the OpenVMS Message Utility. This file contains text of messages and their message symbols. You need this file only if your tasks use the GET MESSAGE clause to access a message file that is separate from the server image.
Procedure Server Images	Created with the LINK command. Contains executable versions of the procedure server transfer module, message file module, and all procedures for the task group.
DECforms form files	Created using DECforms.
Task database --- TDB	Created with the BUILD command of the ACMS Application Definition Utility --- ADU. Contains information used by ACMS to run tasks. Include the /DEBUG qualifier with the BUILD command to examine and deposit data in the workspace while debugging the task.

Table B-3 describes the sources used to create the files used for debugging ACMS tasks.

Table B-3 Source Files for Debugging

File	Description
ADU input files	Contain source definitions for task groups and tasks.
CDO input files	Contain CDD source definitions for ACMS workspace records.
RDU input files	Contain source definitions for requests and request libraries.
Step, initialization, termination, and cancel procedures	Written in COBOL, BASIC, or other high-level languages.
Message source files	Contain source text for messages.
Procedure server transfer module	Created by building the task group. Contains vectors for the procedures handled by the server and the main entry point for the procedure server image.