MQSeries.net :: View topic

yjwjanet

Dear all,

A New Fixpack for JText has release, see URL below and it might help your JText problem.

===
http://www-1.ibm.com/support/docview.wss?rs=695&context=SSMKUK&dc=DB520&dc=D600&dc=DB530&dc=D430&dc=D410&dc=D700&dc=DB500&dc=DB540&dc=D420&dc=D400&dc=DB510&dc=DB550&q1=JText&uid=swg24010583&loc=en_US&cs=utf-8&lang=en
===

It fixes:

Download Description
The following fixes have been included in this Fix Pack:

Internal tracking number 71620
When the Event or Output directories have an extra blank on the MO, the JText adapter would not recognize the directory. The problem has been rectified. The directories would be recognized now for leading and trailing spaces.

Internal tracking number 55201
If event datahandler was not included during request processing, output file would not get written to the output directory. Output datahandler property alone suffices during request processing. This issue has been resolved. Now it is not necessary to include event datahandler while request processing.

Internal tracking number 55373
It was seen that no error message would be logged when the adapter failed to move a file from staging directory to the event directory. The problem has been corrected by logging an error message whenever such a failure is encountered.

Internal tracking number 71561
JText adapter would access an event file and throw a file-lock warning for its own lock. The same has been rectified and the adapter now throws a warning when the file is locked by external non-adapter processes.

Internal tracking number 72218
JText adapter would crash and restart when zero-byte files with no extension is encountered. The issue has been fixed. If the event extension is .in(for eg.), then the files with no extension will not be polled irrespective of their size. The zero byte files with .in extension will be polled and archived as .damage.

Internal tracking number 72220
JText adapter would poll successfully for a while, then make poll rounds, but not pickup event files. The issue was found both with mapped drives and the local drives. The adapter no more gets into such a loop. The issue has been fixed. JText connector would reach to the 100% CPU mode and freeze during polling on HP-UX.The above fix has rectified this issue as well.

Internal tracking number 48648
While polling/request processing in the FTP mode if the file is fetched from a machine which is in Japanese locale, the timestamp of the file would get appended to the name of the file. This has now been resolved in commons-net-1.1.0.jar package.

Internal tracking number 70670
If the file permission of the event folder being polled by the adapter is read-only, the adapter would pick-up the file for event processing, but would fail to delete it subsequently. In this scenario, a warning message would not get logged. This has now been rectified.

Internal tracking number 71211
When the adapter is trying to poll an event file being accessed by another program, it would fail to archive the file and go into an infinite loop causing 100% utilization of CPU. Checking for third-party lock and generating a warning message have rectified the problem.

Internal tracking number 70672
Whenever the adapter tries to access an event file even as it is being written to the event directory by a third-party application, the adapter would throw a â€˜FileNotFoundâ€™ exception. The problem has been resolved by check for lock on event files.

<-----
Janet Wu
------->