VMS IDE How It Works

How It Works

Synchronization

1. The list of files identified by the source, headers, builders, resource masks excluding those in exclude is loaded from VMS, starting with the root directory.
2. A similar list is loaded on the PC side.
3. The modification dates of the corresponding files are compared and two lists are made: A containes the files that are newer on the PC, and B contains the files that are newer on VMS. Differences in modification dates of less than a second are not taken into account.
4. The downloadNewFiles value is checked:
4.1. If downloadNewFiles is equal to skip, the B list is ignored.
4.2. If downloadNewFiles is equal to edit, the files on the B list are loaded into the PC memory and IDE windows are opened to compare the VMS version with the PC version, edit and save the changes.
4.3. If downloadNewFiles is equal to overwrite, the files on the B list are loaded onto the PC, overwriting the existing versions.
5. Files on the A list are loaded into VMS and the modification date of their PC counterparts is set as their modification date on VMS.
5.1. If supportSetFileTime is defined in the SSH settings, the modification dates will be set with SSH commands.
5.2. Otherwise, the SSH Shell is launched and the modification dates are set with the DCL commands set file FILE.EXT /attribute(mod=DATE,att=DATE)
6. Then, the synchronized flag is set on the project.

Upload using ZIP

All the files on the PC side identified by the source, headers, builders, resource masks excluding those in exclude are archived and the archive is loaded into VMS.

1. If unzipCmd is set, the archive will be extracted using unzipCmd + archive name. The command must take into account the following: the modification dates must be set in accordance with the current time on PC, and the extractor must not ask anything from the user, that is, it should always overwrite or skip.
2. If unzipCmd is not set, the archive will be extraced using unzip -oo "-D" + archive name.

If the archive is successfully extracted, the synchronized flag is set on the project.

Uploading

1. If preferZip is set to true, upload using ZIP will be carried out.

2. If preferZip is not set, upload will be carried out as a synchronization, except the B list is always ignored.

Quick uploading

Quick uploading works for the project pointed to by the cursor in PROJECT DEPENDENCIES.

Files identified by source, headers, builders, resource masks excluding those in exclude that have been changed since last synchronization, upload, or since VMS IDE was started are loaded onto the remote machine. If the file was removed on PC, it will be removed on VMS.

If the project was synchronized before last changes to the files, it will be deemed synchronized after the Quick uploading. Otherwise the synchronization flag will not change.

File masks

Example	Meaning
**/folder/**	All files which have this folder in path
*.ext	All files with extension ext
*.	All files without extension
**/build/**/*.com	All files with com extension which have build in path

Building

First, the build configuration is defined. All possible configurations are described in the Project settings/builds/configurations section of the settings. Choice of the current configuration is made in the PROJECT DESCRIPTION window by right-clicking the buildName line.

If the command configuration field is empty, the build will use the automatically generated MMS file. To create it, press F1 and choose the Create MMS command . The project for which MMS needs to be created must be selected in the PROJECT DEPENDENCIES window.

If the command field contains a COM file, it will be run with the parameter specified with parameter.

If the command field contains an MMS file, it will be run with MMS/EXTENDED_SYNTAX/DESCR=mms_file_name _parameter_. That is, parameter will be used as target.

After the build, the files described by the listing mask will be loaded from the outdir directory on VMS into the outdir directory on PC with the "Prepare to debug" command from the "PROJECT EXPLORER" menu for the selected project. Therefore, if you are using your own build script, you should make sure that the listing files are in the root/outdir directory after the build. Also, the "Prepare to debug" command creates a JSON file in the .vscode directory with the correspondences of the module names and the source files; you can edit that file if you wish but don't forget that it will be overwritten after the command is issued again.

Keep in mind that outdir is not a path but the name of the directory that will be created inside root for storing intermediate results of various operations. outdir must consist of English letters only and must not be empty.

Debugging

First, a debugging configuration must be created in VS Code. To do that, create or edit the launch.json file to ensure it includes a vms_dbg configuration and then configure it. If the program name is empty, it will be set using the project settings when the debugging starts. This option is convenient if defaults are chosen elsewhere as well (MMS creation, compilation).
If the program is built with a custom script (COM or MMS), the user will have to provide the debugger with the path to the script in the VMS format. Note that the debugger starts in the user's home directory.
The debugger depends on the listing files corresponding to the source files. The debugger operates in terms of module, and in order to find the source module file, you need the listing files. Also, the code line number in the debugger does not correspond to the line number in the source file. All the line number information is stored in the listing files. That is why it is essential that the necessary listing files are loaded onto the PC at compilation.

NOTE: The debugger uses two terminals - one for the program being debugged and one for the debugger itself. Therefore the user has to have additional privileges: LOG_IO, PHY_IO, SHARE and OPER.

You can read more about debugging in the relevant VS Code documentation.