BASEstar^tm Classic DAS
for OMNI^tm Software
Installation and User's Guide

The upload function transfers the contents of a device's memory to an OpenVMS file. The download function transfers the contents of an OpenVMS file to a device's memory. The directory function lists a device's memory.

In order to avoid errors, you will need to know how OpenVMS files are mapped onto the MMS device organization.

DCM file services provide functionalities to operate on remote device files: file download, file upload, file directory and device program management.

OMNI software supports the MMS File Management Services (primitives FGET, FPUT, FDIR, FRENAME and FDELETE), however they are seldom supported by any of the modern MMS devices. Therefore, these primitives are not supported by the DAS for OMNI software. In this manual, a file is always intended to be a file storing data or instructions related to a Domain, ie. programs, and parameters.

All operations on files are intended to operate on Domains and it is not possible, using the DAS for OMNI software to access the MMS file management primitives.

The download function transfers the content of the host Domain and Capability files to a Domain. The upload function transfers the content of a Domain to the OpenVMS Domain and Capability files.

The directory function lists the names of the Domains and the PIs found on a remote VMD.

Example 3-9 shows an example of the information displayed after issuing the DIRECTORY command.

Example 3-9 Directory Screen

DCM> DIRECTORY GEF_PLC Directory of device GEF_PLC at 17-MAY-1991 09:30:47.46 Path: *.* Domain: I_O_OVERRIDE_TABLE Domain: I_O_TABLE Domain: REGISTER_TABLE Domain: SUBR_VECTOR_ADDRESSES Domain: USER_LOGIC PI : DEMO_PI Total of 6 files, size 0 DCM>

Example 3-10 shows an example of the use of the UPLOAD and DOWNLOAD commands.

Example 3-10 Upload and Download Screen

DCM> UPLOAD GEF_PLC USER_LOGIC.DOM/DEV=USER_LOGIC DCM> ... DCM> DOWNLOAD GEF_PLC USER_LOGIC.DOM/DEV=USER_LOGIC DCM>

The standard extension for the content file is .DOM: you can use any extension for the content file, the capability file has always the same name with extension .CAP.

3.2.7 Start and Stop Functions

The start and stop functions change the status of a Program Invocation.

A Program Invocation can be reusable or not reusable. If a Program Invocation is reusable the start command will switch it from IDLE to RUNNING and the stop command will switch it from RUNNING to STOPPED and then to IDLE again.

If a Program Invocation is not reusable the start command will switch it from IDLE to RUNNING and the stop command will switch it from RUNNING to STOPPED and then to UNRUNNABLE.

To specify the Program Invocation name the OPTIONS field must be used with the following syntax:

DCM> START dev_name /START_OPTIONS="PI=pi_name"

and

DCM> STOP dev_name /STOP_OPTIONS="PI=pi_name"

A Program Invocation must exist on the device or created by the DAS for OMNI software. To create and delete program invocations the OPTION field must be used with the following syntax:

DCM> START dev_name /START_OPTIONS="PI=pi_name,CREATE=dom_name"

or

DCM> START dev_name /START_OPTIONS="PI=pi_name,CREATE=(dom_name_list)"

and

DCM> STOP dev_name /STOP_OPTIONS="PI=pi_name,DELETE"

The Program Invocations created by the DAS for OMNI software are always reusable.

After a program terminates a START command can be entered again. After a program stop (error) a STOP command is needed before the program can be restarted.

If a Program Invocation is idle a STOP/DELETE program will work anyway.

Figure 3-1 shows the effects of the start and stop commands on a program invocation.

Figure 3-1 Program Invocations State TABLE

Please note that many state transactions cannot be done through the DAS for OMNI software.