大型机存储保护

借助存储保护，CICS通过将系统和用户数据放入不同的锁来使用z/OS存储锁保护，这种方法允许CICS系统把对读编码，并写入用户和系统存储，相反，应用程序可以读，但不能更新CICS存储，即使可以随意控制用户存储，因此，正确实现的应用程序重复占位段系统存储会产生一个保护异常（0C4），而不会让CICS当掉。

你可以通过将系统初始化参数STGPORT设为YES为某个区域开启存储保护，这个参数不是动态的，CICS必须返回开关状态。

激活存储保护时，一些事务和程序属性变得非常重要，例如，对某个事务，TASKDATAKEY属性指定CICS使用哪一个锁保护该事务，包括EXEC Interface Block事务工作区。

程序属性EXECKEY告诉CICS当它进入程序时使用哪一个存储锁。

存储保护和上面的资源属性使事情变得更复杂，例如，一个有TASKDATAKEY的CICS事务不能调用有EXECKEY的USER程序，因为程序不能写任务存储，幸亏CICS可以感知到，并杀掉事务。

注意，如果STGPORT被设为NO，TASKDATAKEY和EXECKEY都将无效。

应用程序变化

设置CICS参数是最容易的部分，更大的挑战是找出并修复不能与大型机存储保护功能一起工作的应用程序。

修改CICS数据区域的程序将不再受存储保护的控制，一个好的源扫描工具和一串CICS数据区域将帮助你快速找到它们。

一旦发现，可以修改程序使用CICS广泛的系统编程接口（SPI），如果没有SPI命令，CICS就退出或替换可用的进程，有些人需要确定功能是否仍然需要。

程序可以调用操作系统服务进行内存管理，资源序列化或事件同步，这些服务可能在一个不正确的锁中使用存储，有些系统级代码总是需要操作系统服务，大多数调用应该调整，以便使用CICS的应用程序编程接口（API）。

需要注意的是，这些很可能是汇编程序，面向高级语言的运行时库通常是很智能的，当它们知道它们处于在线环境中时，它们可以调用CICS服务。

但是，对大多数其它程序而言，适宜采用暴力方法，这就需要打开存储保护，运行一个应用程序，获得dump数据，修复代码再次尝试，虽然这会撼动一些较突出的问题，但真正的存储违反行为可能不会出现，除非进行压力测试。

存储保护的实现和局限性

商家可能会采用多个策略实现存储保护，一个选择可能是在开发和测试阶段早期中断保护，程序员然后促进模块和代码质量的提高，测试移动到开启了存储保护的区域，捕捉余下的错误，理想情况下，存储保护应该被关闭，假设所有重复占位段在开发期间全部被消除，但是，生产环境将产生程序员从来都没想过的错误，大多数系统程序员希望给生产区域提供一些保护措施。

还需要注意的是，大型机存储保护不会捕捉到所有重复占位段，一个运行在用户锁中的事务可能会覆盖其它事务的用户锁存储，此外，程序可能覆盖它自己或其它应用程序的代码。

为了修复这个缺点，CICS引入了两个额外的大型机存储保护功能：

重新载入程序，进入类似于z/OS链路包区域的只读存储，需要注意的是，这并没有听起来那么简单，某些程序可能会引起问题，因为它们修改了自己或静态存储区域，根据程序行为的不同，重载程序进行保护模式可能比实施存储保护更困难。

事务隔离将分配给任务的存储分解为子空间，模仿z/OS地址空间，确保每个任务有它自己的子空间，并保证它们不能写其它任务的子空间，但是，事务隔离会引起大量的CPU开销，CICS必须管理子空间开关，这又会引起额外的内存开销，因为子空间有存储边界，需要分段。