百硕客户通讯，总第 17 期（2009 年9 月1 · 百硕客户通讯，总第17 期（2009...

百硕客户通讯，总第 17 期（2009 年 9 月 1 日）

0


1


2

IBM Capacity Offerings

IBM has several different capacity offerings that offer some great help to System z users. The newest offering is a new temporary capacity offering Capacity for Planned Event (CPE), which is a variation of Capacity Back Up (CBU. I will review several of these capacity offerings from IBM in more detail.

Capacity on Demand for System z

IBM® System z models offer and support Capacity Upgrade on Demand, On/Off Capacity on Demand, and Capacity BackUp. These offerings are based on customer requirements.

Capacity on Demand (CoD) includes various capabilities that allow you to dynamically activate one or more resources on your system as your business peaks dictate. You can activate inactive processors or memory units that are already installed on your system on a temporary or permanent basis. The basic principle underlying CoD is accessing the resources that you need, when you need them, and paying for only the resources that you use.

You can add capacity by: • Adding CPs • Increasing the capacity settings of

installed CPs • Adding CPs and increasing capacity

settings of all CPs (to the same capacity setting)

• Increasing the capacity settings and reducing the number of CPs

• Decreasing the capacity settings and increasing the number of CPs

For more detailed information about the CoD options for System z, you can review the

“IBM System z9 and eServer zSeries Capacity on Demand User's Guide”. This PDF was updated in May of 2009 and is intended for customers who has purchased or are considering the purchase of Customer Initiated Upgrade (CIU), On/Off Capacity on Demand (On/Off COD), or Capacity Backup (CBU). The functions are available on z9 and zSeries servers. The Bayshore Technical Library has a copy of this PDF which can be provided to anyone who is interested.

Customer Initiated Upgrade (CIU)

The CIU feature enables you to order permanent capacity upgrades rapidly and download them without disrupting applications already running on the server. When extra processing power becomes necessary, a user administrator simply navigates to Resource Link on the Internet to order the upgrade. The Remote Service Facility on the Hardware Management Console is used to download and activate preinstalled inactive processors or memory for an additional charge.

On/Off Capacity on Demand (On/Off CoD)

This offering is available through CIU. You can use On/Off CoD for temporary increases in processor capacity for your fluctuating workloads. With temporary processor capacity, you can help your business manage both predictable and unpredictable surges in capacity demands. You can activate and deactivate the function quickly and efficiently as the demands on your organization dictate.


3

You obtain additional capacity that you need, when you need it, and the server will keep track of your usage. On/Off CoD provides a cost-effective strategy for handling seasonal or period-end fluctuations in activity and may enable you to deploy pilot applications without investing in new hardware. Although there is a fee for On/Off CoD, free tests are available.

Capacity Backup (CBU)

You can use CBU to add temporary processing capacity to a backup server in the event of an unforeseen loss of server capability because of an emergency. With CBU, you can divert entire workloads to backup servers for up to 90 days. Although free tests are available for CBU, there is an up front fee and an emergency-use fee, which includes testing; software fees are not affected.

Capacity for Planned Event (CPE)

This offering is the newest Capacity Offering that is available from IBM. This offering is a

temporary capacity offering. Capacity for Planned Events (CPE) offers a concurrent and temporary activation of additional CPs, ICFs, IFLs, zAAPs, zIIPs, and SAPs, an increase of the CP capacity level, or both in the event of a planned outage of System z capacity within the enterprise. The capacity of a CPE upgrade is used to replace temporarily lost capacity within an enterprise for planned downtime events, for example for data center changes or system maintenance.

References:

IBM Systems Magazine from November of 2008. The article “System z10 and the Data Center” Ken Milberg. IBM System z9 and eServer zSeries Capacity on Demand User's Guide Updated 5/2009 IBM Redbook System z10 Capacity on Demand SG24-7504 January 2009


4 4

CICS 40 周年 In July 8 2009, CICS celebrated its 40th anniversary as an IBM Program Product. IBM "Blue Letter" 269-44, dated July 8, 1969 announced the availability of the System/360 Customer Information Control System, Program Product 5736-U11, was "ready for shipment".

Prior to 1969, CICS had initially become available as a free "Type II Application Program", which was a common IBM software distribution prior to June 1969.

On June 23, 1969, IBM announced "unbundling", which basically said IBM would begin to charge separately for Systems Engineering services and program software. CICS was among the very first IBM software offerings to be packaged as a "Class A Program Product" (Class A PPs provided software defect support).

Detail information of CICS History

July 8, 1969 • CICS/OS introduced as program offering • Designed to support 50 BTAM terminals • Supported out of Palo Alto, CA • Not expected to last more than a few years • Assembler macros that supported a limited number of functions

1974 • CICS/VS 1.0 introduced • Single address space or partition monitor • Introduction of management functions • Support for DOS/VS, OS/VS1, and OS/VS2 • Macro Level only • HLL supported through pre-processor

1977 • CICS/VS 1.3 • Support moved to Hursley in exchange for PL/1 • Introduction of command level API • Introduction of recovery/restart

1978 • CICS/VS 1.4 • Introduction of ISC • IBM Statement: New functions will be through command level

1980 • CICS/VS 1.5


5 5

• Introduction of MRO

1982 • CICS/VS 1.6, and 6 months later 1.6.1 • Introduction of RDO for PPT and PCT entries • Last release to provide the same functionality across all operating systems • XA functions are provided • VSAM subtasking introduced

1986 • CICS/VS 1.7 • AUTOINSTALL + JES Spool Interface support introduced • VTAM terminals now RDO definable • ISAM support dropped • File control program and other management module rewritten • The new code became OCO • IBM again warns its customers about Macro Level

1987 • CICS/MVS 2.1 • Some performance improvements over 1.7 • Introduction of XRF

1989 • CICS/ESA 3.1 • Macro Level support dropped for HLL programs • Totally new architecture • Multiple TCBs • Many old functions dropped

1990 • CICS/ESA 3.2 • Macro Level support dropped for all languages • Another rewrite for DFHFCP • CICS security as known (DFHSNT) is eliminated • More old functions are dropped

1992 • CICS/ESA 3.3 • Storage protection feature for CICS/ESA domain storage • Introduction of Dynamic Link function • Shared Data Tables • Distributed Program Link • Front End Programming Interface


6 6

1994 • CICS/ESA 4.1 • Transaction Isolation (Storage protection) • MRO using Enhanced Cross System Coupling Facilities (XRF) • Dynamic transaction routing among Parallel Transaction Server

machines

1995 • CICS/VSE 2.3 • Enhanced programmer interfaces allowing for the replacement of macro level calls • Support for LE for VSE/ESA and associated languages • A tool to aid in the migration of customers from the use of internal CICS security to an

external security manager (ESM)

1996 • CICS Transaction Server for OS/390 1.1 • A new domain for logging and journaling - the CICS log manager • A new domain for recovery - the CICS recovery manager • A new domain for temporary storage • RDO for transient data destinations • Addition of the EXEC CICS CREATE SPI command for the creation of CICS resource

definitions for a sysplex-wide systems management product

1997 • CICS Transaction Server for OS/390 1.2 • Introduction of DASDONLY logging

1999 • CICS Transaction Server for OS/390 1.3 • Parallel Sysplex support • Coupling facility data tables • RDO for temporary storage • Long temporary storage queue names • Autoinstall for consoles • CICS business transaction services (BTS) • Open transaction environment (OTE) • Support for the Java Virtual Machine (JVM) • Support for IIOP requests inbound to Java application programs.

2000 • CICS Transaction Server for VSE/ESA 1.1.1 • Exploitation of ESA/390 subsystem storage protection • Extensive Virtual Storage Constraint Relief


7 7

• Expanded Application Programming Support including a new External CICS Interface (EXCI) and a Front End Programming Interface (FEPI)

• System Management enhancements including Resource Definition Online (RDO) for files • Shared data tables for improved performance and availability • The CICS Web Interface (CWI) which provides direct access to CICS applications from

the World Wide Web environment. This will be available from the first quarter of 2000 • The CICS 3270 Bridge, which provides an interface to run 3270-based CICS transactions

without a 3270 terminal. • Inclusion of REXX for CICS, from the fourth quarter of 1999. • Inclusion of CICS/DDM as an optional no-charge feature • Inclusion of Report Controller Facility (RCF) without extra charge.

2001 • CICS Transaction Server for z/OS 2.1 • Support for the industry-standard Enterprise JavaBeans (EJB) architecture, enabling CICS

to act as an EJB server • Facilities for the generation of new EJB applications, or for the reuse or incorporation of

existing applications and data in an EJB solution • Enhancements to the facilities for network connectivity in support of e-business

enablement, and to Java programming under CICS • Extensions to facilities for applications based on procedural programming models • Significant extensions to CICSPlex SM

2002 • CICS Transaction Server for z/OS 2.2 • Enhanced support for Enterprise Java, and session bean support that conforms to the J2EE

Enterprise JavaBeans (EJB) architecture.

2003 • CICS Transaction Server for z/OS 2.3 • Enhanced Java capability including performance improvements, support for Java SDK 1.4,

the Common Client Interface (CCI) Connector for CICS TS, and the addition of CICS Web Support to the JCICS classes

• Improved support for development of applications, including interactive debugging • Further connectivity options, including new security functions, and the recently-

introduced SOAP for CICS optional feature • Enhancements in the area of availability, including workload balancing of the 3270

Bridge using CICSPlex(R) SM • Important performance improvements in CICS-DB2 attachment

2005 • CICS Transaction Server for z/OS 3.1


8 8

• Major new capabilities are provided in the areas of Web services, HTTP function, and security

• C/C++ capability is enhanced by support for XPLink • CICS Web API commands are now threadsafe • OTE function has been extended • Language Environment-enabled Assembler applications are supported • A new mechanism is provided for inter-program data transfer • The Information Center has moved to the Eclipse platform • Functional and usability improvements are provided to the CICSPlex SM Web User

Interface, enabling systems to be fully managed without the TSO End User Interface • New batch update mechanism is provided for the CICSPlex SM data repository

2007 • CICS Transaction Server for z/OS 3.2 • Application Connectivity

o Web services standards, interoperability profiles, large messages, and data mapping

o Intercommunications over TCP/IP o HTTP and TCP/IP management and performance

• Application Reuse o 64-bit storage for CONTAINER data o CICS integrated translator support for C and C++ o Java enhancements

• Service Management o On-line management of program libraries o Enterprise Workload Manager o CICSPlex SM Web User Interface help, usability, and MAP support o CICS-WMQ adapter installation and management

• Architectural Enhancements o Capacity of VSAM ESDS files >4GB, shared data tables >2GB, and CICS regions

in a Sysplex o Trace, monitoring, and statistics o Threadsafe core APIs for accessing VSAM files, journals, and WebSphere MQ

2009 • CICS Transaction Server for z/OS 4.1 • Non-invasive detection and emission of business events from CICS applications provides

insight into business behavior • Atom feeds and RESTful interfaces enable existing CICS programs and resources to

participate in mashups, Web 2.0 and other situational applications


9 9

• The CICS Explorer simplifies the development and management of traditional and modern applications and provides an integration point for IBM and third-party tools

• A wide range of other technical and operational capabilities, including many requirements raised by individual customers and user communities

CICS Product still Support Product name Version GA date End of Support CICS TS for z/OS 2.3 2003/12/19 2009/9/30 CICS TS for z/OS 3.1 2005/3/25 CICS TS for Z/OS 3.2 2007/6/19 CICS TS for z/OS 4.1 2009/6/26 CICS/VSE 2.3 1995/4/21 CICS TS for VSE 1.1 2000/9/29


10 10

再谈 CICS Storage

百硕工程师应永杰

1.CICS Key 和 USER Key

CICS (E)DSA 的 Storage Key 由 SIT 参数 STGPROT 和 RENTPGM 决定。当

STGPROT=NO 时，(E)SDSA 和(E)UDSA 的 Storage Key 为 8。当 STGPROT=YES 时，

(E)SDSA 和(E)UDSA 的 Storage Key 为 9。EXEC Key 为 8 的程序既可以更新 Storage Key为 9 的(E)DSA，也可以更新 Storage Key 为 8 的(E)DSA，这要归功于 z/Arch 的“Storage-Protection-Override Control”机制。

z/Arch 中对于内存的访问提供了四类保护机制，其中之一是 “Key-Controlled Protection”。根据“Key-Controlled Protection”原则，当需要读取相应内存区域时，Access key 必须与 Storage Key 相匹配，或者 Storage Key 中的“Fetch-Protection Bit”等于“0”；当需

要更新相应的内存区域时，Access key 必须与 Storage Key 相匹配。此处的“Key 值匹配”是指 Storage Key 和 Access Key 相等或是 Access Key 为“0”。但 z/Arch 同时提供了“Storage-Protection-Override Control”机制，如果系统支持“Storage-Protection-Override Control”特征，NIP 初始化时会把 CVT 中的 CVTOVER 置为“1”；程序运行时，CR0 的第 39 位为

“1”，此时 Storage Key 9 赋予了特殊含义，即“Public Storage Key(PSK)”。“Key-Controlled Protection”对于 Storage Key 为 9 的内存区无效，任何 Access Key 都可以读写 Storage Key为 9 的内存区域。“Storage-Protection-Override Control”提供了非常有效的子系统空间保护

机制。例如在 CICS 子系统中，容易出错的应用程序在 EXEC Key 9 下运行，只能读取

Storage Key 8 的(E)DSA，但不能更新 Storage Key 8 的(E)DSA。避免了应用程序对 CICS代码和 Control Block 的错误修改，极大地提高了 CICS 子系统的稳定性。同时在 EXEC Key 8 下运行的 CICS 子系统代码可以同时更新 Storage Key 8 和 Storage Key 9 的(E)DSA。

该机制有时也叫 CICS SubSystem Storage Protection（SSSP）。

2.(E)DSALIMIT 和虚存分配

CICS 启动时会根据 SIT 参数(E)DSALIMIT 的值,来申请虚存空间，并非随着(E)DSA实际使用量的增加而加大虚存空间。CICS Region 启动后典型的虚存空间分配情况见下

图：


11 11

图中“Max Ext. User Region Addr”和“Max User Region Addr”是由 JCL REGION 参

数和 IEALIMIT/IEFUSI exit 决定的。

CICS 运行过程中“High Private Area”（图中区域 1 和 9）将根据需要动态向下扩

展。“CICS MVS Storage”（图中区域 3 和 11）使用量的增加或(E)DSALIMIT 参数的动

态调整都会导致 CICS Region Top 向上扩展。因此，必须保留适当的未分配空间（图中区

域 2 和 10）。“High Private Area”空间不足无法向下扩展时常常会导致 S80A 或 S822 等

ABENDs。至少应该有 200KB-300KB 的未分配空间供 RTM 作恢复处理用，否则将会导致

S40D ABEND，使 CICS 异常终止。通过“CEMT SET SYSTEM (E)DSALIMIT”命令动态

增加(E)DSALIMIT 值，系统一般也会在“(Ext.) USER Region Top”上未分配空间里再通

过 GETMAIN 申请一块虚存空间。

3.虚存和实存关系

虽然 CICS 根据 SIT 参数(E)DSALIMIT 的值(E)来申请虚存空间，但并不会造成实存

Frame 的浪费。由于 CICS (E)DSA 对应的 MVS Subpool 都是 Pageable Storage，这些

(E)DSA 的虚存 Page 初始状态都是 First Reference 状态，并没有对应的实存 Frame 来


12 12

“Back”。实际上即使一个任务通过“EXEC CICS Getmain”命令从(E)DSA 中申请了空

间，虚存 Page 也不一定有实存 Frame 来“Back”（当然 SAA 或 SCZ 所在的虚存 Page 肯定是有实存 Frame 来“Back”的）。

实存 Frame 是由 RSM 来管理的，当第一次访问(E)DSA 中虚存 Page 时，DAT（Dynamic Address Translation）过程如果发现该虚存 Page 没有对应的实存 Frame 来

“Back”，将引起一个 Segment Translation Exception(PIC 10，Segment Invalid Bit 为“0”)或 Page Translation Exception (PIC 11，Page Invalid Bit 为“0”)。中断处理例程会把控制

权转给 RSM，RSM 将从 AFQ（Available Frame Queue）中为该虚存 Page 分配一个实存

Frame。（对于 Page-out 到 Page Data Sets 中的虚存 Page，中断处理例程则会通过 ASM 启

动一个 Page-in 操作）。

4.CICS (E)DSA 和 MVS Subpool

CICS 系统中有 8 类(E)DSA（不考虑 2G BAR 上 GDSA），根据 CICS SIT 参数

STGPROT 和 RENTPGM 不同，这些(E)DSA 分属不同的 MVS Subpool(SP)，拥有不同的

Storage Key，其对应关系如下表： (E)DSA 和 MVS Subpool 对应关系表

SIT 参数 STGPROT RENTPGM NO YES NOPROTECT PROTECT

CDSA CICS Key 8 SP 130

CICS Key 8 SP 130

N/A N/A

N/A N/A

RDSA N/A N/A

N/A N/A

CICS Key 8 SP 130

Read-only-Key 0 SP 252

SDSA CICS Key 8 SP 130

USER Key 9 SP 130

N/A N/A

N/A N/A

UDSA CICS Key 8 SP 130

USER Key 9 SP 130

N/A N/A

N/A N/A

ECDSA CICS Key 8 SP 130

CICS Key 8 SP 130

N/A N/A

N/A N/A

ERDSA N/A N/A

N/A N/A

CICS Key 8 SP 130

Read-only-Key 0 SP 252

ESDSA CICS Key 8 SP 130

USER Key 9 SP 130

N/A N/A

N/A N/A

EUDSA CICS Key 8 SP 130

User Key 9 SP 130

N/A N/A

N/A N/A

未分配(E)DSA Key 0 SP 252

Key 0 SP 129

N/A N/A

N/A N/A

CICS (E)DSA 以 Extent 为单位进行分配，16M 线上 Extent 分配单位为 1M；16M 线下

Extent 分配单位一般为 256K（当设置了交易隔离时，UDSA 的 Extent 分配单位为 1M）。

当某类(E)DSA 需要额外的空间时，CICS 会从保留的未分配的(E)DSA(图中区域 4 和

12)中分配一个 Extent 给该类(E)DSA。当保留的未分配的(E)DSA 空间不能满足请求时，如

果其它类(E)DSA 中能找到某个 Extent 的空间都处于 free 状态的 Extent，则该 Extent 可以

被重新分配给请求的(E)DSA。由于不同类(E)DSA 及未分配的(E)DSA 可能属于不同的


13 13

MVS Subpool，所以在该过程中一般需要先释放原 MVS Subpool 的虚存空间，然后在原来

的虚存地址处重新申请新 MVS Subpool 的虚存空间。

5.如何利用 64 位地址空间

2G BAR 以上虚存不区分 MVS Subpool，也不能通过 GETMAIN 或 STORAGE 宏来分

配，只能通过 IARV64 宏来申请。CICSTS V3.2 允许使用 2GB 以上的虚存空间，2G 以上

的 DSA 被称为 GDSA(Grande Dynamic Storage Area)。不同于 DSA 和 EDSA，CICS 不会预

先申请一块 GDSA 虚存空间，CICS 也没有自己的 GDSA 使用上限参数，2G BAR 以上最

大可用空间由 MEMLIMIT 参数控制，默认值为“0”，意味着不能利用 2G BAR 以上虚存

空间。MEMLIMIT 参数可在 CICS 启动 JOB 中指定或在 SMFPRMxx 中设置，当然也可以

在 SMF Exit“IEFUSI”中指定。CICS 对于 2G 上虚存空间的利用主要是通过 Container 来实现，如果指定了 MEMLIMIT 参数，CICS 总是把 Container 放在 2G BAR 上的 GDSA中。虽然 Container 中实际数据存放在 2G BAR 上的 GDSA 中，但当需要操作其中数据

时，总是要先移到 2G BAR 以下的 ECDSA 中，操作完成后再移回到 2G BAR 上的

GDSA，因此特别大的 Container 还是会影响到 ECDSA 的使用。

6.交易隔离和 Subspace Group Facility

CICS 采用 Subspace Group Facility 机制来实现交易隔离。所有 EXEC Key=CICS 的任

务都被分配到 Basespace（BS）里运行，拥有“Full Address Space Addressability”；每一

个 EXEC Key=USER 且 ISOLATE=YES 的任务都被分配到一个单独的 Subspace 里运行，

各任务的 Task-Lifetime Storage 相互隔离；所有 EXEC Key=USER 且 ISOLATE=NO 的任

务都被分配到同一个 Common Subspace 里运行。由于每个 Subspace(SS)都有自己的 ASTE（ASN-Second-Table Entry），也意味着每个 Subspace 拥有不同的 ST（Segment Table）和

PT（Page Table），通过 BSG 指令就可以达到相互隔离的目的。


14 14

BSG 指令用来跳转到 Subspace 方式运行，该指令处理过程有点类似 ART（Access-

Register Translation）。最大的不同在于 ALET 0 和 1 的含义，BSG 指令执行时，如果 AR2中是 ALET 0，则表示返回到 Basespace，如果是 ALET 1 则表示跳转到 Dispatchable Unit上一次运行的 Subspace。BSG 指令处理过程比较复杂，下图是 BSG 指令处理过程的一个

简单说明：


15 15

7.CICS Subpool 的管理

CICS 内部用于空间管理的主要 Control Block 见下图。CICS 内部把(E)DSA 分成近

180 个 CICS Subpool，CICS Subpool 的分配单位是 4K。另一方面，根据空间是否自动释

放，又可以分为 Task Subpool 和 Domain Subpool 两类。Task Subpool 中的空间在 Task 终

止时会自动释放，而 Domain Subpool 中空间只能通过“EXEC CICS Freemain”命令显式

释放。例如 Task 通过“EXEC CICS Getmain Shared”命令可以在 Domain Subpool 中申请

空间，Task 终止后该空间不会被自动释放。

每一类(E)DSA 对应有一个 PPA（Page Pool Control Area），当该类(E)DSA 增加一个

Extent 时，就会生成一个 PPX（Page Pool Extent Control Area），PPX 记录 Extent 的起止

地址等信息，而 PAM（Page Allocation Map）则记录了 Extent 中每个 PAGE 分配给了哪个

CICS Subpool。


16 16

每个 CICS Subpool 都有一个对应的 SCA（Subpool Control Area），用来描述 Subpool的特性和跟踪 Subpool 内部空间使用信息。Domain Subpool 的各个 SCAs 地址直接保存在

SMA（Storage Manager Anchor）中。每个 Task 都有一个对应的 SMX（Transaction Storage Area），Task Subpool 的 SCAs 地址保存在 SMX 中。CICS Subpool 内部空间管理有三种方

式：“Chaining”、“No-Chaining”和“Quickcells”。所谓的“Chaining”就是通过

SCEs（Storage Element Descriptor）和 SCFs（Free Storage Descriptor）来跟踪 CICS Subpool 中空间的使用情况。每个 SCE 中含有已使用空间的起始地址和长度，各个 SCEs间由指针组成一个双向链表；每个 SCF 中含有未使用空间的起始地址和长度，各个 SCFs间由指针组成一个双向链表。在 Domain Subpool 中，某些 Subpool 中空间使用后在整个

CICS Region 运行期间不需要释放。因此，CICS 没有必要跟踪 Subpool 中已使用的空间，

例如 CICS CSA 所在的 Subpool。针对这种情况，CICS 会采用“No-Chaining”方式来管理

Subpool 中的空间，只采用 SCFs 跟踪 Subpool 中未使用的空间，不使用 SCEs。Domain Subpool 中另一种空间管理方式是“Quickcells”，每个 PAGE 被分成定长的 Cells，未使用

的 Cell 开始处有一个 QPF，每个 QPF 指向下一个未使用的 Cell，PAGE 的头部有一个

QPH 指向第一个未使用的 Cell。Quickcell 是一种非常高效的空间管理方式，因为它不通

过 SM Domain Call，一般空间分配和释放只需要 6-10 条指令就可以实现。

另外值得一提的是，大部分的 SM Control Block 本身并不在(E)DSA 中分配，例如

SCEs 和 SCFs。

8.虚存和实存使用的监控


17 17

CICS 虚存使用情况可通过 RMF Virtual Storage Activity Report 来监控，但要先设定

RMF Monitor I 中 VSTOR 参数，让系统收集 CICS 地址空间虚存使用的详细信息。CICS实存使用情况可通过 RMF III Storage Frames Report 来监控。另外 CICS 提供的系统交易

STAT 也提供了 CICS 地址空间的虚存使用信息，CICS 终止时作业队列里的 IEF374I 信息

中也会提供 CICS 地址空间的虚存使用数据。CICS Statistics 报告提供了详细的 CICS (E)DSA 的使用信息。如果能取到 CICS 地址空间的 DUMP 数据，则能获得有关 CICS 虚

存、实存及(E)DSA 使用的更详尽信息。


18 18

Workload Simulator 在压力测试中的应用百硕工程师高玉超

一、概述

WSim（Workload Simulator for z/OS and OS/390）是 IBM 开发的用于模拟主机终端和

网络应用的测试工具，可以模拟基于 SNA 的 VTAM 程序(VTAMAPPL)、基于 CPI-C(LU6.2)的交易程序、以及 TCP/IP 的终端(包括 Telnet 3270、3270E、5250、NVT、FTP等)应用。由于这些模拟终端在功能上和实际终端是一致的，同时 WSim 还提供了比较灵

活的测试数据事后分析功能，因此 WSim 可以广泛应用于应用系统的功能测试、回归测试

和压力测试的过程中。

本文以 WSim 模拟 CPI-C 交易程序为例讲述在压力测试过程中使用 WSim 的方法，描

述了通过 WSim 实施压力测试的基本过程，整个测试可划分为四个阶段，包括：测试计划

阶段、测试准备阶段、实际测试阶段和测试结果分析阶段，WSim 的使用会贯穿在后三个

阶段，在本文针对各个阶段都进行相应的描述。文章第七部分是我们在国内某家大型银行

通过 WSim 进行压力测试的一个案例，在此案例中列举了模拟复杂场景时涉及的一些方

法，以供参考。

二、 WSim 工作原理

在使用 WSim 之前，我们首先认识一下 WSim 的核心部分——脚本，WSim 正是通过

运行脚本来模拟网络资源的。其脚本内容分为两部分：

MGD(Message Generation Deck)部分：此部分定义了脚本运行时在网络上发送数

据的数据结构，通过向主机发送这些数据来模拟应用的行为。

网络定义部分：此部分决定了发送哪些数据规则，如单终端顺序发送、多终端并

发发送，以及并发度是多少等。

WSim 的脚本语言 STL（Structured Translator Language）类似 REXX ，用户可以手工

编写 STL 脚本(在模拟 TCP/IP 资源时经常使用)；此外在模拟 VTAMAPPL 和 CPI-C 交易

程序时，WSim 还提供了其它两种方式构建脚本，一种是通过 WSim 的 Utility IDC(Interactive Data Capture)动态的录制某一 SNA 节点的行为，通过录制的数据自动生成

脚本(模拟 VTAMAPPL 时经常使用)，另一种是首先使用 VTAM Buffer Trace 截取流经某

一网络节点的数据，接着通过 WSim 的 Utility 根据 VTAM Buffer Trace 中的数据生成脚

本。这些操作均可使用 WSim 的 ISPF 工具 WTM(WSim Test Manager)进行。


19 19

脚本生成后，WSim 可以根据网络定义以不同方式运行脚本，进而模拟不同的测试场

景。脚本运行完成后，WSim 还可以提供一系列报告，根据这些报告可以对测试的结果进

行评估。WSim 的工作原理示意图如图 1 所示。

Message Generation Decks

TSO / ISPF

Network DefinitionStatements

z/OS

VTAMWSIM

WTMand

WSIM

TCP / IP Application

ApplicationCICS

XXXX XXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXX

---- ------------------------ --------

11 22222 333

111 222222222222 33333

11 22222222 333333

CICS


---- ------------------------ --------

11 22222 333

111 222222222222 33333

11 22222222 333333

CICS


---- ------------------------ --------

11 22222 333

111 222222222222 33333

11 22222222 333333

SimulatedNetwork

Resources

CICS


---- ------------------------ --------

11 22222 333

111 222222222222 33333

11 22222222 333333

Interactive

Data Capture

Application

WSIMCondjhfa lkh lkjhalkjhf lkj hlkjhsdflkjhAljkf;la jds ;lfk j;alk jfAlk jhflkajhflkjhalk fhlak jsdhLk jhadsfkjhalk jfhlakjhflkjhadljkLk jha ldkjfhlakjhdflkjahdlsk fjhlkjhs jkha flLjhalk fhlakhfjkAk lshfjk

As ldk jhlak jhflkjhds ljkAsdlkhlAlj;pajds;a j;lak j;lk jflkja ;lk j;slkdjf;lkjaskjflsk jsole

Display Monitor

Message Generation Decks

TSO / ISPF

Network DefinitionStatements

z/OS

VTAMWSIM

WTMand

WSIM

TCP / IP Application

ApplicationCICS


---- ------------------------ --------

11 22222 333

111 222222222222 33333

11 22222222 333333

CICS


---- ------------------------ --------

11 22222 333

111 222222222222 33333

11 22222222 333333

CICS


---- ------------------------ --------

11 22222 333

111 222222222222 33333

11 22222222 333333

CICS


---- ------------------------ --------

11 22222 333

111 222222222222 33333

11 22222222 333333

CICS


---- ------------------------ --------

11 22222 333

111 222222222222 33333

11 22222222 333333

CICS


---- ------------------------ --------

11 22222 333

111 222222222222 33333

11 22222222 333333

SimulatedNetwork

Resources

CICS


---- ------------------------ --------

11 22222 333

111 222222222222 33333

11 22222222 333333

Interactive

Data Capture

Application





Display Monitor

图 1-WSim 工作原理图

三、测试计划阶段

测试计划的制定一般涵盖如下内容：

1. 确定压力测试要达到的目标

该目标是标识压力测试成功与否的一个标准，它可以通过一些常用的分析指标(如系

统响应时间、交易速率、DASD 使用、CPU%等)来进行量化。

2. 了解所测应用的处理逻辑

了解应用的处理逻辑是产生 WSim 脚本的基础

3. 确定要模拟的网络资源（如终端）

在测试之前需要根据压力测试的内容确定模拟网络资源的类型和数量。

4. 评估压力测试对测试环境需求


20 20

一般来说测试环境包括硬件环境(CPU、DASD、Channel 等)和软件环境(操作系统、

CICS、DB2 等)两部分，需要从这两方面来评估测试环境是否满足需求。

四、测试准备阶段

在使用 WSim 发起压力测试之前需要做一些必要的准备，其内容包括：

1. 搭建测试环境

根据压力测试需求搭建测试的运行环境，主要包括系统环境和应用运行环境(CICS 等)

2. 准备测试数据

测试数据包括应用程序、程序测试数据，以及程序涉及的交易等等。

3. 准备 WSim 的压力测试脚本

鉴于本文的目的是描述如何在压力测试中使用 WSim，因此重点讲述如何准备 WSim的压力测试脚本，这一过程可分为两部分，分别为截取网络数据、生成测试脚本。

4.1 截取网络数据

根据 WSim 工作原理部分，我们知道产生脚本的方式一共有三种，分别为手工编写、

IDC 自动录制和截取 VTAM Buffer Trace。鉴于我们此次模拟的是 CPI-C(LU6.2)交易程

序，因此构建脚本时选用了截取 VTAM Buffer Trace 方式。

该方式首先需要产生 VTAM Buffer Trace。在此测试案例中测试目的是通过 WSim 模

拟某交易的行为，产生 Trace 的步骤可参考如下。

1. 启动 GTF，GTF 的启动参数如下： TRACE=RNIO,USRP

USR=(F6C,FE1,FE2,FE3,FE4,FEF,FF0,FF1,FF2)

2. 在 VTAM Buffer 中收集某一 CICS APPL 节点的数据，参考命令 F VTAM,TRACE,TYPE=BUF,ID=CICSAPPLID,AMOUNT=FULL

3. 在终端执行需要模拟的交易

4. 停止在 VTAM Buffer 收集该节点的数据，参考命令 F VTAM,NOTRACE,TYPE=BUF,ID=CICSAPPLID

5. 停止 GTF P GTF

4.2 生成测试脚本

在生成测试脚本之前，首先要通过 WSim 的主菜单中的“P”(Project)选项产生一个

“项目”，通过“项目”的不同可将测试目的不同的脚本区分开来。


21 21

图 2-WSim Test Manager

项目创建完成后，通过 WSim 主菜单中的“1”(CASE)选项进入产生脚本(Test Case)的界面，接着使用“ADD”命令增加一个新的脚本，在新建脚本的界面中需要指定脚本的

名称和产生脚本所用的数据来源，如下所示：

图 3-脚本创建界面

如上所示，创建脚本的数据来源共有 6 种，前 3 种常用于模拟 VTAMAPPL，其中第

1 种是通过 IDC 动态录制脚本，操作简单方便，使用也是最广泛的；第 4 种和第 5 种是通

过 WSim 提供的模板或已经定义好的架构产生脚本，这种方式需要用户有一定的 STL 基

础，在模拟 TCP/IP 资源时经常使用；第 6 种是通过 VTAM Buffer Trace（LU 6.2 SNA Trace）产生脚本。此次模拟案例中选用了 VTAM Buffer Trace 的方式，然后在 WSim 接下

来的界面中指定 Trace 数据集名称，WSim 会自动创建脚本。

以模拟 CPI-C 交易程序为例，在指定 Trace 数据集名称后，WSim 会自动创建脚本，

如下所示：

↓


22 22

图 4-打开脚本

脚本生成后，通过行命令“O”打开脚本。可以看到，脚本分为了两部分，分别为网

络定义部分（@NET 开始到@ENDNET 结束）和 MGD 部分（以 MGD_name: MSGTXT 开

始到 ENDTXT 结束），MDG_name 是用户为该 MGD 指定的名称。详细如下： @NET

TEST1 NTWRK CONRATE=YES, * Message rates to the console

OPTIONS=(MONCMND), * Monitor operator commands

CPITRACE=VERB, * Trace CPI-C verbs

PATH=(0), * Default path statement

HEAD='CPI-C NETWORK'

* Model network for CPI-C script generation.

* TestMsgtxt MSGTXT1 (TEST1) 　?DO NOT CHANGE THIS COMMENT 　?

CICSCA11 PATH MSGTXT1

* TestMsgtxt SGENTXT (TEST1) 　?DO NOT CHANGE THIS COMMENT 　?

0 PATH SGENTXT

*

CICSCA11 APPCLU

CICSCA11 TP PATH=(CICSCA11 ),TPTYPE=CLIENT,TPNAME=CICSCA11 ,

INSTANCE=(1,1),UCD=YES

*

@ENDNET

.....

MSGTXT1: MSGTXT

conversation_error = on /* Init conversation error switch */

do forever /* Start do forever loop */

/*----- Allocate a conversation with the remote LU/TP -----*/

partner_LU_name = 'CICSCT11'

mode_name = 'CICSISC '

TP_name = 'TSTS'

.....

send_buffer = ,

/* 0000 */ '0D'x 吵'e'吵'02020102000004'x 吵'TSTS'吵'17'x 吵'?吵,

/* 000F */ '0E02000007'x 吵'?吵'002800'x 吵'?吵'010008'x 吵'DFHE'吵,

/* 0020 */ 'CID '吵'000B02'x 吵'TCPMAIN '吵'000504'x 吵''''吵'00'x 吵,

/* 0034 */ ''''吵'0306'x 吵'妷妷?吵'31323620203033323036232323'x 吵,

/* 0049 */ '23232323232323303030303430303030303031232323232323'x 吵,

/* 0062 */ '23232323232323232323232323232323232323232323232323'x 吵,

/* 007B */ '23232323232323232323232323232323232323232323232323'x 吵,

/* 0094 */ '232323232300'x 吵'?吵'000C323731333030323737303232'x 吵,

/* 00A9 */ repeat('00'x,206)吵 repeat(' ',31680)吵'000708'x 吵'TS'吵,

/* 7D3C */ 'TS'

send_length = length(send_buffer)


23 23

CMSEND(conversation_ID,send_buffer,send_length,,

request_to_send_received,return_code)

……

ENDTXT

在以上的 MGD 部分，变量 Send_buffer 的值代表的是 WSim 在网络中发送的数据，

该数据来源于 VTAM Buffer Trace，即从网络截取的发送给 CICSAPPL 的数据，而常量

partner_LU_name 的值代表了发送数据的目标节点，该节点可以是 CICSAPPL 也可以是其

他的 Reomte LU。

五、实际测试阶段

通过准备阶段的工作，我们已经产生了压力测试脚本，本部分将介绍如何运行该脚

本，主要工作包括：

1. 创建运行压力测试脚本的 Schedule

2. 运行压力测试脚本

3. 收集测试数据

5.1 创建 Schedule

WSim 的脚本是通过 Schedule 来运行的，因此在运行脚本之前需要首先创建

Schedule。Schedule 是脚本运行、重新设置网络定义、产生运行报告等多项功能的一个集

合。其创建过程如下。

通过 WSim 主界面中的选项“4”进入 Schedule 界面，通过 ADD 命令增加一个新的

Schedule，在创建的过程中 WSim 会引导用户如何定义网络资源(如终端的数量等)，通过

这些网络资源运行哪些脚本（通过这些终端发送什么数据）。需要注意的是，在这里的网

络资源定义会覆盖脚本中网络资源的定义。创建完成后的界面显示如下：

图 5-创建 Schedule 主界面

通过“W”行命令查看 Schedule 的网络资源定义，具体如下： SCHE01 NTWRK CONRATE=YES, * Message rates to the console

OPTIONS=(MONCMND), * Monitor operator commands

CPITRACE=VERB, * Trace CPI-C verbs

HEAD='CPI-C NETWORK'

*

* Paths


24 24

* TestCase TEST1 　?DO NOT CHANGE THIS COMMENT 　?

1 PATH MSGTXT1，MSGTXT2

* Simulated Resources

WSIM011 APPCLU

LU011 TP PATH=(1),INSTANCE=(2000,100),TPSTIME=1,UCD=YES





……

通过以上示例可以看到网络资源定义主要包括三部分，分别为 NTWRK 参数、Path 定

义以及 Simulated Resources 定义，其中 NTWRK 定义了所有网络资源的属性，Path 定义了

MGD 执行的顺序，Simulated Resources 定义了模拟网络资源（如终端）的数量和通过这些

网络资源运行脚本的方式，下表是该部分的详细介绍：表 1-网络定义参数表

参数名称描述 WSIM011 VTAM 网络节点的名称，如以上示例中在该节点下模拟了五个终端

(LU001) APPCLU 表示模拟的网络资源的类型为 CPI-C(LU6.2)交易程序 LU011-LU012 表示模拟终端的名称 TP 表示模拟的网络资源为 Transaction Program Path=（1）表示在这些终端上以 Path 1 定义的顺序执行脚本，即先执行

MSGTXT1 再 MSGTXT2 INSTANCE=(2000,100) 表示在该终端上重复运行该脚本 2000，并发运行的最大值为 100 TPSTIME=1 表示重复运行脚本时，脚本运行的间隔为 0.01 秒 UCD=YES 表示交易程序以应用数据的形式处理脚本中发送的数据

该表中列出的是一些常用的参数，其他参数可参考《Creating Workload Simulator Scripts》

5.2 运行测试脚本

测试脚本运行的方式有两种，一是通过 WSim 的 ISPF 界面联机运行，二是以批量作

业的方式运行。建议在发起压力较小的情况下，以联机的方式运行脚本；当发起压力比较

大时，WSim 运行脚本会耗费较多的资源，建议以批量的方式运行。

联机运行：

在 Process WSim Schedule 界面中，在脚本对应的 Schedule 前使用行命令“X”联机运

行脚本。


25 25

图 6-运行脚本界面批量运行：

通过批量运行脚本的作业，该作业可以通过 WSim 的 ISPF 菜单自动产生，用户可以

根据需求在其基础上进行客户化，参考如下： //RUNWSIM JOB (ACCOUNT),'WSim',NOTIFY=&SYSUID,REGION=0M

//RUNWSIM EXEC PGM=ITPENTER

//STEPLIB DD DSN=WSIM.SITPLOAD,DISP=SHR

//PARMDD DD *

PRTLNCNT=60

DMAPPL=ITPDM

NCP=5 -写 Log 文件时使用的 Buffer 数量

NTWRKL=SCHE01 -脚本对应的 Schedule

ROUTCDE=(8)

//SYSPRINT DD DSN=HLQ.WSIMRUN.SYSPRINT,DISP=SHR //INITDD DD DSN=HLQ.NTWRKS,DISP=SHR -存放网络定义的数据集

//MSGDD DD DSN=HLQ.MSGTXTS,DISP=SHR -存放 MGD 的数据集

//LOGDD DD DISP=SHR,

// DSN=HLQ.MLOG.SCHE01 -运行脚本时的 Log 文件

/*

5.3 收集测试数据

在运行压力测试脚本的过程中需要收集必要的测试数据，为测试结果的分析做准备。

收集的数据类型是由计划阶段制定的目标来决定的，一般包括系统响应时间、交易速率、

DASD 使用和 CPU%等等。WSim 会将脚本运行的详细信息保存在 Log 文件中，脚本运行

结束后可以通过 Log 文件得到响应时间和交易数量等信息、

六、测试结果分析阶段

脚本运行结束后，需要对压力测试的结果进行分析，评估是否达到了预期的目标。如

果没有，需要进一步分析找出影响测试结果的原因，根据分析结果对应用或系统进行调

整，并进行重新测试评估。重复以上测试过程直到达到预期的目标。

WSim 提供了一系列的报告，在测试结果分析阶段可以参考使用，在这些报告中我们

可以查看系统响应时间、交易数量、交易速率以及响应时间的分布等。下面将介绍如何产

生和分析这些报告。产生报告：

产生 WSim 报告的方式有两种，一种是通过 WSim 的 ISPF 菜单，另一种通过批量作

业。在数据量比较大的情况下建议使用批量方式，以下是一个批量作业的示例。 //ITPRESP JOB (ACCOUNT),'WSIM',NOTIFY=&SYSUID,REGION=0M

//RESPONSE EXEC PGM=ITPRESP,

// PARM=('PRTLNCNT=60',NOLIST,'RESP=50','TRAN=10',

// 'ROUTCDE=(8)')

//STEPLIB DD DSN=WSIM.SITPLOAD,DISP=SHR

//SYSPRINT DD DSN=HLQ.WTM.SYSPRINT,DISP=SHR //SYSIN DD DSN= HLQ.WTMUSER.SKELS(ITMSCRSP),DISP=SHR _- 报表参数文件

//SYSUT1 DD DISP=SHR,

// DSN= HLQ.TLOG.RUNBND1 - 脚本执行的 Log 文件


26 26

以下是所产生报告的部分内容，显示了交易响应时间分布，如响应时间在 0.00-0.10秒之间的交易数量为 5695 笔，0.10-0.20 秒之间的为 4095 笔： RESPONSE TIME COUNT RESPONSE TIME COUNT RESPONSE TIME COUNT

0.00 5,695 0.10 4,095 0.20 173

0.60 1 0.80 4

RESPONSE TIME COUNT RESPONSE TIME COUNT

0.30 22 0.40 10

以下报告示例中，包含了处理交易的数量，每分钟完成的交易数量，可以得到

Transaction Rate 为 84（即 5085/60）。 NUMBER OF RESPONSES 10,000

PER MINUTE 5,085

RESPONSES DISCARDED 0

VARIANCE 0.0033

95 PERCENT CI (0.04,0.04)

分析评估：

压力测试的分析评估部分，需要根据收集的数据（包括 WSim 产生的报告）分析压力

测试结果是否达到了预期的目标。

七、实施案例

以下我们为国内某家大型银行使用 WSim 进行压力测试的一个测试案例，该测试案例

中 WSim 模拟的网络资源类型为 CPI-C(LU6.2)的交易程序，其中涉及的交易有 5 支，模拟

了 4 个测试场景，如表 2 所示：表 2-场景模拟示例

场景名称场景描述测试目的

基准测试模拟在单终端的情况下，每支交易执行

100 次

验证环境、脚本和数据准备

情况，获得单交易的响应时

间单笔交易负载测

试模拟在 200 个终端并发情况下，每支交

易重复运行 10 分钟获得单交易的响应时间、吞

吐量随负载变化的趋势

混合交易负载测

试

分别模拟 100、200、300、400 和 500 个

终端并发情况下，5 支交易按照一定的比

例混合运行 30 分钟

获得组合交易的响应时间、

吞吐量随负载变化的趋势

稳定性测试模拟在 300 个终端并发情况下，5 支交易

按照一定比例混合运行 6 小时

按一定的交易比例，模拟系

统投产后的场景，获得系统

长时间不间断运行在高负载

下的处理能力

我们首先对以上 5 支交易的逻辑进行了分析，然后根据分析结果在 VTAM Trace 生成

脚本的基础上重新构建了脚本，并在脚本中引入了 User Table 以读取外部数据，引入了随

机数实现交易动态输入，定义了全局变量以进行不同交易间的数据访问控制和参数传递

等。

针对不同场景我们还设置了不同的网络定义，在网络定义中终端数量通过“LU###”的数量来控制；混合交易是通过在不同的终端上运行不同的脚本，并为每个终端按比例设


27 27

置不同的 INSTANCE 来实现的。此外我们还调用了 WSim 的时间函数 TOD()对脚本的运

行时间进行统计，以满足场景中对时间的要求。

在测试结果分析阶段，根据 WSim 测试报告、Strobe 报告、CICS PA 报告以及其他联

机监控工具（Mainview for CICS）所收集的数据，我们对测试结果进行了分析，根据分析

结果对应用和系统进行了相应的调整，并重新进行了测试，最终达到了预期的目标。

八、总结

本文主要描述了在压力测试过程中使用 Workload Simulator 的基本方法。在压力测试

的 4 个阶段中，WSim 的使用贯穿了后三个阶段，在这三个阶段中 WSim 分别扮演了创建

测试脚本、运行测试脚本、产生测试报告等不同的角色。本文第七节介绍了我们为国内某

家大型银行通过 WSim 进行压力测试的一个实施案例，其中提及的使用 User Table、全局

变量等方法可以使 WSim 在实际使用过程中更为灵活。

有关 WSim 的参考资料包括：《WSim User Guide》、《WSim Script Guide and Reference》和《Creating WSim Scripts》。


28 28

SYSPLEX 中的

WLM 管理百硕技术顾问邹杰

对 WLM 有一个常见的理解偏差，即尽可能不要定义超过 30 个 Service Class。这种理

解是片面的。正确的建议是：在指定的时间段内，在 SYSPLEX 中的任何一个系统上，尽

可能定义少于 30 个 Active 的 Service Class 的 Period。

这个建议的关键点包括：

Period：我们应该关注的是 Period 数量，因为 Period 才是需要进行管理的目标。如

果在一个 Service Class 没有定义 Period，系统默认为一个 Period。

Active：我们不需要考虑没有任何活动的 Period，因为它们不会被 WLM 选择进行

管理，并且也不会有可贡献给其他任务的资源。

SYSPLEX 中的任何系统：如果 Workload A 在 SYS1 系统上运行在某个 Service Class 中，但并不运行在 SYS2 上，则这个 Service Class 不能被计算到 SYS2 的活动

Period 数量中去。

指定的时间段：如果一套 Workload 在白天是活动的，而夜晚使用另外一套

Workload 定义，那么这两套应该分别计算 Period 的数量。

基本上来说，该 WLM 管理的建议对于减少 WLM 的开销并无大的好处，更多的是好

处是提高 WLM 的反应能力。如果在一个 z/OS 系统上存在过多 Active 的 Period，WLM 的

反应能力会降低，因为在每个系统上，WLM 每 10 秒最多仅能为一个 Period 提供帮助。如

果更多的 Period 需要被管理，则 WLM 需要更多的 10 秒一个的 Interval，才能对所有的

Period 进行管理。

在很多系统中，技术人员尽很大的努力来保证仅定义最少数量的 Service Class Period。对于那些运行在各系统的 Workload 比较类似的 SYSPLEX，这种措施是可行的。

但是，对于那些特别大的 SYSPLEX 系统，如果它们由处理能力区别很大，而且运行着不

同 Workload 的系统来说，这就不是最佳选择了。因为在 WLM 的 SYSPLEX 管理中，有时

候定义更多的 Period 是需要的，这样，部分系统就可以有唯一的一套 Service Class，以满

足针对处理能力的优化和特定的需求。

SYSPLEX 中的 WLM 管理


29 29

作为 z/OS 的 WLM 管理员都知道，WLM 中单个的 ServiceClass 定义是 SYSPLEX 级

别的。这意味着完全相同的 Classification Rule、 Service Class、Duration、Goal 和

Importance Level 将被用于管理 SYSPLEX 中每个系统的所有 Workload。

WLM 的 SYSPLEX 管理，是指 WLM 依据整个 SYSPLEX 中各个系统共享的 Service Class 定义，按照统一的性能目标，管理在整个 SYSPLEX 中的工作负荷。WLM 的

SYSPLEX 管理主要需注意以下两个方面：

1，WLM 在整个 SYSPLEX 中选择需要管理的系统资源和工作负荷，以使这些工作负

荷达到 SYSPLEX 级别的性能目标。WLM 的关键目标是帮助工作达到预定的目标，无论

它们运行在哪个系统上。出于目标管理的原因，WLM 总是试图从 SYSPLEX 的角度来满

足工作负荷的目标。

2，WLM 选择 SYSPLEX 中需要优化的系统资源。如果达到了性能目标，WLM 将会

在 SYSPLEX 级别来对资源进行优化。这就是 WLM 工作负荷的均衡功能。

WLM 性能管理的设计

要理解 SYSPLEX 中 WLM 性能目标管理的概念，首先了解一些 Parallel SYSPLEX 最

初始的设计思想将会有一定的帮助作用。

Parallel SYSPLEX 的设计初衷是为了让系统程序员和性能分析员把多个系统组合为一

个整体来看待和管理。原理上讲，既然这些系统基本上都是相同的，那么就没有必要关心

一个工作负荷会运行在 SYSPLEX 中的哪个系统上了，因为交易都应该能够达到预想的性

能目标。

那么，从 WLM 设计的角度来看，就有必要考虑尽可能减少管理员针对各单个 MVS系统进行的微观管理。这里的假设条件是 SYSPLEX 中的所有系统都基本相同，并且所有

的工作负荷都可以也应该运行于任何一个系统上。

WLM 的设计原则就是允许在 SYSPLEX 级别设置性能目标，随后调配系统资源来满

足这个目标。从优先级别的角度来看，WLM 的算法首先是要满足 SYSPLEX 级别的性能

目标，之后才是满足各单个系统级别的性能目标。换句话讲，如果有交易在单个系统上的

性能比较差，而在 SYSPLEX 级别上，运行于各个系统上的所有交易的综合性能能够达到

预定的性能目标，那么这个系统上的 WLM 不会立即为这些交易提供帮助。也可以说，单

个系统的 Service Class 的 Period 的性能目标的确会被 WLM 顾及，但只是在从 SYSPLEX角度考虑之后。

WLM 和不同特性的 SYSPLEX

我们今天的 SYSPLEX 已经与当初 WLM 的设计初衷大不相同了，因为现在有很多的

SYSPLEX 都是由不同处理能力、不同工作负荷的多个系统组成的。当前很多 SYSPLEX


30 30

中各系统的处理能力和工作负荷的差别非常大，而 WLM 对于运行于 SYSPLEX 中

Workload 性能目标的管理算法基本没有大的变化。

因此 WLM 管理员应该特别关注以下几个方面：

当工作负荷运行于不对称的 SYSPLEX（SYSPLEX 中的各系统处理能力不对称）中

多个系统上的同一个 Service Class 时，有可能在某些系统上一个 Service Class 的

Period 的性能目标很容易就达到了，而在 SYSPLEX 中的其它系统上却不能达到。

在这种情况下，WLM 有可能会延迟对性能较差的工作负荷提供帮助，因为从

SYSPLEX 的整体平均来看，这个工作负荷达到了 Service Class Period 预定的性能

目标。所以，当对于运行在不对称 SYSPLEX 中多个系统上的工作负荷设置性能目

标时，需要事先考虑此种情况。当 Service Class 的性能目标在一个处理能力较小的

系统上很难达到，而在一个处理能力相对较强的系统上轻易就能达到时，最好能够

把这样的工作负荷分到两个不同的 Service Class 中去，并且为它们按照各自的系统

设置不同的、最佳的性能目标。

当一个工作负荷运行在 SYSPLEX 中的多个系统上，但它的重要程度与其他的工作

负荷因在不同的系统可能存在差别。例如，生产系统的 DDF 交易可能运行在多个

系统上，但是在一些系统上这些交易的重要程度比 CICS 高，而在另外一些系统上

它的重要程度比 CICS 低。这样，在对在 SYSPLEX 不同系统上重要程度不相同的

工作负荷进行性能目标定义的时候，就需要在这方面有所考虑。这种情况下，为不

同系统定义各自唯一的 Service Class 可能会更好一些。因为，当 WLM 使用重要程

度来选择一个需要提供帮助的 Period 时，基于不同系统定义的不同的重要程度会比

较合适。

如果一个 SYSPLEX 中的系统运行着不同类型的工作负荷，例如多个系统运行生产

的 CICS 交易，但在不同系统之间的 CICS 工作负荷完全不同。这些不同的工作负

荷可能需要不同的 Service Class 来定义不同的性能目标和不同的重要程度。这种情

况适用于那些正在进行 SYSPLEX 整合的数据中心或者为不同客户提供 SYSPLEX服务的外包中心。在这种情况下，基本上一定需要为各种不同的工作负荷定义不同

的 Service Class。

如果各系统运行完全互斥的工作负荷，例如 WebSphere 交易可能仅运行在

SYSPLEX 中的一部分系统而不是所有的系统。因为在同一个 Service Class 中最好

不要混杂不同特性的交易，所以最好为不同类型的工作负荷单独定义各自的

Service Class。在不运行 WebSphere 的系统上，WebSphere 的 Service Class 则显示

为 Inactive，它的所有统计数据将为 0。在 WLM 进行管理时，这种 Inactive 的

Period 对于当前系统上活动的 Period 的目标管理不会有影响。所以，对于这种仅运

行于 SYSPLEX 中部分系统上的工作负荷定义单独的 Service Class 也是不错的选


31 31

择。

WLM 如何在 SYSPLEX 中进行目标管理

WLM 在 SYSPLEX 中管理性能目标的方法并不复杂。在 SYSPLEX 中的任意一个系

统上，当工作负荷被分类之后，它会被赋予两个性能目标。这两个性能目标的指标是相同

的，但它们的范围是不同的。第一个性能目标是在 SYSPLEX 级别上的，即该工作负荷在

SYSPLEX 所有系统总体上需要达到的目标，称为“SYSPLEX Goal”。第二个性能目标是

工作负荷在各个单独系统上需要达到的性能目标，成为“Local Goal”。事实上，每个系

统上的 WLM 都会计算和评估这两个 Performance Index（PI）。“SYSPLEX PI”是衡量性

能目标在 SYSPLEX 级别达到的程度，“Local PI”用来衡量在各个系统上性能目标的达

到程度。

SYSPLEX 中的每个 z/OS 系统都有自己独立的 WLM 来管理系统的工作负荷，以使它

们在系统级别达到性能目标。不同系统间的 WLM 没有主/从关系，也不存在 SYSPLEX WLM。各个系统上的 WLM 都是独立的，一个系统上 WLM 不会要求另外一个系统上的

WLM 去做任何事。

在每一个 Importance Level，WLM 总是会根据 SYSPLEX Goal 达到的情况去试图帮助

某一工作负荷，之后才会根据 Local Goal 的达到情况去提供帮助。

在这种设计下，如果 SYSPLEX Goal 不能达到，并且一个系统上的 WLM 检测到

Local Goal 没有达到，那么这个系统上的 WLM 将会为相应的工作负荷提供帮助，使

Service Class 的 Period 达到 SYSPLEX Goal。WLM 也可能会根据 Local Goal 的达到情况对

工作负荷提供帮助，但这仅会发生在 WLM 试图达到 SYSPLEX Goal 之后。

如果一个 Service Class 在某个系统上没有任何活动，那么 WLM 不会去管理它的

Period。因此，这个 Service Class 的 Period 也就不会被计算在所谓的“30 个 Period”之

内。

WLM 的管理员需要为运行于 SYSPLEX 中的各种工作负荷定义 Service 来包含最佳的

Service Class、Goal、Importance Level 等等设置，SYSPLEX 可能由处理能力不对称的系统

组成，而工作负荷的性能在不同系统之间也可能存在很大差别。进行定义时，必须考虑有

些工作负荷与某些系统之间的互斥，以及在不同系统间存在不同的工作负荷。

进行定义时，还需要考虑必须确保 WLM 的正确响应和对性能目标管理的优化。

对 SYSPLEX 环境下 WLM 的调整，通常需要把不同的工作负荷或受到不对称的处理

能力系统影响的工作负荷，分别定义到不同的 Service Class 中去。当然，也需要避免过度

细分 Service Class，仅在需要的情况下才这样定义。

监控的考虑


32 32

很多 z/OS 的系统管理员会把 SYSPLEX 中各系统的监控数据综合到一起，以从

SYSPLEX 的角度来监控性能。大多数 WLM 相关的性能衡量指标，如果被综合到一起来

从 SYSPLEX 角度观察，有可能因 SYSPLEX 中各系统处理能力的不同而失去意义。一个

例外是 SYSPLEX PI，也包括相应各系统的 Local PI。

有些系统管理员会在一个报告中同时包括 Local 系统和 SYSPLEX 级别的数据，如：

响应时间统计

Using 和 Delay 统计

各系统的 Local PI 和 SYSPLEX PI

当 WLM 对 Local 级别和 SYSPLEX 级别的数据进行监控时，它会每 10 秒钟进行一次

检查。但大多数的性能监控报告不会达到这么细致的监控，因为通常它们的数据是使用更

长时间的 Interval 来进行汇总的，如 SMF 通常使用 15 分钟作为 Interval。

建议

因为越来越多不同的系统（运行着不同的工作负荷）被合并到越来越少的 SYSPLEX中，就很有必要理解如果设置不正确，WLM 的 SYSPLEX 管理可能导致难以预知的 WLM决策。

以下为一些在 SYSPLEX 环境下进行 WLM 管理相关的参考建议：

最需要的工作是检查可能受到不对称处理能力或不同工作负荷影响的 Service Class的 Period，以确定是否存在潜在的问题。然后通过对系统和工作负荷进行监控，以

确定问题是否发生。

如果一个系统上的工作负荷的性能与其它系统明显不同，就不要把不同系统上的工

作负荷强行合并到同一个 Service Class 中，这通常发生在相同的工作负荷运行于多

个系统，但各系统的 LPAR 处理能力却明显不同的情况。

WLM 分类规则中一个很有用的 Qualifier 类型是 SY。使用这种类型，WLM 管理员

可以根据工作负荷启动在哪个系统上来进行分类。但这种类型方式不适用于分类规

则为 JES（即批量作业）的工作负荷。

不要把不相似的工作负荷合并到同一个 Service Class 中，即使这些不相似的工作负

荷分别运行在不同的系统上。

既要从 Local 级别，也要从 SYSPLEX 级别监控 PI 和性能达到情况。如果

SYSPLEX PI 显示工作负荷在 SYSPLEX 级别达到了性能目标，但在某个单个系统

上的 Local PI 有规律的呈现出不能达到性能目标的情况，就需要特别关注了。如果

这种情况有规律可循，需要进一步检查 Local PI 指标较高的 Service Class 是否因为


33 33

SYSPLEX PI 值较低而没有得到 WLM 的帮助。

检查所有系统上活动的 Period 的数量。可能在 WLM 的 Policy 中定义了较多的

Period，但需要确保在任何系统上活动的 Period 数量少于 20 至 30 个。如果报告中

显示消耗了 CPU 或存在完成的交易数量，则表示此 Period 为活动的。

需要的情况下，按照系统对工作负荷进行分类。通常，除了 JES 类型的分类规则

外，都可以使用 SY 作为分类类型，通过设置分类规则，标识出某种工作负荷应运

行在哪个系统上。例如，使用 SY 作为分类类型，如果某种工作负荷运行在系统

SYSA 上，可设置其 Service Class 为 ABC；如其运行在系统 SYSB 上，可以设置其

Service Class 为 XYZ。

不必担心把不同系统上运行的工作负荷分类到不同的 Service Class 而造成 Service Class 数量的增加。因为在任何给定的系统上，没有活动的 Period 是不会被 WLM管理的，而定义这样的 Period 开销很低。

为相同的性能目标和重要级别定义多个 Service Class 也是可行的。只需要记住，重

要的是各个系统上的任意时间点，有多少活动的 Period。

在考虑不要超过 20－30 个活动 Period 时，不要把以下类型的 Period 计算在内：－SYSTEM 和 SYSSTC：因为所有系统都必须定义它们－Discretionary 类型而没有对应 Resource Group 的 Period：因为各系统上所有次类

型的工作负荷会被一起管理，而不论有多少个 Period。例如，如果 5 个 Service Class 都定义了一个 Discretionary 的 Period 而且没有相应的 Resource Group，那

么 WLM 会把这 5 个 Discretionary 的 Period 作为一个来进行管理。－通常情况为空而只为出现问题情况下才特别定义的 Period，如 KILLIT 和

SWAPOUT －通常情况为空而只为偶尔进行加速处理的 Period，如 HOTBATCH 和 HOTTSO

在把不同系统上运行的工作负荷定义到各系统不同的 Period 时，如果达到了 100 个

Service Class 的限制，这时，更需要关注的是那些 Importance Level 为 1 和 2 的 Period，应

先按照需要把这些 Period 按系统分到不同的 Service Class，而对于 Importance Level 为 4和 5 的则不必都按此划分。


34 34

是谁导致 FTP 传输

中文出错百硕技术顾问徐卫华

在日常工作中，常常需要将主机的文本文件传输到本地（Windows 系统或 Unix 系

统）。在某些情况下，需要传输的文本文件中包含有中文字符。使用 FTP 是最常见的文件

传输方式，通常会事先使用下述两个 FTP 命令中的一个，来设置汉字转码表：

使用字库 BG2312：

QUOTE SITE TYPE B 9

使用字库 GB18030：

QUOTE SITE ENCONDING=MBCS

QUOTE SITE MBCSDATACONN=(IBM-1388,IBM-5488)

这些 FTP 命令的使用不是本章内容的重点，可以参考《百硕客户通讯》总第 9 期

（2007 年 9 月 1 日）“主机汉字转码”部分获取详尽内容。

如果传输的中文文本中有非法字符，将导致传输失败。本文将探讨如何找出导致 FTP传输失败的非法字符。

1. FTP 场景

我们首先设置 FTP 场景，模拟在 FTP 传输中文的过程中，由于文本中包含有非法字

符，导致 FTP 传输失败。

在主机文件 TMPUSR6.BBIIMAGL 中，为了便于比较，我们输入两行内容相同的文

本，如下图所示（以 HEX ON 方式显示）：

这两行文本完全相同，每行都包含了五个汉字“在此基础上”及其它文本字符。我们

对第一行文本进行修改，将第四个汉字“础”（HEX 为‘4AA0’）改成一个非汉字字符

（HEX 为‘0AA0’），可以通过 HEX 方式来看到明显的改变，如下图所示：


35 35

使用如下 FTP 命令进行传输：

quote site encoding=mbcs

quote site mbdataconn=(ibm-1388,ibm-5488)

get BBIIMAGL

由于我们已经将合法字符“础”修改为非法中文字符，所以导致 FTP 失败，下面是

FTP 客户端软件的输出信息： quote site encoding=mbcs

200 SITE command was accepted

quote site mbdataconn=(ibm-1388,ibm-5488)

200 SITE command was accepted

GET BBIIMAGL

200 Port request OK.

125 Sending data set TMPUSR6.BBIIMAGL

451 File transfer failed. Multi-byte data conversion error occurred

FTP 传输文件失败，返回码是 451。失败的原因是 FTP 调用 iconv()进行转码时出现错

误。

2. 收集 FTP Trace 信息

2.1 设置 FTP 参数

为了查找 iconv()出错时处理的数据，我们需要修改 FTP 的参数，以收集相关的 Trace信息。在 SD.LOG 中输入以下命令： /F FTPD，DUMP=(42)

/F FTPD，DEBUG=(FSC)

设置完以上命令后，FTP 会自动记录 Trace。

2.2 重新执行 FTP

完成以上设置后，重新执行 FTP 命令，重现上述错误信息“451”，这样 FTP 会收集

相关的 Trace 数据。

2.3 查找 FTP Trace 数据


36 36

一般情况下，通过 SD.DA 可以看到系统中运行一个名为 SYSLOGDn（SYSLOG Daemon）的 Address Space。

1、如果 SYSLOG Daemon 是通过 Start Task 启动的，如下所示： //*CONFHFS EXEC PGM=SYSLOGD,REGION=4096K,TIME=NOLIMIT,PARM='/-c -i'

//CONFPDS EXEC PGM=SYSLOGD,REGION=4096K,TIME=NOLIMIT,

// PARM='/-c -i -f //''SYS1.&SYSPLEX..TCPPARMS(SYSLOG)'''

//SYSPRINT DD SYSOUT=*

//SYSIN DD DUMMY

//SYSERR DD SYSOUT=*

//SYSOUT DD SYSOUT=*

//CEEDUMP DD SYSOUT=*

那么在‘SYS1.&SYSPLEX..TCPPARMS(SYSLOG)’中指定了 LOG 的存放位置，如

下所示： # any host with IP address in the range 192.168.0.0 to 192.168.0.255

# to the operlog log stream.

#

# (192.168.0.6/24).*.crit /dev/operlog

#

#####################################################################

#

# Write all messages with priority err and higher to log file errors.

#

# THIS EXAMPLE STATEMENT IS UNCOMMENTED.

#

*.err /var/log/%Y/%m/%d/errors

#

*.ftpd*.*.* /tmp/ftp.log

*.TRMD*.local4.* /tmp/trmd.log

local4.* /tmp/ipsec.log

*.*;local4.none /tmp/syslog.log

从上面的配置文件，可以看到 FTP 的 Trace 数据存放在/tmp/syslog.log 中。我们通过

查看文件/tmp/syslog.log 找到出错的数据。

2、如果 SYSLOG Daemon 是通过/etc/rc 启动的，如下所示： BROWSE /etc/rc

Command ===>

#-----------------------------------------------------

# Start automount daemon

/usr/sbin/automount &

# Start syslog daemon

_BPX_JOBNAME='SYSLOGD' /usr/sbin/syslogd &

# Start inet daemon

_BPX_JOBNAME='INETD' /usr/sbin/inetd /etc/inetd.conf &


37 37

在这种情况下， SYSLOGD 使用缺省的配置文件：这个配置文件存放在：

/etc/syslog.conf 中： #**********************************************************************

#* This file contains sample code. IBM PROVIDES THIS CODE ON AN *

#* 'AS IS' BASIS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS *

#* OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES *

#* OF MERCHANT ABILITY OR FITNESS FOR A PARTICULAR PURPOSE. *

#**********************************************************************

#**********************************************************************

#* *

#* If this file is edited, the following rules must be followed: *

#* *

#* a) The file must be edited and saved using an IBM-1047 code *

#* page *

#* *

#* -OR- *

#* *

#* b) The rules for editing a file in another code page (other *

#* than IBM-1047) must be followed. Please refer to the rules *

#* for performing the required actions in the IBM OS/390 Firewall *

#* documentation. *

#* *

#**********************************************************************

*.* /dev/console

如上所示，所有的 Trace 信息将会写到系统/ dev/console 中。进而调用 WTO 函数将

Trace 信息写入到系统 Console 中（Console 上会显示 BPXF024I 信息），可以通过

SD.LOG 查看 FTP 的 Trace 信息。

3、如果 SYSLOG Daemon 没有启动，那么 FTP 的 Trace 信息直接写入到系统 LOG中。

4、如果 SYSLOG Daemon 中指定的配置文件中没有指定 SYSLOGD log 的存放位置，

那么 FTP Trace 存放的位置为：‘/var/log/%Y/%m/%d/syslogd’。

通过以上方法，在找到 FTP Trace 数据后，我们就可以分析数据，查找导致 FTP 出错

的非法字符。

3. 查找非法字符

下面数据摘自 FTP 记录的 Trace 数据： BPXF024I (TMPUSR6) Aug 20 09:47:59 ftps　66038　: RR2438 mvs_retrieve: 806

use multi-byte processing for multi-byte encoded ASCII data

BPXF024I (TMPUSR6) Aug 20 09:47:59 ftps　66038　: NC0313 convertMB: 817

iconv() rc was -1 - EDC5147I Illegal byte sequence. (errno2=0x00000000)

BPXF024I (TMPUSR6) Aug 20 09:47:59 ftps　66038　: NC0316 convertMB: ip 818

2C813 isz 38 op 16012 osz 92126


38 38

BPXF024I (TMPUSR6) Aug 20 09:47:59 ftps　66038　: C)0344 convertMB: 819

iconv() failed on converting 57 bytes at 2C800, rc = -1, 38 bytes

left - EDC8106I Destination address required. (errno2=0x12140272)

BPXF024I (TMPUSR6) Aug 20 09:47:59 ftps　66038　: NC0352 (00) iconv 820

inbuf

BPXF024I (TMPUSR6) Aug 20 09:47:59 ftps　66038　: 0002C800 C1C1C1C1 821

C1C1C1C1 C1C1C1C1 0E5AD94A *AAAAAAAAAAAA.!R.*

BPXF024I (TMPUSR6) Aug 20 09:47:59 ftps　66038　: 0002C810 CA4E9A0A 822

A0556F0F 5AC4C4C4 C4C4C4C4 *.+....?.!DDDDDDD*


C4C4C4C4 C4C4C4C4 C4C4C4C4 *DDDDDDDDDDDDDDDD*


C4C4C4C4 15 *DDDDDDDD. *

BPXF024I (TMPUSR6) Aug 20 09:47:59 ftps　66038　: TO5737 readMB: 825

conversion error

BPXF024I (TMPUSR6) Aug 20 09:47:59 ftps　66038　: RR1395 retrieve: 831

0 bytes transferred

从上面数据可以看到，函数 iconv()共转换 57 个字节失败，其中还有 38 个字节没有转

换成功，即成功转换了 57-38=19 个字节，也就是说，第 20 个字节出现错误，导致 FTP 失

败。

下面是第一行数据的 EBCDIC 与 HEX 码： 123456789012345678901234567890 AAAAAAAAAAAA.!R£A + . ?.!DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD　　　　 CCCCCCCCCCCC05D4C490A5605CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC 111111111111EA9AAEAA05FFA4444444444444444444444444444444

从上面数据可以看到，第 20、 21 个字节为‘0AA0’，它不是一个合法的汉字编码。

至此，我们成功地找到导致本次 FTP 失败的非法字符。

本文总结了通过 FTP Trace 查找非法中文字符的方法，解决 FTP 传输失败的问题，也

初步介绍了与 FTP 相关的 Unix 的配置，希望可以引到抛砖引玉的作用，对我们的日常维

护工作有所帮助。


39 39

RACF 相关的问题

百硕外籍技术专家 Mohd Shahrifuddin

问题 1：What’s RACF Profiles?

解答：

The rule that protects a resource (dataset or general) is called a profile. A resource (dataset or general resource) can be protected by more than one profile although only one will ever apply to a user at any given time.

Profiles can be grouped together. This allows a user access to all the resources in a group by giving the user access to the group. This obviously simplifies the rules required to administer RACF and improves the performance of the system as well.

Profiles can be generic or specific. Generic profiles allow RACF to protect multiple resources within a class with a single profile. Specific profiles protect only a specific resource within a class. However, we cannot define generic profiles in groups.

问题 2：How User-ids been defined to RACF?

解答：

Users are defined to RACF with a user-id and usually a password. A user-id can represent a real user or a batch job or started task within the system.

User-ids are associated with a default group (of users not resources) when they are defined. Whenever a user-id signs on to RACF, it is connected to this default group.

The user-id can be given access to a resource or the group can be given access, in which case all user-ids within the group will have access to that resource.

A user-id can also be CONNECTed to other groups of users as well as the default group. The user-id will then have access to the resources allowed for those groups as well as its default group.

问题 3：What meaning RACF authorities?

解答：

RACF uses a hierarchy of authorities, ie if we have a particular level of authority to access a resource we automatically have all those below it. In descending order, this hierarchy is :

ALTER - the user-id can delete and define the protected resource.

CONTROL - this applies to VSAM datasets. The user-id can access the protected dataset(s) using control interval access.

UPDATE - the user-id can read and update the resource.


40 40

READ - the user-id has read access to the resource.

EXECUTE - the user-id can execute programs from a load library but cannot read the library (for example with IEBCOPY).

NONE - the user-id has no access to a resource if the user-id's authority is NONE.

Note that the actual implementation of this hierarchy is dependent upon the application using RACF. RACF simply returns the permitted authority to the application. It is up to the application to interpret this and apply it accordingly.

问题 4：What's RACF SETROPTS?

解答：

SETROPTS is a TSO command that controls the operation of RACF at a system-wide level. For example, it defines the active RACF classes, user-id password syntax, etc.

Example: Activating the CICS RACF classes

Before we can use RACF security with CICS we must enable the RACF classes used by CICS. We only need to do this for one class as all the other classes will be enabled at the same time. This is because they all have the same POSIT value within the RACF class descriptor table. The POSIT value is used by RACF to tie together different classes and has no effect on the use of RACF by CICS as it is purely a RACF operand. The RACF class descriptor table defines the characteristics of the resource classes in RACF, such as maximum name length and type of class entries, group or discrete, etc.

To activate all the CICS RACF classes use the command:

SETROPTS CLASSACT(classname)

where classname can be any valid CICS RACF class name such as GCICSTRN. This will enable all the standard IBM-supplied RACF classes defined for CICS.

In order to define generic profiles to RACF in the CICS RACF classes we need to enable the class for GENERIC profiles using the command:

SETROPTS GENERIC(classname)

where classname is the required CICS RACF class name such as TCICSTRN. We can only activate generic profiles for the discrete classes such as TCICSTRN, ACICSPCT, etc.

问题 5：What's RACLIST?

解答：

RACLIST is a RACF function whereby RACF loads the requested profile classes into storage. RACF can then use these in-storage profiles to search for authorities rather than accessing its database and suffering the resultant I/O waits


41 41

We can use the SETROPTS command to cause RACF to load profiles in certain RACF classes into storage in order to improve the performance of RACF.

We can use this facility to cause RACF to load other class profiles into storage such as those used with a QUERY SECURITY command in CICS. This would avoid the I/O associated with a RACF request if RACF had to access the RACF database for the profiles.

To activate the in-storage profiles for a class and cause RACF to load the profiles for the first time, use the command:

SETROPTS RACLIST(classname)

where classname is the name of the class whose profiles we want RACF to load into storage.

Any changes made to profiles in a RACLISTed class are not reflected in the in-storage profiles, and therefore not seen by any user of that class, until the profiles are refreshed using the command:

SETROPTS RACLIST(classname) REFRESH

问题 6：How's RACF protecting dataset profiles?

解答：

We create the RACF profiles used to protect datasets using the TSO ADDSD command. In addition, RACF can also automatically protect datasets when they are defined.

The format of the ADDSD command is:

ADDSD 'dsname' UACC (universal access)

'dsname' can be either a specific name such as

CICS.CICSP01.DFHTEMP or a generic name such as

CICS.CICSP01.* or CICS.CICSP01.**.

RACF will check that the high-level qualifier used for the profile is defined to RACF as a user-id or group name. If it is not so defined then RACF will not allow we to create the profile.

UACC (universal access) is the default minimum level of access that we want any dataset protected by this profile to have. For example, if we do not want anyone, other than specifically authorized users, to have access to the protected datasets then specify UACC (NONE).

Remember that the 'best fit' rule applies and that there may be more than one profile for any resource, although there cannot be two the same - they must be different, even if by only one character. Consider the following:

ADDSD 'CICS.*' UACC(READ)

ADDSD 'CICS.DFHTEMP' UACC(NONE)


42 42

anyone can read all the CICS datasets, except CICS.DFHTEMP, for which the default access is none.

问题 7：How's to granting access to dataset profiles?

解答：

To grant a user-id access to a dataset, or any other resource for that matter, we must use the TSO PERMIT command to grant the required level of access to the profile that protects the dataset or resource.

For datasets the format of the PERMIT command is:

PERMIT 'profile' ID(name) ACCESS(access)

'profile' is the name of the profile defined to RACF. For specific profiles this will be the same as the dataset name. For generic profiles it will be the generic profile name. For generic profiles we are giving the specified access to all the datasets protected by the profile.

ID (name) is the name of the user-id or group being given the required access. In the case of a group, all user-ids with either that group as their default group or CONNECTed to the group will be given this level of access.

ACCESS (access) is the level of access being granted to the named user-id or group for the dataset or datasets protected by the named profile.

问题 8：How's to removing access to dataset profiles?

解答：

To remove a user-id's or group's authority to access the datasets protected by a profile, we use the PERMIT command but specify DELETE instead of ACCESS (access). This deletes the named id from the list of authorized users for the profile.

For example:

PERMIT 'CICS.*' ID(SYSADMIN) DELETE

would delete the id (group or user-id) SYSADMIN from the list of authorized users for the profile CICS.*.


43 43

百硕客户通讯 BAYSHORE ADVISOR 中国主机用户专享的资讯季刊

2009 年 9 月 1 日出版（总第 17 期）

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

出版：百硕客户通讯编委会吕宁李琰马彤雷王晓兵刘京平吴笳笳张凤华陈银波陈建邹杰罗文军贺明徐卫华高春霞高大川高玉超郑霞康会影

Darryn Salt Martha Hall

地址：北京市朝阳区望京科技园利泽中二路 1 号中辰大厦 209 室电话：010 64391733 传真：010 64391582 电子邮箱：[email protected]

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


44 44

百硕客户通讯总第 17 期（2009 年 9 月 1 日）百硕同兴科技（北京）有限公司 Bayshore Consulting and Service Co., LTD.

百硕客户通讯，总第 17 期（2009 年9 月1 · 百硕客户通讯，总第17 期（2009...

Documents

Transcript of 百硕客户通讯，总第 17 期（2009 年9 月1 · 百硕客户通讯，总第17 期（2009...