Hi Sonam,
Dont worry, this fix will work. webMethods is already released the fix which controls the generation of unique id to not to exceed 24 bytes, which is bascially class which generate uniqueid internally using some algoritham. By this everyone should be ok.
For going plan B, you have to do at BIOS level only, if you change the time at OS level, OS is smart enough to rollback to bois time settings. If we have to go to your plan B which is not at all possible for the people who has this problem in the production.
I guess best plan will be doing at DB level(increase column of BizDoc.DOCID to 25 from 24), that is only if webMethods is not able to provide the fix or fix doesn’t work. We tested Our plan B in Dev which works excellent.
Thanks “Paul Saker” pointing the right column, which saved a lot of our time.
We are running IS/TN 4.6. The fix for 4.6 was TNS Fix 86, which is working fine now for us in production with no errors.
In dev, we saw one failure in the first document submitted – a Java index out of bounds exception. But since the other tests after that ran fine, I’m putting it down to a one off effect of applying the patch.
After this incident, I fully expect WM to add time-shift testing to their regression test suite. It would be possible to run VMWare instances, programatically change the OS time, and run their tests.
For what it’s worth, I looked at what the fix actually does. It simply truncates the date part of the ID to 8 characters, keeping the most signifigant digits. Since this is base 32, and the date is 9 digits in base 32, you’re dropping one digit, which equates to 32 milliseconds. Therefore - instead of the date portion of the TN ID changing every millisecond, it changes every 32 milliseconds.
There is also a 4-digit sequence number, which equates to 1048576 (base 32, remember) available IDs for each date value. So as long as you receive less than 1048576 documents every 32 milliseconds, duplicates aren’t an issue.
I suppose in theory you might need to worry about what happens when the date goes to 10 digits, which would mean the date part would change only once per 1024 milliseconds, but that won’t happen until 3084-12-12 07:41:28.832. I’m guessing we’ll probably be using a different webMethods version by then.
If you have 6.1, you need to apply the TNC patch to any client PC that has TNC installed. It may appear to work without it, but (according to a wm support person) when you add or modify processing rules, it won’t work without the TNC 6.1 patch.
We are operating IS and TN 4.6 on a Solaris 5.8 box with Sybase ASE 12.5. Our machine acts as an ebXML hub servicing a number of spokes. We were NOT affected by this problem in any way. Virtually all of our spokes who use webMethods were, with the exception of one, who uses a HP UX box and Oracle (don’t know versions)
We have applied the fix anyway and all still works fine.
Darren,
If your connection to database has SET ANSI FLAG setting “off” then it will work because this setting will truncate the values to their specified length of column in DB and ignore the error.
