z/OSにはCSAやSQAなどの共通域をトラッキングする機能があります。この中にCSA領域をユーザープログラムの記憶保護キーで獲得できるか否かを設定するパラメーターVSM ALLOWUSERKEYCSAがあります。
このパラメーターはz/OS V1R8から追加され、そのデフォルト値はYESでした。しかし次のV1R9からデフォルト値がNOに変更されています。

元々MVSでは、特にクロスメモリー機構がサポートされる前は、異なる空間の間でデータをやり取りするため、CSAを使っていました。システム・プロダクトと言えどもOSやOSと密接な関連を取るようなプログラムでない限り、むやみにキー0などのシステム・キーでは動かず可能な限りユーザー・キー（キー8など）で動くように設計されました。必要があってキーを0にしても、キー0で動く部分は本当に必要な箇所だけに限定するように考えることが多かったのです。これはキー0のプログラムが誤って動くとOSの領域を破壊しかねない、という保全面を考えてのことでもありました。

しかしIBMは別の観点でのセキュリティの意味から、ユーザー・キーのプログラムが誤ってCSA領域を破壊しないようにとCSA域そのものを基本的にはシステム・キーでなければ確保できないように変更しました。これはCSA自体が共通域であるが故に、一般のユーザープログラムであっても簡単にアクセスできてしまうからでもあります。

z/OS以降、互換を捨てて既存のプログラムの改修を必須とするような変更がいくつかなされています。そんな中でもこのCSAをユーザー・キーで割り振れないことをデフォルト動作にする、というのは結構影響が大きいように思えます。
某ISVにいた知人に以前聞いたのですが、その会社の製品でもユーザー・キーでCSAを使っていて、この変更が引っ掛かりました。なのでDIAGxxパラメーターのVSM ALLOWUSERKEYCSAの設定をYESにすることでの回避を提案したところ、ユーザーに却下されたそうです。理由はセキュリティに関するパラメーターなので変えること自体できません、というものだそうです。拒否する理由は技術的なことではないんだろうな、と思いましたがどうなんでしょうね。
製品を提供する側でもシステム・キーを使用してCSAを使うようにする改修は考えるでしょうが、次期バージョンとかPTFとかでもそれなりに計画しなければならないわけで、それまでの回避策でデフォルト値を変えての運用はありだと思うのですが．．．

そんなわけで、実際現場で影響が大きいのかそうでもないのかを調べたく、z/OS、特にV1R9以降のバージョンを運用されている皆様、ぜひアンケートにご協力下さい。