BASEstartm Classic DAS
for OMNItm Software
Installation and User's Guide


Previous Contents Index

3.2.6 Download, Upload and Directory Functions

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.

Domain Restrictions

In general a Domain must first be uploaded from a device before it may be downloaded, this is due to vendor specific formatation of a devices Domain. Prior to a Domain being downloaded it must first be deleted at the remote MMS device, since the DAS for OMNI software does not support deleting of domains.

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.


Previous Next Contents Index