As yet I only have what "seems" to be happening, and am wondering if anyone
else is experiencing the same.

Long story short: A driver that has been working for a long time has
suddenly been seen to cause the AS400 processor utilization to spike to 70%.
Turning off Automatic loopback detection eliminates the issue, but I don't
understand why it would suddenly appear.


1. Began using Designer 4.0 in deploying mods to the driver.
2. Implemented a publisher input Transform rule that enables accounts,
whenever a status "success" of password subscription appears. (That is, when
a person changes their password in the IDVault and that change is
successfully replicated to the AS400, I listen for the status "success" on
the Pub-Input Transform to then enable that account in the AS400, if the
account had been auto-disabled in the AS400.) Might this somehow be
triggering the loopback detection? It worked in testing, and ran overnight
with this new rule.

The processor spike has been replicated in LAB and PRODUCTION.

Here's the new rule code, if it helps answer the question in 2 above.
<?xml version="1.0" encoding="UTF-8"?><policy>
<description>Enable "Stale Accounts" when IDVault password is
successfully changed</description>
<comment xml:space="preserve">Check password sync status event. If
successful, set I5OS account Status = "*ENABLED"</comment>
<if-operation mode="case" op="equal">status</if-operation>
<if-xpath op="true">self::status[@event-id =
<if-xpath op="true">self::status[@level =
<do-set-local-variable name="assoc" scope="policy">
<do-set-src-attr-value class-name="UserProfile" name="STATUS">
<token-local-variable name="assoc"/>
<arg-value type="string">
<token-text xml:space="preserve">*ENABLED</token-text>