[Jim Kosloskey]

Well, I had a few minutes, and my test shows the results are dependent upon the variant definition. This is not surprising.

In the standard ORU^R01 message the OBR is a required segment in the ORC Group (see layout in an above post). So, when PATHCOPYing @null at the group level, as many empty OBR segments as were created before the PATHCOPY will remain as empty OBR segments. Those can be reused but cannot be removed within the Xlate. The Xlate always outputs required segments even as empty segments.

However, if one makes the OBR segment optional it will be gone after the PATHCOPY.

The relationship between message variants and what wants to be done in the Xlate is essential to accomplish the transformation needs.

 

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

Chaining Xlates is a way to identify filtering is going on in the NetConfig or NetMonitor via Xlates.

The first Xlate does the filtering and only the filtering, the second does any transformation warranted. Naming the first filter something indicating filtering helps.

I have begun experimenting with ‘globalizing’ filter Xlates. The INCLUDE Xlate Action could be instrumental with a few changes to its functionality (some of which I have requested on this forum) along with appropriate variant definitions.

At my last employer before the INCLUDE was available, I accomplished some of this. I was just beginning that work when the employer decided to get rid of Cloverleaf and I departed.

I think it is close to doable, but I do not have any testing to evaluate and describe how-to and impacts.

I also use Tcl for filtering but less and less these days simply because many of my clients do not have the staff to support Tcl beyond very simplistic functionality, but they do understand the Xlate better.

That situation is what drove me to do my evaluation of the performance differences. If they were substantial, it would not be fair to my clients to not recommend Tcl over Xlate.

For the environments where there appeared to be a big difference, I frequently discover an architectural issue like overloaded processes or sites (more frequently overloaded sites).

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

email me and I will send you what I did to evaluate the performance differences between Tcl filtering and Xlate filtering – including chaining for filtering.

I will send you the evaluation and the testing components I used to do the evaluation which you can run on your environment. If you do decide to run the evaluation, I would be interested in your evaluation.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

Note the Group Address Path does not have the trailing (0). If that is there the PATHCOPY only handles the first ITERATION. Without that (in my example – 1(0).1 – ending with the actual group identifier, all iterations should be affected by the PATHCOPY.

Let me know what you find out. I will try a test here as soon as I get some time.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

Methods 1 and 2 performance is controlled by the ‘Read Interval’ and ‘Max Messages’ settings of the fileset-local protocol (I am assuming Fileset-local here).

If you ran with the defaults, the performance would be slow. I am not sure what goes on under the covers for method 3 but I am pretty sure you can improve the performance of the other methods with appropriate settings.

Did you try various settings?

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

I will offer that most times I don’t need to ‘clear’ the entire message buffer between multiple message issuances. Especially for results, it is usually the OBR Group or the OBX group that is different the rest of the message is rather static (meaning most of the data in the rest of the message is the same for each of the messages being created).

So, by using a PATHTCOPY Action at the OBR Group level I can clear out only that portion of a message needed to be cleared.

Something like:

@null    PATHCOPY    1(0).1         where…

The OB format is the basic 2.5 ORU^R01 (see attached file).

This will clear all of the ORC group including the OBR segment, and OBX subordinate groups. This section of the message is typically all that changes with the issuance of a new OB message.

If there is only one ORC group and if the OBR changes, I can PATHCOPY @null to the OBR segment and the OBX Group to just clear that part of the buffer. If the OBX Group is all that changes, I can PATHCOPY @null to the OBX Group.

By just clearing the pieces that need clearing, I can avoid the overhead of building the unchanging portions for every created message. Sometimes a ballpeen hammer is more useful than a sledgehammer.

 

• This reply was modified 1 week, 5 days ago by Jim Kosloskey. Reason: Typo correction

Attachments:

You must be logged in to view attached files.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

Yes, the ability to clear the ‘buffer’ in an Xlate is a shortcoming.

Here is how I would consider use Chaining in your circumstance:

1. Chain of 2 Xlates
2. First Xlate –
   1. Place a unilateral SUPPRESS at the top of the Xlate.
   2. Create the Lab OB message
   3. Do a SEND. The difference between SEND and CONTINUE is SEND places the message in the OB thread directly, bypassing post Xlate processing. CONTINUE passes the OB message to the next state (in this case the second chained Xlate).
   4. Do a BULKCOPY with a CONTINUE. This will make a ‘copy’ of the IB message fo the next Chained Xlate.
3. Second Xlate –
   1. Create the Micro messages using SUPPRESS and CONTINUE as needed. As I understand it you would likely have multiple Micro messages.

Just be aware if any post processing of the SEND Lab message is needed, the Tcl code would be placed at the OB thread not the post-xlate. For the Micro messages, post-xlate could be used or at the OB thread.

Of course, another valid method is to use PATHCOPYs at each of the Group (or Segment) level (depending on the message structure) nulling out the Group by Group and Segments outside of Groups. Using the PATHCOPY at the Group level properly.

And lastly, something different…

1. Change the OB format to make the entire message a group (mark the MSH through last Group/Segment as repeating).
2. In your Xlate:
   1. PATHCOPY the MSH segment to the OB and anything else you need to do (the Xlate needs the MSH info in the OB buffer to parse the mesage).
   2. After you have CONTINUEd your message, PATHCOPY @null to the MSH Group (the entire message) this should ‘clear’ the OB buffer.
   3. Don’t forget to have a SUPPRESS (likely unilateral).

 

Jim

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

Just so we understand how this works… The formats and tables are loaded into memory with the first of a given message, thereafter there is no overhead for loading these into memory, just the overhead of retrieving them for use.

Great efforts post 6.1 have been made by the developers to enhance the overall performance of the Xlate. There are techniques that can be coded in Xlates that get the job done but are inefficient, wherein the Xlate itself is performing well but is asked to perform more than it should. I have seen this most often with a misunderstanding of the ITERATE Action.

Interesting history, the product originally was not to have Tcl exposed as an extensibility language. As I understand it (from one of the founding fathers) there were some passionate discussions before Tcl was exposed. The original design intent was to use the toolset sans Tcl unless it was something that could not be done in the toolset, then use Tcl.

I suspect there are very few (maybe no) shops 100% Xlate. There is likely some Tcl outside the Xlate  and within the Xlates to handle things the toolset does not. Within the Xlate itself, with the advent of the STRING Action Functions, there should be less need for Tcl within the Xlate to do the job.

Even then, I advocate writing reusable Tcl instead of ‘snippets’ imbedded in the Xlate. There is a slight performance advantage and means fewer Tcl modules to maintain.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

I submit a lack of knowledge is not a valid reason to make such a major change. Xlate is not that difficult to learn.

Moreover, I did a performance evaluation of using Tcl vs Xlate vs Xlate Chaining for filtering. That study result was posted on this forum, and I have a white paper (and testing components) available for the asking – just email me.

The gist of the study is there is not a significant difference in the performance among the techniques. If you want to know the difference on your processor, you can just run my test suite and do your own evaluation.  I would be interested to see your results.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

Chaining, in this case, would be useful IF the OB message structure is the same as the IB. Is that the case?

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

There are a number of ways to address this.

Have you considered using Xlate chaining?

One could also set up a route for the Lab and another for the micro each having their own Xlates. You would start with a clean OB message on each route.

Another option is to PATHCOPY @null at a segment level to clear out the unwanted segments between handling of Lab and Micro.

If you would like to discuss off-line, email me.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

What should happen is the newly arriving messages should go to the end of the queue and be delivered when it is their turn.

In your scenario the A03 should not arrive before the A01.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

Peter,

I am curious if you tried this select outside of Cloverleaf (with something like DB Analyzer)?

If so, did that return multiple elements in the result set? Are you configured to handle multiple elements in the result set?

If you are configured for multiple elements in the result set, how is that configuration defined?

Jim

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

Also understand the & has special meaning as an HL/7 separator so the receiving system (depending on how it parses the message) may treat that as a separator rather than data.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Jim Kosloskey]

You do not indicate what release of Cloverleaf but if 6.0 or later, check out the Xlate STRING Action Map command I think that should do it without using Tcl. If you are not familiar with the STRING Action, email me and I will send you a packet with a presentation that explains all of the STRING Action Functions; some additional STRING Actions I created; an exercise Xlate for all of the STRING Actions (including the ones I have written/modified); and a test file to use with the Xlate in the Testing tool.

If you decide to explore the STRING Action Map Function, realize the backslashes (\) are Tcl escape characters and you will need to escape them something like this \\T\\ in your map.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Author]

Replies