Resolution:
Yes TIBCO ObjectStar Integration Foundation 4.0.2 can operate under z/OS 1.10 but you should contact TIBCO Support for the latest PSP bucket for TIBCO ObjectStar Integration Foundation 4.0.2. In particular, you should ensure that these fixes are applied:
   AP12716 Move AEWNXAEW setting for z/OS 1.10    
   AP12023 Correct DBONLINE for z/OS 1.8            
   AP11733 Change HRNBRHDW/HRNKEY00 to compile in z/OS 1.7
if you do not already have them on your system.

A concern is the z/OS system configuration option "VSM ALLOWUSERKEYCSA(NO¦YES)". In z/OS 1.8 the default was "YES" which TIBCO ObjectStar Integration Foundation operates quite comfortably with. During communications initialization, ObjectStar builds control blocks to allow communications amongst 4.0.x, 4.1.x and 5.0 ObjectStar/Object Service Broker systems. (You can connect Data Object Brokers at different release levels.) These control blocks are built in user key CSA. In z/OS 1.9 and 1.10, the default was changed by IBM to "NO" and in a future release of z/OS the option will be removed and IBM will only implement "NO", full stop. Maintenance was provided for the last two current releases of ObjectStar/Object Service Broker, 4.1.x and 5.0, to run with "NO". There is no support for 4.0.x systems for the "VSM ALLOWUSERKEYCSA(NO)" option however.

So if you are running ObjectStar 4.0.2, you will need to make sure that z/OS 1.10 is IPLed with the former "VSM ALLOWUSERKEYCSA(YES)" setting. Once ObjectStar has initialized with that option, the setting for "ALLOWUSERKEYCSA" must not be changed dynamically through z/OS operator commands. If the setting is changed dynamically, ObjectStar systems will fail during z/OS cross memory communications resulting in communication failures. To correct would require an IPL.

For ObjectStar 4.1.x and Object Service Broker 5.0 systems which support "VSM ALLOWUSERKEYCSA(NO)" with the provided maintenance applied, the rule is that once an ObjectStar address space initializes with a setting (either "VSM ALLOWUSERKEYCSA(NO) or "VSM ALLOWUSERKEYCSA(YES)") then that setting must not be changed dynamically; otherwise, failures will occur as control blocks will be in mixture of user key and system key CSA.

ObjectStar does not keep secure information in the CSA but the control blocks for communications contain pointers for identifying and connecting XMS address spaces.

See the following Late Breaking News items:
  LBN1-8ZD37N  
  LBN1-8YMJ6O  
  LBN1-8WXEW8  
  LBN1-9ZDKUK  
concerning maintenance for later levels of ObjectStar and Object Service Broker with z/OS ALLOWUSERKEYCSA. Customers are encouraged to upgrade their ObjectStar systems to the most current release to obtain the latest maintenance and compatibility with newer z/OS operating systems. The most current release is TIBCO Object Service Broker for z/OS 5.0.0.

Is TIBCO ObjectStar Integration Foundation4.0 Put02 compliant with z/OS 1.10 ?