The tws.xls and ddedll.dll are current as of 12/29/01. Using the edemo to test the dde operation:
The IBJts\darykq\user.ini file holds "DdeId=idxxxxxxx" from the last activity where idxxxxxxx is the highest id number last used.
When you start up the next time, the JAVA tws applet reads this in and ignores any orders with id numbers lower than this as "possible duplicates" (according to the log). Since these ids are Time number derived, much of the next day's orders are ignored. The order counter "genid" which is appended to the Time number does not lessen this problem.
If the tws applet is supposed to reset the user.ini's DdeId value to zero at the start of a new day, it is not happening in our testing.
If before connecting to edemo, we open user.ini and manually reset DdeId to "DdeId=id0", then new orders are accepted normally. This method however may not protect you against old orders left on tws.xls from yesterday being resent, so you may have to strip them out as with earlier versions.
It seems to us that if the id number contained both the date and the time (need more digits at tws.xls), the system would work as planned.