- This topic has 6 replies, 2 voices, and was last updated 4 years, 11 months ago by
.
-
Topic
-
First, I realize that when taught in class it was always recommended to not reuse iterate variables. With that said, over time, some of our Xlates have managed to reuse some iterate variables in separate (non nested) blocks. This has always functioned correctly in our current prod version 6.1.2 and previous versions.
When testing 19.1.0.1, we found that if a message meets the criteria to hit a second iterate in an Xlate that reuses an iterate variable, the process dies and dumps the memory. This was confirmed by support and the developers in China.
Just consider this an FYI if you are considering going to version 19 or above that this “rule” is now being enforced and you will need to do some re-coding of your Xlates if you managed to reuse an iterate variable.
A basic pseudo code example of this is
Iterate (IAM segment) using %s1
Pathcopy in-IAM (%s1) to out-IAM (%s1)
END Iterate
Iterate (AL1 segment) using %s1)
Pathcopy in-AL1 (%s1) to out-AL1 (%s1)
END Iterate
The iterate for AL1 (assuming there was an IAM segment, which would cause %s1 to be used) is the iterate that fails and dumps the memory.
Its odd that this just started to be enforced with 19, but in previous versions, the Xlate code worked fine. I always interpreted the iterate function as declaring or re-initializing the variable, which is why it was able to be reused prior to 19, but I guess that is not the case.
Hopefully this helps others in preparation to go to 19 because we will need to delay to rewrite some code.
-
Replies
-
-
First that is an unfortunate happening but one which (as you stated) should not be done (at least not without re-initializing the used variable).
Perhaps this was done to satisfy a long standing request the variable value be available after an ITERATE has ended.
So for example if one needed to know the value of %s1 when the ITERATE ended in earlier releases one needed to store that value off in another variable because once the ITERATE was completed the assigned variable did not have a value.
That along with what I believe is now available BREAK Action, once could search through a repeating something, BREAK when found, and then the assigned variable would have the positional value of the repetition which caused the BREAK.
Can you try to echo the variable value after the first ITERATE to see if it exists and has the value of the last occurrence? (use $%s1 as the Source Value for your echo code).
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
It may be the value of the variable is outside the tokenized range of the next repeating element thus causing the issue.
A dump is a rather drastic way to handle the situation however. I would think something more benign should be done.
I can see the worthiness of having the value retained post ITERATE.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
-
-
Well, it’s hard to believe, but I think I found the issue. In doing the above testing, I was recreateing the iterates and saving different versions. I later starting doing some diffs on the xlt files. Then I saw that the xlt that was failing had the first iterate type as list, not segment. Fixing that, everything still runs fine in 19, even reusing the same iterate variable. I can’t believe how much time I just wasted on this issue, good thing it’s Friday.
I still think we will go back and fix all the iterate variables, but it’s nice to know that things actually do function fine converting from 6.1.2 to 19.1.0.1.
If anything, I uncovered that in 6.1.2 you can define an iterate for a segment as a list and it still functions, but in 19 it doesn’t, which is more of a bug with 6.1.2.
If the admins would like to delete this thread I understand, I don’t want to have misinformation out there.
-
-
- You must be logged in to reply to this topic.
