With Entire Operations you can use different versions of objects of type job network and symbol tables.
This section describes the usage of this concept. For further information refer to the detailed description of the object types in the User's Guide.
This document covers the following topics:
The versioning of job networks and symbol tables is optional.
For each job network and for each symbol table you can decide individually whether you like to use versions, or not.
You may use versioning:
to archive previous network versions, so that they can be activated manually any time later;
to archive previous symbol table versions;
to prepare new network versions or symbol table versions for future use.
By defining network version usage ranges or symbol table version usage ranges, you can define which version is to be used by scheduled activations.
This section covers the following topics:
Version names can be a maximum of 10 bytes. The assignment of names is with few exceptions user-defined.
Following conventions, restrictions and recommendations apply:
The use of upper and lower case characters is allowed.
Space and the characters ?, <,
> are not allowed.
Because of reserved names the usage of ‚(‚ as first
character of version names is prohibited.
Due to the wildcard function the usage of "*" in a name is not allowed.
To prevent problems during porting to other platforms do not use special characters and umlauts.
With the usage of a global version names exit you can force a customer-specific version name syntax. For detailed information, see Global Exit for Version Names in the Administration documentation.
<empty>; in selections and in the log
also: (unnamed)Is used for an unnamed version.
This is the only existing network version, after migration from an Entire Operations version prior to Version 5.4.1.
In parameter listings "e.g. for Reporting" you can use also a hyphen "-".
(current)Will be replaced by the version that is the set in the activated time schedule.
(current) can be used in version references.
You can use the copy function also to clone Job Networks and to create new versions.
This is a common way to build new network versions.
You can also use the import function to add a version.
Jobs in any version can copied out of the originating network.
If multiple versions of a job network exist, then one must select one to be deleted.
Unless the last, "or only" version is deleted, then automatically the "Network Main" object will be deleted too.
Independent version objects that belong to the network will be deleted with the "Network Main" object.
A network version can not be deleted if listed in a activated time schedule as a standard version. A defined date in the past is not relevant.
By using the API
NOPUAC5N
(Function D, Run Number -1) you can delete single
network versions and jobs.
To maintain version usage in Network administration, use the corresponding functions described in Maintaining the Usage of Network Versions in the User's Guide.
This section covers the following topics:
The following applies:
If only one version exists in a network, then this version will be activated. A schedule definition will be ignored.
If multiple versions exist in a network, then it will be checked if a version has a current activated time schedule. If this is so, then this version will be activated.
If usage intervals are defined for a network version, but the activation date is not in this interval, then the network will not be activated although scheduled. Corresponding protocols "Log entries" and messages will be sent.
If you choose a manual activation, then any network version can be selected. The standard version for schedule activation "if existent" will be offered to you first.
In the sub-network definition you can define any version or the
reserved (current) name.
For the network or job activation as end-of-job action you can define
any version or the reserved (current) name.
For the network or job activation via API
NOPUAC5N
you can define any version or the reserved (current) name in the
field NETWORK-VERSION.
Note that the API may issue version-related return codes.
In Entire Operations you can save multiple versions of job networks. Versions that are not, or are no more in the usage interval of schedule activation will not be activated automatically.
The history of the network activations contains the network version for every run.
Network versions will be considered.
Network versions will be considered.
Entire Operations exits that are active in networks, support network versioning.
The maximum number of network versions can be limited system wide as described in the section Versioning of Job Networks.
This section covers the following topics:
Version names can be a maximum of 10 bytes. The assignment of names is with few exceptions user-defined.
The following conventions, restrictions and recommendations apply:
The use of upper and lower case characters is allowed.
Space and the characters ?, <,
> are not allowed.
Because of reserved names the usage of ‚(‚ as first
character of version names is prohibited.
Due to the wildcard function the usage of "*" in a name is not allowed.
To prevent problems during porting to other platforms do not use special characters and umlauts.
With the usage of a global version names exit you can force a customer specific version name syntax. For detailed information, see Global Exit for Version Names in the Administration documentation.
<empty>; in selections and in the log
also: (unnamed)Is used for an unnamed version.
This is the only existing network version, after migration from an Entire Operations version prior to Version 5.4.1.
In parameter listings "e.g. for Reporting" you can use also a hyphen "-".
(current)Will be replaced by the version that is the set in the activated time schedule. (current) can be used in version references.
(NV)Will be replaced with the network version of the active network. If only a unnamed network version exists, then this symbol table will be referred to this.
If a symbol table version with the same name is not existent in the network version, then a error message will be sent and the request aborted.
(nv) can be used in network versions.
(svn)The symbol table version will be replaced thru the active network.
(svn) can be used in referenced versions of a slaved network.
Usage for e.g.:
job definition,
all situations where (svj) can be defined.
(svj)The symbol table version will be replaced thru the active job.
(svj) can be used in referenced versions of a slaved job.
Usage for e.g.:
Requested prerequisite dependant from the symbol value,
Requested prerequisite dependant from multiple symbols,
End-of-Job action: set symbol.
You can use the copy function also to clone symbol tables and to create new versions.
This is a common way to build new symbol table versions.
You can also use the import function to add a version.
Symbols in any version can copied out of the originating symbol table.
If multiple versions of a symbol table exist, then one must select one to be deleted.
A symbol table version can not be deleted if listed in a activated time schedule as a standard version. A defined date in the past is not relevant.
By using the API
NOPUSY6N
you can delete single symbol table versions and symbols.
To maintain version usage in symbol table administration, use the functions described in Maintaining the Usage of Network Versions in the User's Guide.
The symbol table versions can be defined in the:
network versions definition,
job definition.
The activation of symbol tables is a component of network and job activations.
A symbol table can only be activated in a clearly identified version. The identification of the requested symbol table version is part of the activation process.
Active symbol tables loose there version nomenclature
(current) or (nv). They are detached during
activation.
Active symbol tables can only have the version nomenclature
(none) or a defined version name.
If a requested symbol table version is missing, or the version cannot be defined, then the activation process will be aborted with a error message.
If a situation is not clear, do not "guess" the symbol table version.
Before symbol prompting (during manual activation and before executing the symbol prompting exit in the monitor), the symbol table versions to be used will be clearly determined. See also Symbol Prompting during Network or Job Activation in the User's Guide.
If at least one symbol table version cannot be identified, the activation process will be aborted with a error message.
The order in which symbols are searched for in the symbol tables defined in your environment depends on the hierarchy levels at which the symbol tables defined in you envionment can be accessed: see Symbol Table Types and Symbol Search Order in the User's Guide for details.
Symbol tables at system and owner level are not version-controlled.
The symbol tables are:
SYSDBA / A <owner> / A
Logging of symbol actions include the version of the table where the symbol was loaded from.
The generated comments in the Entire Operations JCL header contains the symbol table version of all used symbols.
Symbol table versions will be considered.
Symbol table versions will be considered.
Symbol table versions will be considered.
Entire Operations exits ans APIs that are related to symbols, support network versioning.
Examples:
Symbol query-exit
API NOPUSYxN
The maximum number of symbol table versions can be limited system wide as described in Default Setting (3) in the Administration documentation.