百硕客户通讯，总第百硕客户通讯，总第23 期（2011 年3 月1 日） 7 7 far the...

百硕客户通讯，总第 23 期（2011 年 3 月 1 日）

1 1


2 2


3 3

高性能主机数据 Sort

处理软件—SyncSort

■ 文 / 百硕技术顾问王晓兵

内主机用户在数据集中的环境下，每天面对着必须在有限的时间内完成海量数据批处理的压

力，其中对数据的 Sort、Merge 和 Copy 处理是批量窗口中耗用相当时间的工作。如国内一家

大型银行在批量过程中为有效进行数据的 Sort、Merge 处理，需要并发运行上千个作业，处

理的数据量以 TB 为单位进行；而据国外的调查机构数据显示，在数据中心，数据 Sort 相关的处理占

据了批量处理窗口中大约 25%的 CPU 时间，因此对 Sort 相关处理的优化可以显著降低批处理的整体时

间窗口和资源耗用。

本文介绍的 SyncSort 是一个在国外使用非常广泛的主机高性能数据 Sort 处理软件，希望能够对国

内用户有所借鉴。

SyncSort for z/OS 作为 z/OS 系统上专注进行数据 Sort、Merge、Copy 处理的高性能工具软件，与

传统实现相同功能的数据处理软件相比，其基于专利的数据 Sort 处理算法，利用不断更新的硬件系统

和操作系统的高级功能和高级访问方法，使用动态优化技术，能够为数据 Sort 处理带来显著的性能提

升和操作灵活性；该软件同时支持 OS/390（2.10 以上版本）操作系统和 S/390 兼容主机。

SyncSort 的特点

SyncSort 依据专利算法，能够显著降低 Sort 处理作业的 CPU Time 和 Elapsed Time，进而提升系统

整体的效能。SyncSort 在执行的过程中，其动态优化技术能够依据正

在使用的 CPU 型号，监控系统状态，包括 CPU 利用率、DASD 争

夺、控制器 Cache、中央存储可用性以及 Paging 活动，通过利用

PAV 技术，使用 MIDAW 和新型号 z 处理器的 zIIP Facility，依据系

统状态做出自动响应，降低作业的 CPU 消耗和处理时间。

性能提升：与传统 Sort 处理软件相比，能够降低 CPU Time 的比

率为 30-40%，能够缩短作业处理时间的比率为 20-40%。

SyncSort 的资源管理特性

动态存储管理（Dynamic Storage Management – DSM）

DSM 是 SyncSort 在监控和动态控制 Sort 性能及资源使

用的专利技术。

DSM 持续监控中央存储的可用性，以及 DASD 和

DASD I/O Channel 的性能与活动，这些信息被记录在内部特

殊的历史数据库中。

DSM 通过分析当前的资源使用状态和 Sort 作业的特

征，结合历史数据库信息，基于并发运行作业的需求、系统

的状态、以及系统其它运行作业的压力等综合考虑，决定并

国


4 4

发作业的资源分配，不仅能够使 Sort 作业的执行性能达到最优，同

时能够保证系统的整体运行效能。

动态 Sortwork 分配（Dynamic Sortwork Allocation - DSA）

DSA 通过使用独特的增量 Sortwork 分配技术，不仅使 Sort 作业

的资源使用最小化，同时防止了由于 DASD 空间不足或对数据文件

大小的错误评估导致的作业 ABEND。

根据测试，增量 Sortwork 分配技术能够减少最多 25%的 Sortwork 磁盘空间需求。

MAXSORT

对于超大数据的 Sort，MAXSORT 能够在一个作业步中完成对输入数据的分割，对分割的数据进

行单独 Sort，将多个 Sort结果进行 Merge 处理；从而实现在有

限 DASD 空间限制下完成对超大数据的有效 Sort 处理。

同时，MAXSORT 具有断点重启（Breakpoint/Restart）的

功能，即在执行过程中，可以计划或者非计划的终止当前 Sort

作业的执行，以保证其它高优先级作业的优先处理，在重新执

行的时候，SyncSort 可以在中断点恢复并继续执行。

PARASORT

PARASORT 是特有的并行处理技术，对于处理大数据量的跨卷数据集混合处理——可以包括磁带

数据集，通过并发，能够显著降低作业运行的 Elapsed Time。

SyncSort 的数据处理功能

DB2 Query处理

DB2 Query功能可以使 SyncSort 基于 SQL SELECT 语句指定的 Query从 DB2 数据库中得到相应的

数据并进行 Sort 和 Copy 处理；该处理功能具有比 DB2 DSNTIAUL 工具明显的性能优势，并且不需要

进行多余的设置步骤和用户出口程序。

数据编辑（Data Editing）处理

Data Editing 功能可以依据 SyncSort 的控制流语句实现对批量数据的复杂处理（包括数据格式转

换、记录数值计算等），不需要使用 Cobol 或其他高级语言的编程处理。

数据聚合（Join Processing）处理

聚合处理功能能够将 2 个文件依据指定的键值，对文件进行聚合和 Reformat 处理，从而快速产生

合并、拼接、计算等需要的数据文件。

多输出（Multiple Output）处理

该功能可以创建不同的数据选择集合，同时进行 Reformat 处理，并把结果数据输出到多个不同的

数据集中，整个处理过程（记录选择、修改、多输出）只需要一个 Sort步骤。

SortWriter 处理

SortWriter 在不需要 Cobol 编程的情况下即可更容易地创建高性能报表输出。


5 5

SyncSort 的透明性

SyncSort 对 DFSORT 具有透明替代的作用，充分兼容所有的 z/OS（包括 OS/390 V2.10）操作系统

和硬件处理器。在从其它的 SORT 软件进行转换的时候，对 JCL、控制语句、参数、出口程序、调用

Sort 处理的应用程序、系统软件（包括 DB2 和 IMS Utility Sort）都不需要进行过多的修改，对用户的

出口程序和调用 Sort处理的应用程序也不需要执行重新编译或 Link Edit 操作。

SyncSort 的背景信息

1968 年，SyncSort 的创始人专注主机大数据量的数据处理算法研究并获得专利，1971 年以专利算

法为基础研发出比市场上其他主机 Sort 软件领先的 SyncSort 软件，在过去 40 年 SyncSort 一直在主机

高性能 Sort 技术领域处于领先地位。目前，SyncSort 的客户分布在 55 个国家，在主机第三方软件装机

数量上位居首位，财富 100 强企业中有 95％以上都是 SyncSort 产品的用户。

基于对 SyncSort 特点和性能优势的广泛调研，百硕同兴公司已于 2011 年 1 月与 SyncSort 正式签署

了合作协议。如需了解 SyncSort 的更多信息或 DFSORT 与 SyncSort 的对比测试结果，可直接与我们联

系。


6 6

All You Need to Know

about the IBM zEnterprise

■ 文 / 百硕外籍技术专家 Gerry Borja

ver the last few months, we‟ve been hearing a lot of noise regarding IBM zEnterprise.

We keep on asking question in our mind and became curious – Is it synonymous to the

next generation processor - the z196, the successor of z10? However after reading lots of

articles, we‟ve come to realized that the term “zEnterprise” is actually the identity that IBM

wants to call their new enterprise product – the “zEnterprise”. The zEnterprise is comprised of

three main components: a new mainframe, an extension to host blades and management firmware

to streamline, automate and optimize how the collection of system is managed. (See figure below)

The zEnterprise is consists of the z196 mainframe and the Blade Center Extension (zBX), both of

which will be managed by the Unified Resource Manager (zManager). The zEnterpriseis not just

a new mainframe or blade server combined in one box but rather it is a collection of multi-

platform servers designed to blend and complement each other. The result is a more powerful,

more flexible and more energy efficient integrated computing solution that permits workloads in

mainframe, POWER7, and System x environments to share resources and can be controlled from

a single point of control as well as can be monitored and managed seamlessly.

The z196 Mainframe

The new IBM z196 is designed with improved flexibility, performance, security, availability, and

virtualization. Under the hood, the z196 now uses 5.2 GHz Quad Core processor chips. This is by

O

zEnterprise

Operation

Controls

Hypervisor

Management

Virtual

Server

Management

Performance

Management

Network

Management

Energy

Management

z196 (The new mainframe)

zBX (The new z BladeCenter Extension)

Single Point of Control

zManager (The Unified Resource Manager)


7 7

far the fastest processor in the world in terms of clock speed. Each box comes with up to 96 cores

(processors), it can have 80 cores spinning at 5.2 GHz and 3 TB of memory allocated to a single

system image running z/OS. With 80 cores dedicated to z/OS, the z196 is rated at more than

50,000 MIPS of aggregate processing capacity. At 1,200 MIPS of raw performance, each single

engine in the box has about 30 percent more MIPS than its z10 predecessors. Compared to the

previous generation System z10, this represents a 40 to 60 percent increase in overall system

capacity at equivalent energy consumption. Each processor supports more than 100 new

instructions, which translates to increased overall speed, especially for Java and C++ applications.

The figure shown below is the history of the mainframe starting from 9672 G4 mainframe server

until the zEnterprise server:

The zBX – z BladeCenter Extension

The zEnterprise BladeCenter Extension (zBX) as its name implies is the new infrastructure for

extending the tried and tested System z(mainframe) qualities of service and management

capabilities across a set of integrated distributed systems such as the POWER7 and IBM x86

servers. Aside from that the zBX also houses high-performance specialty processors for specific

workloads, such as the IBM Smart Analytics Optimizer for DB2 for z/OS or WebSphere

DataPower Appliance.

The IBM Smart Analytics Optimizer for DB2 for z/OS is a high performance, integrated

hardware/software, accelerator delivering dramatically faster analytic query responses

transparently to users. It integrates into an IBM DB2 for z/OS data warehouse environment,

providing high-performance query software that is based on advanced data in memory

technology.


8 8

The WebSphere DataPower Appliances on the other hand are built for purpose, easy-to-deploy

network devices to simplify and accelerate XML and Web services deployments.

The zBX is designed with integrated IBM certified components, tested and packaged together to

improve availability. Hardware redundancy is built into the zBX at various levels – the power

infrastructure, rack mounted network switches, power and switch units in the BladeCenter chassis,

and redundant cabling for support and data connections to the z196. The System z maintenance

strategy is also extended to the installed blades as well.

Currently, the zBX only support Linux (x86) and AIX (POWER7). Missing from the mix so far

are prominent systems such as VMware, Windows, and Sun Solaris. IBM has no immediate plans

to support VMware, but there‟s news that some type of VMware and Windows support will be

supported soon in the near future.

The zManager

The zEnterprise Unified Resource Manager (zManager) as its name implies is the system

management components that unify the mainframe and the blades servers. The zManager is a

firmware that executes on the Hardware Management Console (HMC) and Support Element (SE)

to monitor and manage server‟s activity. There are six management areas that make up zManager,

these are Operational Controls, Hypervisor Management, Virtual Server Management,

Performance Management, Network Management, Energy Management.

Key to the Success of zEnterprise

Because of the mainframe and servers are on the same machine, the secure, high-speed

communications connection between the zBX and z196 reduces latency. It takes much fewer

“hops” to get to the data and eliminates network delays and reduces potential points of failure

because physical networks are removed from the equation.

However, the key element to the success of zEnterprise 196 and zBX combination is not just

networking, but the way it is networked. With the new setup, the hypervisors on the Power and

x86 blades are treated just like system firmware on the mainframe, just like the PR/SM

hypervisor. So PR/SM, PowerVM (Aix virtualization technologies), and RHEV (Linux

virtualization technologies) are all treated like firmware on the mainframe and are all linked back

to the mainframe and to the zManager tool on the mainframe by a point-to-point 10 Gigabit

Ethernet network that's implemented in a switch. This switch hooks into the Advanced

Management Module (AMM) in the BladeCenter chassis, and the zManager tool uses SNMP

interfaces to manage the BladeCenter hardware and has hooks into the PowerVM and KVM

(Kernel-based Virtual Machines) hypervisors to manage virtual machine partitions on the Power

and x86 blades.

Here's what the management networks look like schematically:


9 9

As the schematic shows, this internal network is used to manage the deployment, performance

monitoring, availability, security, and energy management aspects of the virtualized servers in the

box.

Summary

zEnterprise represents a significant enhancement of System z virtualization and platform

management so that it can provide a single policy/view across all System z resources and extend

this view to a carefully selected set of non-z environments as well.

The zEnterprise is expected to attract diverse workloads such as solutions that want to leverage

the strengths of System z, such as security, reliability, availability, recoverability and

manageability. The zEnterprise is also expected to benefit applications from other platforms that

have hit scaling limitations that require a higher level of integration capabilities and efficiency

and consolidating all these systems will become more affordable.

For all of us involved in the mainframe world, we now have a much clearer picture of how IBM

intends to keep the mainframe and its ecosystem viable for the next decade and beyond.


10 10

使用 Mainview SRM

对数据集监控

■ 文 / 百硕工程师高玉超

1、概述

目前中国的主机用户大多集中于金融领域，如银行、保险等。这类用户大多具有一个相同的特

点，即业务量庞大，且随着业务的增长，数据量的增长迅速。这些数据在主机上的主要逻辑载体就是

Data Set，系统和应用正是通过 Data Set 来访问数据的，Data Set 出现问题将会直接影响系统和应用的

运行，例如常见的 x37 ABEND 等。因此，日常 Data Set 的监控就显得非常必要。

Mainview SRM 是一款专门针对主机存储的监控软件，其监控范围包括 DASD 使用率、DASD

Performance、Tape、DFSMShsm 等，当然也包括 Data Set。由于篇幅有限，本文将主要介绍如何在实

际应用中通过 Mainview SRM 对 Data Set 进行监控。

2、Data Set 监控

通过对 Data Set 相关属性的监控以避免 x37 ABEND，首先需要分析产生 x37 ABEND 的条件，然

后针对不同的条件分别进行监控。在这些条件满足之前进行预警，在问题发生前进行相应的处理，从

而避免 x37 ABEND 发生。

基于业界经验，x37 ABEND 的原因通常包括数据集 Extend 数量达到最大限制、数据集大小达到最

大限制、VTOC Index 空间不足、VVDS 空间不足、Storage Group 空间不足、Dir Block 不足等等（此外

还包括没有指定 Secondary Space、当前 Volume 上处于 Open 状态数据集数量达到最大值等不常见的

ABEND 原因）。

根据以往的经验，我们实施的 Data Set 监控流程，如下所示：

Data Set信息收集 Data Set分类

Mainview Alarm报警到

Console(Alarm Message发送到Console)

Netcool捕获Alarm Message后报警到事件平台或工单系

统自动或手动问题处理

2.1 Data Set 信息收集

Data Set 属性信息，分别保存在 Catalog、VTOC（VVDS）、Data Set 本身（如 Directory Blocks 信

息等）中，因此数据集收集需要从上述三个方面着手。

Catalog 和 VTOC 信息可以通过 BMC 主机监控工具 Mainview SRM 访问，但访问机制有所不同。


11 11

对于 Catalog 中的信息，Mainview SRM 会从 Catalog 中实时读取，读取的信息只用于展示而不能用于存

储。对 VTOC 中的信息，Mainview SRM 则会根据既定的 Policy 去收集每个卷的 VTOC 信息，然后将

其存储在自己的 Data Base 中。用户在查看这些信息时，Mainview SRM 会读取自己的 Data Base。对于

Directory Blocks 中的信息，Mainview 没有提供相应的监控手段，需要用户调用 TSO CLIST LISTDSI 或

者 REXX 的 LISTDSI Function 获得该部分信息。

从 Catalog 和 VTOC 中获得的部分 Data Set 信息是重复的。但这两种获取信息的方式对系统的影响

却并不相同。通过 Catalog 信息监控，Mainview SRM 会在每一个监控的 Interval 读取 Catalog，在数据

集数量较大的情况下势必会造成针对 Catalog 的大量 I/O，影响其它应用对 Catalog 的访问。但通过

VTOC 信息监控则不同，这部分信息保存在 Mainview SRM 的 Data Base 中，对这部分信息的访问不会

影响其它应用。因此在不影响监控效果的情况下，建议通过 VTOC 信息对数据集进行监控。

2.2 Data Set 分类

在主机 z/OS 环境，Data Set 类型的不同决定了其属性的不同，这就决定了针对不同类型 Data Set

需要设置不同的监控阀值，所以设置监控阀值之前需要根据 Data Set 类型对其进行分类。常用的数据

集分类为 PDS（Partitioned Data Set）、PDSE（Partitioned Data Set Extended）、PS（Sequential

Dataset、Large Format Sequential Dataset 和 Extended Format Sequential Dataset）、VSAM（VSAM、

Extended Format VSAM）。

在 Mainview SRM 中，上述所有 Data Set 显示在同一 View 中。为了将不同属性的数据集区分开，

需要使用 Mainview View 的 Customization 功能。该功能支持用户自定义 View，在新定义的 View 中用

户可以根据任意一个或多个列的属性对数据进行筛选，具体如下：

Step 1 View WBVTOCD 未客户化前所有类型的 Data Set 显示在同一个 View中。如在以下界面中

包含 PDS、PS 和 VSAM 数据集：


12 12

Step 2 通过“CUST”命令调用 Mainview View 的 Customization 功能：

Step 3 通过“P”选项对“DSORG”列进行过滤，如过滤条件为“W21DSO = „PS‟”,其中

W21DSO 为 DSORG 列的名称（将光标移动到该列，通过 Help 命令可以获得该列名称），通过该过滤

条件在新的 View 中只显示 Sequential 数据集：

Step 4 通过“Save”选项，把客户化后的 View保存为“PS”View，结果显示如下。该 View 中

只显示了 Sequential Data Set。


13 13

如果需要进一步区分 Sequential Data Set 和 Extended Format Data Set，则需要在 Step 3 按照

DSORG 和 Data Class（该 View中没有 DSN Type 列，所以只能根据其 Data Class 属性进行区分）列进

行过滤，过滤条件参考如下：

(W21DSO = 'PS') AND W21DCLAS IN (DCEXT1,DCEXT2)

2.3 Data Set 监控报警

完成数据集分类后，相同属性的数据集会保存在同一 View 中，这就具备了设定统一监控阀值的条

件。然后根据 x37 ABEND 产生的条件调用 Mainview Alarm Manager 对 View 中相应的指标进行监控。

基于前面的分析，与 x37 ABEND 有关的指标包括 Data Set Extended、大小、VTOC Index、VVDS、

Storage Group 使用率、Dir Block 等。

在 Mainview SRM 中上述指标与相关 View 的对应关系如下：

指标 View名称

Data Set Extended Data Set客户化 View

Data Set大小 Data Set客户化 View

VTOC Index SPVOLVV

VVDS SPVOLVV

Storage Group使用率 SPPOOL

2.3.1 Mainview Alarm 调用

以 Sequential Data Set 为例，Mainview Alarm Manager 调用具体如下：

Step 1 针对单卷的 PS Data Set，扩展次数最大为 16 次，因此我们设置两级报警，Extended 次数大

于 12 时，执行 Warn 报警，大于 14 次时执行 Critical 报警。首先进入“PS”View，然后将光标移动到

Extend 列，通过命令“MAKEALARM”调用 Mainview Alarm Manager，如下：


14 14

Step 2 在上述界面中指定监控频率和监控时间后，然后通过 Next 进入阀值设置界面，如下：

Step 3 然后，接下来的界面中指定报警信息的 Message ID 后，激活 Alarm 设置：

Step 4 Alarm 激活后，就会按照设定的监控频率对数据集进行监控。如达到报警阀值，则在

Console 上发出报警信息：


15 15

PSEXTENDS0 SEV=CRI ADCD Data SetName: IBMUSER.ADIBM.PROD.XMIT (Exts > 14)

PSEXTENDS0 SEV=WAR ADCD Data SetName: OMEG.V310.S3310PH8.TRS (Exts > 12)

PSEXTENDS0 SEV=WAR ADCD Data SetName: IBMUSER.CP1C.D101215.T204106.S00131.TRS

(Exts > 12)

PSEXTENDS0 SEV=CRI ADCD Data SetName: IBMUSER.OFFLOAD.DS1 (Exts > 14)

PSEXTENDS0 SEV=WAR ADCD Data SetName: IBMUSER.CP1C.D101228.T201950.S00139.TRS

(Exts > 12)

Step 5 通过 Netcool 在 Console 捕获上述 Message 后，会将其发送到事件管理平台或其它工单系

统，触发产生声、光等报警或 Email、短信等工单。

2.3.2 阀值监控建议

针对不同 Data Set 类型，其 Extent 数量和 Size 限制，可参考如下：

类型属性 NON- Extended Format Extended Format

HFS

单卷 EXTENT最大数 123 -

EXTENT总数 255 -

VOL总数 59(NON SMS LIMIT TO 1 VOLUME) -

Size大小 > 65535 TRKS * 59 VOL -

PDS


EXTENT总数 16 -

VOL总数 1 -

Size大小 65535 TRKS -

PDSE


EXTENT总数 123 -

VOL总数 1 -

Size大小 > 65535 TRKS -

PS

单卷 EXTENT最大数 16 123

EXTENT总数 59 * 16 = 944 59 * 123 = 7257

VOL总数 59 59

Size大小 65535 * 59 TRKS 59 * VOLME CAPACITY

VSAM

单卷 EXTENT最大数 123 123

EXTENT总数 255 for each comp.( 使用 extent

constraint removal 可增加到 7257)

255 for each

comp.( 使用 extent

constraint removal

可增加到 7257)

VOL总数 59 59

Size大小 4G 使用 EA,> 4G

针对其它指标的阀值参考如下：

指标阀值参考

VTOC Index使用率 Warn>80

Critical>85

VVDS使用率 Warn>80

Critical>85

Storage Group使用率 Warn>80

Critical>85


16 16

3、总结

本文主要介绍了在主机平台 z/OS 环境中如何通过 Mainvew SRM 对 Data Set 进行监控，内容包括

了如下方面：

Data Set 信息收集

Data Set 分类

Data Set 监控报警

通过上述监控，我们可以有效地避免一些常规的 x37 ABEND。当然，由于数据集本身的复杂性，

以及基于应用不同，对不同数据集的监控策略也会有所不同。因此，我们在实际操作中需要根据实际

需要进行客户化，并逐步做到精细化的监控，才能发挥出更好的监控效果。

关于主机存储的监控涉及到很多内容，由于篇幅所限，这里只是以 Data Set 的监控为例来说明整

体的监控流程。对于任何的监控工具，用好它的关键是制定最适合自己需要的监控策略和监控体系。


17 17

使用REXX程序

处理RACF DB

■ 文 / 百硕工程师田野

我们维护系统的时候，有时需要REVOKE绝大多数的TSO USER ID，如果涉及到多个系统，

并且需要在有限的时间窗口来完成相应工作，那么使用程序来查找USER ID并自动生成

REVOKE命令，能够在很大程度上简化工作，提高工作效率。

我们知道，RACF使用与各个资源相对应的Profile来控制对该资源的访问，而这些Profile是存放在

一个特殊结构的数据集里面，即RACF DB。所以，可以考虑从RACF DB里获取数据来做相应处理。

在这篇文章里，我们就通过一个实例来说明如何使用一些Utility和REXX程序来处理RACF DB的内

容。希望朋友们能从中获得一些经验和小技巧。

第一步、导出RACF DB内容

使用Uitility（IRRDBU00）把RACF DB的内容导出，放在能够很容易处理的SDS数据集里面。下面

是一个示例:

//*---------------------------------------------------

//* LOAD RACF DB WITH RACF UTILITY

//*---------------------------------------------------

//STEP1 EXEC PGM=IRRDBU00,PARM=NOLOCKINPUT

//SYSPRINT DD SYSOUT=*

//INDD1 DD DSN=RACF.dbname,DISP=SHR

//OUTDD DD DSN=&&FLATFILE,DISP=(NEW,PASS,DELETE),

// UNIT=SYSDA,SPACE=(CYL,(2,2)),

// RECFM=VB,LRECL=4096,BLKSIZE=4100

上面的IRRDBU00是RACF提供的一个Utility。它用来把名为‘RACF.dbname’的RACF DB导出到

一个临时文件中，以便对接下来的作业步进行处理（当然你也可以导出到一个SDS数据集中，看看它

的格式和内容，之后我们会根据这些格式和内容做编程处理并进行讲解）。

第二步、筛选导出的结果

使用DFSORT只把USER Profile从上面的输出文件中筛选出来，这样做是为了减少数据量。因为在

下面的REXX处理中，打开文件时会把所有的记录一次性全部放入混合型变量中，而RACF DB中可能

存在大量的Profile。这样会避免打开文件时可能引起的内存短缺现象。

（后面还会简单介绍另一种方法，直接在REXX中使用“LISTUSER *”命令来实现相同的功能。这

种方法也有内存方面的考虑。）

下面是SORT作业步：

当


18 18

//*---------------------------------------------------

//* SORT THE RACF DB AND SELECT '0200'(USERID RECORD)

//*---------------------------------------------------

//SORT1 EXEC PGM=ICEMAN

//SYSOUT DD SYSOUT=*

//SORTIN DD DISP=OLD,DSN=&&FLATFILE

//SORTOUT DD DSN=&&DBOUT,DISP=(,PASS),

// UNIT=SYSDA,SPACE=(TRK,(1,1),RLSE),

// DCB=(RECFM=VB,LRECL=4096,BLKSIZE=4100)

//SORTWK01 DD SPACE=(TRK,(1,1)),UNIT=SYSDA



//SYSIN DD *

INCLUDE COND=(5,4,CH,EQ,C'0200')

SORT FIELDS=(5,4,CH,A)

/*

在弄清楚上面控制语句之前，先了解一下Profile在RACF DB中的格式。

在《z/OS Security Server RACF Marcos and Interfaces》的第 9.3.2章节中，对各类USER Profile作了

详细的讲解。对于该场合，知道当前系统存在哪些USER就足够了。一个USER Basic Data记录唯一对应

于一个User ID，USER Basic Data类型由1-4位的常值„0200‟代表（每一个类型Data都有一个常值与之对

应）。

因此，上面的控制语句表示：当前SORT只处理文件中字符„0200‟所代表的USER Basic Data记录。

需要注意的是，由于输入文件是VB记录格式，所以需要再加上4个字节，即5-8位的4个字节。

第三步、REXX程序设计

在这个环节里，我们设计一个REXX程序，针对上面的SORT结果作处理，然后自动生成用于

REVOKE USER的JCL。

设计考虑点：

1. 希望所有的用于STC（Started Task）的USER不执行REVOKE。

2. 希望留一个SPECIAL权限的用户，以防万一。

3. 希望当前用于实施作业的USER不被REVOKE。

4. 一般来讲，STC的USER都是NOPASSWORD，即USER具有PROTECTED属性。但是通常系统中

总有一部分还是以PASSWORD形式被定义，这些信息需要R与ACF管理员和熟悉环境的人员进行确

认。

基于以上考虑，REXX程序如下。右侧以„@‟开头的部分是相应解释，并非语法的一部分。

/* REXX for REVOKE TSO USER */

/* GET USER INFORMATION FROM SYSTEM AND GENERATE A JCL */

PARSE UPPER ARG ULIST @接收输入参数（参见考虑点 3）

DO IW =1 TO WORDS(ULIST) BY 1 @如果调用时有多个 USER,分解到各变量

ULISTCK.IW = WORD(ULIST,IW)

END

ADDRESS TSO

"NEWSTACK"


19 19

"EXECIO * DISKR FROMSMF (STEM FILINE. FINIS" @打开文件

JS = 0 ; JU = 0 ; JR = 0; JP = 0; IE = 0 ; EX.0 = 0 @各类 RECROD 计数

outputRV.0 = 0; outputPR.0 = 0; outputU.0 = 0;outputS.0 = 0 @各类 RECORD 总计

DO II = 1 TO FILINE.0 BY 1 @处理文件所有行,检查下列 Field 值（需要了解记录格式）

filedTYP = SUBSTR(FILINE.II,1,4) /* RECORD TYPE */

filedUSR = SUBSTR(FILINE.II,6,8) /* USER ID */

filedS = SUBSTR(FILINE.II,40,3) /* SPECIAL */

filedRV = SUBSTR(FILINE.II,50,3) /* REVOKE? */

filedPR = SUBSTR(FILINE.II,391,3) /* PROTECTED */

IF ( filedTYP == '0200' ) THEN NOP @程序只处理 0200

ELSE

SAY "Check your SORT JCL to ensure only 0200 was specified"

IF WORDPOS(filedUSR,ULIST) == 0 THEN DO @处理程序输入参数中 USER 以外的所有 USER

SELECT

WHEN (filedRV == 'YES') THEN DO @检查已 Revoked 用户,存入混合变量,待后处理

JR = JR + 1

outputRV.0 = outputRV.0 + 1

outputRV.JR = filedUSR||" --> is already REVOKEed"

END

WHEN (filedPR == 'PRO') THEN DO @检查 STC(NOPSW)用户,存入混合变量,待后处理

JP = JP + 1

outputPR.0 = outputPR.0 + 1

outputPR.JP = filedUSR||" --> is the PROTECTED user"

END

WHEN (filedS == 'YES') THEN DO @检查 SPECIAL 用户,存入混合变量,待后处理

JS = JS + 1

outputS.0 = outputS.0 + 1

outputS.JS = " ALTUSER "||filedUSR||" REVOKE"

END

OTHERWISE DO @处理其它用户,存入混合变量,待后处理

JU = JU + 1

outputU.0 = outputU.0 + 1

outputU.JU = " ALTUSER "||filedUSR||" REVOKE"

END

END

END

ELSE DO @检查参数输入的用户,存入混合变量,待后处理

IE = IE + 1

EX.0 = EX.0 +1

EX.IE = filedUSR" was excluded 'cause you specify it in the REXX

PARM"

END

END

CALL JCLQUE @调用子程序,把 JCL 存入 queue,然后输出到文件

"DELSTACK"

ADDRESS

EXIT(0)

/*********************************************************

SUB Routine(JCLQUE) : Creat JCL head

*********************************************************/

JCLQUE:

QUEUE "//CTESTOP JOB ,'BAYSHORE',CLASS=A,MSGCLASS=A, "

QUEUE "// NOTIFY=&SYSUID,MSGLEVEL=(1,1) "

QUEUE "//* run TSO command "

QUEUE "//RACFTSOU EXEC PGM=IKJEFT01 "

QUEUE "//SYSTSPRT DD SYSOUT=* "

QUEUE "//SYSTSIN DD * "


20 20

DO JJ = 1 TO outputU.0 BY 1

QUEUE outputU.JJ

END @和下面的循环处理一样,把同类的 USER 归类到同一位置以便确认

QUEUE "// "

QUEUE "// "

QUEUE "//* Do you want bellow SPECIAL user to be REVOKE? "

DO JJ = 1 TO outputS.0 BY 1

QUEUE outputS.JJ

END

QUEUE "// "

QUEUE "//* Bellow USER had been revoked "

DO JJ = 1 TO outputRV.0 BY 1

QUEUE outputRV.JJ

END

QUEUE "// "

QUEUE "//* Bellow is Protected USER, can't be REVOKE "

QUEUE "//* Means it is used with STARTED TASK "

DO JJ = 1 TO outputPR.0 BY 1

QUEUE outputPR.JJ

END

DO JJ = 1 TO EX.0 BY 1

QUEUE EX.JJ

END

"EXECIO * DISKW OUTJCL (FINIS" @输出并关闭文件

相应的调用作业步为：

//*---------------------------------------------------

//* RUN REXX TO PRODUCE THE JCL

//* INPUT THE USER ID IF YOU DO'T WANT IT TO BE REVOKED

//* AS THE PARM OF REXX

//*---------------------------------------------------

//STEP2 EXEC PGM=IKJEFT01

//SYSEXEC DD DISP=SHR,DSN=your.REXX.SRCLIB

//FROMSMF DD DISP=OLD,DSN=&&DBOUT

//OUTJCL DD DISP=SHR,DSN=your.JCLLIB(RVKUSER)

//SYSTSPRT DD SYSOUT=*

//SYSTSIN DD *

%REXXRVK BAYSP02 BAYSP21

/*

把上面3个步骤合为一个JOB，就可以很方便的在任一系统里提交自动生成用于REVOKE（除

BAYSP02和BAYSP21以外的）用户的JCL，JCL保存在“your.JCLLIB(RVKUSER)”中。

其他方法的考虑

上面提到使用“LISTUSER *”命令也可实现该功能。只要在REXX程序里使用下列语句设置一个

陷阱，这样接下来的命令执行后，结果被存放在混合型变量VAR.里。然后，通过在变量里查找各

USER并作类似上面方法的处理即可。

x = OUTTRAP('VAR.')

"LISTUSER *"

other processing......

y = OUTTRAP('OFF')

虽然上面只需要执行REXX程序这一个步骤即可，但该方法有两个不足之处：

1. LISTUSER *可能会产生大量结果信息，在REXX程序打开文件时造成内存不足。


21 21

2. 对于命令结果的处理，逻辑比较复杂。

为了使逻辑更加简单，也可以采用类似之前介绍的方法，分三个步骤来得到TSO USER的信息。

1. 在 JCL中调用 IKJETF01，执行 TSO 命令 LU *，将 SYSTSPRT DD 语句指向 SQ FILE 或 PDS 的

MEMBER。

2. 使用 DFSORT 对前一步的输出结果进行过滤。

3. 设计一个 REXX 程序，读取过滤后的数据，生成 REVOKE USER 的 JCL。

还有一些其它的方法来查看或整理RACF DB。比如，RACF提供了一套创建DB2 Table的JCL。可

将RACF DB的内容导入到DB2的表里，使用SQL语句来处理相关内容。具体介绍可查看《RACF

Security Administrator's Guide》的第7.5章节和主机上SYS1.SAMPLIB(RAC*) Sample文件。

总之，根据不同的情况，我们可以把诸多技术结合起来，或进行比较，采用更适宜的方法，使繁

琐的处理步骤简单化，以便更好地提高工作效率。


22 22

CICS 和 DB2 的

连接指南

■ 文 / 百硕工程师朱彩明

大型银行的主机应用中，很多都使用了 DB2 作为其数据库系统。在联机业务中，CICS 作为

中间件，承担着终端客户应用和 DB2 数据访问的连接任务。

在 CICS 中每一个访问 DB2 的应用，都要首先建立和 DB2 的连接。CICS 提供了 CICS

DB2 Attachment Facility，使得 CICS 的应用程序能够访问 DB2。

在 CICS 中建立与 DB2 的连接

我们可以使用 RDO 定义 CICS DB2 Connection，具体体现的是三种不同的资源：DB2CONN (DB2

Connection Definition) ， DB2ENTRY (DB2 Entry Definition) ，和 DB2TRAN (DB2 Transaction

Definition)。

1、定义 DB2CONN，要实现 CICS 和 DB2 的连接，必须首先定义 DB2CONN

在


23 23

DB2GROUPID(name) 和 DB2ID(name)

DB2GROUPID 可以指定 Data-sharing 环境的一个 DB2 Group。

DB2ID 指定一个单独 DB2 Subsystem。

不能同时指定 DB2GROUPID 和 DB2ID。如果在同一个定义界面，同时定义了

DB2GROUPID 和 DB2ID，则只有 DB2ID 生效。

在一个 CICS 系统中，被 INSTALL 生效的 DB2CONN 定义只有一个（一个 CICS，同一时间

只能连接一个 DB2 子系统，一个 DB2 子系统可以被多个 CICS 连接）。

PURGECYCLE 参数：设置 Protected Thread 在没有 reuse 的情况下，会被保留的时间。

TCBLIMIT 参数：用于限制建立 DB2 连接的 CICS Thread TCB 数。DB2 V7 以后，CICS 连接

DB2 时会使用 Open TCB，TCBLIMIT 和 MAXOPENTCBS 都会影响到 CICS 和 DB2 连接的建

立。

2、定义 DB2ENTRY 和 DB2TRAN


24 24

TRANSID(transaction)：指定一个交易名和 DB2ENTRY 联系起来，可以用通配符来指定一类

交易。

DB2ENTRY 和 DB2TRAN 不能单独存在，始终和 DB2CONN 联系在一起，如果要 INSTALL

定义好的 DB2ENTRY 和 DB2TRAN，必须先有一个已经生效的 DB2CONN，如果 DB2CONN

被 Discard，相关的 DB2ENTRY 和 DB2TRAN 同时会被 Discard。

DB2TRAN 要和 DB2ENTRY 联系在一起，是 DB2ENTRY 的延伸，使更多的交易类型可以用

到同一个 DB2ENTRY。如果要 INSTALL DB2TRAN，必须先 INSTALL 该 DB2TRAN 中指定

的 DB2ENTRY。

如果 DB2CONN、DB2ENTRY 和 DB2TRAN 定义在一个 GROUP 中，CICS 会首先 INSTALL

DB2CONN ，然后 INSTALL DB2ENTRY，最后 INSTALL DB2TRAN。如果在不同的

GROUP，则需要注意，必须是 DB2CONN 所在的 GROUP 先被 INSTALL，其次是

DB2ENTRY，最后是 DB2TRAN。

Thread 的概念

CICS 交易访问 DB2 数据时，需要一个 Thread 连接到 DB2，一般在 CICS 交易执行第一个访问

DB2 的语句时建立，在 Syncpoint 完成后释放（除非 Thread 被 Reuse）。

建立 Thread 需要消耗一定资源，所以在 Thread 释放前，CICS DB2 Attachment Facility 会检查是否

有别的交易正在 Wait Thread，如果有的话，会首先检查是否可以 Reuse，否则释放。CICS DB2

Attachment Facility可以使用三种 Thread：

1、Pool Thread


25 25

„„

有以下情况，会使用到 Pool Thread

交易没有定义相应的 DB2ENTRY 和 DB2TRAN。

交易定义了 DB2ENTRY 或 DB2TRAN，但是设置了 DB2ENTRY 参数 THREADLIMIT(0)

和 THREADWAIT(POOL)。

交易定义了 DB2ENTRY 或 DB2TRAN ，只设置 THREADWAIT(POOL) ，但是

THREADLIMIT 超出了，会 Overflow 到 Pool Thread。

交易定义了 DB2ENTRY 或 DB2TRAN，但是 DB2ENTRY 被 disabled 。

在 DB2CONN 的 Pool Thread Attributes 中定义相关参数。

参数 THREADLIMIT 定义最大 Pool Thread 数。

2、Command Thread

„„


26 26

用于在 CICS 中执行 DB2 命令，类似 DSNC + DB2 命令。

在 DB2CONN 的 Command Thread Attributes 中定义相关参数。

COMTHREADLIMIT 参数定义最大 Command Thread 数，超过了会被 Overflow 到 Pool

Thread。

3、Entry Thread

„„

Entry Thread 有如下特性：

对应一个或一类，有特殊需求的交易，比如对响应时间要求很高的关键交易或者有特定控制

的交易。

在 DB2ENTRY 和 DB2TRAN 中定义。

参数 THREADLIMIT：定义了最大 Entry Thread 数。

参数 THREADWAIT：定义了 Entry Thread 达到最大值后是否 overflow 到 pool Thread、等待


27 27

Entry Thread 释放或者直接 ABEND。

PROTECTNUM(n)可以用来定义 Entry Thread 是否是 Protected Thread，Protected Entry Thread

在交易结束后，即使没其他交易在等待这个 Entry Thread，也不会立即释放，如果一直没人使

用，会在两个 PURGECYCLE（在 DB2CONN 定义）后释放。

Thread 使用的一些建议

1、增加 Thread 的 Reuse，可以有效节省 CPU 资源。

Thread Reuse 避免了重新创建一个新的 Thread，对于大批量的同类应用交易，在节省 CPU 资源

上，有比较大的影响。

Pool Thread 在交易结束后，一般情况 Thread 会被立即释放，但是如果有其他交易在等待 Pool

Thread （需要设置 DB2CONN 参数 THREADWAIT=YES），并且使用同一个 Plan 的话，能被 Reuse。

Unprotected Entry Thread 在交易结束后，一般情况 Thread 会被立即释放，但是如果有交易在等待

Thread 释放（需要设置 DB2ENTRY 参数 THREADWAIT=YES），且使用的是同一个 DB2ENTRY 时，

会被 Reuse。

Protected Entry Thread 在交易结束后，它所使用的 Thread，即使没其他使用同一个 DB2ENTRY 的

交易在 Wait 这个 Thread，也不会立即释放，如果一直没有 Reuse，会在两个 PURGECYCLE（在

DB2CONN 定义）后释放。

PURGCYCLE 是 DB2CONN 定义中的一个参数，如果定义的是 30 秒，那么 Protected Thread 可以被

保留 30 至 60 秒。

综上所述，要增加 Thread Reuse 以减少 Thread 创建时的消耗、节省 CPU 资源，定义 Protected

Entry Thread 是最有效的手段。

一般生产系统，对于主要的联机交易都会实施 Protected Entry Thread，这些交易的特征都是大数量

和高频率，一般还有很快的响应时间。

2、根据应用交易不同的属性特征，我们对应可以使用不同的 Thread 类型，以便达到最优性能。

Transaction Description Thread Type Overflow

BIND Options

ACQUIRE RELEASE High volume (all types) Protected

Entry Yes,但是要定义足够的 Entry

Thread，尽量减少 Overflow

到 Pool Thread 的次数

ALLOCATE DEALLOCATE

Low volume, requires fast response time

Unprotected Entry

Yes USE COMMIT

Low volume, limited concurrency

Unprotected Entry

Never USE COMMIT

Low volume, does not require fast response time

Pool N/A USE COMMIT

3、定义合适的 CICS 和 DB2 连接

曾经遇到过的案例，CICS 中有大量交易挂起，从 DUMP 中的数据分析，交易等待的资源都是

‘CDB2CONN’，也就是 TCBLIMIT 已经达到上限，其他交易都在等待 Open TCB。进一步分析发

现，该 CICS 定义的 TCBLIMIT 是 60，而 DB2ENTRY 却定义了 1500 个，所有 DB2ENTRY 中定义的

Protected Thread 总和达到了 10000 多个，所以在一些 DB2ENTRY 类的交易结束后，相关的 Protected

Thread 需要最多两个 PURGECYCLE 的时间才能被释放，其他 DB2ENTRY 类交易的 Thread 无法被创


28 28

建。这样就导致当 CICS 中所有 Thread 都被几个 DB2ENTRY 交易的 Protected Thread 用完后，其他

DB2ENTRY 的交易只有等待 CDB2CONN，从而造成大量交易挂起。

为了避免类似的问题出现，我们在定义 CICS 和 DB2 连接时需要依据下文提到的规则。首先要明

确影响 CICS 和 DB2 连接的参数主要有：

MAXOPENTCBS 在 SIT 参数中指定，设置 CICS 可以使用多少 Open TCB

TCBLIMIT 在 DB2CONN 中指定，用于限制建立 DB2 连接的 CICS Thread TCB 数

量

THREADLIMIT 在 DB2CONN 和 DB2ENTRY 中都有指定。用于限制建立 Pool Thread

和 Entry Thread 的数量

CTHREAD 在 ZPARMS 中指定，用于限制在 DB2中同时建立的 Thread的数量。

对于 CICS 与 DB2 连接定义的一般规则是：

TCBLIMIT < MAXOPENTCBS

TCBLIMIT > SUM (THREADLIMIT)

TCBLIMIT < CTHREAD

结束语

以上简单介绍了 CICS 和 DB2 的连接定义与使用，希望对大家的工作有所帮助。


29 29

JES2 作业流

不能正常执行的

问题分析与解决

■ 文 / 百硕工程师王志军

在工作中遇到了在 JES2 中作业流已经提交，但是不能正常执行的问题。通过对这个问题的分

析和解决，使我更深入的理解了在 SYSPLEX 环境下，JES2 作业运行的原理和 WLM 对作业

的调度，这是我之前从未涉足的内容，因此记录下来这个问题的描述、分析与解决，与大家

分享，希望对大家有所帮助。

问题描述：

在某系统中每天使用 SA（Tivoli System Automation）定时提交产生系统性能报表的作业流。该系

统是一个 SYSPLEX 的环境，其中包含六个 LPAR：SYS1、SYS2、SYS3、SYS4、SYS5 和 SYS6。

2011 年 01 月 06 日，系统重新 IPL，所有系统均正常运行，7 日凌晨由 SA 定时自动提交的相关报表作

业流全部按时提交，但是这些作业在 JES2 的 Input Queue 中长时间等待，一直无法进入运行状态，导

致当天的所有报表都未按时自动生成，影响了后续的性能分析工作。

问题追踪：

(1)检查 Input Queue 中等待执行的作业流，发现其指定的 JOBCLASS 均为 CLASS=A。

(2)检查系统的 IPL 信息，发现系统在 2011 年 01 月 06 日 18.59.45 重新 IPL(使用命令：D

IPLINFO)。

(3)检查 JES2PARM 中的定义，发现 SYS1 中有 CLASS=A 的 INITIATOR，SYS2~SYS6 中没有

CLASS=A 的 INITIATOR。

(4)分别在 SYS1 和 SYS3 上提交同一个测试作业，指定 CLASS=A，测试结果都是这个作业在 Input

Queue 中长时间等待而不运行。

问题：为什么系统重新 IPL 后，虽然在系统 SYS1 的 JES2PARM 中定义了 CLASS=A 的

INITIATOR，但是提交 JOBCLASS 为 A 的作业却在 Input Queue 中持续等待，而不能选择 SYS1 中的

INITIATOR A 呢？

问题分析：

(1) 检查 JOBCLASS(A)的属性，如下：

$D JOBCLASS(A)

$HASP837 JOBCLASS(A) 604

$HASP837 JOBCLASS(A) MODE=WLM,QAFF=(ANY),

$HASP837 QHELD=NO,

$HASP837 SCHENV=,

我


30 30

$HASP837 XEQCOUNT=(MAXIMUM=*,

$HASP837 CURRENT=0),

$HASP837 XEQMEMBER(MVST)=(MAXIMUM=*,

$HASP837 CURRENT=0)

根据上面的信息，MODE 参数指定了 WLM，说明 JOBCLASS 为 A 的作业运行是通过 WLM 管理

的，SCHENV 参数应该指定 Scheduling Environment 名字，但这里却没有任何指定(这些信息在 Input

Queue 中也可以看到)。

经查，在 TSO 的 SD.SE 画面，本 SYSPLEX 中只有一个 Scheduling Environment，是 JES2WLM。

(2) 检查 Scheduling Environment(JES2WLM)的状态信息，如下：

D WLM,SCHENV=JES2WLM

IWM036I 14.36.20 WLM DISPLAY 449

SCHEDULING ENVIRONMENT: JES2WLM

DESCRIPTION: JOB UNDER WLM

AVAILABLE ON SYSTEMS: SYS3 SYS4 SYS5 SYS6

可见，系统重新 IPL 之后，只有系统 SYS3~SYS6 上的 Scheduling Environment(JES2WLM)是可用

的。我们使用命令“D WLM,SCHENV=JES2WLM,SYSTEM=system_name”检查 SYS1 和 SYS2 的

Scheduling Environment(JES2WLM)，发现其状态均为不可用的。

只有当系统的 Scheduling Environment 为可用状态时，WLM 才可能选择在这个系统去执行作业。

但是在该 SYSPLEX 环境下，JOBCLASS(A)的管理模式是 WLM，SCHENV 参数没有指定。在这

种情况下提交 JOBCLASS 为 A 的作业，WLM 不能根据相应的 Scheduling Environment 来选择在哪个系

统中运行该作业，进而导致该作业在 Input Queue 中长时间等待而不能继续执行。如果 JOBCLASS(A)

中的 SCHENV 参数指定了 Scheduling Environment（JES2WLM），无论是在 SYS1 还是 SYS3 上提交

JOBCLASS 为 A 的作业，WLM 都会选择 SYS3~SYS6 中的某一个系统来运行该作业。

问题解决：

为了使在 Input Queue 中的作业能够正常执行，有如下四种方法。

方法一：修改该作业的 JOB CLASS 为 C（CLASS=C 是 JES2 管理的，可在 SYS3 上运行），这样

该作业就可以在 SYS3 上执行。

方法二：因为 JOBCLASS A 是 WLM 管理的，所以要执行 JOBCLASS 为 A 的作业，则需要将

JOBCLASS(A)的 SCHENV 默认参数动态修改为 JES2WLM。具体操作为：在 SYS1 中使用命令“$T

JOBCLASS(A), SCHENV=JES2WLM”。这样，WLM 就会选择 SYS3~SYS6 中的某一个系统来运行该

作业。

方法三：如果想在 SYS1 上运行 JOBCLASS 为 A 的作业，则除了修改 JOBCLASS(A)的 SCHENV

参数外，还要将 SYS1 的 Scheduling Environment(JES2WLM)改为可用状态。具体操作为：在 SYS1 中

使用命令“F WLM,RESOURCE= JESWLM,ON”，将 JES2WLM 需要的资源 JESWLM 开启，这样

SYS1 中的 Scheduling Environment(JES2WLM)即为可用状态。

方法四：这个问题产生的根本原因是在系统重新 IPL 后，有人手动将 JOB CLASS (A)的管理模式

从 JES2 管理修改成 WLM 管理，但是并没有同时修改 JOBCLASS(A)的 SCHENV 参数，因此，将

JOBCLASS(A)的管理模式恢复为原来的 JES2 管理，这样当提交 JOBCLASS 为 A 的作业时，JES2 就会


31 31

选择 SYS1( 含有 CLASS=A 的 INITIATOR) 来运行该作业，具体操作是： $T

JOBCLASS(A),MODE=JES。

问题关联知识点介绍：

JES2 中有三种作业 Batch Job、Started Task 和 Time-sharing User，它们的 JOBID 都是 8 个字符，格

式是分别是"JOBnnnnn"， "J0nnnnnn"， "STCnnnnn"， "S0nnnnnn"， "TSUnnnnn" 和"T0nnnnnn"。与作

业的种类相对应有 38 个 JOB CLASS，其中 CLASS=STC 为 Started Task 专用，CLASS=TSU 为 Time

Sharing Users 专用，CLASS=A~Z 和 0~9 共计 36 个类别为 Batch Job 使用。在作业流中的 CLASS 参数

指定了该作业属于哪个 JOB CLASS。

每一个批量作业都有自己的一个独立的地址空间，所有的批量作业都存放在相应的 CLASS 队列

中，由 Initiators 根据相应的规则从各个 CLASS 队列中选择不同的作业交给系统来执行，批量作业是否

能够执行是由 Initiators 来决定的，而 Initiators 有两种模式，一种是由 JES2 控制的 JES 模式，另一种是

被 MVS 管理的 Workload Management (WLM)模式，在 JES2PARM Job Class 定义中有关于这个 MODE

参数的指定。也就是说，JES2 选择 Job 执行有两种不同的选择机制，这两种不同的选择机制对应着两

种不同的队列结构，他们分别是：

(1)由 JES2 管理的 Initiators 来处理的队列，这个队列是 JES2 把转换后的 JCL按照 JOB CLASS、优

先级和转换完成的先后顺序排列成的。JES2 Initiators 选择拥有最高优先级的 CLASS 队列里的拥有最高

优先级的作业，然后将控制转给 MVS，由 MVS 启动程序。

作业执行时显示的信息如下：

$HASP373 TESTJCL STARTED - INIT 1 - CLASS A - SYS SYS1

(2)由 WLM 动态控制的 Initiators 来处理的队列。如果提交一个作业，这个作业的 JOBCLASS 定义

中指定了 MODE=WLM，那么当这个作业被成功转换之后，JES2 使用 WLM 分类，根据 JOB CLASS、

JOB NAME、JOB Priority、提交作业的 USERID、作业的统计信息和作业中的“PERFORM”参数来给

提交的这个作业分配一个服务类(Service Class)，然后作业就根据这个服务类进行排队，这个队列里的

作业就是由 WLM 动态控制的 Initiators 来选择处理的。WLM 能够根据不同的队列名、作业的性能目标

和它的重要性、完成这个作业的利益大小和每个系统中的作业容量限制等信息对每个系统中的

Initiators 的数量进行调整，使每个系统都能合理高效的运行相关的作业。

作业执行时显示的信息如下：

$HASP373 TESTJCL2 STARTED - WLM INIT - SRVCLASS BATWLMME - SYS SYS3

注意：Started Tasks 和 Time Sharing User 这两种作业不需要 Initiators 来选择执行，它们直接由系统来调

度。

问题扩展（MODE=JES）：

如果一个由 JES2 管理的作业在 Input Queue 中持续等待，我们需要查找 JES2 中定义的 Initiators，检查

每个 Initiators 的 CLASS 参数指定情况。

例如：在 Input Queue 中有 CLASS=K、MODE 为 JES 的一个作业在持续等待，使用命令$D I 显示所有

Initiators 的信息，以下是其中的一部分：

$D I

$HASP892 INIT(1) 981

$HASP892 INIT(1) STATUS=INACTIVE,CLASS=A,NAME=1,

$HASP892 ASID=001B


32 32


$HASP892 INIT(2) STATUS=INACTIVE,CLASS=BA,NAME=2,

$HASP892 ASID=002D

检查完定义的所有 Initiators 后，没有找到 CLASS=K 的参数指定，也就说 JES2 管理的 Initiators 不

对 CLASS=K 的队列进行调度处理，因此在 CLASS=K 的队列里的作业一直处于等待状态不能被

Initiators 选择执行。

我们也可以有两种方法解决此问题：

方法一：

修改 Initiators 中的 CLASS 参数，增加 CLASS=K 的定义。

例如，修改 INIT(1)中的 CLASS 的定义，如下：

$T I1,C=AK


$HASP892 INIT(1) STATUS=INACTIVE,CLASS=AK,NAME=1,

$HASP892 ASID=001B

方法二：

让作业使用 JES2PARM 中已定义的 JOB CLASS。

例如 INIT(1)中有 CLASS=A 的指定，将作业的 CLASS=K 改为 CLASS=A，如下：

$T Jnnnnn,C=A

$HASP890 JOB(DEFGDG) 082

$HASP890 JOB(DEFGDG) STATUS=(AWAITING HARDCOPY),

$HASP890 CLASS=A,PRIORITY=1,SYSAFF=(ANY),

$HASP890 HOLD=(NONE)


33 33

CICS 系统相关的问题

■ 文 / 百硕高级工程师应永杰

题 1．CICS CMF Performance Class 中各种类型的 Suspend (Wait) Time 和

Dispatch Wait Time 是什么关系？

答：上图是在各类文档中经常能见到的 CICS 交易响应时间组成图。交易 Suspend Time 包含了 First

Dispatch Delay、Dispatch Wait 以及各种类型的 Suspend (Wait) Time 明细，例如 File I/O Wait Time、LU

6.2 I/O Wait Time、Local ENQ Delay Time 等等。但需要引起注意的是 CICS CMF 数据中各种类型的

Suspend (Wait) Time 明细中都已经包含了一部分的 Dispatch Wait，不能简单地认为：

当导致某种类型 Suspend (Wait)的事件结束后，任务需要重新被 CICS Dispatcher 调度，事件结束至

任务被重新调度这一段时间即计入该类型的 Suspend (Wait) Time 中，同时也计入 Dispatch Wait 中。当

QR TCB 不能及时调度任务而出现比较长的 Dispatch Wait 时，往往会增加各种类型 Suspend (Wait)

Time 明细的时间。

问


34 34

Application execute E.C Write File

CICS File Control create VSAM RPL

Call VSAM

VSAM Connect RPL to I/O Control Blocks

Schedule I/O

Call CICS through UPAD Exit for WAIT

UPAD Exit create ECB for I/O Completion

Extend ECB to point to CICS Post Exit Stub

Update DTA resource fields and remove from dispatchable chain

CICS Dispatch other tasks„„

IO complete

ECB Posted and drive CICS Post Exit

CICS Post Exit driven

Update DTA resource fields and put back on dispatchable chain

Task was picked up by CICS dispacher and redispatched again

Finish one IO and Return to VSAM or ApplicationDis

pat

ch W

ait

Tim

e

FC

IOW

AIT

Par

t 2

Par

t 1

我们以上图中简化后的 LSR 文件访问过程为例来说明，VSAM 启动了 I/O 操作后通过 UPAD Exit

返回控制给 CICS，CICS 把任务状态置为 FCIOWAIT 并开始计时，任务对应的 DTA 从 Dispatchable

Chain 中移除，CICS 开始调度其他任务。I/O 结束后 CICS Post Exit 会把任务对应的 DTA 放入

Dispatchable Chain 中等待重新调度，Dispatch Wait Time 计时开始，但 FCIOWAIT 计时并没有停止。任

务被 CICS Dispatcher 重新选中执行后，FCIOWAIT 计时才结束。FCIOWAIT 即包含了物理 I/O 花费的

时间（图中 Part 1 部分），也包含了物理 I/O 完成后，任务等待被重新调度的时间（图中 Part 2 部

分）。任务等待被重新调度的时间（图中 Part 2 部分）会同时计入到 FCIOWAIT 和 Dispatch Wait 中。

2．应用程序在 CICS L8 TCB 上运行时，其 EXEC KEY 是否一定是 8？

答：不是。L8 TCB 是一个 Key 为 8 的 TCB，所谓 Key 为 8 实际上代表 TCBPKF=8，也就是 TCB 的

Storage Protection Key为 8。在 OPENAPI的应用程序中 TCBPKF起着非常重要的作用，OPENAPI 的应

用程序中往往需要直接调用一些 MVS Service，例如 Getmain，在很多情况下，Getmain 获得空间的

Storage Protect Key 是由 TCBPKF 决定的，此时如果程序在 L8 TCB 上运行，则 Storage Protect Key 为

8；如果在 L9 TCB 上运行则 Storage Protect Key 为 9。但对于 CICSAPI 的应用程序，TCBPKF 意义不

大，因为 CICS 屏蔽了很多处理细节。EXEC KEY 和 TCBPKF没有直接关系，应用程序在 L8 TCB 上运

行时，其 EXEC KEY 既可以是 CICS KEY（8）也可以是 USER KEY（9），取决于程序 PPT 定义中

EXEC KEY 参数（EXECKey==>User|Cics）。这和 QR TCB 上运行的应用程序，其 EXEC KEY 既可以

是 8 也可以是 9 是一样的道理。

问题 3．CICS 系统尤其是 FOR 中经常需要定义大量的文件，这些文件又可能分布在多个

卷上，这样会不会导致 TIOT 空间不足？


35 35

答：不会，CICS 资源定义中的文件采用 XTIOT 而非 TIOT。TIOT 的大小在 PARMLIB 的 ALLOCxx

Member 里定义，默认值是 32K。TIOT 在 16M 线下，是一块连续的空间，主要由 DD Entry组成，在文

件分配时建立，每个 DD 定义对应 TIOT 中一个 DD Entry。每个 DD Entry 又包含了若干个 Device

Entry。Device Entry指向特定的 UCB 或 DUMMY UCB，Device Entry个数取决于以下两个值中的较大

的一个：数据集在 Catalog 中的 Volume Count 数量，数据集对应的 Data Class 中 DVC 参数。DD Entry

和 Device Entry 一旦建立后在整个文件分配期间不能改变大小。32K 默认值足以支持 1635 个不跨卷的

数据集，或者 129 个均跨 59 个卷的数据集。对于 CICS 系统，在 CICS 启动 JCL 中定义的文件会受到

ALLOCxx 中 TIOT 参数大小的制约，但 CICS 资源定义 DFHCSD 中定义的文件都是采用动态分配，并

且设置了 PLIST 的 S99ACUCB 标志，最终会创建 Uncaptured UCBs 和 XTIOT。XTIOT 分布在 16M 线

上，不同于 TIOT，XTIOT 中各 Entry 是不连续的，不受 ALLOCxx 中 TIOT 参数大小的制约。可以通

过下图 Control Block 搜索到文件对应的 TIOT/XTIOT DD Entry，该方法对于 TIOT 或 XTIOT 都有效。

编程中一般会采用 GETDSAB 宏来取得特定的 TIOT，或遍历 DSAB Chain 来获得所有的 TIOT Entry。

另外 DB2 系统中 Tablespace 对应的文件也是采用 XTIOT。

DCBDEBA DEBXTNP DEBXDSAB DSABTIOT TIOT DD Entry

问题 4．CICS SYSTEM DUMP 格式化后 KE Domain Error Table 中 Branch Event

Address 是什么含义？

答：Branch Event Address 表示上一次成功执行的分支指令（Branch Instruction）的地址。从 Z9-109 开

始，z/Architecture 引入了一个新的 64 位 CPU 寄存器 BEAR（Breaking Event Address Register），存放

上一次引起程序顺序执行流程跳转（Break）的指令的地址。BEAR 需要 z/OS V1.7 以上版本的支持，

CICS TS V4 全面支持 BEAR。当出现 Program Check 时，BEAR 中的值会保存到 PSA（Prefixed Save

Area）的 FLCEBEA 字段中。Recovery Termination Manager 获得控制权后创建的 RTM2 Work Area 中就

包含了 BEAR 的值（RTM2BEA 字段），RTM2 会把 BEAR 的值通过 System Diagnostic Work Area

（SDWABEA 字段）传给 CICS ESTAE 出口程序 DFHKESTX，最后会保存在 TAS，KERRD 或 TACB

等 CICS Control Block 中。格式化 DUMP 时，BEAR 的值最终会显示在 KE Domain 的 Branch Event

Address 中。CICS TS V3 需要安装相应的 APAR 才能显示 Branch Event Address。对于非 CICS 的

DUMP，一般也能通过 IPCS 命令‘IP SUMM FORMAT’来格式化 DUMP，然后从 RTM2WA 中找到

BEAR 的值。如果在 System Trace Table 中能找到调用 ESTAE 的 SYNCH（SVC C）请求对应的 Trace

Entry，那么 Register 1（UNIQUE-3 字段）会指向 SDWA，可以用 IPCS 命令‘IP CBF xxxxxxxx

str(SDWA)’格式化 SDWA 并找到 BEAR 的值。BEAR 极大地方便了诊断‘Wild Branch‟引起的

0C1/0C4 等异常情况。


36 36

Fetch

instruciton

pointed to by

PSW into

CPU

Update PSW to

point to the

NSI(Next

Sequence

Instruction)

Store instruction

address into BEAR

Update PSW from

the instruction

Execute the

instruction

Branch type

instruciton?

NO

YES

Branch Instruction Execution


37 37

百硕客户通讯 BAYSHORE ADVISOR

中国主机用户专享的资讯季刊

2011 年 3 月 1 日出版（总第 23 期）

主办：百硕同兴科技（北京）有限公司

出版：百硕客户通讯编委会

吕宁

李琰

王晓兵

徐卫华

邹杰

刘京平

吴笳笳

高春霞

高大川

张凤华

陈银波

高玉超

贺明

郑霞

康会影

彭晰遥

Martha Hall

地址：北京市朝阳区望京科技园利泽中二路 1 号中辰大厦 209 室

电话：010 64391733 传真：010 64391582

电子邮箱：[email protected]

如果您对百硕客户通讯有任何意见和建议，欢迎您随时与我们交流！


38 38

百硕客户通讯总第 23 期（2011 年 3 月 1 日）

百硕同兴科技（北京）有限公司

Bayshore Consulting and Service Co., LTD.

百硕客户通讯，总第百硕客户通讯，总第23 期（2011 年3 月1 日） 7 7 far the...

Documents