Managing Physical Storage
A physical storage space can be managed in VC/m only when at least one location has been mapped to that space. (See the article on Managing Locations.)
To manage physical storage spaces, navigate in the folders panel to Setup -> Physical Addresses. If you have already set up some locations and mapped them onto some physical storage spaces, each physical address will be listed in the main panel:
By double-clicking on each physical address entry, you can view and modify the way in which VC/m interacts with it.
When mapping a location onto a physical storage space, along with the physical address a storage format must also be specified. The combination of physical address and storage format constitutes a physical location. Managing physical storage space in VC/m is done in terms of physical locations.
Physical Locations
Note: The term 'physical location' is generally avoided as much as possible when referring to the management of physical storage, so as to prevent its confusion with locations. However, the term still has a technical role to play in the structure of VC/m.
A physical location is the unique combination of a physical address and a storage format. The following diagram shows two locations with the physical addresses to which they map their components. The physical locations are displayed in blue boxes:
In this diagram, the two locations - Location1 and Location2 - map to the following four physical locations.
| Physical Location Code | Storage Format | Physical Address |
|---|---|---|
| Location1$M | M | VCM-LOC1 |
| Location1$text | text | \usr\pages |
| Location2$bin | bin | \usr\pages |
| Location2$M | M | VCM-LOC2 |
Physical locations have the following properties:
- Single-version or Multi-version
- Controlled or Uncontrolled
- Dependency check
Single- and Multi-Version Physical Locations
Windows and UNIX operating system directories are only able to store a single version of an object at any one time. Libraries and sequential files, however, may be defined either as single-version or as multi-version, depending on the role they are to be used for.
Logical locations can also be defined as single-version or multi-version. A logical location which maps onto a multi-version physical location may be defined as single-version or multi-version. However, by definition, a logical location which maps onto a single-version physical location must only be single-version.
Note: Certain locations, e.g. Windows and UNIX operating system directories, also have a physical limitation in that they can only hold a single version of any component name at any one time. This means that when a component of the same name belongs to more than one object, only one of the component versions can exist in such a location.
Controlled and Uncontrolled Locations
A physical location has a type of controlled or uncontrolled. A controlled physical location is one which VC/m expects to have full knowledge of.
An uncontrolled physical location is one whose contents VC/m does not assume it has exclusive control of. Uncontrolled locations can be referenced within VC/m in exactly the same way as controlled locations. The difference is that VC/m does not perform any checks on the contents of an uncontrolled location before making a transfer to it. Deletions are not propagated to uncontrolled locations, and unregistered components are not protected from being overwritten in uncontrolled locations.
Controlled is the default and this should normally be used.
Dependency check
When a location is used as a dependency on a transfer route, VC/m may need to compare each component at this location with the same component at the from location. Component comparisons occur if the same version of the object being transferred is already active at the dependent location. The dependency check associated with the physical location for the component at the dependent location determines the mechanism which is used:
| Dependency check | Behaviour |
|---|---|
| Component Timestamp | Compares the component's native timestamps (e.g. class last-modified timestamp, file modification date/time) |
| Physical Compare | Compares components byte-by-byte |
| VC/m Internal Timestamp | Compares VC/m's own internal date/time stamps |
| Best Available | If the component driver supports getting and setting of native timestamps a 'Component Timestamp' check is performed. Otherwise a 'Physical Compare' check is performed. See note below. |
The default for new physical locations is 'Best Available'.
Note: Component types that can be stored in 'bin' or 'text' storage formats (e.g. BIN or T type components) will only have their native timestamp propagated by a VC/m transfer if VC/m is able to use a Perl interpreter. See here for more information. Failure to set this up correctly can lead to repeated automatic transfers.
The 'Physical Compare' check will be the most accurate but it will also be slower than the others, particularly where VC/m is managing code on remote nodes.
The 'Component Timestamp' check will only work for components which have a native date/time stamp. For example, operating systems typically record the date and time when a file is modified, but a Caché/M implementation does not record the date and time when a global is modified.
The 'VC/m Internal Timestamp' check is unsuitable if an editor is being used which does not have an interface to VC/m. Without an editor interface, the VC/m date/time stamp will not be updated when the component is changed.
Note: For the 'VC/m Internal Timestamp' check, the components do not physically have to exist at the location.
See Also: Physical Storage, Managing Locations