Using XCOM for Linux History inserts file XCOMHIST_FILE without any database
search cancel

Using XCOM for Linux History inserts file XCOMHIST_FILE without any database

book

Article ID: 422803

calendar_today

Updated On:

Products

XCOM Data Transport XCOM Data Transport - Linux PC

Issue/Introduction

Using XCOM for Linux and want to capture history records.
However the MySQL supported for the XCOM History Database RDBMS is not something normally used in house. PostgreSQL is the standard RDBMS which XCOM does not currently support.
Only need the history records stored somewhere where they can be copied to a central cloud database under AWS.

  1. Is it possible to just force the records into the XCOMHIST_FILE without having a database?

  2. Also if the database is not available, will XCOM retry until the timeout (XCOMDB_SQL_TIMEOUT) set?
    Is this expected to introduce a performance lag or delay in processing further transfers or is this multi-threaded in that the transfers are not impacted by this history table/file update thread?

Environment

XCOM Data Transport for UNIX/Linux

Resolution

Per XCOM Data Transport for UNIX/Linux 12.0 > Installing > Complete Configuration Tasks > Set Up the History Database, XCOM Support set up a History DB configuration in the xcom.glb file but without configuring an ODBC data source name or having an actual database installed.

They installed package unixODBC to get the /lib64/libodbc.so.2 library installed.

In the xcom.glb file having just these 2 parameters changed from their default null values was enough:

XCOMHIST=xcomhist
XCOM_ODBC=/lib64/libodbc.so.2

Also set "XTRACE=10" in the file to check the generated trace file after a transfer.

This is an extract of some relevant trace file lines after a loopback transfer:
*****
        fsmachin.c 13320: Calling Perform_Insert function
        sqlutil.c 5911: Perform_Insert entered: XCOMHIST=xcomhist, XCOMHIST_TBL=xcom_history_tbl, XCOMHIST_USER=, XCOMHIST_OWNER=
        sqlutil.c 5915: XCOM_ODBC=/lib64/libodbc.so.2

...
        sqlutil.c 6782: SQL string cmdstr1 is 4583 bytes
        sqlutil.c 6786: SQL string cmdstr1(1) = <insert into xcom_history_tbl ( StartDate,StartTime,reqno,sysname,sysid,l>
        sqlutil.c 6786: SQL string cmdstr1(2) = <uname,rluname,mode,file,lfile,transfer_id,GregStartDate,GregEndDate,EndD>
        sqlutil.c 6786: SQL string cmdstr1(3) = <ate,EndTime,msg_flag,msg1,msg2,msg3,msg4,msg5,error_message,user_name,in>
...
        sqlutil.c 6786: SQL string cmdstr1(63) = <20',x'20',x'20',x'20','','','','',0,0,x'20','','                        >
        sqlutil.c 6794: SQL string cmdstr1(64) = <                                        ',' ');>
        sqlutil.c 6802: About to SQLConnect user = .
        sqlutil.c 6806: Setting the connection timeout properties=1766020097
        SQL Connect timeout is:XCOMDB_SQL_TIMEOUT = 10:
        sqlutil.c 6811: Time at start of SQLConnect=1766020097
        sqlutil.c 6818: SQLConnect rc = -1, time = 1766020097
        sqlutil.c 6828: SQLConnect failed, 0, user = , [unixODBC][Driver Manager]Data source name not found and no default driver specified
        sqlutil.c 6891: SQL: insert request written to /opt/CA/XCOM/config/history.inserts
*****

Therefore because there is no data source name xcomhist, the connection immediately failed and does not retry or wait i.e. the XCOMDB_SQL_TIMEOUT parameter is then not relevant.
Due to the failed connection then the process immediately inserts the history record into the history.inserts file. Checking that file confirms that record is present.
Therefore the history record insert is part of the individual transfer process and so it should not impact/prevent other ongoing transfer activity from running synchronously.