BOI Software Entwicklung und Vertrieb GmbH

Phone: +43 (0) 732 / 736423 - 0

Spazgasse 4


4040 Linz, Austria

The SHS/ESA Technology

The SHS/ESA Technology

The SHS/ESA technology provides the central storing of data in the main memory and the access to these centrally loaded data. ESA data spaces (z/OS) or shared memory (Unix, Linux, Windows) are used as central memory areas. (Please note: For TABEX we use the word SHS data space.)

This guarantees, that only one copy of a table is used in all applications. Furthermore no database access must be performed. This is why TABEX can access data with high performance and without additional memory usage.

ESA is the abbreviation for Enterprise System Architecture of IBM:

Fig.: Architecture

With the introduction of S390/ESA-Architecture by IBM, the use of data spaces in addition to the address space was made possible. TABEX was thus extended, so that it can load tables in the ESA data space. Thus, the performance has been significantly enhanced by the use of access to the same datapool loaded in memory tables from all regions.

TABEX has taken advantage of the possibility that after the introduction of 31-bit addressing up to 2GB of virtual data spaces can be used additionally to the address spaces.

The following benefits are offered by using the SHS technology in TABEX:

  • Read-access with high-performance calls
  • Loading or reorganizing data spaces can be performed without affecting running applications (uninterrupted switching between load data space and work space, following data change or reorganization)
  • No synchronization required Separated data spaces for the various integrated subsidiaries (multi-client capability) analogous to IMS and DB2. For the partition between the clients different search paths and project identifications can be used.
  • Several ESA data spaces can be active in parallel and filled with different tables. Via application-specific paths and project identifiers, the order of searches, such as clients, different environments, etc. can be controlled.
  • By addressing each table by name, date and file ID, the IT organization can be mapped. With the additional project identifier, different instances or test levels are possible. This ensures that only the correct version of the tables is accessible.
  • A special data space can be used to buffer data that must not be affected by a rollback. This is used, for example to save insurance contract numbers, so that in case of a crash of the application the system can rewind the process. In this case it is important that this contract number is not lost through a rollback (this would be the case with DB2 storage) or that the performance of the application is decreased because of too many I/Os (when writing the contract numbers in a file).

For organizing the SHS data spaces, subsystems (e.g. for development, test and production environment) can be used. By using a four digit subsystem ID, up to 16 data spaces can be generated. In z/OS a subsystem must be configured in the operating system. A holder task assigned to a subsystem controls its data spaces.

There are numeric (0 to 9) and alphanumeric SHS data spaces (A to Z). In z/OS the numeric ESA data spaces offer higher reliability as they are generated with 'storage key' '0' and can therefor only be changed by authorized applications.

SHS data spaces with special functionality are the data spaces S and 0.

  • S is defined as statistic data space. Access counters are stored there. Activation, deactivation and analysis of the statistic counters can be performed with the utility TABN04.

  • 0 is the work data space. It is used to avoid interrupts when loading, reloading or reorganizing a data space.

When loading the data space for the first time, the data are loaded into the work data space. After the load process has finished, the activation of the new data is done by a switch (exchange of the name of the data spaces) between work data space and active data space (e.g. data space 1).

If the work data space is used for several numeric data spaces with differing sizes, the work data space must be newly generated in the according space before the loading process.

Even if the data spaces are of the same size, we recommend to create a new work data space before each loading process performing a switch, as the assignments 'paging' are transferred.

Example for TABN04 utility in z/OS:

- Generate work data space


- connect from subsystem TBX1 to work data space

*,TBX1,0 - initialize work data space


- load tables (one or more load commands)




- activate work data space as work data space 1


The reload of single tables directly into the data space can be done with the utility TABN04. The 'old' table is marked with a delete flag after the loading of the new table, but the memory is not yet physically released.

Example call TABN04 utility:

- reload a table into data space 1



If the data space has to be reorganized, the work data space must be used. You can use TABN04-SHSOCC to call the reorganization depending on the database occupation in %.

Example call for reorganization in z/OS (in German):

- generate work data space


- connect from subsystem TBX1 to work data space


- initialize work data space


- copy active data space into the work data space


- reorganize the work data space


- activate work data space as data space 1


To control in which sequence the SHS data spaces are scanned for the called tables, the following SHS path specifications must be set:

  1. subsystem ID

  2. a maximum of 10 data spaces in the wanted scan sequence

  3. project IDs to map two or more environments in one data space. For that purpose tables with the same name can be loaded with different IDs into the data space. Then the project ID can be used to define the sequence of the scan.

Depending on the system environment, there are different ways to specify the SHS path definitions:

  • as parameters (constants or variables) of a program which is called with a fixed name by the TABEX access interface

  • as environment variables with fixed name

  • at the start of the access system (CICS)

  • set by a function call in the application program

To learn more about data spaces in general and the path definitions in particular, please consult BOIDOC-201. Details on load commands of SHS utility TABN04 can be found in BOIDOC-206.

A holder task (TABEX utility TABN14) must be executed for each subsystem. This holder task manages the subsystem and its data spaces. This task should run 24 hours a day without interruption and should not be shut down. If the holder task is shut down, all the loaded data spaces are no longer available.

Abb.: Maintenance of the data spaces

The administration of data spaces is executed by TABEX utility TABN14:

  • start and stop of a subsystem

  • deletion a data space

  • reorganization of a data space

  • start and stop of the holder task


Changes in ESA data spaces, efficient migration and a new success story: Learn more in our newsletter!


Migration Packages

BOI GmbH offers migration packages for the table management systems SPITAB, TABSYS and VTAS.


» Migration Packages

Success Stories

GDIS and BOI: Carrying on the Success

With TABEX4 JTC, GDIS has introduced the world's fastest Java interface for table access on customer and control data. Learn the details in our new Success Story.


» read this Success Story

» read more Success Stories