[Jim Lohe]

Jim

We are on 5.7.    Thanks for all the advice and alternatives.    I had a solution for my particular issue, but was just curious if it was do-able to iterate on the outbound variant.

Since I had a minimum of 2 OBX and a  max limit of 3 OBX’s (for a blood pressure vital),  I ended up simply doing an ITERATE on a list where the list was 0 1 2, then used the %l1 as the index to the outbound variant.    

Thanks everyone.

Jim

[Jim Lohe]

Jim Kosloskey wrote:

No you cannot iterate using an outbound element.

However, if you are on a release of Cloverleaf which supports Xlate Chaining then you can chain two Xlates, one that does the original ITERATE and then asecond one which now can ITERATE over the output of the first Xlate.

If you are not on such a release, then a method that can be used is to have two instances of the ITERATE, the first builds the outbound, the second is a complement over the inbound which simulates what would have been built to decide how to proceeed. I have done this in the past for various reasons.

While the multiple ITERATE in one Xlate can get the job done, the process is convoluted and difficult to maintain.

Now that we are on Cloverleaf 6.0 I would try the chaining if the need arises again.

I hadn’t thought to do that – that would do the trick, but yes it would be messy to maintain.    We are not yet on V6.0.

Funny though, that cloverleaf allows you to set it up using point and click in the gui, and then simply doesn’t execute it.

[Jim Lohe]

Jill Fredericks wrote:

We have experienced two Panics this week. During the second, the logging was on and indicated a problem with the variant, but we could not reproduce. We did however notice two messages with the exact same date/timestamp (MSH-7) passing through the xlate, 20120322162149. When we try to SMAT the file for a time range that includes this time, we only get the first message and have to use other search criteria to bring in the second message.

[Jim Lohe]

Jim Kosloskey wrote:

Jim,

I just tested this Cloverleaf 5.6 and it worked fine for me.

I set @contains to your value, did the IF (with else) referenced an inbound HL/7 field that is null and the False path was appropriately taken.

After a phone call to Jim (thanks Jim!) I came to understand that “ct” operator does not work like a “list search”, but rather like a “string match”.    I completely misunderstood the point of the command, and my initial tests matched my expected outcomes, only confirming my misinterpretations.    Oh well, better to learn now then after I move something to production.    

Thanks again Jim.

[Jim Lohe]

Jim K, one question,

if I set a temp variable

COPY = M F O

[Jim Lohe]

Thanks to both for your input.    I have considered a tcl solution – but given that it doesnt happen that much, it hasn’t made it to the top of my pile yet.    

BTW – we are on Cloverleaf version 5.7 Sun Solaris

[Jim Lohe]

Scott Folley wrote:

Are you using ACK/NAK processing on the receiving thread?

[Jim Lohe]

Jim

Thanks for the input.   It sounds like that certainly can’t hurt.    The hard part is that I can’t make it happen in test or production, so it will be hard to know if anything fixes it.   It just happens randomly on it’s own.    

I will update test and see how it goes.    Thanks again.

Jim

[Jim Lohe]

Jim Kosloskey wrote:

I should clarify it is XML with which I am not very impressed.

By the way what releas of Clovelreaf are you trying this on?

How large are these messages?

Me too.  Cloverleaf in general is wonderful.  

I figured it out, or rather a co-worker did.    When I compiled the XML the first time I didnt select a root.     I had since selected root on a subsequent compile.   That left me with two ocm files.   I was using the wrong one.    (That one did have the &format tag, but it still couldnt “see” it).

Thanks for your help.    Turns out it was something stupid.

[Jim Lohe]

Jim Kosloskey wrote:

Jim,

Hmmm… Just guessing here (as I said I have not done much with XML but not very impressed at this point) try enclosing your notation in curly braces like this:

set valPointer [grmfetch $gh {nm1:DOCUMENT_MESSAGE.nm1:document_data.&format}]

Thanks for the  reply.    That has been tried unsuccessfully.   Still looking for answers.     I am not impressed either.    The reason I am trying to do this in tcl is because some of my document-embedded xml is taking 5-8 minutes to go through the xlate.   Hoping tcl is faster.    I dont need messages stuck in state 5 for that long!

[Jim Lohe]

Jim Kosloskey wrote:

Klaus,

Here is what I would do:

I would build an Xlate (if you don’t already have one) and reference the field in question. The Xlate tool will give you the address path along with a reference to the repetition position (you already seem to have that but it never hurts to have confirmation).

Make sure you are getting what you want via the Xlate Testing tool.

Then Copy the Source for the field in question from your COPY Action in the Xlate and paste it into your code or just verify the construct is the same.

Whatever the Xlate uses to reference the field is what you would use in Grm in general.

Jim K…I am doing exactly that.

[Jim Lohe]

I am working closely with my mainframe systems person and trying to get a sense of the expected protocol.    All this info is good and helps me wrap my head around the problem.   As soon as I have more info I will be back and may contact some of you directly.

Thanks all of you for your help.

[Jim Lohe]

Well….that’s what I am trying to figure out….what is it I need to do.

My systems person seems to be telling me to send a message with the tran id and then after that I won’t need to.     But I am working through what “happens” on the mf side when I send this tran-id message through.

I do have a good connection to the mainframe…so that’s a start.

[Jim Lohe]

So…there isn’t something already built in cloverleaf…that helps me!  

If you find something, I’d appreciate seeing it….it could save me some time.

Jim

[Author]

Replies