WIKI Search


TABEX4 general topics

What do I need to comply with the upgrade to a new release?


Upgrading to a new TABEX4 Release, applying fixes, as well as configuring TABEX4 often comes with questions concerning the control tables.

In this chapter, we will introduce you to the concept and approach on the individual cases.

TABEX concept for upgrading control tables

In TABEX4, custom control tables are strictly separated from system control tables.

This concept enables a smooth upgrade to new releases. In addition, it creates safety for the customer when it comes to editing control tables in order to configure the product.

System control tables are maintained by BOI only. They are always stored in BOI Databases. For pre-chained custom databases, the adaption of system control tables is only permitted on explicit instruction given by the BOI Support.

Custom control tables are initially stored in the BOI databases as well. Per default, they are either empty or contain sample entries.

The configuration

Usually, you edit your custom control tables via the admin menu item "edit control tables" provided by the TABEX4 Table Manager.

However, some control tables come with their own menu item, for example, "administration → databases → TABEX database → edit database usage". In addition, some functions of the Admin GUI will edit your custom control tables as well.

After editing a custom control table with one of these methods, the table is stored in the pre-chained custom database.

When the control table is loaded by TABEX4, the custom database will always take priority over the BOI Database. This ensures that your custom adaptations will come into effect, while the original table is left ineffective.

All tables that do not have the BOI name scheme are custom tables as well, and you can edit them via the admin menu item "edit control tables".

All you need to do is to enter them in a table list. The admin menu items "add customer control tables" and "add customer control tab. text" are available for this purpose.

Upgrade procedure

Upgrading to a new release replaces the BOI Database - and hence, all system control tables.

We recommend to keeping the custom control tables stored in the pre-chained databases. This ensures, that the complete configuration will stay effective on the new release.

Sometimes, a release upgrade requires adaptations of the custom control tables. You can use batch job ADAPTCTL to process that widely automatic.

With that, it is also possible to skip intermediate releases without having to install each one temporarily.

In rare cases, you may need to adapt control tables manually. Please note: You will have to manually adapt intermediate releases as well, even if you skip them.

ADAPTCTL and manual adaptations are described in BOIDOC-250...(the corresponding version for the latest release).

Process for pre-releases and fixes

Adaptations for installed releases are provided by BOI in the form of control tables and program tables. We recommend to apply these adaptations to the pre-chained custom databases at first.

In case that testing the adaptations in the customer environment fails, you can easily remove the adaptations by simply deleting all inserted tables from the pre-chained databases.

Please note: After successfully testing, you need to move all inserted system control tables from the pre-chained databases to the BOI Databases chained behind. This is necessary to avoid issues at the next release upgrade.

If you leave the system control tables in the pre-chained custom databases, they will take precedence over the newer and possibly adapted system control tables of BOI in the next release. This situation can cause various system malfunctions and is laborious to correct.

All functionalities of pre-releases and fixes provided for a certain release are integrated to the latest development status. Thus, they are automatically effective in the following release.

In case a customer's installed version is not the latest release, the adaptation is usually not available for the already published releases. Instead, it will be effective in the following release.

See also:


What are TABEX Views?

TABEX Views are views on data of relational databases or TABEX Databases.

You can create TABEX Views by defining a SELECT statement analogous to views in relational databases.

In order to be able to define a TABEX View onto a table of a relational database, the table must exist as SQLT table. SQLT tables are TABEX Tables connected to a relational database.

The SELECT statements of relational database views and TABEX Views are, as far as possible, similar in syntax and options.



Please note: Views cannot be edited. They serve displaying purposes only.

See also:


What is TABEX4 JAVA ACCESS Remote Connection Factory?

Load balancy and reliability

Together with the TABEX4 JAVA ACCESS Products TABEX4 JAVA ACCESS flexible and TABEX4 JAVA ACCESS unlimited, the so-called TABEX4 JAVA ACCESS Remote Connection Factory is provided. You can use it to implement load balancy and reliability for data accesses executed by your applications.

Remote Connection Factory details

Gain an overview of the Remote Connection Factory in the following PDF:

TABEX4 Java Access & Remote Connection Factory


  • You may call TABEX APIs for read access via TCP/IP only.
  • The interface cannot be used to change any data.
  • The data you want to access must be identical on all participating call servers (services BOITPSV). You can ensure that by, e.g., replication.

Which application servers are supported?

TABEX4 supports the following application servers (the versions maintained by the vendors respectively):

  • Apache Tomcat
  • IBM Websphere
  • JBoss

TABEX4 Table Manager prerequisites

A servlet/JSP engine must be installed.

Minimum requirements:

  • Servlet 2.5
  • JSP 2.1


Known bug in Tomcat
A bug affecting the JSP compiler of the Tomcat servlet container caused, that the main area of the TABEX4 Table Manager main interface could not display any content.

The following Tomcat versions are affected by that bug:

  • 8.0.8 (fixed in 8.0.9)
  • 7.0.54 (fixed in 7.0.55)

Bug link:

Which options do I have for checking table data?

TABEX4 offers several mechanisms to check table data:

  • Checks via check tables
  • Referential integrity checks (RI check)
  • Key checks
  • Routines for field checks

Checks via check tables

You can define rules for data checks in the form of so-called check tables.

With these check tables, you may, for example, limit the data input to particular values or value ranges.

In addition, you can work with a great number of check operators to implement custom check sequences.

To implement checks that go beyond the capabilities of the standard check operators, you can use programs called via exit operator. Also, you can call exteral check programs.

If a rule is violated, the modified table cannot be stored and a message is displayed.

Sample of a simple check table:


In this sample, the two fields PRODNR (product number) and PRODNAME (product name) are checked.

The content of field PRODNR must be >= 1000 and <= 9999. If this is not the case, a message with key MSG001 is searched in message table MYMSGTAB. This message is then displayed.
In addition, field PRODNAME must not be empty. If this field is empty, a message with key MSG002 is searched in message table MYMSGTAB. This message is then displayed.

You can find a detailed description of this feature in BOIDOC-201, section "Checking the Input (Check Tables)" of chapter „Table types“.

Referential integrity checks (RI check)

The RI check ensures that data of an underlying data model are consistent.

It does not allow to input values that are not existing in the assigned parent tables (join check).

And it prevents the deletion of key values that are in use in child tables (delete rule).

If a rule is violated, the data cannot be updated and TABEX4 displays a message.

Key checks

This check ensures the key values of tables to be unique. Multiple keys of the same value cannot be stored and a message is displayed.

Field check routines

To check field contents, you can create check routines that are executed during the save action.

You can define check routines by a setting in the field definition. (See BOIDOC-201, chapter „Field definitions“, description of FLD_VERI.)

By default the check routines are entries of a SSL program named $TBXC_$FDV.

The called entry is ENT_x, where „x“ is the defined character of FLD_VERI.

Details about the required entry parameters are described in BOIDOC-201, chapter „Field definitions“


See also:


What is SHS adressing?

SHS adressing enables to store data centrally in the main memory and grants shared access on that centrally loaded data for multiple applications.

For zOS, Common Dataspaces are used as central memory. For Unix, Linux and Windows, it is Shared Memory.
In TABEX4, the terms „SHS Dataspace“ resp. „Dataspace“ are used as general definitions.

Storing data centrally guarantees, that it is always the same copy of a table which is adressed in the various applications.
Furthermore, applications do not need to access the database directly.

Thus, applications can access data in a high-performance, CPU-saving way.

For zOS, TABEX4 uses the Enterprise System Architecture (ESA) of IBM:

IBM's Enterprise System Architecture has made it possible to use dataspaces along with address spaces.

TABEX uses this additional functionality to load tables to dataspaces and address them for read accesses of applications.

Thus, the access performance can be significantly increased by the sharing of tables loaded in memory by several application regions.

Using SHS technology in TABEX4 offers the following benefits:

  • Read accesses with high-performance calls.
  • You can load, reload, or reorganize dataspaces without affecting any applications (uninterrupted switch between active dataspace and work dataspace after reloading and/or reorganizing a dataspace).
  • No synchronization required.
  • Separate dataspaces for different integrated organizations (multi-tenancy) analogous to IMS and Db2.
    To distinguish between the tenants, you can use different search paths and project IDs.
  • Several dataspaces can be active simultaneously and be filled with different tables.
    You can control the search order for, e.g., instances, tenants, environments, by using path definitions specific to an application (which define the search path) and project IDs.
  • By addressing each table by name, date and file ID, you can put it under version control. Furthermore, you can depict your IT organization by using organizational access control.
    Using an additional project ID gives you the possibility to use various instances or test stages. This ensures to access the appropriate version of a table always.

Organizing and maintaining SHS dataspaces

A subsystem with a 4-digit subsystem ID allows you to create up to 16 dataspaces. The TABEX names of the dataspaces are single-digit (digits or capital letters).

For zOS, you need to define the subsystem in the operating system. A holder task assigned to that subsystem creates the dataspaces and ensures their availability for applications and TABEX4. By using MVS modify commands or TABEX Utility commands, you can create and delete dataspaces.

In operating systems other than zOS, you can maintain SHS dataspaces by using the TABEX Utility TABN14.

Holder tasks for SHS dataspaces are designed for 24-hour use and must NEVER be stopped! Otherwise, the dataspaces may be abruptly unavailable for applications. This will cause numerous exceptions and interrupt all (!) applications that access TABEX4 Dataspaces!

Application control through SHS paths

The SHS paths are provided for mapping different clients, test stages and instances.

You can insert them into the TABEX Access interfaces independently of the application programs.

An SHS path specification consists of:

  1. Subsystem ID: Specifies the subsystem that contains the dataspaces defined in the access path.
  2. Access path: A maximum of 10 dataspaces in the order you want search them for called tables.
  3. Project ID: Arbitrary number of file IDs. Table versions are searched in advance with these file IDs in the specified order.



Access path=21
Project ID=TEST

On accessing the application program with file ID TABVSAM, loaded tables are searched in the following order:

Table with file ID TEST in dataspace 2 of subsystem TABX

Table with file ID TABVSAM in dataspace 2 of subsystem TABX

Table with file ID TABVSAM in dataspace 1 of subsystem TABX
(Only the first dataspace of the access path is searched with the project IDs by default. You can extend this to further dataspaces.)

Depending on the system environment, you have various options to specify SHS path definitions:

  • in the zOS batch as program TABEXSSI. It returns the specifications to the caller (= TABEX4 Access routine).
    A sample sourcecode (Assembler) for that program comes with your TABEX4 Installation.
  • in non-mainframe environments as environment variable BOICLSSI
  • in CICS as control data when the access system is started by the TABEX4 Start transaction
  • generally except in CICS by function call in the application program

You can find a detailed description of the SHS path specifications with examples in BOIDOC-201, section "Description of the SHS access specifications".

Loading tables to SHS dataspaces

The dataspaces 0 and S have special meaning:

  • S is defined as statistic dataspace. It stores access counts.
    You can execute the activation, deactivation and report of the statistic counters with utility TABN04.
  • 0 is the work dataspace. It is used to provide uninterrupted data access during reloading or rebuffering data.

During a reload, the work dataspace containing the new data is loaded first. After successful loading, the new data is activated by a switch (name interchange) between work dataspace and active dataspace (e.g. dataspace 1).

If the work dataspace is used for several numeric dataspaces of various sizes, you need to regenerate one for each in the required size before loading.

If a switch is to be executed, we recommend regenerating the work dataspace before every loading, even when the dataspaces are of the same size. The switch will transfer the assignment configuration for the 'paging' as well.

Sample process of utility TABN04 for zOS:

  • Regenerating the work dataspace
  • Establishing a connection to the work dataspace of subsystem TBX1
  • Initializing the work dataspace
  • Loading tables (one or more load commands)


  • Activating the work dataspace as dataspace 1

You can rebuffer tables directly to the dataspace with TABN04, command N.

The 'old' table is marked with a delete flag after loading the new table, but the memory is not released physically.

Sample process of utility TABN04:

  • Rebuffering a table in dataspace 1


If the dataspace has to be reorganized, you need to use the work dataspace again.

You can use e.g. TABN04-SHSOCC to define a job that is dependent on the database occupancy. This job will call the reorganize function when the defined occupancy is reached.

Sample process of reorganizing zOS:

  • Recreating the work dataspace
  • Establishing a connection from subsystem TBX1 to work dataspace
  • Initializing the work dataspace
  • Copying the active dataspace to the work dataspace
  • Reorganizing the work dataspace
  • Activating the work dataspace as dataspace 1

By using TABEX4 Utility TABN14, you can administer the dataspaces as follows:

  • Start and stop a subsystem
  • Delete a dataspace
  • Reorganize a dataspace
  • Start and stop the holder task


See also:


How are SHS dataspaces implemented in TABEX4 Windows?

In TABEX4 Windows, SHS Dataspaces are implemented as shared memory segments in the form of Windows file mapping objects.

To provide access on that global system objects for TABEX4 Services and Programs of newer Windows versions, you need to adapt the configurations as described below.

Windows permissions

You need to assign the Windows permission "Create global objects" to user IDs that run TABEX4 services or batch and console programs.


TABEX4 System Parameters

To address objects of the global namespace and not objects of, e.g., the own session, you need to adapt the TABEX4 System Parameters (file boiparam.txt in TABEX4 subdirectory "sys"): Set the entry WINOBJ to prefix "Global\".

You may find the required entry in commentary brackets in the parameter file. In that case, you need to edit the comments to activate the required entry and deactivate the current one.

Otherwise, you need to adapt the current entry or add a new one.

General technical questions

What is the Deployment Cockpit?

The Deployment Cockpit is a convenient graphical user interface for defining and parametrizing TABEX Servers used for the Web Application.

For this, open the web application file provided by BOI (file with WAR or EAR extension). Click the button "Connection settings": Now, you will see a list of all TABEX Servers that are displayed on the login screen.

The parameters of the individual server connections are displayed clearly and grouped for each connection.

You can specify the following parameters for each TABEX Server:

  • Monitor settings (host, port, timeout, ...)
  • Debug settings (debug and trace level, log path, ...)
  • Layout settings (behavior of the scroll bar, ...)
  • RACF monitor settings (host, port, timeout, ...)

To minimize your configuration effort, you can define default values, which will be used for parameters whose values have not been changed.

You can assign the server connections to different groups. These assignments are displayed in a well-arranged matrix. A server connection can be assigned to several groups.

During editing, you can temporarily save your definitions. It is possible to switch to an older, temporarily stored definition within the active session (undo).

After having finished configuring, you can create the web application file including your settings by saving the WAR / EAR file.

Use function „Save configuration“ to save your settings. You can re-use them for the next release as follows: Open the new WAR / EAR file and load your defined settings with the function  „Open saved configuration“. Then, save the new WAR / EAR file.

How do I define a summary database used in a TABEX4 browser application?


You need to take the following steps:

  • Define the partial databases of the summary DB in the alloc script in Unix directory "etc"with the following command:
      ALLOC FI(ddname) ...
  • Enter the DD name of the file containing the summary specifications in the sysparm of the web application. The sysparm is defined in file, folder WEB-INF of your TABEX Application.
    Example: You want to name the file, that contains the summary specifications, DDDEFS. Thus, you need to extend the sysparm with an entry "CTDD":
  • Now, add this file (DDDEFSin our example) to the alloc script as well. Please make sure to add it as text file with fixed record length 80:
      ALLOC FI(DDDEFS) ...

See also:



  • NameSummary-DB ... MYSUM
  • Name 1st partial DB ... MYPARTA
  • Name 2nd partial DB ... MYPARTB

The entry in file DDDEFS needs the following structure:

For a summary DB:





For a chained summary DB:





Which allocation levels are available for TABEX Databases?

General information

When a user logs in, a new TABEX4 Monitor session is started, in which allocations of databases are executed in several stages.

The following levels of allocation are available:

  1. Monitor allocation script (zOS) or JCL file (Unix, Linux, Windows)
  2. Dynamic allocation table of the session (sysparm settings)
  3. Dynamic allocation table of the user (user profile settings)
  4. Dynamic allocation table of the instance (instance configuration settings)

By implementing exits, further customer-defined allocations are possible.

Please note: If you allocate a file for a DD name, you must not use that DD name for any further allocation, neither in the same level, nor in any other.

Level 1: Monitor allocation script (zOS) or JCL file (Unix, Linux, Windows)

After a new session has been started by the monitor, the session executes the commands defined in a script/JCL file.

Details see: BOIDOC-226_Tcpip-monitor (for zOS) and BOIDOC-224_cs_admin (for Windows, Unix, Linux), as well as the sample for Level 1 (see below).

Level 2: Dynamic allocation table of the session (sysparm settings)

If keyword SESALCID is found in the sysparm, further session allocations from a TABEX Table (“dynamic allocation table “) are executed.

Details see: BOIDOC-209a_Config and the sample for Level 2 (see below).

Level 3: Dynamic allocation table of the user (user profile settings)

If keyword DYNALC is found in the user profile (or in a copybook embedded in the user profile), user-specific allocations from a TABEX Table are executed.

Details see: BOIDOC-209a_Config and the sample for Level 3 (see below).

Level 4: Dynamic allocation table of the instance (instance configuration settings)

If keyword DYNALC is found in the instance configuration table, instance-specific allocations from a TABEX Table are executed.

Details see: BOIDOC-209a_Config and the sample for Level 4 (see below).

Additional custom-defined allocation levels (exit implementation)

You can encode further allocations as custom exits, for example between level 3 and 4, by an instance initialization exit.

Details see: BOIDOC-209a_Config

Allocations of TABEX4 Delivery Databases

The following TABEX Databases and their concatenation databases must be allocated in Level 1:


At the latest in level 3, the following TABEX Databases and their concatenation databases MUST BE allocated:


Details see: BOIDOC-209a_Config

Allocation sample for Level 1

Monitor allocation script for zOS


JCL file for Unix, Linux, Windows

FILE = INTSRC '<tabexcus>/.tdb'<tdb>
FILE = INTMOD '<tabexcus>/.tdb' <tdb>
FILE = OPSMSG '<tabexcus>/.tdb' <tdb>
FILE = TABLGG '<tabexcln>/.tdb' <tdb>
FILE = TABLGE '<tabexcln>/.tdb' <tdb>
FILE = TABCTL '<tabexcus>/.tdb' <tdb>
FILE = APPLGG '<tabexcln>/.tdb' <tdb>
FILE = APPLGE '<tabexcln>/.tdb' <tdb>
FILE = INTSRC1 '<tabextdb>/INTSRC.tdb' <tdb>
FILE = INTMOD1 '<tabextdb>/INTMOD.tdb' <tdb>
FILE = OPSMSG1 '<tabextdb>/OPSMSG.tdb' <tdb>
FILE = TABLGG1 '<tabexlng>/TABLGG.tdb' <tdb>
FILE = TABLGE1 '<tabexlng>/TABLGE.tdb' <tdb>
FILE = TABCTL1 '<tabextdb>/TABCTL.tdb' <tdb>
FILE = APPLGG1 '<tabexlng>/APPLGG.tdb' <tdb>
FILE = APPLGE1 '<tabexlng>/APPLGE.tdb' <tdb>

Allocation sample for Level 2

sysparm = SESALCID=XY

When this sysparm statement is added to file, single version table $TABI4ATXY is searched in database OPSMSG and the allocations defined therein are executed.

The structure of the entries of single version table $TABI4ATXY is similar to these of the monitor allocation script for zOS and the JCL file for Unix, Linux, Windows shown in the sample for Level 1.

Allocation sample for Level 3

Entry in profile of user BOI

When entry DYNALC = DYNALC_BOI-99999999(OPSMSG) is added to the profile of user BOI, single version table DYNALC_BOI is searched in database OPSMSG and the allocations defined therein are executed.

The structure of the entries of single version table DYNALC_BOI is similar to these of the monitor allocation script for zOS and the JCL file for Unix, Linux, Windows shown in the sample for Level 1.

Allocation sample for Level 4

Entry in the instance configuration table

When entry DYNALC = DYN_INST05-99999999(OPSMSG) is added to the configuration of instance $ICFG_005, single version table DYN_INST05 is searched in database OPSMSG and the allocations defined therein are executed.

The structure of the entries of single version table DYN_INST05 is similar to these of the monitor allocation script for zOS and the JCL file for Unix, Linux, Windows shown in the sample for Level 1.

How do I create a dump of a TABEX4 browser session under zOS?

Requirements and preparations

In order to analyze an error, BOI needs the following information:

  1. Log files containing informaiton about the abort (register contents, call context)
  2. Formatted dump

Please note: All files have to be created with the same browser session. Otherwise, the analysis is not possible.

Log files

You can set the log file directory and names with the following monitor parameters

By setting standard values, the log files are created in directory logs of the TABEX4 USS directory:

?HFSP? is the TABEX4 USS directory. The monitor replaces %u with the session number.


The system prints the dump in a file allocated as SYSUDUMP. For this, you need to take the following measures:

Change the call parameter for the session monitor in the start JCL:
Change the language environment option TRAP(ON) to TRAP(OFF), e.g.:



Please note: For normal operating state, TRAP(ON) is required. TRAP(OFF) prevents the delivery of signals in Posix applications.


Add the ALLOC statement for SYSUDUMP in the alloc script of the monitor sessions:
When using the default monitor parameters, the script is located under the name alloc in subdirectory etc of the TABEX4 USS directory.

Dump file format

Organization: PS

Record format: VBA

Record length: 125

Block size: 1632

How do I define rules for assigning table names?

You can define rules for assigning table names by using a check table. To create it, you need to:

  • assign the check table with the function administration / application / general settings / assign check table
  • create the check table in database TABCNT via the TABEX4 Console or the functions
    TABEX database / new / create copy of table and
    TABEX database/ management / edit without data checks

    Specify the table name as field TI_TABLE, the version date as TI_FROMDAT and the version info as TI_INFO.


  • Assign the check table:
    Table: $TAB4PT001
    Control table: ctrltab (the name of the check table is freely selectable).
  • Sample of a check table:
 MSName must consist of ABCDEF


TABEX4 Table Manager topics

What are the elements of the TABEX4 Table Manager?

The TABEX4 Table Manager consists of the following segments:

  1. Navigation bar
  2. Login-/Logout area
  3. Explorer menu
  4. Separator to show or hide the explorer menu
  5. Icon bar
  6. Selection list "more actions"
  7. Active panel (with red border) currently focused. In the figure below, the panel containing the table is currently active. The table maintenance panel underneath is inactive.
  8. Filter area to apply row filters. You can use operators for enhanced filter methods.
  9. Dialog panel containing the table
  10. Functions for filling/emptying the table maintenance dialog
  11. Selective panel to display the table maintenance or modification formula dialog. In the figure below, the table maintenance dialog is currently displayed.
  12. Area for TABEX4 system messages.

The selection list "more actions" offers additional functions that are not displayed via icon, e.g. "import from XLS-file (add)".

In addition, there are group icons that display or hide further icons:

This icon displays the icon group of sorting operations.


This icon displays the icon group of row operations.

This icon displays the icon group of column operations.

This icon displays the icon group for functions of the table maintenance and modification formula dialog.


When you display a group of icons, they will stay visible during a session even when you select other menu items of the TABEX4 Browser Interface (e.g., "edit table", "display table", etc.)

In the TABEX4 Help, section "Basics", you can find further information on the interface, icons, more actions, filter operators, and table maintenance and modification formula functions.

What is the advantage of combining several TABEX Servers to groups?

You can group the TABEX Server configurations that are accessed by the TABEX4 Table Manager.

The advantage of this method is, that a server definition can be used for multiple groups, without the need to create several TABEX4 Table Manager deployments with repeated server definitions.


See also:

What is the Deployment Cockpit?



How can I change the colors of the navigation bar and the background?

You can set the color of the navigation bar and the color of the background of the TABEX4 Table Manager via the instance parameters INSTNAVOL and INSTBCOLOR. In addition, you can use instance parameter INSTLOGO to specify an image which is to be displayed in the browser window of the TABEX4 Table Manager.

You can find further information about the parameters in BOIDOC-209a_Config.

What can I do to display the TABEX4 Web Application window in maximum size on Windows?

Displaying the TABEX4 Web Application

The TABEX4 Web Application opens in a new browser window without a menu and navigation bar. MS Windows does not support opening this browser window to its maximum size.

Therefore, the TABEX4 Web Application can not automatically use the entire screen for display.


The index file displayed in the browser is at its maximum size in the following figure, but the opened login window is displayed in a reduced size:

The started TABEX4 web application is also displayed in a reduced size:


If you try to maximize the application by icon, you get the following message:


 If you cancel the dialog by pressing the "Cancel" button, the display remains small.

If you press the "OK" button, the display will adapt. However, if the browser window is closed, the next time TABEX4 is started, the original small browser size is effective again.

Thus, after closing and reopening the application, the login screen is displayed in reduced size:

Solution / Workaround

MS Windows remembers the size of the browser window that was opened first.

In order to display the windows of the TABEX4 Web Application as large as possible, the size of the first window must be set manually.

To do this, carry out the following steps:

Minimize the login screen

Reduce the login screen by clicking on the "Reduce" symbol on the left side of the red "Close" symbol.

Make the window larger

Manually maximize the window by dragging the corners of the window to the outer edge of your screen, until the window fills the entire screen. The "Maximize" icon should still be displayed:

Close browser, start TABEX4

Close the browser and start the TABEX4 Web Application. MS Windows has saved the browser window size.

The login screen and application will now be displayed in the size you have defined before:

See also:



What are the settings for export / import / print?

You can configure the export / import / print settings with the function "settings for print and import/export" (can be selected via the selection list "more actions" or via the menu item "settings"). Please note: These settings are only temporarily effective during the active session.

You can set the following parameters for export / import / print:

Print mode
You can set either CSV, PDF, TEXT or XLS for the print mode. This setting determines whether the "print" icon resp. the Ctrl + P hotkey generates a CSV-, PDF-, text- or MS -Excel-file.

Content of the PDF info on the cover page
You can enter a four-digit combination of Y (for display) and N (for hide):

  • The first letter indicates whether the selection criterion is displayed.
  • The second letter defines whether the field names of the unprinted fields are also displayed on the cover sheet.
  • The third letter indicates whether the sorting criterion is given.
  • The fourth letter defines whether the (original) field numbers of the table are displayed before they are rearranged.

PDF row number output
You can enter the following values:

  • 'D' (print row numbers if row numbers are displayed)
  • 'P' (do not print row numbers)
  • 'Q' (always print row numbers)

PDF page layout portrait/landscape

  • Specifying PORTRAIT prints in portrait orientation.
  • Specifying LANDSCAPE generates a PDF in landscape format.

Attention: The PDF page format affects the PDF printing and PDF export.

CSV import separator, CSV export separator

  • ';'
  • ','

Export mode

  • 'CSV'
  • 'PDF'
  • 'XLS'

Import mode

  • 'CSV'
  • 'XLS'

Export/Import/Print XLS(X) files

Exporting table data is a popular feature of the TABEX4 Table Manager.

The following options are available:


  • Printing as CSV, PDF, XLSX, or text file

  • Output of the editor settings as PDF

  • Export as CSV and PDF

  • Import CSV in "Replace" or "Add" mode


The export, import and print of MS Excel documents in .xls and .xlsx formats offer a convenient option:

During printing and exporting, MS Excel documents (in .xlsx format) are generated, which can be edited and saved in MS Excel.

The great advantage is that TABEX4 generates the MS Excel document directly when exporting and sets the appropriate data formats and displays for each table column. This way, MS Excel does not make automatic data format changes. Thus, a correct import of .xls and .xlsx files is possible.

The export / import process with TABEX4 and MS Excel is shown in the following figure:

You can use an additional system parameter XLSRGTTRIM when printing and exporting from TABEX4 to control whether following spaces in a cell should be cut off in order to enable a more compressed display in the MS Excel document.


See also:



Batch Jobs

I need to pass a parameter to a job, but the placeholders are not correctly replaced by the parameter’s value.

You need to pass a parameter to a batch job. You would like to define that parameter in the system settings.

To achieve that, follow this approach:

  • Use the placeholder in the job input table.
    For example: ‘database=&actdb’
  • Define the parameter in the job parameter table.
    For example: PAR=ACTDB; VAL=&P:DD_DEFAULT
  • Define the parameter in the in the user settings, instance configuration, or system settings if this has not already been done.
  • After selecting the job, the parameter values are displayed. Thus, you are able to check, whether the placeholders have been replaced correctly by the parameter values.

If the parameterhas not been replaced, consider the following:

  • The allowed length of placeholders which might be used for the input template is limited to 8-digit names.
  • Thus, you may need to shorten the parameter to 8 digits maximum.
  • In addition, you will need to correct the parameter in the parameter template, as well as the placeholder in the input template.

See also:


Exits/Protocol Exits

I want to call an exit after table selection, but before table maintenance. How can I do that?

To call an exit between table selection and execution of a selected function, e.g., table maintenance, define the exit via control table $TAB4PTC24. You can find details about control table entries and a sample in BOIDOC-209a_Config.

See also:


How do I display a self-defined message in an exit?

How do I determine the currently active instance within a protocol exit?

You can determine the current instance via the TABEX4 Interface.

For this, you need to import the TABEX4 Interface to your exit program by using "%use $TAB4PTINF". That allows you to determine the currently active instance by using  "$TAB4_INTF.getInst()", e.g.:



dcl instance char(08)

instance = $TAB4_INF.getInst()


See also:


TABEX4 Protocol Databases (TABPRO, TABCMP, TABPCA)

What kind of data is stored in the databases TABPRO and TABCMP?

What kind of data is stored in TABPRO?

TABPRO stores protocol entries. Those are no tables, but comparable to status entries. Thus, they are not visible in the table catalog.


What kind of data is stored in TABCMP?

TABCMP is stores associated difference tables resp. utility protocols. You can display them by clicking menu item revision/display protocol entries.

See also:


What is the estimated data volume of the protocol databases TABPRO and TABCMP?

The actual data volume is highly individual and depends on the amount of protocolled actions, resp. which actions are protocolled in TABCMP.

You can configure this with the functions of menu item administration/protocol entries.

Information about protocol entries in TABPRO:

  • You can store 20 single entries per database record.
  • When you combine to $TAB4PTPRA versions, you may store approx. 100 entries per database record.


See also:


TABEX4 Utility functions

When I try to display the protocol entries resp. TBVW01-PROTREP, I get the message 'Second comparison table not available'. What does it mean?

Whenever actions are logged, TABEX4 creates a differential protocol as soon as an already existing table version is overwritten due to that action. You can display the differential protocol with the menu item “display protocol entries”.

If there is no former table version (hence, the table version is newly created with the logged action), TABEX4 cannot create a differential protocol. In that case, you will get the message mentioned above if you try to display the protocol entry for the action (in our case “online transfer in production” or “batch transfer in production”).

To compare different versions of a table, use the functions of “display table”.

When I execute utility functions, I get messages without any text. What should I do?

When the text of the messages ERRnnnn, INFnnnn and SECnnnn is not displayed during utility operations, the reason might be missing databases allocates for the APPLNG chain.

Check your settings and edit them if necessary.