Unable to compile XLT file

[Michael Lacriola]

Clover 5.6 rev2, AIX HA and all that jazz…

This is a long one and I contemplated putting it in the product enhancement section, but, I thought this would be very informative to newbies and long timers who have become lazy with error checking after a simple mod to a xlate file.

I will start by saying that, as a level 3 and a Clovertecher for almost 15 years, I got burned by this because I got lazy. My fault. I cannot stress that enough. Here’s what happened:

Modification to a xlate that included a new field from a variant. This variant already existed in prod from initial install of the interface years prior. I copied the xlate from our test environment to prod environment after vigorous testing, but forgot to copy the changes from the variant (***MISTAKE***).

After stopping/starting the engine process to have it read the new xlate which is attached to a wildcard route looking like ADT_A0(1|4|5|8), it could not compile the xlate because it could not find the new field it was trying to fetch. Plenty of errors were logged to the engine process .err log regarding this. I did not bother to check. Since the A01, A04, A05 and A08 transactions defined for that route existed on other routes in that engine process, no error messages concerning failed messages were seen on the thread status of the receiving thread or sending thread, not even the messages for that failed xlate compile for that route went to the error database. It was as if the wildcard route that contained that xlate to that specific outbound thread did not even exist. Other OB threads on that wildcard route were receiving messages without issue.

This ugly situation went on for a week and half until it was noticed by the end users. The receiving vendor did not even notice that they were no longer receiving these message types (they usually get about 10,000 a day).

Product Enhancement part — Let the interface engine analyst know he’s a moron in advance of such a mistake. No, really, I would have loved to see those messages in the number failed of the inbound thread or outbound thread (new error state), maybe even something in the error database with a new error state concerning the xlate not compiled.

Topic

[Charlie Bursell]

I will make a fortune when I invent a computer that knows what I maent to say!  😀

[Brent Fenderson]

In 5.7 you can monitor the number of messages in the error database. At least you would have gotten a notice.

[James Cobane]

I would have thought that these messages would have shown up in the error database, and would have affected other destinations on the route since when an Xlate fails, it fails the inbound message for everybody as there is only 1 Xlate thread that is responsible for all translation occuring in a given process.  I seen where a message that failed in translation gets written to the error DB with an incorrect state of 101, but would get written to the error DB nonetheless.  If the messages aren’t showing up in the error DB when an Xlate is failing, then this would sound like a ‘bug’.  Perhaps I’m misunderstanding the scenario/event.

Jim Cobane

Henry Ford Health

[Michael Lacriola]

That’s what I thought. You are definitely right when it comes to a Tcl proc error in the Xlate route, IB thread or OB thread. I was taken back by the whole thing and spent the weekend resending 40,000+ transactions to get all the unique accounts missed up to date. Luckily, I was able to programatically do this after identifying the accounts from 10 days of previous SMAT files.

[Author]

Replies