The author code is a trigram (signature) characterising the user. One such code must be present for every user account. It serves as a reference identifying the account to use when running tasks in DOLLAR UNIVERSE.
All jobs scheduled within DOLLAR UNIVERSE, even if attributable to a user (developer or end-user) in reality only memorise the author code, to ensure that automatic conversion can be performed between submission accounts during implementation.
Reference manual Users • 39 This occurs during the transfer phases (automatic translation of a developer-user into an end-user), and also in the distribution phases (for example, automatic translation of an user for a given node into another end-user on another node).
The following example illustrates the advantages:
Example : a task is planned in the applications area and is associated with an account whose username is
"cpttest". The author code for this account is "001".
The task in question is distributed to a remote management unit.
On the node supporting the management unit in question, the account "cpttest" is not defined, but another account with the username "accnt" and an author code "001" exists.
When it is time to run the task in question, the author code will ensure that the account "accnt" is linked to it.
The above example shows that it is not necessary to standardise accounts for all the nodes affected by a DOLLAR UNIVERSE operation. It is simply necessary to link the reference formed by the author code, to existing accounts.
The author code therefore contributes to the portability of tasks defined in DOLLAR UNIVERSE, from the development environment to the production environment.
Reference manual Parameters • 41
Parameters
Resources
In Windows, UNIX and VMS, the resource enables, using a logical identifier, the description of a system resource or a logical one (virtual) which should be scanned in order to condition the running of operations procedures.
Definition
A resource is identified by a reference :
q The reference is a logical identifier allowing the Uproc (and, therefore the application description) to remain transparent in relation to the executing environment. In the event of a change of node (or even of operating system), the Uproc description will adapt to take account of any related special features.
q Resource references are defined globally for a given node, irrespective of the area.
A resource is defined by:
Nature FIL : file VMS, UNIX, Windows
LOG : logical VMS, UNIX, Windows
PRC : process VMS
DSK : disk VMS
LNM : logical name VMS SYS : system object VMS
QUE : job queue VMS
A resource is identified by:
q Its name: Physical name of the resource to supervise, in the sense of the operating system.
q Its location : Name of storage object (for example, the directory name for a file).
The resource "location" is exclusively used for resource categories "FIL" and "LNM" (LNM in VMS and OPENVMS).
The notion of "location" of a resource corresponds to an access path used by resource category "FIL" (in VMS and OPENVMS, may take the form of a logical name or symbolic link, unless the resource name is also expressed in the form of a logical name).: For resource category "LNM" (in VMS and OPENVMS only), it represents a table name.
Note: this location may refer to resources not resident on the resource analysis node, provided that the primitives of the operating system used (corresponding to the defined category and attribute), so allow.
DOLLAR UNIVERSE version 5 for Windows, UNIX and VMS
42 • Parameters Reference manual
If a resource is defined as "exclusive", it may not be shared by another conditioned Uproc. Otherwise, quotas may be defined to manage resource sharing between Uprocs :
Quota 1 Maximum value of the resource's quota 1, which may be between 0 (default) and 9999.
Quota 2 Maximum value of the resource's quota 2, which may be between 0 (default) and 9999.
Finally, a resource is examined according to a specific frequency (by a dedicated process known as the supervisor: see "The operations process" chapter).
Codification
The resource name may be encoded with certain functional elements proposed by DOLLAR UNIVERSE. The following expressions can be inserted into a resource name.
This coding is usable only for the resource natures "LOG", "FIL" and "LNM" (the latter available in VMS and OPENVMS only). They can be inserted at any point in the name.
q "!UG!": The management unit code can be inserted into the name; this is the code obtained from data defined by "inter-MU Checks" on the resource condition. If interpretation of this data points to several management units, the generic resource name created by insertion of this expression will correspond to the same number of resource names as there were management units designated.
Caution: even if the management units targeted by the condition are not resident on the examined node, the corresponding resources will be searched locally (unless the location refers to a remote resource).
q "!DTRAIT!": The processing date can be inserted into the resource name; this is the date expressed in the
"functional period definition" of the resource condition (format : YYYYMMDD).
q "!SOC!" Allows the name of the current company to be inserted during examination of the resource condition.
q "!ESP!" Allows insertion of the current area code (A, I, S or X) into the resource identifier during examination of the resource condition.
Furthermore, in VMS and OPENVMS, logical names are accepted solely for resource category "FIL", and only if the location is not itself expressed using a logical name. While DOLLAR UNIVERSE checks the syntax of the specific expressions used ("!ESP!","!SOC!" Etc.), It cannot check for usage restrictions on logical names described previously.
On UNIX, VMS or Windows systems, for a "FIL" resource, the name of the file may contain a wildcard (*) anywhere in its name. The wildcard may not be used, however, in the location of the file. Neither are the characters " ? " or " [ ] " accepted by the scheduler.
Note: in VMS and OPENVMS, in order to ensure that the operations process remains as independent as possible of the environmental organisation, it is advisable to use logical names to define the location (access path) of a file rather than its name.In general terms, adding variables into resource names and locations will depend on the
"dynamic" character of the parameters proposed (that is, which can change over time): therefore "static" concepts ("!UG!", "!SOC!" And "!ESP!") Will be used for the location, while "dynamic" concepts ("!DTRAIT!") will be employed in the resource name.
Example : reception and consolidation of files from shops
The Uproc employed for consolidating files from the shops has a resource condition based on its reference, defined as follows:
Type FIL
Attribute exist
Reference manual Parameters • 43 Name comm_t!DTRAIT!g.dat
Location rep_!ESP!!UG!
The "inter-MU Check" associated with this condition is a HDP convention of type "{S }" (all shops depending on head office, such as "S01" and "S02", for example).
The "functional period definition" associated with this condition will use identical processing dates to the processing date of the considered Uproc (same day, for example).
When launching the Uproc for 21 December 1994, DOLLAR UNIVERSE will translate the symbols
"!UG!" And "!DTRAIT!" By their values as obtained in the "inter-MU Check" and the "functional period definition".
If the launch takes place in the production area, the files to supervise will be:
REP_XM01: COMM_T19941221G.DAT REP_XM02: COMM_T19941221G.DAT
Where REP_XM01 and REP_XM02 will be logical names describing the directories for storing the COMM_T19941221G.DAT files.
If the option "all necessary" was selected for the "inter-MU Check", the two files must be present in order for the condition to be satisfied.