Table of Contents


  1. Preface
  2. Introduction to PowerExchange
  3. DBMOVER Configuration File
  4. Netport Jobs
  5. PowerExchange Message Logs and Destination Overrides
  6. SMF Statistics Logging and Reporting
  7. PowerExchange Security
  8. Secure Sockets Layer Support
  9. PowerExchange Alternative Network Security
  10. PowerExchange Nonrelational SQL
  11. PowerExchange Globalization
  12. Using the PowerExchange ODBC Drivers
  13. PowerExchange Datatypes and Conversion Matrix
  14. Appendix A: DTL__CAPXTIMESTAMP Time Stamps
  15. Appendix B: PowerExchange Glossary

Preventing a PowerExchange User ID From Being Reported as Inactive

Preventing a PowerExchange User ID From Being Reported as Inactive

Some z/OS sites have procedures for identifying and removing inactive users by using the LAST-ACCESS date in the RACF database. A user ID that only PowerExchange tasks use might be erroneously reported as inactive.
To avoid this problem, you can configure PowerExchange to update the LAST-ACCESS date in RACF whenever a connection task starts on the PowerExchange Listener on z/OS. To enable this updating of the LAST-ACCESS date, configure the following statements in the DBMOVER configuration file:
  1. Set the UPDATE_USER_ACTIVITY statement to Y. For more information, see UPDATE_USER_ACTIVITY Statement.
  2. Set the SECURITY statement to either (2,N) or (2,Y).
    When the first parameter in the SECURITY statement is set to 2, the PowerExchange Listener verifies and executes a user connection request by using the user credentials of the requestor and not the user profile of the PowerExchange Listener. In this case, the LAST-ACCESS dates of the requesting user are updated. For more information, see SECURITY Statement.
To view active user details from RACF, including the LAST-ACCESS date, issue the TSO LISTUSER command with an authorized user ID.
Informatica recommends that you use the UPDATE_USER_ACTIVITY=Y statement to get updated
dates in RACF. Although updating the user activity might increase the elapsed time of a connection task, the increase is small in comparison to the overall elapsed time of setting up a z/OS language enclave for a new task. Also, you can deploy connection pooling to reduce the number of times tasks are created.
For more information about RACF, see the following IBM publications:
  • z/OS Security Server RACROUTE Macro Reference
  • z/OS Security Server RACF Macros and Interfaces
  • z/OS Security Server RACF Command Language Reference
  • z/OS Security Server RACF Security Administrator’s Guide


We’d like to hear from you!