Embed Size (px)
Citation preview
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
2
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
3
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
4
IBM 推出新机型 “Z9 Business Class Model”
日前，IBM 在 z9-EC 基础上最新推出了一系列新
机型。这些机型主要面向小规模的企业用户，处理能力
较小，被称为 z9 Business Class 或 z9 BC。其中最
小的型号为 27MIPS，在美国的售价为 10 万美元。
z9 BC 的机型类别是“2096”，机器型号由机器
类型和表示 CPU 数量的指数组成。目前有两种基本型
号，即 R07 和 S07。R07 最多支持 3 个 CPU，容量在
27 到 171MIPS 之间。S07 最多支持 4 个 CPU，容量
在 28 到 1787MIPS 之间。
这些机型通常只能支持 3 个到 4 个可运行 z/OS 的
常规 CPU，但如果安装了专门的 CPU，CPU 总数可达
到 7 个。这些专门 CPU 的价格在美国已经降到了 9.5万美元，包括：
zAAP - System z9 Application Assist Processor
zIIP - System z9 Integrated Information Processor
IFL - Integrated Facility for Linux ICF - Internal Coupling Facility
zAAP 是 IBM 为 z9 推出的第一款专门 CPU，用来
承担常规 CPU 上运行的 JAVA 工作。
zIIP （ z9 Integrated Information Processor ）是 IBM 最新推出的专门 CPU，主要有以
下特点：
用户不必对在 zIIP 中运行的软件付费，同时可
以延缓常规 CPU 的升级，减少软件投入 安装在系统上的 zIIP 的数量不能超过该系统上
常规 CPU 的数量 可以使用 RMF 对 zIIP 进行监控 在美国，zIIP 对 z9-BC 用户的价格是 9.5 万
美元，对 z9-EC 用户的价格是 12.5 万美元
第一个使用 zIIP 的是 DB2 V8，有以下三种 DB2工作可以转移到 zIIP 中运行：
BI、ERP 或 CRM 使用 TCP/IP 之上的 DRDA协议通过 SQL 语句访问主机 DB2
需要使用 DB2 Star Schema Parallel Query的 BI 应用
部分指定的 DB2 Utility 功能，例如 Load、Reorg 和 Rebuild Index 等
理论上，安装专门 CPU 不需要对 DB2 进行任何修
改。DB2 Stored Procedure 和用户定义的功能(User Defined Functions)不能在 zIIP 中运行。
根据 IBM 的估计，运行在 zIIP 上的大部分工作都
会使用 DRDA 的方式。用户可以执行以下步骤，以确定
有多少工作适合在 zIIP 中运行：
在 WLM Policy 中 为 SUBSYSTEM TYPE=DDF 定义一个或多个 Service Class
收集 SMF Record Type 70 和 72 记录，用
于 RMF 报告 针对高峰时段（约 12 小时的轮班时段内）运
行 RMF Workload Activity report (SYSRPTS)，显示 DB2 DDF 工作相关的
Service Class 针对 DB2 DDF 的 Service Class 报告中，40
％左右的“APPL%CP”工作量可转移到 zIIP中运行
以下是 zIIP 对软硬件的要求：
z/OS V1.6 or z/OS.e V1.6 or later DB2 for z/OS Version System z9-BC or z9-EC processor
* 以上文章中的部分信息来自 2006 年 3 月的西雅图
Share 用户大会，刊登于 Cheryl Watson Newsletter 2006 Number 3.
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
5
DB2 Admin Tool 的使用技巧 —生成系统现行 ZPARM 源码
百硕资深工程师 吴笳笳
自从 DB2 支持 ZPARM 中的某些参数可以动态修改之后，特别是 DB2 V7 支持多套 ZPARM 参数的动态设置后，数
据库管理员们一定觉得非常方便，如果发现某些参数定义的不合理，不需要启/停 DB2 就可以进行修改。但是大家
有没有发现，这种便利的同时也带来了维护管理上的不便。如果你是个细心的数据库管理员，对于每一次的 ZPARM
参数修改，你都应该进行记录，以便下次重新编译 ZPARM 时做参考。但如果是其他人在你不知情的情况下，为解决
紧急问题而动态改变了 ZPARM 参数，而你下次编译 ZPARM 的时候使用了错误的源码就会产生问题。
我们曾遇到过这样的情况，某客户在一次 DB2 变更前不清楚现系统使用的是哪一套 ZPARM 源码，因为在他们的
系统环境中有多套作业库包含了 ZPARM 源码，而且不能确认自上一次变更之后，是否有谁动态修改过其中的参数。
因此，客户打印了 SMF 的 SYSPARM 与其中一套 ZPARM 源码进行比较，SMF 打印出来的某些参数的单位与 ZPARM 中设
定的不一致。而且有些参数只是 SMF 的 SYSPARM 中有的，而在 ZPARM 中并没有，反之亦然。另外，他们各自的展示
方式也有所不同，这些都给比对造成了一定的困难。客户花了很长时间对二百多个参数进行一一比对，我们同样花
费了很多的精力与时间协助进行最终的核对。这是一项非常精细的工作，一旦某个参数比对错误，就可能对生产
DB2 系统的正常运行造成影响。
对于这种情况，我们希望能够有一种工具能够自动从 DB2 系统中生成当前系统使用的 ZPARM 源码。我们发现
IBM 的 DB2 Admin Tool 能够实现该功能。为了使每个安装了该工具软件的客户都能全面了解其功能，并能充分利
用。我们愿借此文与大家共享这方面的信息，希望通过这个栏目向大家介绍该工具中某些实用功能的使用，让大家
通过使用工具轻松地管理您的系统。
下面，我们将介绍如何使用 DB2 Admin Tool 中自动生成 ZPARM 源码的功能：
首先进入 DB2 Admin Tool 的主菜单，选择 Z - DB2 system administration
DB2 Admin -------------- DB2 Administration Menu 7.1.0 ------------------ 11:24
Option ===> z
1 - DB2 system catalog DB2 System: DSTA
2 - Execute SQL statements DB2 SQL ID: BJISV02
3 - DB2 performance queries Userid : BJISV02
4 - Change current SQL ID DB2 Rel : 710
5 - Utility generation using LISTDEFs and TEMPLATEs
P - Change DB2 Admin parameters
DD - Distributed DB2 systems
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
6
E - Explain
Z - DB2 system administration
SM - Space management functions
W - Manage work statement lists
X - Exit DB2 Admin
进入系统管理菜单后，选择 2Z - Manage system parameters
DB2 Admin ----------------- DSTA System Administration ------------------ 11:25
Option ===> 2Z
DB2 System: DSTA
DB2 SQL ID: BJISV02
DB2 activity related functions:
2D - Display threads 2U - Display/terminate utilities
2T - Display/manage traces 2R - Display/update resource limits
2S - Stop DB2 2G - Display group
2B - Display/manage batch checkpoint 2Z - Manage system parameters
Buffer pool functions:
BD - Display buffer pools BA - Alter buffer pools
BH - Display buffer pool hit ratios
DB2 log functions:
LD - Display archive log parameters LS - Set archive log parameters
LA - Archive current log LI - Display log information
LZ - Set log checkpoint frequency
DDF functions:
DU - Display/update CDB
DC - Display/cancel distributed thds DL - Display active locations
DT - Start DDF DS - Stop DDF
Stored procedures and functions options:
PM - Manage stored procedures FM - Manage functions
在接下来的菜单中允许选择查看并生成源码、编译 ZPARM module、动态 LOAD 新的 ZPARM。如果想生成源码选
择 1 - Display Parameters/Generate DSNZPARM source，DSNZPARM Source 后面所填写的是你将要生成的 ZPARM
源码所存放的数据集，member 的名字可以自己随意指定。注意下面的一些系统库名要按照自己的系统环境进行修
改。
DB2 Admin ------------------- DSTA System Parameters -------------------- 11:26
Option ===> 1
1 - Display Parameters/Generate DSNZPARM source DB2 System: DSTA
2 - Assemble and Linkedit DSNZPARM module DB2 SQL ID: BJISV02
3A - SET SYSPARM LOAD( )
3B - SET SYSPARM RELOAD
3C - SET SYSPARM STARTUP
Output datasets:
DSNZPARM Source ===> 'BJISV02.DSTA.INSTALL(SOURCE)'
LinkEdit SYSLMOD ===>
Assembly listing ===> ADB.ASM.LIST
LinkEdit listing ===> ADB.LKED.LIST
Optional Debug ===> ADB.DEBUG.LIST
Input datasets:
Assembly STEPLIB ===>
Assembly SYSLIB ===> 'DSN710.TDB2710.SDSNMACS'
===> 'SYS1.MACLIB'
LinkEdit SYSLIB ===> 'DSN710.TDB2710.SDSNLOAD'
===>
Options:
Assembly ===> ADATA,LIST(133),OBJECT
Linkedit ===> LIST,XREF,LET,RENT
回车后，该工具会自动触发打开 Monitor Trace 的命令，收集相关的系统信息
DB2 Admin ------- DSTA Browse DB2 Command Output --- Line 00000000 Col 001 080
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
7
-START TRACE(MON) AUTHID(BJISV02) DEST(OPX)
********************************* Top of Data **********************************
DSNW130I -DSTA MON TRACE STARTED, ASSIGNED TRACE NUMBER 03
DSN9022I -DSTA DSNWVCM1 '-START TRACE' NORMAL COMPLETION
******************************** Bottom of Data ********************************
在使用 PF3 键返回时，系统会显示目前系统所使用的 DB2 系统参数供你查询
DB2 Admin --------- DSTA System Parameters - System Parameters ---------- 11:27
DB2 System: DSTA
(*) Online changeable parameter DB2 SQL ID: BJISV02
More: +
Storage sizes and connections
Operator and DDF functions
Tracing and data installation
Locking (IRLM)
Active log
Archive log
Protection and data definition
Stored procedures
Data sharing parameters
Application programming defaults
Other parameters
Restart parameters
Allow explain during autobind . . . . . . . . . . . . . YES (ABEXP ) *
Allow autobind operations. . . . . . . . . . . . . YES (ABIND ) *
Accumulate DB2 accounting data. . . . . . . . . . . . (ACCUMACC) *
Rollup accting aggregation fields . . . . . . . . . (ACCUMUID) *
Archive log allocation unit . . . . . . . . . . . . . . CYL (ALCUNIT ) *
Copy 1 prefix . . . . . DSTA.ARCLG1 (ARCPFX1 ) *
Copy 2 prefix . . . . . DSTA.ARCLG2 (ARCPFX2 ) *
Archive retention period . . . . . . . . . . . . . . . 30 (ARCRETN ) *
Archive WTOR routing codes. 1,3,4 (ARCWRTC ) *
Issue WTOR before archive mounts. . . . . . . . . . . . NO (ARCWTOR ) *
Read COPY2 archives first . . . . . . . . . . . . . . . NO (ARC2FRST) *
Plan authorization cache size . . . . . . . . . . . . 1024 (AUTHCACH) *
Bind new version. . . . . . . . . . . . . . . . . . BIND (BINDNV ) *
Archive dataset blocksize . . . . . . . . . . . . . . 24576 (BLKSIZE ) *
IMS/BMP timeout factor. . . . . . . . . . . . . . . . . 4 (BMPTOUT ) *
Cache dynamic SQL statements. . . . . . . . . . . . . . NO (CACHEDYN) *
Catalog archive datasets. . . . . . . . . . . . . . . . YES (CATALOG ) *
ICF catalog name . . . . . . . . . . . . . . . . . DSNDSTA (CATALOG ) *
Current degree special register . . . . . . . . . . . . 1 (CDSSRDEF) *
Activate change data capture. . . . . . . . . . . . . . NO (CHGDC ) *
System checkpoint frequency (LOGLOAD). . . . . . . 400000 (CHKFREQ ) *
Compact archive logs. . . . . . . . . . . . . . . . . . NO (COMPACT ) *
Maximum concurrent remote connections . . . . . . 100 (CONDBAT ) *
Contract CT long storage pool . . . . . . . . . . . . . YES (CONTSTOR) *
在 COMMAND 处输入“GEN”命令，系统将弹出如下两个对话框，告诉你源码已经生成了，选择 1. Confirm
member replacement and continue 确认并继续
DB2 Admin -------- DSTA Dataset Confirmation ---------- 11:28
The specified member already exists in the dataset. Choose
whether to replace the member or cancel.
Data set . : 'BJISV02.DSTA.INSTALL'
Member . . . SOURCE
Select a choice
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
8
1 1. Confirm member replacement and continue
2. Cancel
The updated macro source has been successfully created. Execute the
assemble & linkedit step to create a new parameter load module. To use
the new parameter module, execute the 'SET SYSPARM' command: Example: SET
SYSPARM LOAD( SOURCE)
按 PF3 键回到系统参数画面后再按 PF3 键，系统再次弹出确认画面，你可以选择 2. Cancel 或者不做任何选
择
DB2 Admin -------- DSTA Dataset Confirmation ---------- 11:28
The specified member already exists in the dataset. Choose
whether to replace the member or cancel.
Data set . : 'BJISV02.DSTA.INSTALL'
Member . . . SOURCE
Select a choice
2 1. Confirm member replacement and continue
2. Cancel
按 PF3 键后系统弹出如下对话框，提示你有部分参数是这个功能不支持的，这些参数一般都用默认值，如果要
改的话，需要自己写到 ZPARM 源码中，如果使用默认值就无需再做修改。
DB2 Admin -------- DSTA Unrecognized Macro Parameters Row 1 to 4 of 4
The following are parameters in the supplied macro in the SDSNMACS
dataset but are not recognized by this function. Values from the
current subsystem parameters could not be obtained. Any listed
values are the default value for the macro. You may specify a new
value for a parameter by over-typing the default. If the macro does
not provide a default and a value is required, an assembly error may
occur.
Macro Parameter Default
DSN6SPRM OPTCCOS2 OFF
DSN6SPRM PARAPAR1 NO
DSN6SPRM PROTOFF NO
DSNHDECM DB2SUPLD NO
************************** Bottom of data ***************************
再按 PF3 后，系统自动触发关闭 Monitor Trace 的命令
DB2 Admin ------- DSTA Browse DB2 Command Output --- Line 00000000 Col 001 080
-STOP TRACE(MON) AUTHID(BJISV02)
********************************* Top of Data **********************************
DSNW131I -DSTA STOP TRACE SUCCESSFUL FOR TRACE NUMBER(S) 03
DSN9022I -DSTA DSNWVCM1 '-STOP TRACE' NORMAL COMPLETION
******************************** Bottom of Data ********************************
按 PF3 退出后，你就可以在开始设定的存放源码的库中找到新生成的 ZPARM 源码了，这个功能的操作非常简
单，而且免去了比对的风险，大大减少了工作量，你可以把这个源码覆盖到原先的 ZPARM 编译作业中。如果还不放
心，想要和原先的 ZPARM 进行比对，也比与 SMF 打印出来的 SYSPARM 做比对轻松容易的多。
有了这个功能，管理和维护您的 ZPARM 参数是否轻松多了呢？它的确是数据库管理员的好帮手。
DB2 Admin Tool 还具备许多其它实用功能，如果您对它的某项功能感兴趣，或者在您的日常 DB2 维护管理中
有什么特别的需求，请反馈给我们，我们会在后续的文章中为大家作介绍。
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
9
随着 IBM 主机硬件容量的提升以及 IT 集中管理
的趋势，在业界存在将多个主机系统进行整合的需
求，而 RACF Database 的 Merge 是系统整合项目
中所必须进行的一个步骤。
许多担负 IT 集中管理运行任务的国家级数据处
理中心，为了满足大量测试及生产任务的需求，均存
在多套主机系统环境。由于某些原因不同系统的
RACF 配置可能存在很大差异。为了避免由于 RACF配置的差异影响或延误正常的应用测试与投产工作，
有必要同步各环境的 RACF 数据库定义；同时也需要
有一种方法能够快速检查并发现不同系统的 RACF 数
据库（以及同一系统不同时间点的 RACF 数据库备
份）之间的差异。
另 外 ， 在 实 施 RACF Remote Sharing Facility (RRSF)之前也需要对多系统的 RACF DB进行同步处理。
RACF Database 的 Merge 与同步处理从本质
上讲都是基于对 Source 和 Target RACF DB 进行
比较的基础之上，通过提取 Source 的 RACF 定义与
Target DB 的定义进行对比，按照一定的规则合并
一致的定义，同时判断出两个 DB 存在的差异，并使
用一些 RACF 指令解决所有的差异。当然，最直接的
方法是在系统中重新定义所有的 USER ID 以及
USER ID 所需要的资源访问配置，但这种处理方法
会对终端用户的使用造成影响，而且工作量也是显而
易见的。
通常，对两个来自不同系统的 RACF DB 的
Merge 和同步处理主要包括如下十个步骤： RACF 数据库 的合并与同步
处理 百硕资深工程师 王晓兵
Step 1. 检查 SETROPTS 冲突，比较两个
RACF 数据库的 SETROPTS 设置并判断和解决所有
的差异。该步骤是进行同步 Profile 定义的前提
Step 2. 检查 User/Group 冲突，从 SOURCE数据库选择 User 和 Group 与 Target 数据库的定义
进行检查，判断定义不一致的地方
Step 3. 确定 Superior Group，为每个同步或
Merge 的 Group 确定新的 Superior Group。
Step 4. 确 定 USER 和 GROUP 的
Ownership，为每个同步和 Merge 的 Group 确定
新的 Owner
Step 5. 合并 User-Group 连接，判断并确定
新的 User-Group 连接与连接属性
Step 6. 确定 Default group，确定每个 USER的 Default-Group
Step 7. 检查 Dataset 和 General Resource Profile 的定义差异，判断并确定新的 Profile 定义
Step 8. 确定 Dataset Profile 和 General Resource Profile 的 Owner，经过该步骤的处理所
有 Profile 的 Owner 将被确定
Step 9. Copy/Merge Dataset 和 General Resource Profile 的 ACL，确定所有 Profile 的
ACL，ACL (Access Control Lists)
Step 10. 确 定 其 他 的 User/Group/Data set/General resource 的 Profile 属性
所有的步骤完成之后，需要生成 RACF DB 配置
的差异分析报告并产生执行 Merge 处理的 RACF 命
令。
从上述步骤可以看到 RACF 数据库的合并与同步
处理是一个比较复杂且烦琐的过程，不仅需要实施者
（RACF 管理员）具有深厚的主机安全管理知识，同
时还需要对同步的两个 RACF DB 定义有比较全面的
了解。
为了使 RACF DB 的 Merge 与同步处理过程尽
可能地自动化处理，目前业界主要采用以下三种解决
方案：
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
10
使用 IBM 的 RACF Utility IRRUT400 合并
RACF 数据库
该 方 案 首 先 需 要 在 测 试 环 境 使 用
IRRUT400 进行测试，发现并分析 IRRUT400 合并
处理过程中存在的问题，通过一些 RACF 命令解决使
用 IRRUT400 进行 Merge 时出现的错误。
该方案的主要优势在于用户及其口令不会出
现任何问题。通过设置输入的 RACF 数据库读取顺
序，可以选择相同 Profile（USER、Group 或
Resource）的处理优先级。
该方案存在的最大问题在于目标 RACF 数据
库可能会出现难以解决的定义完整性问题，IBM 明
确警告，IRRUT400 不适合多系统异构的 RACF 数
据库合并。但是在国外一些案例中显示这种 Merge的方法在某些情况下仍然是可行的。
使用 IBM 提供的工具 DBSYNC 和 PWDCOPY
DBSYNC 用于 RACF Database 通过
IRRDBU00 Unload 出来的数据进行比较并产生消
除差异的 RACF 指令；PWDCOPY 则可用于从一个
RACF 数据库中将 USER ID 的 PASSWORD 复制到
另一个 RACF 数据库中。
该方案主要的优势在于软件是免费的。它实
际上是一组 REXX 程序，使用者可以对这些 REXX进行改写以符合自己的需求，当然首先需要研读并理
解所有程序的功能及程序处理流程。
实际案例中显示该方案主要的问题在于其进
行的是覆盖式的 Merge，例如产生的包含关键字的
命令在目标系统上定义的 Profile 与原系统是完全相
同的；在处理过程中缺乏对 Merge 冲突判断的有效
控制；使用时用户需要具有丰富的 RACF 知识和编程
技巧、需要自己编写额外的处理程序并进行反复的测
试。
使用提供成熟 RACF Merge 功能的第三方产品－
如 Consul zAdmin
zAdmin 对 RACF 数据库的比较和 Merge是通过其两个内置的命令 Summary（产生不同
RACF 数据库的比较列表和报告）和 Merge（产生
进行 RACF Merge 处理的 RACF 命令并产生 Merge处理报告）来实现的。
该方案基于对实际 RACF Profile 的比较，
自动产生相应的 RACF 指令用于 Merge 处理；对于
Merge 处理过程（出现冲突的优先级处理）也提供
了丰富的控制选项（称之为 MERGERULE）。如，
对于 Access List 的 Merge 处理，可以依据
MERGERULE 选项产生基于最高访问、最低访问、
源系统访问或者目标系统访问等多种控制；另外，该
产品也提供了同步用户 Password 的功能。在产生
Merge 处理指令的基础上，zAdmin 还会自动产生
Merge 处理报告，详细描述 Merge 产生的 RACF 与
Source 和 Target RACF 数据库之间的差异。
市场上提供 RACF Merge 功能的第三方产
品并不多见。zAdmin 是 Consul 公司主机安全管理
与审计解决方案 Consul zSecure™ Suite 中的一个
产品，除具有独特的能够对不同来源 RACF 数据库进
行比较与合并处理功能之外，zAdmin 实际上提供的
是一整套主机安全管理解决方案，能够有效提高主机
安全管理员的工作效率和质量，如实施主机 RACF 管
理自动化（定时 PERMIT 和 CONNECT 等）、
RACF 管理的分级控制以及细化 RACF 控制、RACF数据库智能清理等。
无论选择哪一种解决方案，最后都需要针对新的
RACF DB 产生基于 Profile 定义的差异分析报告，
与最初的 Source 和最终的 Target RACF DB 中
Profile 定义进行比较，确定新的定义不会对系统的
稳定运行造成任何潜在的影响。
实施 RACF DB 的 Merge 和同步处理期间也是
对当前 RACF Database 进行清理和优化的良好时
机，在实施过程中借助专业咨询服务公司的经验和建
议是非常有必要的。
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
11
Table Spaces And Locking Levels By Bonnie Baker
对于使用 DB2 的主机用户来讲，经常会遇到的问题是交易发生超时或是死锁。然而 DB2 的锁机制是
非常复杂且难以理解的。了解锁的类型和级别对于深入分析交易超时和死锁现象是很有帮助的。
因此，我们为大家选摘了著名的 DB2 专家 Bonnie Baker 所撰写的关于 Table Spaces 和锁机制的文
章。
她的这篇文章分为三个部分刊登在《DB2 MAGAZINE》杂志上。在第一部分中 Bonnie Baker 为大家介
绍了三种 TABLESPACE 的属性，刊登在 2006 年一期。第二部分介绍了锁的类型和级别，刊登在 2006 年第
二期。第三部分介绍超时和死锁，刊登在 2006 年第三期。
此文运用了大量生动形象的比喻，比较易于数据库管理员理解，而且在概念介绍上紧跟产品发展的
趋势，适用于 DB2 V6、V7、V8 版本的广大用户。
如果您对本文的内容有任何问题或希望和我们探讨，请随时与我们联系。
下面就请大家鉴赏这位 DB2 专家是如何由浅入深地讲解锁的概念。
百硕资深工程师 吴笳笳
Bonnie Baker is a consultant and educator specializing in application performance issues on the DB2 UDB for OS/390 and z/OS platforms. She is an IBM DB2 Gold Consultant, a five-time winner of the IDUG Best Speaker award, and a member of the IDUG Speakers Hall of Fame. She is best known for her series of seminars entitled "Things I Wish They'd Told Me 8 Years Ago."
Yes, programmers, you do acquire table space and table locks.
While I was talking with a programmer about locking contention and overhead one day, I mentioned table and table space locking. She looked at me and in all innocence said, "Oh, we don't ever use table space or table locking here. We only use page locking."
Buried in that response was the seed of a column. Why? Everyone who uses DB2 for z/OS (MVS or OS/390) acquires table space and table-level locks. And partition-level locks. And, well, lots of levels of locks. I set the idea for the column aside.
But, in one of my prior columns, "More Joys of Commitment," I made a comment about partition-level locking and the use of the LOCKPART parameter in CREATE TABLESPACE DDL. I received one particularly insightful email about that comment. And that made me take the time to finally write this column.
We must start at the beginning. To fully understand the issues surrounding locking levels, we must first understand the difference between a database and a table
space. We'll then look at the three basic types of table spaces.
Next time, in Part 2, we'll examine the types and levels of locks possible with each. Finally, in Part 3, we'll learn about timeouts, deadlocks, lock escalation, and lock upgrades, as well as many of the program logic and performance problems affected by these functions within DB2.
Level 1: DATABASE
The term database is often misused. For example, I hear folks saying database when what they really mean is table. In DB2, a database is more of a grouping concept than a physical entity. Just as the word neighborhood is a grouping concept for a bunch of houses, a database is a grouping concept for a bunch of table spaces, tables, index spaces, and indexes.
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
12
If a real estate entrepreneur decides to buy some land and build some houses, she must first decide on a name for the new development. The name can then be incorporated, the land purchased, architectural drawings commissioned, permits pulled, and houses built. All under the official name "Happy Acres." Happy Acres is the database in DB2 that lets us incorporate, establish an official DBD (database descriptor), purchase space (table spaces and index spaces), issue permits (grant authorization), and so on. To mix metaphors, the database name is the umbrella under which all of these things stand.
When a database is created, a numeric identifier is assigned. This identifier, the DBID, is used to begin a chain of information, called the database description chain (or DBD), about all of the objects that will be created in the database. As each object (table space, table, index space, and so on) is created within the database, the new object is also assigned an identifier: an OBID if the object is a tablespace or a table and an ISOBID if the object is an index space designed to hold its index. The DBD chain lengthens as objects are created and their identifiers and object information are stored in it. The DBD chain is stored in a database in DB2 called the Directory (DSNDB01).
The DBD chain must be resident inside DB2 whenever any object in the DBD is "in use." If it's not already resident, the chain is retrieved from DSNDB01 and brought into DB2. In version 7, the chain is stored, while resident, in the EDMPOOL, the same space used to hold package and plan segments.
In v.8, the resident chain has its own area of memory, called the EDM DBD CACHE. To ensure that the objects are not modified or dropped while in use, the DBD is locked. This database lock most often affects the DBAs who are unsuccessfully trying to issue ALTERs or DROPs of objects in the
chain. Putting too many objects in a single database can essentially put a DBA out of the business of object manipulation. Just as our entrepreneur would not build a million houses in Happy Acres, neither should a DBA create all objects in a single database. Conversely, the developer probably wouldn't put just one house in Happy Acres either.
Level 2: TABLE SPACE
Okay. Now we're ready to purchase some land. Once a database is created and the DBD is established, the next step is to create a table space. Just as we purchase a piece of property with the knowledge of what we plan to build on the land, we create a table space with the idea of what we're going to put into it. Table spaces are created to hold tables. We must know the size of the tables, the lock size needed, and so on. The creation of the table space causes a file allocation (unless the build is deferred — but that's another topic).
Generally, when we create a table space, we plan to create a single table in it. But in some applications, the DBA chooses to create many tables in a single table space. Instead of a single house on our land, we end up with condominiums! There are some negative ramifications of this practice. Utilities, such as LOAD, RECOVER, and REORG, are run at the table-space (or partition) level, not the table level. And there are many parameters that apply to the entire table space and all tables in it. The granularity of these parameters (pctfree, lock size, and so on.) is lost when too many tables are put into a single table space. However, by putting tables with similar behavior patterns in the same table space, file allocations, opens, and closes are reduced.
There are three types of table spaces:
Simple. In the early days of DB2 on the mainframe, there were only two types of table
spaces; simple was one of them. You could put multiple tables into the simple table space, but there was no way to automatically segregate the rows of one table from the rows of another. Therefore, rows of two (or more) tables could be interleaved on a single page. When DB2 used a table-space scan to access the rows of one table, it actually had to read all of the rows of every table in the space. Maintaining the cluster order of the tables was difficult, if not impossible. Even if there was only one table in the table space, the performance wasn't as good as it could be for inserts or mass deletes. IBM recommends that you no longer use simple table spaces.
Segmented. DB2 V2R1 introduced a smarter type of table space. Today, a new parameter (SEGSIZE) allows the DBA to allocate a second type of table space, one with pages grouped by segment. And one segment can only belong to one table. A table-space scan can now identify, at the segment level, which segments to scan; a table-space scan is actually a table scan. Oddly enough, even if there's only one table in the table space, the segmented table space is better because the information needed for insert logic is twice as robust. Also, rows can be mass deleted by merely maintaining entries in a space-map page rather than accessing, locking, and logging the maintenance of each individual page and row. And there are other benefits of the segmented table space; for example, the image copy utility recognizes which pages are active and which are not, and only backs up the active ones.
Partitioned. The other type of table space that has been around from the beginning is the partitioned table space. Because DB2 datasets are really VSAM files and because the maximum size of a VSAM file allocation back in those days was 4GB, there needed to be a style of
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
13
table space that could control more than one allocation gracefully. The partitioned table space allows the DBA to control the fragmentation of data when the table size exceeds 4GB.
In our analogy, the three table-space types represent the architectural concepts of the types of houses we are going to build in Happy Acres: basic ranch-style houses, three-story colonials, and condominiums with multiple towers. In other words, we have three basic architectural drawings and, with minor modifications to each, we can build many unique structures in our new subdivision.
How locks help friendly readers and not-so-friendly writers get along.
In Part 1, I described a database as well as the three types of table spaces that can be defined within a database. You might want to review Part I before reading this installment on locking.
Locking Levels
The LOCKSIZE parameter is part of the CREATE TABLESPACE data definition language. What are the options for that parameter? In general (without regard to table space type), we can choose from five LOCKSIZE parameter values: TABLESPACE, TABLE, PAGE, ANY, and ROW. The larger the LOCKSIZE value (the farther to the left in that list), the lower the overhead and the less concurrency (in other words, one or two locks can buy you access to everything you need to see, but might cause others to have difficulty accessing the data that you control). The smaller the LOCKSIZE (the farther to the right in the list), the more overhead, but also the more concurrency (in other words, for the price of more locks, more people can be using the data simultaneously without getting into each other's way). These locksizes are referred to as locking levels (as in, "I am doing page-level locking," or, "this table space is defined with row-level locking").
Locksize Any
Let's get this LOCKSIZE ANY out of the way for now. ANY is a schizophrenic LOCKSIZE value. It starts as page-level locking, and then morphs into its other identity when opportunity and necessity permits. In Part 3, I'll discuss this identity switch while covering LOCK ESCALATION (what that term meant in days of old as well as what it means today with the MAXLOCKS parameter). So, for now, let us ignore LOCKSIZE ANY.
Writers Vs. Readers
Before we get specific about the locking levels for each of the three table space types, we must keep in mind a general concept. Readers are generally very friendly with each other. If (and that is a big if) they get locks on their locking level, they get SHARE (S) locks. They may even acquire no locks at all. They don't mind sharing their level with other readers, and sometimes they don't mind sharing space with writers (those doing maintenance). They're a friendly sort.
Writers, however, aren't friendly at all. They certainly won't share their level with each other. Nor will they share with most readers. They pretty much want exclusive control of their locking level. The only users who can access their data when they have EXCLUSIVE (X) locks on the level are readers willing to read uncommitted data.
How The Levels Work
Think of the locking levels as a three-part hierarchical structure with table space at the top (see Figure 1).
The path on the left is that of a simple table space. The path in the middle is that of a segmented table space. And the path on the right is that of a partitioned table space.
Simple Table Spaces
Three LOCKSIZE options control serialized access to a simple table space: TABLESPACE, PAGE, and ROW.
As you might remember from Part 1, rows from multiple tables may share a single page in a simple table space. This means that if your simple table space holds more than one table, there's no ability to lock each table individually. There is no table-level locking for the simple table space.
So, if a simple table space is defined with LOCKSIZE PAGE, the user who accesses that table space (intending to read a page) must first acquire a table space lock. However, you should be using segmented or partitioned table spaces for your tables, as simple table spaces are deprecated. In the next release of DB2, you'll be able to keep the simple table spaces you created in version 8 and earlier, but you won't be able to create any new ones.
Segmented Table Spaces
Four LOCKSIZE options control serialized access to a segmented table space: TABLESPACE, TABLE, PAGE, and ROW.
So, if a segmented table space is defined with LOCKSIZE PAGE, the user who accesses that table space (intending to read a page) must first acquire a table space lock and then a table lock.
Partitioned Table Spaces
Three LOCKSIZE options control serialized access to a PARTITIONED table space: TABLESPACE, PAGE, and ROW.
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
14
As you remember from Part 1, a PARTITIONED table space can only contain a single table. Therefore, there's no need for table-level locking. However, there may be a need to lock at a level between PAGE and TABLESPACE—the PARTITION level. In versions 6 and 7, a parameter called LOCKPART* is part of the DDL for creating a partitioned table space. When this parameter is set to NO (the default), and LOCKSIZE is set to PAGE, the user who accesses the table space (intending to read a page) must first acquire only a table space lock before accessing the page. When this parameter is set to YES, and LOCKSIZE is set to PAGE, the USER who accesses the table space (intending to read a page) must first acquire a table space lock and then a partition lock (on the partition in which the page resides).
Also, setting this parameter to YES allows programmers to explicitly override page- or row-level locking and switch to partition-level locking. They can do this by coding:
LOCK TABLE mytable PART 4 in SHARE MODE
An S lock on the whole partition would allow readers, but no writers, to access the data while this program is being run. Programmers can also code:
LOCK TABLE mytable PART 1 in EXCLUSIVE MODE
This statement would prevent everyone except those willing to read uncommitted data from accessing the data. The default for the versions 6 and 7 LOCKPART parameter was NO (for upward compatibility with the days when no partition locking was possible). However, IBM highly recommended that DBAs use LOCKPART YES because of performance issues, especially in a data sharing environment. The performance issues are so important that the LOCKPART parameter was eliminated in version 8; the only option now is to do partition-level locking.
Getting Into The Building...
Let's assume LOCKSIZE PAGE and a SEGMENTED TABLESPACE and that I'm trying to do an insert. To insert a row into a table, using the hierarchical structure in Figure 1, I must first get into the table space. Now I don't need an exclusive (X) lock on the table space but I do need a milder lock that will let folks know that I'm in the table space. The perfect lock for this is an "intent lock," in this case an IX lock (I "intend" to do something "exclusive" = IX). So, I ask for one of these "I intend to do something exclusive" lock (an IX lock) on the table space. Then I must get into the table. I do so by asking for another "I intend to do something exclusive" lock (IX lock)—on the table. I'll be holding two IX locks before I even touch a page. Just as you must first get into a building to get onto a floor to get into a room, in a DB2 segmented table space you must first get into the table space (building) to get into the table (right floor) to get to a page (room). Although most buildings in DB2 are single-story buildings, the table level lock is needed just in case someone defines another table in the same table space.
pag
For a partitioned table space created in version 8 (or created using LOCKPART YES in prior releases), you must first get into the building (table space) to get into a tower (partition) to get into a room (page). With page level locking, intent locks will be acquired on the table space and the partition.
Just as there is no magic way of leaping into a room without first getting into the building and onto the right floor, there's no way to get into a page without locking the table space and table/partition.
The good news is that the intent locks are very friendly with each other. IX locks are compatible with other IX locks and they are also compatible with IS. So, if they're so friendly, why do we acquire them?
Holding these intent locks lets the lock manager know that someone is in the building, or the floor, or the tower without having to search room by room. If someone comes along and wants to burn down the building or lay new carpet on the floor or work on the elevator in the tower, the lock manager can see at a glance if someone with an IX or IS lock is there. You see, neither of these will share with an X lock. A LOCK TABLE mytable Part 4 in EXCLUSIVE MODE wouldn't be successful because these INTENT locks signify the presence of incompatible users.
Once we start entering the rooms (pages or rows), things get a bit more serious and a bit less friendly. At the page or row level, we get S (share for readers) locks, U (read for update) locks, or X (exclusive for writers) locks. Or we may, in fact, get no lock at all (a reader willing to read uncommitted data won't get a page or row lock). To provide data consistency, use "latching" for serialization at a lower cost.
The locking matrix (Figure 2) at the
1. X locks shar
e level shows that:
e with no
ks share with other S
ith S s.
r words, a single page could
other locks,
2. S loclocks as well as U locks, and
3. U locks share only wlock
In othehave one X lock on it, and no other lock. Another page could have one or more S locks on it. A third page could have one or more S locks on it along with one and only one U. A U lock will not share a page with
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
15
another U lock; no two users can read the same page for update at the same time.
Looking Ahead
erstand how locks are handled in table spaces, we can
scribed a database and three types of table spaces that
ow DSNZPARMs are used to control
ires about 250 bytes of memory (540 in V8
NZPARM specifies the maximum number of locks a user
er DSNZPARM limits the number of locks a user is allowed to
g Es to a table in a
rarely succeeds. When it does, it usually causes
ystem value for the maximum e
Now that we und
move on to tackle some of the nuances of locking. In the next column we will look at how DSNZPARMs are used to control the length of time we're willing to wait for a lock, the maximum number of locks we may acquire, and other system level controls. I will also discuss issues such as timeouts vs. deadlocks and lock escalation vs. lock upgrades. Finally, we know that we don't get locks on indexes. So how can an index-only job timeout? That, too, is a topic in Part 3.
Successful sharing ... with a little help from
UPDAT
DSNZPARMs.
In Part 1, I de
can be defined within a database. In Part 2, I discussed how page-level locking is handled in those different types of table spaces.
In this part, we'll look at h
the maximum number of locks we may acquire, the length of time we'll wait for a lock, and other system-level issues. We will also explore timeouts, lock escalation vs. lock upgrades, and deadlocks. And, we'll find out how an index-only job can time out even though we don't get locks on indexes.
DSNZPARMs
Because each lock requ
and later), system-level controls (DB2 DSNZPARMs) limit the number of locks each user can acquire.
One DS
number of locks per table spac
may acquire while his program or transaction is running. If a user tries to exceed that number, the lock
request will receive a -904 SQLCODE (resource unavailable). The unavailable resource is another lock.
Anoth
acquire on any one table space. If a user attempts to exceed that number, DB2 will try to allow the job to continue (and attempt to avoid a long ROLLBACK) by taking over the next higher lock level (TABLE or PARTITION, depending upon the type of table space). This process is called "lock escalation." If the escalation succeeds, the lower-level page locks can be released.
Let's say the user is doin
segmented table space. This user first acquired an IX lock on the table space and on the table before acquiring an X lock on each page on which an UPDATE has occurred. The X locks on the pages have accumulated and reached the DSNZPARM maximum. Instead of rolling back the statement, DB2 recognizes that all the X page locks can be released if this user can acquire an X table lock to replace the existing IX table lock. In order for the request for the X lock on the entire table to be successful, no other user can have any kind of lock on the table. If another user does, the attempt to escalate will fail and the greedy user will receive a -911 (TIMEOUT) SQLCODE. If the escalation is successful, the user will have an IX lock on the table space and an X lock on the table; all the other locks will have been released.
Lock escalation
problems because the X lock on the table causes all other users to time out.
The s
may not be appropriate for some table spaces. Therefore, you can override it in the table space DDL with the LOCKSMAX parameter.
When lock limits are being reached and users are receiving -911s and -904s caused by asking for too many locks or by a failed attempt to escalate, don't increase the limits. Doing so rewards "the bad guy" — and could eventually bring DB2 down. Instead, examine the greedy jobs to see if appropriate, lock-releasing COMMIT logic is in use.
A third DSNZPARM sets a limit on the amount of time users will wait for an unavailable lock. Suppose the parameter is set to 60 seconds (the default). When a user requests a lock on a resource and an incompatible lock exists (our user needs an X lock on a page and another user has an S lock on that page), the user will wait...but not forever. The user will wait under a clock. If the S lock is released, the user will immediately acquire the needed X lock. If the S-lock isn't released, our user will time out in the following manner: The clock has an alarm that goes off every 60 seconds (per the DSNZPARM). Each time the alarm goes off, any user that was waiting the last time the alarm went off (in other words, has waited at least 60 seconds) will time out. If the user has waited less than 60 seconds, he will continue to wait until the next time the alarm goes off. Our user times out the second time the alarm goes off and receives a -911 SQLCODE.
Lock Upgrades
Suppose our user begins by reading a page using a CURSOR that includes the FOR UPDATE OF... syntax. On the initial read, the user will acquire an IS lock on the table space, an IS lock on the table, and a U lock on the page. If the user then executes an UPDATE WHERE CURRENT OF CURSOR statement, the existing locks must be upgraded to show that our user is no longer just reading. The U lock must be upgraded to an X lock, and both IS locks must be upgraded to IX locks.
Lock upgrades occur when a user begins as a reader with the intent to share and then changes to a writer
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
16
with the intent to do something exclusive. Upgrades can fail with a -911 if another user has an incompatible lock on the page. For example, assume our user has a U lock on the page and another user has an S lock on the same page. When attempting to upgrade to an X lock, our user will be told to wait under the clock. If the user with the S lock lingers too long, our user will time out.
Deadlocks
A deadlock isn't the same as a timeout. While a user who times out did have a chance to succeed (if the incompatible user had released his lock and gotten out of the way), a deadlock victim had zero chance of success.
Here's a typical example of a deadlock. User 1 acquires an X lock on page 1 and needs an X lock on page 2 to complete his unit of work. However, User 2 has acquired an X lock on page 2 and needs an X lock on page 1 to complete her unit of work. Neither has a chance of success because each needs what the other has before a COMMIT can be executed to release the locks.
Because deadlocks are hopeless situations, DB2 has a deadlock detector. The detector will determine which user has done the least work (written the fewest log records) and issue that user a -911, rolling back the unit of work.
The example I mentioned involved two pages. However, two users can deadlock on a single page. Suppose User 1 has a U lock on page 1 because of a read FOR UPDATE OF... and wants to upgrade that lock to an X lock with an UPDATE WHERE CURRENT
OF CURSOR... statement. User 2 has an S lock on page 1 and issues a stand-alone, searched update to update a row on page 1. She must upgrade the S lock to an X lock. Neither can succeed because of the other. The deadlock detector must come to the rescue.
Index-only Locking Contention
Since V4 and the Type 2 index, DB2 no longer acquires locks on indexes. So, how can an index-only job time out?
Suppose an index-only job is running concurrently with a job that isn't index-only. The index-only job uses INDEX2 (on LASTNAME, FIRSTNAME, MIDDLEINITIAL) on the EMPTABLE and executes this SQL:
SELECT FIRSTNAME, MIDDLEINITIAL FROM EMPTABLE WHERE LASTNAME = :HVLN
This SQL doesn't read the table, because everything it needs is in INDEX2. The other job uses INDEX1 (on EMPLOYEE_NUMBER) and executes this SQL:
UPDATE EMPTABLE SET SALARY = SALARY + :HVMORE WHERE EMPLOYEE_NUMBER = :HVEMPNO
It reads both the table and INDEX1.
For the second job, DB2 can easily ensure that updates are being done only to committed data. DB2 can check as the table page is read and locks are requested. However, the first job was bound with ISOLATION CS — it isn't willing to read uncommitted data. On this job,
table pages aren't read and locks aren't requested. So how can DB2 be sure that none of the index rows are uncommitted?
Using some lock avoidance techniques that use information in the index-page and index-row headers, DB2 determines whether the index data being read is possibly uncommitted. If there's a possibility that the index data is uncommitted, DB2 must protect the CS reader. DB2 does this by taking the row ID (RID) associated with the current index row to the IRLM (DB2's Lock Manager) and determining whether another user has an X lock on that RID. If User 2 happens to be updating the salary of the employee whose name we're trying to read, User 1 will be told to wait under the clock and might time out. The name column information is perfectly clean but the row is uncommitted. DB2 doesn't do column-level checking for uncommitted data. If any part of a row is uncommitted, the entire row's data is uncommitted.
What We Know Now
We've learned that our most common lock size (page) is multilevel and includes table space and table/partition locks as well as page locks. We've learned about intent locks and that a lock's mode can change because of upgrades or successful escalation. DSNZPARMs police our locking, and a deadlock detector provides relief from irreconcilable differences. We've also learned that an index-only job can (on very rare occasions) time out. But there's much more to learn about locking, and I'll share more in future columns.
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
17
Smooth Moves—Seven Habits Of A Highly Effective Migration By Marna Walle
IBM z/OS 1.7 已经正式发布了 1 年的时间，许多客户正在考虑或已经开始了实施升级 z/OS 到 1.7
的项目，相信所有的人都会关心如何才能完成平稳的过渡，而本文列出的 7 件事可以为我们提供参考－
在升级之前我们可以和需要做什么？
本文最初刊登在 2006 年 2 月发布的第 15 期 z/OS 时事通讯杂志《HOT TOPICS》中。作者 Marna
Walle 在 z/OS Build and Installation department 工作了 16 年，目前专职负责 z/OS 平台的版本升级
和安装方面的技术，在 z/OS 安装的客户研讨会中多次担任发言人。.
如果您希望迁移到 z/OS V1.7 且需要更多相关信息，请联系我们，我们可以帮助您进行规划。
百硕资深工程师 王晓兵
So, you’re migrating from z/OS V1R4 to z/OS V1R7 and you want to make it go as smoothly as possible? You’re on the right page, because here’s a list of seven things you can do now to help make your migration to z/OS V1R7 uneventful. Even if you’re migrating from z/OS V1R5 or z/OS V1R6 to z/OS V1R7, review this list because z/OS V1R7 introduces many of these items.
1. Get on z/Architecture™. z/OS V1R6 introduced an Architecture Level Set, which means you must be running in z/Architecture (64-bit) mode. Hopefully, your V1R4 system is already in z/Architecture mode, and this is not an issue. If you’re not running z/Architecture yet, migrate to a z/Architecture-capable server first. On z/OS V1R4, take advantage of the Bimodal Migration Accommodation to remain in 31-bit mode according to the terms and conditions agreement. Then move to 64-bit mode using the Washington Systems Center (WSC) Flash10185 at
ibm.com/support/techdocs/atsmastr.nsf/Web/Flashes to help you. It is strongly recommended that you migrate to z/Architecture before migrating to z/OS V1R7, to avoid migrating architecture and software level at the same time.
2. Ensure that you are running JES2 Z2 mode. z/OS V1R7 JES2 requires that your system run in Z2 mode, also known as full-function mode (and not in R4 or compatibility mode). If you depend on the control blocks and field changes that have changed for Z2 mode, you might need to change your JES2 exits and modifications. If your system is already in Z2 mode, then cross this one off your list. If your system is still running in R4 mode, see z/OS V1R7 Migration, GA22-7499, that corresponds to your current z/OS JES2 level for details about the Z2 changes. Also, see z/OS JES2 Commands, SA22-7526, for information about using $ACTIVATE to go to Z2 mode.
3. Do not use JOBCATs or STEPCATs. With z/OS V1R7, you cannot use JOBCAT or STEPCAT DD statements. If a job contains a JOBCAT or STEPCAT DD statement, the first step in the job that contains the statement is unsuccessful. The job ends with accompanying message IEFC034I. If you use JOBCAT or STEPCAT extensively, your jobs will be impacted, and you’ll need to remove the statements. If your system is at z/OS V1R5 or V1R6, you can detect these statements more easily than you can on z/OS V1R4, and allow JOBCAT and STEPCAT to be reenabled. Nevertheless, you can’t use these statements for long, because z/OS V1R7 does not support the reenablement of JOBCAT or STEPCAT.
4. Move to the International Organization for Standardization (ISO) C/C++ compilers that z/OS has been shipping (and updating) since z/OS V1R2. The ISO C/C++ compilers have changes in semantics, and add keywords. To
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
18
give you time to migrate from the older compilers to the newer ones, both have been shipped in z/OS since z/OS V1R2. In V1R7, however, the OS/390® R10 C/C++ compilers are gone. You can still reinstall them on your z/OS V1R7 system with limitations, but it’s going to be additional work for you (see informational APAR PK05324). If you’re not yet using ISO C/C++ compilers, which are now called XL C/C++ compilers, this item affects you.
5. Get ready for the one-byte console ID support removal in V1R7. As of z/OS V1R7, almost all of the onebyte console ID support is removed. (Programs compiled using older versions of the changed macros continue to work in z/OS V1R7.) If you are running a z/OS V1R4 system with the Consoles Enhancement feature or z/OS V1R5 or higher, you can use the Console ID Tracking Utility to help identify whether you use one-byte console IDs. If your z/OS V1R4 system does not have the Consoles Enhancement feature, that support is integrated into z/OS V1R7. Use the Console ID Tracking Utility in z/OS V1R7 to help with this activity. Before using the Console ID Tracking Utility, make sure you have retrieved the latest exclusion list for your appropriate z/OS level, at
ibm.com/servers/eserver/zseries/zos/downloads/. Remember, in the release after z/OS V1R7, the remainder of the one-byte console ID support is intended to be removed, so position yourself to have this work done before your migration to z/OS V1R7 or while on z/OS V1R7.
6. Plan your z/OS V1R7 JES2 user exit changes. In z/OS V1R7, there are many JES2 exit changes that might be required because some network job entry (NJE) and existing internalreader processing was moved from the JES2 address space to user address spaces. If you have specialized JES2 exits, you might need to make many changes to accommodate this restructure. There might also be other updates to automation and procedures you need to make based on the new JES2 processing. If these changes will be too big for you to handle during your usual migration window to z/OS V1R7, remember you can plan to stage your JES2 level, and run your existing lower JES2 release on your z/OS V1R7 system which would also allow you to delay Z2 mode for a little while longer! For details on the changes required, see z/OS V1R7 Migration, GA22-7499.
7. Understand the IODF V5 coexistence requirement in z/OS
V1R7. If you want to make changes to your input/output definition file (IODF) from z/OS V1R7, upgrade your IODF to the V5 level. And you must continue to use z/OS V1R7 hardware configuration definition (HCD) to update that IODF. If you want to use a JOBLIB or STEPLIB from the lower system, you need to use the higher HCD data sets for processing. This upgrade introduces coexistence considerations when sharing your V5 IODF with lower-level systems. These coexistence considerations are more complicated if your z/OS V1R4 system does not have the z990 Compatibility or z990 Exploitation feature installed (that is, you don’t have HCD FMID HCS7708). If you intend to share an IODF between z/OS V1R7 and a lower-level system, make sure you know the requirements for which are explained in z/OS V1R7 Migration, GA22-7499. These coexistence requirements might prompt you to delay making updates to your IODF from your z/OS V1R7 system (thus, not requiring an update to the V5 IODF level). You might also consider not sharing the IODF between z/OS V1R7 and lower systems. By understanding these seven important migration actions, your smooth move to z/OS V1R7 can be well underway before you even place your order!
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
19
Web 环境中的 CICS 百硕资深工程师 李琰
不久前，IBM 正式推出了适用于 IBM eServer z系列服务器 WebSphere Application Server for z/OS 6 版本和 CICS Transaction Server for z/OS 3.1 版本。
IBM WebSphere Application Server for z/OS, V6 是面向大型机的主要 Java 2 Enterprise Edition (J2EE)和 Web 服务应用服务器，它交付了
具有独特平台区分器的事务引擎，这些区分器支持最
高质量的业务工作负载；CICS TS 3.1 使用 Web 服
务能力来将 CICS 应用扩展到 SOA（服务导向架构）
环境，同时通过简化的接口，方便这些应用的开发、
集成和管理。
CICS 作为客户信息控制系统，于 1969 年被正式
开发推出，目的在于实现交易的联机实时处理，它的
发展主要经历了以下几个阶段：
VSE 环境下的 CICS/VSE； MVS/ESA 环境下的 CICS/ESA V4.1； OS/390 下环境推出了 CICS TS V1.1； 当前 z/OS 环境下的 CICS TS V3.1；
我们可以看到，Internet 的高速发展正在促进
IBM 主机系统向 Web 方向发展。在 CICS V3.1 新版
本下，CICS 可以使用 EXEC CICS 指令，可以通过
CICS 应用程序发出 HTTP 的客户端请求，即：CICS成为了 Web 应用服务器的客户端，CICS 作为 HTTP的 Client 已经完全集成到 CICS Web support 中。
在 CICS TS V3.1 环境下，可以通过在 CICS 程
序中发出 EXEC CICS 命令去建立一个到 HTTP 服务
器的链接，然后发送请求，并且接收响应的数据并进
行处理。为了方便开发这种程序，CICS 引入了一些新
的 EXEC CICS 指令，并且已有的指令在提供输入参
数的同时也提供了相应的输出参数。
作为 HTTP 客户端的 CICS，意味着 CICS 应用程
序可以编写成：
对 business-to-business 通讯使用公共的
协议； 使用 HTTP 协议来控制硬件和软件（比如：
对打印机的控制）； 可以访问 HTTP 的应用，提供或接收相关的
信息
您可以通过使用一个 CICS Web Support 的
Global 用户出口程序，使 CICS 的 HTTP 请求能够使
用代理并且增加一些相关的安全策略。
当 CICS 是一个 HTTP 客户端时，CICS 作为一个
Web 的客户端与 HTTP 服务器通信，此时用户的程序
通过 CICS 向 HTTP 服务器发送请求并接收应答。
CICS 负责维持与服务器之间的稳定连接。CICS 通过
在相关的用户程序指令中使用 Session token 来辨别
每个连接。
CICS 中的客户程序必须显式地使用 CICS WEB API 和 HTTP 服务器进行交互，发送请求或接收回
应。
发送请求的 CICS 应用程序需要处理来自服务器
的返回数据，这些数据可能包含错误的返回数据，到
其他 URL 的重新定向，嵌入的超文本链接，HTML 表
格，图片或其他需要程序处理的内容。在发送和接收
的过程中，CICS 根据需要会进行必要的编码方式的转
换。
CICS 作为 HTTP 客户端处理流程如下:
1. 应用程序初始化一个到 HTTP 服务器的连接
应用程序通过 EXEC CICS WEB OPEN 命令初始
化一个到 HTTP 服务器的连接，其中 scheme 和 host name 可以通过程序显式指定，也可以通过引用一个
已经定义好的 URIMAP 资源来指定。
2. CICS 建立到服务器的连接
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
20
通过应用程序提供的信息，CICS 会首先在指定的
端口上选择一个 TCP/IP 链路去访问 HTTP 服务器，
当链路建立起来后，CICS 会返回给应用程序一个
Session token 来唯一标示这个连接。应用程序会在
后续的处理中使用这个 Token 来使用这个连接与
HTTP 服务器进行通讯。
3. 应用程序可以在请求数据中添加 HTTP Header 信息。
Header 信 息 可 以 通 过 WEB WRITE HTTPHEADER 指令生成、存储并用于后续的发送。
4. 应用程序指定 Request 行中的相关信息。
request method, path information 和 query string 可以通过 WEB SEND 或者 WEB CONVERSE指令来指定。
5. 应用程序可以提供 HTTP 请求的 body 数
据。
请求的内容(body)可以通过 WEB SEND 或者 WEB CONVERSE 指令来指定。
6. 应用程序发出请求。
当 应 用 程 序 使 用 WEB SEND 或 者 WEB CONVERSE 命令时，请求首先被发送到 CICS，然后
CICS 根据 Session token 来确定需要使用的连接。
7. CICS 在相关的请求中添加一些 HTTP Header 信息，并把它发送到 HTTP 服务器。
8. 服务器接收和处理请求并作应答。
CICS 把应答数据返回给应用程序。
9. 应用程序接收并分析应答数据。
WEB READ HTTPHEADER 命 令 或 HTTP Header 浏览命令可以分析应答数据中的 Header 部
分。WEB RECEIVE 命令或 WEB CONVERSE 命令
可以用来接收应答数据中的 Body 部分、应答码和应
答字，这些信息可以被程序处理。
10. 应用程序可以发出进一步的请求和响应。
如果服务器支持长连接，session token 标示的
连接会在后续的请求中始终保持 OPEN 状态。
11. 应用程序关闭到服务器的连接。
当所有的请求和应答都完毕时，应用程序可以使
用 WEB CLOSE 命令使 CICS 关闭这个 TCP/IP 链
路。如果程序没有使用 WEB CLOSE 命令，那么程序
建立的连接会在程序退出时被 CICS 关闭。
在这个过程中，当信息“进入”和“离开”CICS时，编码转换通常是需要的，这样 CICS Web 支持模
块和用户程序（一般使用 EBCDIC 编码）就可以与
HTTP 服务器（一般使用 ASCII 编码）进行通讯。
新的及修订过的命令
新的用于 CICS HTTP 客户端的 EXEC CICS WEB 命令:
EXEC CICS WEB OPEN EXEC CICS WEB CONVERSE EXEC CICS WEB CLOSE
增加了新选项的 EXEC CICS WEB 命令：
EXEC CICS WEB SEND EXEC CICS WEB RECEIVE
新的可同时用于 CICS HTTP 客户端与服务器端的
EXEC CICS WEB 命令:
EXEC CICS WEB PARSE URL EXEC CICS CONVERTTIME
其他的 EXEC CICS WEB 命令选项作了一些修
改，其中可以同时用于 CICS HTTP 客户端与服务器端
的命令：
EXEC CICS WEB WRITE HTTPHEADER EXEC CICS WEB READ HTTPHEADER EXEC CICS WEB STARTBROWSE
HTTPHEADER EXEC CICS WEB READNEXT
HTTPHEADER EXEC CICS WEB ENDBROWSE
HTTPHEADER EXEC CICS WEB EXTRACT EXEC CICS FORMATTIME
WEB FORMFIELD 和 WEB RETRIEVE 命令不能
用于 CICS 的 HTTP 客户端程序。
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
21
专家问答
Q & A with Experts
从本期开始，我们增加了“专家问答”栏目，由百硕的技术专家与读者在工作中遇到的实际问题进行交流与探讨。
欢迎您将关心的问题发送给我们，我们将在后续的客户通讯中为您安排专家解答。
您可通过 [email protected],或您的百硕客户代表转达感兴趣的问题。
本期专家：Martha Hall
资深主机系统专家，拥有 33 年以上的主机经验。
曾服务于 IBM 华盛顿系统中心、美国国防部和美国海关。自 2002 年起，作为百硕常驻的主机专家，参与了中国银行、工商银行、建设银行、农业银行、人民银行、交通银行和深圳发展银行等多项主机咨询和实施服务项目，拥有丰富的本地服务经验，非常了解国内主机用户的实际需求。
有关 SMP/E 的四个问题
问题 1: Where do I look for critical SMP/e Product installation information?
专家解答:
Program Directory
The program directory contains product specific information about any product being installed, including problems and solutions that have already been uncovered with the product installation. This is the most critical document to reference during product installation.
IBM Migration Documentation
IBM provides detailed migration information for all customers doing a software migration; such as moving from z/OS 1.4 to z/OS 1.7. It contains information about all the steps required for the migration, such as Compatibility PTFs, and DASD storage requirements, new datasets and datasets which are deleted.
User Group provided documentation from Early Support Programs
When a new IBM program or Product is first released, it is released in “BETA” status. Several IBM Customers are chosen for an Early
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
22
support program. These customers install and test the software before the software is available for all other customers. The Early support customers will present their findings and their experiences during user group meetings so that other customers can benefit from hearing about the issues and challenges presented during the installation process. This type of documentation is available from Users Groups such as SHARE, CMG, and GUIDE.
IBM Manuals
There are several IBM Redbooks that discuss how to install and maintain both Operating systems and Program products such as CICS, DB2, and IMS. One of the better IBM manuals is the Redbook“Parallel Sysplex Software Management for Availability” (SG24-2451).
问题 2: Should I IPL my SMP/e Target Volumes as my SYSRES volumes? Should I apply system maintenance to my running system?
专家解答:
In the US, this is not done. SMP/e volumes are solely for use by SMP/e. The target volumes (TLIBs) are copied or “cloned” and these secondary volumes then become the IPLable SYSRES volumes. One reason we have chosen to do this is to avoid applying maintenance to an IPLed volume. System maintenance should never be applied directly to a volume that is currently IPLed. If the DDDEFs are pointing to the currently IPLed System Residence volume then maintenance can be inadvertently applied to a “running” system, and this can have a very negative impact on System Availability if problems are encountered.
问题 3: Should PTFs be accepted on my system?
专家解答:
Absolutely yes. This is the IBM recommendation, and the ACCEPT step is always included in the IBM Program directory and the IBM Migration documentation. Not accepting the PTFs can lead to problems when and if system components are linked using the DLIBs and the DLIBs are not in sync with the target libraries. APARs and UserMods should never be accepted. These rules have been in effect for many years, and should always be followed. IBM recommends that system maintenance be ACCEPTED immediately following a sucessful APPLY step.
问题 4: What is a “Rolling IPL”?
专家解答:
A Rolling IPL is always used in a SYSPLEX environment, and again has to do with System Availability. System maintenance is never applied to more than one image in a SYSPLEX at a time except in very special cases, when IBM will tell you a SYSPLEX wide IPL is required. Instead, it is rolled across the SYSPLEX members with an interval of several weeks between each IPL. This is an integral part of the SYSPLEX concept to ensure System availability. It is the reason “compatibility PTFs” are installed to ensure that several versions of the Operating system can co-exist in one SYSPLEX at the same time. Installing complete system replacements can be difficult and problems can be encountered even if load testing has been done using TPNS or other similar products. Without Load testing, it is imperative to use Rolling IPLs so that problems are never encountered on Production systems.
* 关于 SMP/E 方面的其他问题，我们将在后续的百
硕客户通讯中陆续为大家刊登。
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
23
百硕客户通讯 BASHORE ADVISOR 中国主机用户专享的资讯季刊
2006 年 9 月 1 日出版（总第 5 期）
主办：百硕同兴科技（北京）有限公司
出版：百硕客户通讯编委会 吕宁
郭庆雪 李琰
吴笳笳 王晓兵 徐卫华 邹杰
刘京平 郑霞
康会影 Daniel Chow Martha Hall
James Smith John Varendorff
地址：北京市朝阳区望京科技园利泽中二路 1 号中辰大厦 209 室 电话：010 64391733 传真：010 64391582 电子邮箱：[email protected]
百硕客户通讯，总第 5 期 2006 年 9 月 1 日
24
