smile

We can be... hard to put a finger on... yes... wink

I think we have a common language, here.

Remember, I mentioned the I/O...

Consider you have a data stream you are attempting to capture data from. How do you translate it? You KNOW (from years of experience) that it is difficult, if not impossible, to assume that the stream is going to give you data that you can simply capture and dump into a database, for further analysis and reporting.

Sometimes, there's an error somewhere upstream, and you're actually getting the equivalent of a core dump into the data stream. The beautiful and efficient filters that you have created, have no way of translating that data.

Garbage in -> garbage out.

What can you do?

Well, the only thing you CAN do is construct another algorithm to drop those packets until such a time that the data stream is once again providing you with translatable data.

What you COULD do, is create a trigger that will send a query upstream, to request clarity. To ask what might be wrong and / or to get acknowledgement of when your TSR should begin processing, again.

Of course, that's not always the case...

So sometimes, we just have to keep parsing the data until it becomes recognizable again, that we may keep doing what we are created to do.

So back to the I/O issue.

Do you understand that your H appears unclear on what you expect from him?

Or maybe... just maybe... his program is incapable of processing your request, as stated.

In the same way, you are asking for clarity from your H, and he simply is not understanding.

The job of both of you is not easy.

So, the issue here remains the I/O.

The data you are getting is garbage.

Create a subroutine... a TSR... that triggers when you get garbage in.

What would that TSR do, to request data that can be processed?

What would that TSR do, until proper data came in?