TABEX4 WIKI

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 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.

Example:

SELECT STAT_CODE,STAT_NAME,CONT_NAME
FROM STATES
LEFT JOIN CONTINENTS
ON STATES.CONT_CODE=CONTINENTS.CONT_CODE
WHERE CONTINENTS.CONT_CODE='EU'

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

See also:

BOIDOC-201_Basis

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

Restrictions

• 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.

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: https://issues.apache.org/bugzilla/show_bug.cgi?id=56561

TABEX4 offers several mechanisms to check table data:

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

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.

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:

BOIDOC-201_Basis
BOIDOC-206_Utility

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.

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

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.

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.

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 boiadmin.properties, 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":

  existing-sysparm-statements,CTDD=+DDDEFS

• 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:

BOIDOC-201_Basis

For a chained summary DB:

Example:

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.

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

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

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.

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.

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.

You can set the log file directory and names with the following monitor parameters
  MON-SESSION-JOBLOG-FILE
  MON-SESSION-OUTPUT-FILE
  MON-SESSION-ERROR-FILE

By setting standard values, the log files are created in directory logs of the TABEX4 USS directory:
  MON-SESSION-JOBLOG-FILE  ?HFSP?/logs/log%u
  MON-SESSION-OUTPUT-FILE  ?HFSP?/logs/out%u
  MON-SESSION-ERROR-FILE  ?HFSP?/logs/err%u

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

Organization: PS

Record format: VBA

Record length: 125

Block size: 1632

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.

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.

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.

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?

BOIDOC-209a_Config

BOIDOC-241_Deployment

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.

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:

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:

See also:

BOIDOC-209a_Config

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'

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:

BOIDOC-209a_Config

BOIDOC-240_AdminInterface

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.
  For example: PAR=DD_DEFAULT; VAL=TABVSAM
• 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:

BOIDOC-209a_Config

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:

BOIDOC-209a_Config

How do I display a self-defined message in an 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.:

[...]
%use $TAB4PTINF
dcl instance char(08)
instance = $TAB4_INF.getInst()
[... 

See also:

BOIDOC-209a_Config

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

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

See also:

BOIDOC-206_Utility

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:

BOIDOC-206_Utility

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 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.