Performance with Dynamic SQL
People have long tended to avoid dynamic SQL as much as possible. The reasons given were usually: additional CPU overhead for the statements’ prepare, no or little capacity for quality assurance, and lack of transparency: “You don’t know what or when something will be executed, and what the consequences will be.”
As more and more licensed standard products make use of dynamic SQL, this attitude is becoming less and less viable. And another challenge presents itself. The z/OS platform has rivals, and its superiority in reliability and performance rests among other things on established quality assurance processes. The question therefore is not whether or not to use dynamic SQL, wisdom lies again in a bit of both. How can we approve dynamic SQL, profit from dynamic SQL, and assure quality – in other words, guarantee performance?