Data Archival for Adabas

I don’t see a category for Data Archival but will post this here since it uses products that do (I think).

We bought this product with our ELA and are beginning to install it. Based on what we were instructed, we’d like to archive data from Adabas on z/OS to and archive db on z/OS as well as disk or tape on the same platform.

The data archival product itself only comes for Windows platform, and I downloaded it using the SAG Installer. What I don’t know is what all it comes with for this to work. Here’s what I think:

Adabas on Windows - necessary for repository data for Data Archival configurations
Adabas System Coordinator - necessary for orchestrating the work
Entire Net-work for Win and z/OS - so the Windows products can talk to the mainframe processes that extract and process archival work.
System Management Hub - to view and somewhat manage Data Archival components listed above
Adabas Manager - for managing Adabas on Windows

I seem to be going round and round with distribution on license keys as they don’t think we need any at all and especially not Entire Net-work on z/OS, but we don’t even have an adr16.xml key from them.

What all do we need product wise, and which ones should distribution be giving us keys for?




Hi Brian,

Just a brief overview about Data Archiving requires a Windows box for the user interface, where
you define your archiving actions and many other things.
An Adabas database can run on z/OS and all LUW platforms where Adabas runs on.
On z/OS it runs on USS connecting to the z/OS where Adabas runs.
It is possible archive data on z/OS as well as on an LUW platform.
Another option to use Data Archiving is to create a sub-set of data and apply it to another Adabas database,
not necessarily on z/OS.
Entire Net-Work is not required. After getting the license key the package contains all you need for a computer.


Hi Brian,

Browsing around I came across your post, you’re probably long-since through whatever hurdles you faced but just in case a.n.other finds this useful in future…

The archiving product will run anywhere (that it is licensed of course). The ‘extractor’ pulls data out of your Adabas whereever your Adabas lives (mainframe, unix, windows…) and the ‘accumulator’ transmits the extracted data into your choice of destination. Your destination could be another Adabas (in the same or different computer running a different operating system if you wish). Or your destination could be the ‘vault’ (a flat-file directory structure in the same or different platform to where it was extracted).

The basis of ‘extracting from’ and ‘accumulating to’ demands the software is ‘distributed’ in concept and in practice. In a mega-infrastructure you might be running any number (unlimited) of extract/accumulate pairs across any number of system pairs. And yes, that means you are not restricted to a single vault. You may decide to have different vaults for different divisions for example.

Given the distributed and platform-neutral nature of the software the mechanism for administering it needs to be neutral/easy too. You don’t want to have to be handling system-specific horrors such as JCL etc. This is where the ‘administration’ (browser) component comes into play. In this house you describe the things you want to be extracted, where you want them to be stored, when you want things to run, how often, under what restrictions, etc. You can also watch (monitor) all the concurrent actions running from this browser too, across all computers from the single browser seat.

Having lightly described the distributed basics (administration, extraction, accumulation, vault) finally there needs to be some glue to hold all this together. This is the ‘(Adabas) System Coordinator’. System Coordinator understands the network of computers where this software is installed (automatically during installation across the various machines). You will find your administration browser magically acquires this knowledge thereby making your life easier when picking the from/to pairs for the extract/accumulate actions you define.

The System Coordinator ‘network’ manages itself according to the actions you define so that extractors and accumulators will run when you want them to - automatically. You can set the ‘pace’ at which these things run too for example so as not to overload etc.

The communication bewteen all these components is by TCP/IP without need for the Net-Work product.

There is one thing that confuses people. Well two actually…

First is the administration browser cannot run on mainframe. The browser can only run on either (or both) Unix or Windows (LUW). This is quite an obvious limitation since the mainframe finds browser displays a bit difficult.

Second, the installation of all the components is performed from non-mainframe (LUW). This means anyone wishing to install components onto mainframe must do so from ‘off-host’ by getting the Installer to ‘push’ the mainframe components up onto your mainframe. For a single mainframe implementation a site would:

a) Drop the Installer on your choice of LUW stations.
b) Use the Installer to drop the Archiver onto your choice of LUW browser.
c) Use the Installer to drop (push) the Archiver up to your mainframe.

The pre-reqs (other than Adabas) get dropped as needed during the installation process (System Management Hub etc) where needed.

A brief (but still long) tale, hopefully it makes sense to whoever needs it in future.

Best regards,


1 Like

Thanks, Michael. This is going to be a helpful thread, hopefully, for those who come after me in this process. I was clearly confused but these points about the installation process are clear now thanks to the help I received:

  1. Regardless of whether you plan to run the archival processes on the mainframe or LUW, the software is distributed via the Software AG Downloader and installed running the SAG Installer on a Windows box. You have to make sure if you will be running on the z/OS that you select the product components in the downloader labeled as such.

  2. The mainframe components of Data Archival and Adabas System Coordinator are installed into the Unix Services portion of your z/OS platform (OMVS).

  3. No license key is required for mainframe installation, unlike for LUW installation.

The mainframe installation prerequisites need to be understood, also, before you begin. This document is found at

Most of us mainframe DBAs have never played around on the OMVS area before but I have played around on other Linux/Unix servers so it’s not totally unfamiliar, and once the platform and security teams define the RACF id and permissions required as well as setting the environment up to comply with specification (enough region size, enough storage at mount point for /opt/softwareag, etc), I should be ready to proceed.

Stay tuned for updates as we move along!