If you want to cut off the incoming requests that take more than specified time from the server side, unfortunately no way to configure this in WebSphere. There is a property at the plug-in level that might be sufficient. Please see the ‘ServerIOTimeout’ property in the document at link:  http://www-01.ibm.com/support/docview.wss?uid=swg21318463

This would make it so that the plug-in cuts off the connection after 5 seconds. Please keep in mind that this request would still continue in WAS and eventually result in an IOException when it tries to write the response. This will not cause any problems, but it won’t reduce any performance impact if you’re expecting that when reducing the timeout.

Yorum (comment) (0)


When you logon to the TEPS, if you get “invalid username or password” message on client and  decrypt error on TEMS log although you provide correct user and password, you should add following parameter.

Edit the kfwenf file, for Windows,install_dir\CNPS (where install_dir is C:\IBM\ITM by default) using a text editor.

  1. On Linux/UNIX, you must edit the <ITM Home>/<OS Specific Folder>/cq/bin/<OS name>env file. (For example, on AIX for System /opt/tivoli/omegamon/ITM/aix536/cq/bin/lnxenv ). The following steps are the same.
  2. On a line by itself, enter the following text:
  3. Save the file and exit.
  4. Stop the Tivoli Enterprise Portal Server, if it is running, and start it again.


TEMS log:

014.157 11:33:02.23 (0000-CD8955E3:kglcry.c,3499,ÜCRY_DecryptÜ) Function failed

014.157 11:33:02.23 KDSPA003   Logon validation did not complete – system error

Yorum (comment) (0)

Yılda bir kez kutlanan sistem yöneticilerinin günü bu yıl 12.si gerçekleştirilmek üzere 29 Temmuzda olacaktır. Ayrıntılı bilgiler linklerde…

Today is the 12th Annual System Administrator Appreciation Day, make sure to give a big thanks to awesome sys admins who keep your servers running. For more information:


Yorum (comment) (2)

The Secure Socket Layer protocol was created by Netscape to ensure secure transactions between web servers and browsers. The protocol uses a third party, a Certificate Authority (CA), to identify one end or both end of the transactions. This is in short how it works.

  1. A browser requests a secure page (usually https://).
  2. The web server sends its public key with its certificate.
  3. The browser checks that the certificate was issued by a trusted party (usually a trusted root CA), that the certificate is still valid and that the certificate is related to the site contacted.
  4. The browser then uses the public key, to encrypt a random symmetric encryption key and sends it to the server with the encrypted URL required as well as other encrypted http data.
  5. The web server decrypts the symmetric encryption key using its private key and uses the symmetric key to decrypt the URL and http data.
  6. The web server sends back the requested html document and http data encrypted with the symmetric key.
  7. The browser decrypts the http data and html document using the symmetric key and displays the information.

Yorum (comment) (0)