Skip to main content
Support

KB Article #179955

Table Server functionality and clean-up procedure

Problem

Table Server functionality and clean-up procedure

Resolution


The Table Task is a temporary storage of acknowledgement references, like:

OFTP - EERP

X435 - PN/NN

EMAIL - MDN/DSN

EDIFACT - CONTRL

X12 - 997

and can also be used by Integrator users by using the calls:

MBC_HIERCHMSGENV.CorrelationWrite/Read/Delete

Now, the Table Task is storing all these tag/value pairs in a big hash table, which consist of a number of files for persistence of the table values (hash backup files). These files exist under $CORE_DATA/table/xxx/t0000001 and so on.

If there are remaining table entries that are not deleted, due to bad programming or other strange runtime events, they will never disappear. Furthermore, those old entries will cause the table files to grow in numbers. It is enough to have one old entry left in the oldest table hash backup file, and the Table Task will not delete it, and thus not delete any subsequent table files.

This is an un-normal situation, and should be analyzed carefully in order to detect the reason for the remaining table entries. Quite often remaining table entries coincides with active log entries. Compare the date of the oldest table files and active log entries.

There is a program called read_table.x4 which will read the contents of the Table Task files. The program can be obtained separately, through support.

Run the program by:

$ r4edi read_table.x4-> no parameters should be needed.

Example of output is:

CORE_TA:mmcpheat2-000000018157: {"X420000000004958"} or

CORE_TA:X420000000004701: {"X420000000004701","mmcpheat2-000000017646","167:1-1","0","0","2","MMCPHEAT2UA","KENNYUA",0,{2,1,"c:\\xib\\data\\tmp\\196826",0,42,{0,{0,"","",0,0,0,0},0,0},{0,{0,"","",0,0,0,0}}}}

If there is remaining entries from some Transfer Adapter, try to find the corresponding Transfer Id in the Message Log and analyse why the Ack is not returned, for instance.

Once the Table Task is properly analysed and the faulty program fixed, or a proper support case is logged, it is time to clean out the Table Task.

To be 100 % sure that you can clean up the Table server, make sure that Table server files (hash files) are older than the longest timeout is for your acks. Typically a week for EDIFACT CONTRL messages...Also compare with your Message Log archiving frequency. If you archive all entries older than 14 days, there is never any reason to keep hash files older than 14 days. And make sure that there are no active log entries older than the table files you delete.

Currently, besides read_table.x4 there is also a GUI tool (Table Utility) easier to use, which doesn’t require command line access.

There are 3 methods you can use in order to purge the Table server:

  • Automatically, using TABLE_OPTIONS

From the table server 1.0.4, it is now possible to clean the table server automatically, by setting a specific start option. The start option is

"-R time"

"This option has the effect that the Table server automatically deletes records that have become older than the specified time option argument. The time option argument should consist of a decimal number followed by an s,m,h or d character, indication that the time is specified in units of seconds, minutes, hours, or days, respectively. Note that for Integrator 2.1.1, without the patch CORE_211_03-11-xx , each individual record does not have a time stamp, instead all records in a file are considered to have the same time as the modification time for the file containing the record. With the patch CORE_211_03-11-xx , every record has a timestamp.”

Adding start options to the table server is usually done by:

  • Either by Adding the environment variable is introduced, TABLE_OPTIONS.
  • Or from the GUI, TaskManager -> choose Table Task->go to Configuration tab-> Data directory-> Advanced button

"Before processing the command line options, the Table server processes the options specified by the TABLE_OPTIONS environment variable." Typically this environment variable is set up in the $CORE_LOCAL /config/environment/dat or in the $CORE_LOCAL/bin/core_setup file.

For example to setup the Table server to delete table entries that are older than 10 days, assign the TABLE_OPTIONS env variable like this:

TABLE_OPTIONS="-R 10d"

You now need to restart the complete Integrator servers (core_servers stop/start on UNIX) with this new env variable set, to make it work.

2. Using xib_clean.x4 -t (clean tables)

Step-by-step:

1.start Integrator, StartAll in TaskMonitor

2.go to $CORE_DATA/bin and run the command r4edi xib_clean.x4 -t

3.you will be asked to stop the Integrator server before the command will be executed

4.after the command execution, go to Integrator instaladion directory and$CORE_DATA/table subdirectories-> normally the old files should be deleted and only one new table file (automatically generated atfer the serever restart)

3. Manually

The last method to clean up the Table server involves stopping and starting all Integrator runtime tasks to work. Analyse the Table server directory and look at the dates of all Table server files.

Here is an example of a Table directory:

2002-10-1615:411 048 576 t0000002

2002-10-1623:051 048 576 t0000003

2002-10-1623:161 048 576 t0000004

2002-10-1708:441 048 576 t0000005

2002-10-1710:471 048 576 t0000006

2002-10-1714:191 048 576 t0000007

2002-10-1715:281 048 576 t0000008

2002-10-1715:281 048 576 t0000009

2003-04-2313:541 048 576 t000000a

2002-10-1813:531 048 576 t000000b

Usually it is enough to take away the oldest file and then see what happens. The Table Task will clean up all empty files up until the oldest remaining non-empty file.

Step-by-step:

1. Stop Integrator, StopAll in Task Monitor

2. Goto $CORE_DATA/table/xxx

3. remove the oldest table file, in the example above: rmt0000002

4. Start Integrator, StartAll in Task Monitor.

5. Analyse how many table files remain, once the table server has started properly, maybe the whole procedure needs to be done again if too many files still remain.