Resolution:
The cause of the problem is that since the procedure to DEFINE  a REMOTE DB2 Table is not documented in a user-friendly manner, the user assumes that while defining a Remote DB2 Table the DB2 Location can be specified via DB2 LOCATION field on the Table Definer Screen. This is not a correct assumption.

The proper way to define a Remote DB2 Table is as follows:

   a)  Notations used:

                      {T} - OSB's DB2 table to define;

                      {L} -  DB2 location for {T}';

                      {S} - a running DB2-Gateway's SERVERID

    b) Required steps:

                      1) Browse table @DB2SYS; select first row with SERVERID={S}; if found, let {SYST} and {SYSC} denote
                           that row's field TABLES and field COLUMNS values, respectively.

                      2) If not found, refer to "Defining Additional Server IDs for the Gateway" in the manual; let {SYST} and {SYSC}
                          denote the SYSTABLES and SYSCOLUMNS mappings just defined.

                      3) Edit table @DB2TABLES; select row with NAME={SYST} and set DB2LOCATION to {L}; select row with
                           NAME={SYSC} and set DB2LOCATION to {L}.

                      4) Run the table definer against {T}.  

Note that Your SERVERID’s setup is central to this implementation: the definer issues GET @DB2SYS WHERE SERVERID={your serverid} to locate {your systables}/{your syscolumns} mappings of DB2’s SYSTABLES/SYSCOLUMNS dictionary tables; it then reads your table’s column attributes from DB2 via FORALL {your syscolumns} WHERE TBCREATOR={your creator} & TBNAME={your table}; in order for the latter request to reach  the DB2 database at {your location}, the rows in @DB2TABLES corresponding to {your systables}/{yoursyscolumns} must have DB2LOCATION set to {your location}.  Please consider the DB2LOCATION you set up in @DB2TABLES for {your systables}/{your syscolumns} as the "define-time DB2 location", and consider the DB2 Location you enter on the definer screen as the "run-time DB2 location".

Note that the above applies only to V5.0 of TIBCO Object Service Broker and the process to Define Remote DB2 Table has been totally redesigned in V5.2 of  TIBCO Object Service Broker.

Message "DB2 creator "xx" and/or table "tablename" does not exist" issued when a Remote DB2 Table is beibng DEFINEd on workbench and DB2 LOCATION field is used to identify the Remote DB2 system.