IBM经常建议系统程序员调整他们的大型机应用程序线程安全，以便获得平行以及垂直整合的性能优势。但为什么不使用CICS ENQ命令呢？

具备线程安全的程序至少要能够重入和串行访问重要资源。CICS和数据库管理系统保护数据访问，但其他东西，如内存中的某个位置，需要应用程序自己进行锁定。这里CICS ENQ或者队列能派上用场。

执行CICS ENQ命令

ENQ接口需要一个资源名或者地址以便代理访问。在执行了命令后，如果没有队列，控制器将返回给调用者。否则默认情况下任务将等待，直到队列用户通过执行出列(DEQ)命令来终止并释放资源。

为增强灵活性，其他参数允许队列在任务生命周期内持续通过工作单元，并且NOSUSPEND会通知CICS，即使在其他任务持有队列的情况下，也立即返回到应用程序。

例如，如果应用程序需要序列化访问存储中的计数器，那么队列命令可能看起来像这样：

EXEC CICS ENQ RESOURCE(CNTRADDR)

CNTRADDR 包含了存储的地址。因为许多原因，如果将命令调整为以名字进行序列化，效果会更好：

EXEC CICS ENQ RESOURCE('LameResourceName') LENGTH(16)

LENGTH参数告诉CICS资源名称到底有多重要。

为了让其正常工作，所有程序需要使用完全一致的资源名称，精确到位和长度。任何没有连接到队列的程序都会在全过程中遭到压制。

启动全局队列

上述命令被限制在单一的CICS区域内。然而，某些应用程序需要提升至逻辑分区或者系统复合体队列的级别。这些被成为“全局队列”。全局队列会让CICS产生全局资源序列化(GRS)ENQ宏，带有8字节队列和最多44字节的资源名称。

全局队列需要队列模型(ENQMODEL)的资源定义。ENQMODEL定义了指定队列的名称（ENQMODEL）和范围(ENQSCOPE)。在ENQNAME的最后放置了星号作为通配符，这样可以让系统程序员免除为应用程序组可能设计的名称组合分别创建独立的模型。ENQSCOPE指定了一个4字节范围。

对于每个ENQ命令，CICS根据加载的ENQMODEL匹配资源名。如果没有找到符合的匹配，队列将在本地处理。如果CICS找到非空的ENQSCOPE匹配模型，CICS将发出全局ENQ宏。

CICS利用最后的ENQSCOPE值，格式化ENQ宏队列名称作为“DFHE”，并且将来自原CICS命令的RESOURCE参数传回。

所以，如果程序发出资源名为“HelloDolly”的ENQ命令，匹配某个ENQMODEL的ENQSCOPE值“HOOB”，那么CICS会发出一个带有队列名称为“DFHEHOOB”以及资源为“HelloDolly”的GRS ENQ宏。GRS配置参数(GRSCNFxx)同样生效。

队列等待问题排查

这听起来很简单，但有可能因为一个扭转而导致混乱的结果。

根据研究人员，全局队列资源发生冲突时，CICS并不会将请求的任务转换为休眠状态；它只会规定一个200毫秒(msec)等待。等待期满后，CICS将继续重试ENQ宏，直到它最终控制了队列。IBM证实CICS事务可以被延迟200毫秒的等待。

考虑此影响。一个事务可能发出ENQ命令，但CICS监控设施(CMF)关于全局队列等待的性能计数器只会反馈CICS试图控制队列的次数。

在下图所示，没块代表50毫秒。蒂尔矩形显示当某个任务拥有队列时，红色的表示等待时。

在时间间隔1和2中，TRNA拥有队列。TRNB尝试，但没有成功获取到间隔2的控制权，所以CICS让任务休眠200毫秒间隔。区间3中，TRNA放弃了队列，此时TRNC获得了所有权，并且持续了250为妙。与此同时，TRBN在间隔6时苏醒，发现与TRNC冲突，并再次进入等待。最后，到间隔10，TRNC释放队列，这样TRNB才获得了所有权。

这种情况下产生的问题。运气不好的定时任务可能需要进行不必要的长期等待，而且任务可能无法按照预期的排队顺序获得队列所有权。

本地ENQ命令对锁定本地CICS资源的效果不错。参与全局队列的资源可能会涉及到大量的占有与释放开销，尤其是在大型的系统复合体环境下，这可能让全局队列望而却步，但这取决于你的业务需求。如果可能的话，在数据库系统以及记录级共享上使用全局锁。