The Versioning Tool modules, macros and sample jobs are supplied with Adabas System Coordinator. All files have the name prefix “VER”.
The following table provides an overview of the steps required to install the Versioning Tool:
Step | Description |
---|---|
1 | Create versioning load libraries. |
2 | Assemble the database versioning table.
Note: |
3 | Assemble the Coordinator daemon versioning table.
Note: |
4 | Create client versioning tables(s) and link
module(s) for batch clients.
Note: |
5 | Create client versioning tables(s) and link
module(s) for CICS clients.
Note: |
6 | Apply co-requisite product maintenance. |
7 | Copy and rename required product modules into the versioning library. |
8 | Add the versioning libraries to required job control. |
to install the Versioning Tool, perform the following steps:
Software AG recommends that versioning is implemented by creating a new library to hold copies of product modules that have been renamed in support of versioning. This will protect the original modules. It will also enable new maintenance to be applied to the original modules, which can then be refreshed in the versioning libraries by re-running the appropriate installation jobs.
In the sample job control supplied with the product this library is called SAG.CORVER.ALLVERS.LOAD.
The library is added to the Joblib or Steplib concatenation of all servers, CICS tasks, batch Adabas server start-up jobs and Coordinator daemon tasks that require versioning support.
If you are implementing client versioning, you need to create a second library that will be used for the special link modules (VERLNK01, VERCIC01, ADALNKnn, ADABASnn), and the client versioning tables.
In the sample job control supplied with the product this library is called SAG.CORVER.CLIENT.LOAD.
Note:
It is imperative that these link modules are only used in the
client environment. Therefore, they must not be placed in the ALLVERS load
library that is used by the Adabas servers and Coordinator daemon.
Note:
This step is required for database versioning only.
Use sample job VERI055.
The versioning table source consists of a number of VERDB macro statements. Here is an example:
VERDB SUFFIX=81,VRL=812 VERDB TYPE=END
The database versioning table will have an entry for each version to be run. There are 2 parameters:
Parameter | Description |
---|---|
SUFFIX= |
Identifies the suffix for all the required modules of all the products at that version. |
VRL= |
Denotes the version, release and maintenance level of the suffixed collection of modules. VRL needs to be set accurately because it is used internally by the software to ensure correct operation. |
The following rules apply:
The values for SUFFIX=
are unique across all
VERDB entries in the table.
The values for VRL=
are unique across all
VERDB entries in the table.
The table must end with VERDB TYPE=END
.
Note:
This step is required for deamon versioning only.
Use sample job VERI060.
The daemon versioning table enables you to use the re-named Coordinator and product modules in the System Coordinator daemon. This ensures that the same modules at the same maintenance levels are available in both the Adabas and the System Coordinator daemon.
Note:
Multiple version support in the daemon is achieved by running a
separate daemon for each required version. The Coordinator daemon does not
support multiple versions in a single daemon instance.
Note:
This is an optional activity. You may still run the Coordinator
daemon from the original product libraries, if desired.
The versioning table source consists of a number of VERDM macro statements. Here is an example:
VERDM SUFFIX=81,VRL=812,JOBNAME=SYSCO812 VERDM TYPE=END
The daemon versioning table will have an entry for each daemon to be run. There are 3 parameters:
Parameter | Description |
---|---|
JOBNAME= |
Identifies the jobname of a System Coordinator daemon. |
SUFFIX= |
Identifies the suffix for all the required modules of all the products at that version. |
VRL= |
Denotes the version, release and maintenance level of the suffixed collection of modules. VRL needs to be set accurately because it is used internally by the software to ensure correct operation. |
Note:
This step is required for client versioning only.
Batch versioning configuration is managed using macro settings to produce a configuration module, loaded dynamically at runtime. Here is an overview of what must or can optionally be defined:
The (mandatory) first element introduces the defaults for Batch. This element defines the defaults, and these settings are cascaded to the specific versioned link modules defined below, and optionally overridden by individual elements.
One or more elements identifying the versioned link module(s) to be used. There must be at least one. One of these acts as the default versioned link module. The others are each followed by one or more job-name elements that are a list of the job names that will use the versioned link module that precedes them. Where a job name is not matched (at runtime) it will use the default element’s versioned link module defined here.
The end of the settings definitions is specified.
There are various options for using a global module (generically referred to as LNKGBLS) when using versioning. These options accommodate sites wishing to:
Enforce use of the dynamically loaded global module (generically referred to as LNKGBLS).
Disallow use of the dynamically loaded global module.
Enforce use of the linked-in global module.
Disallow use of the linked-in global module.
Allow/disallow versioned dynamic global module, paired with the versioned link module.
Allow propagation of ADARUN DBID=
and/or
SVC=
settings into the dynamically loaded, versioned
global module.
Mixtures of these options across different link modules.
Here is an example versioning configuration:
VERCL JOBTYPE=BATCH, Batch defaults OVERIDES=YES, WTO=NO, LNKGBLXX=YES, BINDGBLS=IGNORED, DBID=DDCARD, SVC=DDCARD VERCL VRL=813, 8.1.3 module, the default DEFAULT=YES, SUFFIX=8A VERCL VRL=814, 8.1.4 module SUFFIX=81, LNKGBLXX=YES, BINDGBLS=IGNORED, DBID=15, SVC=ASIS VERCL JOBNAME=jobname, Use 8.1.4 BINDGBLS=IGNORED, DBID=15, SVC=ASIS VERCL TYPE=END The end.
This section describes the controls which can be used for the default BATCH settings:
Control | Description |
---|---|
JOBTYPE=BATCH | BATCH for batch configuration entries defaults. |
OVERIDES=YES|NO |
YES: Allow override settings for individual versioned
elements. |
WTO=YES|NO |
YES: Details of the configuration will appear on the
console. |
LNKGBLXX=YES|NO |
YES: A versioned global module LNKGBLxx (where xx is the
suffix) is to be used, paired with the versioned link module of the same
suffix. For re-entrant link modules, the versioned global module is named
LNRGBLxx. |
BINDGBLS=IGNORED|REQUIRED |
IGNORED: Dynamically loaded global modules must be used, if
one cannot be found an error is raised. |
DBID=DDCARD|ASIS|number |
DDCARD: The value from the |
SVC=DDCARD|ASIS|number |
DDCARD: The value from the |
This section describes the controls which can be used for the versioned link module entry settings:
Control | Description |
---|---|
VRL=814|813 |
814: This identifies an 8.1.4 link module. |
DEFAULT=NO|YES |
YES: This identifies the default link module. Only one
default link module is allowed. Do not define any jobs elements for the default
link module; it is used by any job not specified to use another versioned link
module. |
SUFFIX=xx |
xx: This identifies the two character suffix to be used when loading the link module and the global module (where appropriate). Example: |
The following controls are only allowed if
OVERIDES=YES is used. They default to the overall values
specified on the JOBTYPE definition.
|
|
LNKGBLXX=YES|NO |
YES: A versioned global module LNKGBLxx (where xx is the
suffix) is to be used, paired with the versioned link module of the same
suffix. |
BINDGBLS=IGNORED|REQUIRED |
IGNORED: Dynamically loaded global modules must be used, if
one cannot be found an error is raised. |
DBID=DDCARD|ASIS|number |
DDCARD: The value from the |
SVC=DDCARD|ASIS|number |
DDCARD: The value from the |
This section describes the controls which can be used for specific job name entry settings:
Control | Description |
---|---|
JOBNAME=jobname | This identifies the jobs that are to use the link module version identified prior to this job-name list. |
The following controls are only allowed if
OVERIDES=YES is used. They default to the values
specified on or inherited by the preceding link module definition.
|
|
LNKGBLXX=YES|NO |
YES: A versioned global module LNKGBLxx (where xx is the
suffix) is to be used, paired with the versioned link module of the same
suffix. |
BINDGBLS=IGNORED|REQUIRED |
IGNORED: Dynamically loaded global modules must be used, if
one cannot be found an error is raised. |
DBID=DDCARD|ASIS|number |
DDCARD: The value from the |
SVC=DDCARD|ASIS|number |
DDCARD: The value from the |
The resulting load module must be named VERC01 for standard batch or VERC09 for re-entrant batch and the versioning table load modules must be linked REUS, – not RENT. Sample job VERI065 shows how to assemble and link the versioning table.
Copy VERLNK01 to your client versioning library as ADALNK and VERLNR01 as ADALNKR, using sample job VERI085 (making sure the real ADALNK and ADALNKR are not lost). Certain fixed offsets in the Adabas link module contain information which is required by some callers of ADALNK. For example, length of the USER and Review extensions. If you use other than default values, you must zap the correct values into the ADALNK and ADALNKR copies of VERLNK01 and VERLNR01. Sample job VERI088 may be used to do this.
Important:
This library must not be made available to any target in the
Software AG network which acts as a DBID – such as Adabas, Broker, Com-Plete,
Entire System Server, Net-Work, System Coordinator daemon etc.
Copy your existing ADALNK and LNKGBLS modules to the client versioning library, renaming them to have the appropriate suffix:
ADALNKxx and LNKGBLxx for standard batch ADALNRxx and LNRGBLxx for re-entrant batch
Note:
This step is required for client versioning only.
There are several prerequisites which must be fulfilled before you can use the CICS client versioning facility:
All transactions which will use it must be defined with a minimum
TWA size equal to the value specified as the VERCL COFF
parameter plus 32 bytes. So, if you specify COFF=96
, TWA
size must be at least 128.
Adabas 7.4 link modules must be assembled with the ADAGSET
parameter PARMTYP=ALL
.
For Adabas 8.1, ensure that PARMTYP=ALL
is
set in LGBLSET (this is the default).
You must not mix TRUE-enabled link modules with non-TRUE-enabled link modules. Either all link modules must use the TRUE or none.
PPT entries must be defined and installed for the Adabas client versioning link module (ADABAS, or other name you may choose, or if using Adabas Version 8, ADACICS); for VERC03, and for all renamed Adabas CICS link modules, Adabas TRUEs and Adabas PLT programs (LNKENAB and ADACIC0). You may require additional PPT entries for add-on product modules (specifically – Version 742 and later modules can be loaded from DFHRPL if PPT entries are defined for the product modules).
Additionally, the PPT entries for ADABAS (or ADACICS) and VERC03 must specify Resident.
Use sample job VERI065.
The CICS versioning table is named VERC03 and consists of a number of VERCL macro statements.
VERCL JOBTYPE=CICS, CICS defaults COFF=96, WTO=NO VERCL VRL=814, 8.1.4 module, the default DEFAULT=YES, SUFFIX=81 VERCL VRL=744, 7.4.4 module SUFFIX=74 VERCL TRAN=AA74 Use 7.4.4 VERCL TYPE=END The end.
This section describes the controls which can be used for the default CICS settings:
Control | Description |
---|---|
JOBTYPE=CICS | CICS for CICS configuration entries defaults. |
COFF= TWA | Offset to be used for saving context information. |
WTO=YES|NO |
YES: Details of the configuration will appear on the
console. |
This section describes the controls which can be used for the versioned link module entry settings:
Control | Description |
---|---|
VRL=814|813 |
814: This identifies an 8.1.4 link module. |
DEFAULT=NO|YES |
YES: This identifies the default link module. Only one
default link module is allowed. Do not define any transaction elements for the
default link module; it is used by any transaction not specified to use another
versioned link module. |
SUFFIX=xx |
xx: This identifies the two character suffix to be used when calling the link module. |
This section describes the controls which can be used for specific transaction entry settings:
Control | Description |
---|---|
TRAN=transaction code | This identifies the transactions that are to use the link module version identified prior to this transaction code list. |
You must also link VERCIC01 with your CICS stubs, naming the output load module appropriately (for example ADACICS). Installation job VERI085 includes sample JCL.
For each suffix defined in VERC03, you will need modules called:
Module | Description |
---|---|
ADAENAxx | PLT TRUE enabler |
ADACICT | Adabas Version 8.1 TRUE |
ADABASxx | Link module |
where xx is the suffix and the first 6 characters of the module name must be as shown.
For an Adabas 8.1 or above link module, VERCIC01 must be linked as ADACICS and, assuming VERC03 defines suffix 81:
Copy the supplied ADACIC0 to ADAENA81
Copy the supplied ADACICS to ADABAS81
Note:
The Adabas 8.1 TRUE has a fixed name (ADACICT), so you may only
have one Adabas 8.1 link module in the versioning table. Please contact
Software AG support for details on how to use client versioning with Adabas
8.2’s support for multiple task-related user exits (TRUEs).
Define PPT entries for ADAENA81, ADABAS81, ADACICS and VERC03
Add ADAENA81 to the CICS PLT
Now, during CICS initialisation you will see a set of ADAK messages for each TRUE, each of which will say “in use by ADABAS link routine ADACICS”. This is because the versioning module is invoked by each PLT routine. The versioning module ensures that the correct TRUE and link module are initialised.
Finally, you must ensure that your renamed Adabas link modules and add-on product modules are available in the CICS DFHRPL and Steplib concatenations.
The CICS versioning tool supports callers using both the Direct Call Interface and the EXEC CICS LINK interface. It always uses the DCI to call the various Adabas link modules. Only command-level link modules from Version 7.4 and above are supported.
When invoked via EXEC CICS LINK, it first looks for the Adabas parameter list in COMMAREA and then in TWA.
Do not use CICS NEWCOPY to reload the versioning tool, versioning table or any Adabas link modules defined in the versioning table.
If you use the COR Node Error Program, you must be sure to change the sample source so that it starts the CORNEP transaction for each link module.
The messages issued by client versioning (if you specify
WTO=YES
), have changed format slightly. The batch client
versioning routines now only report the link module and options in use by this
job, rather than all modules in the table, for example:
+VER101I Jobname Link Module Globals SVC DBID +VER101I -------- ----------- -------- ------ ------ +VER101I ADA81TST ADALNK81 BINDGBLS ASIS ASIS
The CICS client versioning routine still lists the full table contents:
+VER101I Criteria Link Module +VER101I -------- ----------- +VER101I Default ADABASDF +VER101I DEMO ADABASDE +VER101I N426 ADABAS81
If client versioning detects an error (for example, the required link module is not available), it issues a message and rejects all Adabas commands with response 101, subcode 87.
The following maintenance fixes must be applied before using versioning with these products:
Product | Maintenance Fix |
---|---|
Adabas Version 742 | AI742030 |
Adabas System Coordinator Version 742 | Install the COR L005 load library update |
Online Services INPL updates | IS06 |
Adabas Fastpath Version 742 | AW742081 |
Adabas Vista Version 742 | AV742017 |
Adabas SAF Security Version 742 | AX742002 |
Customize and use the following sample jobs:
Version 742: VERI080D
Version 811: VERI080E
The sample jobs indicate all of the modules that require copying and renaming. No other product modules should be renamed.
Note:
The System Coordinator module ADAPOB must not be renamed. If you
have multiple versions of this module, ensure that the one in use is at the
highest level.
The versioning llibrary (the ALLVERS Library) must be added to the Joblib or Steplib concatenation of all Adabas server start-up jobs that require versioning support. The library should be added at the top of the concatenation, so that the special version of ADAPOP will be invoked at nucleus start-up.
If you want to run the System Coordinator daemon from the same versioning load library, you should also add the ALLVERS library first in the daemon Joblib or Steplib concatenation.
The ALLVERS load library and the client versioning load library must be added to the top of the Steplib concatenation for any batch jobs that require versioning support.
For CICS, the client versioning load library and the ALLVERS load library must be added to the DFHRPL and Steplib concatentations.