Special folders

On each machine, the install folder (installation folder) is the local folder where the USoft product is installed. If you have multiple USoft installations on a machine, it is the folder where USoft was last installed, but it is good practice to allow a maximum of 1 USoft application on any given machine at any one time.

The path leading to the folder is returned by:

select        RulesEngine.GetProperty( 'SystemDir' )

In path syntax, you can refer to the install folder by using the $$install path variable.

Source-side

On the source side (= in Development environments), the install folder is specified as an attribute of the current release. You can view or change it by choosing Release, Current Release from the menu. To change, press the Change button at the "Install folder" field. This lets you specify a new folder path of your choice, or alternatively it lets you set the install folder to the folder where USoft was most recently installed (use the Set Local button for this).

You cannot run Tasks on a development machine unless the folder where USoft was most recently installed equals the "Install folder" set for the Current Release.

Target-side

On the target side (= non-Development environments), you can specify a machine's install folder as the "Install folder" Computer attribute. However, such a specification is for documentation only: it has no effect on upgrade scripts. This is because upgrade scripts do not actually expand the $$install path variable to the value of the "Install Folder" Computer attribute. Rather, they expand it to the RulesEngine.GetProperty( 'SystemDir' ) call. This ensures that when an upgrade script referring to $$install is run on a target machine, the actual installation folder on that machine is used, even if the value of the "Install folder" Computer attribute for that machine points to a different folder.

On each machine, the temp folder is the local folder where Delivery Manager stores temporary or intermediate files that used only as steps in a larger operation.

Do not confuse the temp folder with the USoft Temp Folder specified at USoft installation time, which is the folder path returned by the following call:

select        RulesEngine.GetProperty( 'USoftTempDir' )

You may choose to set "Temp folder" to the USoft Temp Folder. It is, however, good practice to reserve a special folder as the Delivery Manager temp folder. While it is typically not necessary to inspect materials placed in the temp folder, this may be useful for debug purposes.

In path syntax, you can to refer to the temp folder by using the $$temp path variable.

Source-side

On the source side (= in Development environments), the temp folder is specified as an attribute of the current release. You can view or change it by choosing Release, Current Release from the menu. To change, press the Change button at the "Temp folder" field. This lets you specify a new folder path of your choice, or alternatively it lets you set the temp folder to the USoft Temp Folder (use the Set Local button for this).

Target-side

On the target side ( = non-Development environments), you can specify a machine's temp folder as the "Temp folder" Computer attribute. This only has an effect if you use the $$temp path variable in upgrade scripts, in which case the path variable will be expanded to the correct folder path for each Computer.

The previous release folder is the folder where deliverables of the most recent release prior to the current release were written to.

In path syntax, you can to refer to the temp folder by using the $$previous path variable.

If the current release is an initial release, there is no previous release folder. In this situation $$previous is automatically resolved to the current release folder.

Source-side

The previous release folder is typically a source-side concept. The following query in Development returns the previous release folder:

select                concat( root_folder, concat( '\', prev_folder_label ) )

from                t_dl_release_frame

where                dl_current = 'Y'

Target-side

On the target side ( = non-Development environments), you can specify a target machine's previous release folder in the "Previous folder" Computer attribute. To do this, set the "Root folder" Computer attribute. Delivery Manager composes "Previous folder" by combining the value of "Root folder" with the version name of the previous release. However, this option exists only for completeness. To point to deliverables on a target machine, the intended use is unpack folders rather than release folders.

The root folder is the parent folder where deliverables of the current release and all the past releases are found. The root folder identifies the release tree.

In path syntax, you can to refer to the temp folder by using the $$root path variable.

Source-side

The root folder is typically a source-side concept. Root Folder is an attribute of the Current Release and may be viewed by choosing Release, Current Release from the menu. The only way to change the root folder is to re-initialise the release tree by choosing Release, Initialise Release Tree from the menu.

The following query in Development returns the root folder:

select                root_folder

from                t_dl_release_frame

where                dl_current = 'Y'

Target-side

On the target side ( = non-Development environments), you can specify a target machine's root folder as the "Root folder" Computer attribute. However, this option exists only for completeness. To point to deliverables on a target machine, the intended use is unpack folders rather than root folders and release folders.

The release folder is the folder where deliverables are currently written to.

In path syntax, you can to refer to the temp folder by using the $$release path variable.

Source-side

The release folder is typically a source-side concept. Release Folder is an attribute of the Current Release and may be viewed by choosing Release, Current Release from the menu. The only intended way to change the release folder is to create a new release by choosing Release, Create New Release from the menu. But if necessary because errors must be redressed, it is possible to revert to a previous release.

The following query in Development returns the release folder:

select                concat( root_folder, concat( '\', prev_folder_label ) )

from                t_dl_release_frame

where                dl_current = 'Y'

Target-side

On the target side ( = non-Development environments), you can specify a target machine's previous release folder in the "Release folder" Computer attribute. To do this, set the "Root folder" Computer attribute. Delivery Manager composes "Release folder" by combining the value of "Root folder" with the version name of the current release. However, this option exists only for completeness. To point to deliverables on a target machine, the intended use is unpack folders rather than release folders.

On each machine, the stash folder is a folder that you can use for temporary storage of application data that is in danger of being lost when it is transferred or transformed during upgrade. Once upgrade has proven successful, the contents of this folder is no longer relevant until the next upgrade.

You can refer to the stash folder by using the $$stash path variable. Delivery Manager does not use stash folders internally. Stash folder settings have no effect unless and until you refer to them using $$stash.

Source-side

In Development, "Stash folder" is an attribute of the Current Release. The value of this attribute is what $$stash is expanded to if $$stash is used in a task step parameter (a Folder or File parameter, or a SQL Command parameter). The value of this attribute may be viewed and changed by choosing Release, Current Release from the menu. To change, press the Change button at the "Stash folder" field.

However, the stash folder is typically a target-side concept referred to by occurrences of $$stash in upgrade scripts. You can specify a machine's stash folder as a Computer attribute. The value of this attribute is what $$stash is expanded to if it is used as a path in an upgrade script. If you want to test a stashing operation specified in an upgrade script from a Development machine, you must declare that Development machine as a Computer.

Target-side

The stash folder is typically a target-side concept. You can specify a machine's stash folder by specifying it as a Computer attribute. In upgrade scripts, you can then use $$stash to refer to each machine's stash folder for stashing purposes.

On target machines, the unpack folder is the folder where a new version of the application's deliverables is placed before they are unpacked and deployed on the target machine. The unpack folder is also referred to as the hatch.

You can refer to the unpack folder by using the $$unpack path variable. Delivery Manager does not use unpack folders internally. Unpack folder settings have no effect unless and until you refer to them in upgrade scripts using $$unpack.

You can specify a target machine's unpack folder by specifying the "Unpack folder" Computer attribute.

On each machine, the using folder is a folder where helper files are placed that are necessary for operations in the parent folder. Normally, the using folder is the "\scripts\using" subfolder of the release folder and it contains the following 2 types of helper files for producing deliverables in the "scripts" parent folder:

•Intermediate .XML files and .XSL transformations that Delivery Manager needs to compile the "200.upg.rdbms.sql" database upgrade script: the new-style "Create-Tables" script.

•.XSL transformations that are applied by upgrade scripts in the "scripts" folder and must be distributed to each target machine.

Although the using folder is typically only an internal facility for Delivery Manager, you can refer to it explicitly in upgrade scripts by using the $$using path variable. $$using is expanded to the value of the "Using dir" Computer attribute for each machine. Delivery Manager automatically sets this value either to the "\scripts\using" subfolder of the release folder, or to the "using" subfolder of the unpack folder. You can choose between these 2 alternatives by setting or unsetting the "Set using relative to unpack" Computer attribute.