This is tricky, but you should be able to handle most cases.

A driver scoped variable will hang around until you restart the driver or is cleared somewhere else.

Side note; Testing if a variable is available, is not a good choice, since once defined, you cam empty it of contents (set local variable with a value of "") but you cannot remove it.  So remember to test for a value, test if equal, Regex compare of .+ (period plus) which means 1 or more characters.

Which part have you tried that has not worked?

Can you elaborate on the use case in a bit more detail, maybe with some actual traces (anonymised of course) that show the flow.

My initial thought is to use the ability to inspect in pub-itp all sibling responses and look for a retry, that way you can invert the way you implement the logic.

To that end, strongly suggest you review the three articles I wrote that are very relevant to this topic.

community.microfocus.com/.../delving-into-and-beyond-the-current-op-part-1

community.microfocus.com/.../delving-into-and-beyond-the-current-op---part-2

community.microfocus.com/.../delving-into-and-beyond-the-current-op-part-3

I have been meaning to ask... Is the ability to see siblings of the operation, unique to the ITP but not elsewhere? 

Geoffrey Carman said:

Is the ability to see siblings of the operation, unique to the ITP but not elsewhere?

It has been many years since I dug into this topic and wrote up those articles, so do take the following answer with a grain of salt.

I do believe that this capability exists in all policy sets and can be accessed anywhere that the relevant tokens can be used.

Have always thought of it as an alternate way to solve some of the last bits that normally can only be solved by StyleSheets.

After all stylesheets get access to the entire document, not a piecemeal "current-op" approach as DirXML rules by default operate on.

However, it seems to be most useful in the input and output transforms (pub or sub), for rather obvious reasons.

• It is here one more often deals with scenarios where there can be many sibling nodes under a given input or output node
• Rules that exploit this capability are generally most effective when placed as early as possible (or late) in the overall processing.

Thanks that makes sense.  And your last reason is probably the real reason for most use cases.