IC63067: PCOM: HACL APPLICATION HANGS AFTER REPEATED REGISTER AND UNREGISTER OF ECLKEYNOTIFY EVENT

Personal Communications 5.9.7
Personal Communications Fix Pack 1 (5.9.6.1) for 5.9.6
Personal Communications 5.9.6

APAR status

• Closed as program error.

Error description

• Customer needs to block user input in IBM Personal Communication
  Terminal window for a certain amount of time. Blocking (and
  unblocking) should be triggered through a Java program running
  on the users workstation. Therefore the customer developed a
  JNI bridge to the C++ HACL API (since key event handling seems
  to be unsupported by the HACL Java API).
  But solution does not work as expected: After several cycles of
  registering and unregistering the ECLKeyNotify event the Java
  program hangs and does not respond. Java thread/heap dump is not
  possible.
  Problem is not acceptable for client, since register /unregister
  cycle have to work reliable in to give the solution in
  production.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All HACL API interface users                 *
  ****************************************************************
  * PROBLEM DESCRIPTION: HACL application hangs while calling    *
  *                      RegisterKeyEvent/UnRegisterKeyEvent in  *
  *                      a tight loop.                           *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  With ctfmon.exe active in a Windows operating system, a sample
  HACL application making RegisterKeyEvent/UnRegisterKeyEvent
  calls in a tight loop will hang after a randon number of
  iterations.
  

Problem conclusion

• When ctfmon.exe is active and running it installs a global
  system wide hook on all the process using SetWindowsHookEx
  Win32 function. This hook intercepts the messages of all the
  windows and has the potential of delaying the delivery,
  altering and possibly not passing the message at all to the
  receiving window procedure.
  
  PCSECLVC.DLL has been changed to introduced an infinite wait
  as opposed to the earlier 5 sec wait and changed _beginthread
  call to _beginthreadex to create the key intercept thread. The
  thread handle returned by _beginthreadex is guaranteed to be a
  valid handle which is not the case with _beginthread.
  
  Fixed in Fix Pack PCOM 5.9.5.2
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Modules/Macros

• PCSECLVC
  

Fix information

• Fixed component name

  PCOMM V5 COMBO-

• Fixed component ID

  5639I7000

Applicable component levels

• R590 PSY IP23068

     UP09/12/22 I 1000