百硕客户通讯，总第 - bayss.com · rexx routine，利用system rexx的 execs自...

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

0


1

目录

消息快递 News Express

z/OS V1.9 简介 2

DB2 V9 新体验 5

经验分享 Experience & Tips

更为灵活的 DB2 数据库表备份方式 7 百硕资深工程师吴笳笳

DFSMShsm Tips 10 百硕外籍技术专家 Mohd Shahrifuddin

百硕博客 Bayshore Blog

C:D 使用经验

—为菲律宾某银行实施数据传输工具（C:D）的几个实例 14

百硕资深工程师刘京平

XMS 与 ASN-and-LX Reuse Facility 浅析 20 百硕工程师应永杰

z/OS 中的 APF 机制 30 百硕工程师罗兴魁

专家问答 Q & A with Experts

本

期

主要内容

Logger 相关的三个问题 34 百硕资深工程师王晓兵

来稿选登 Selected Contribution

File Transfer time Reduced from 7 Hours 40 Minutes to 3.1

Minutes 36

Sterling Commerce case study


2

z/OS V1.9 简介

IBM 对 z/OS 的支持期限

目前 IBM 每年 9 月份会发布 z/OS 操作系统的新

版本，每个新版本的支持期限是三年。 z/OS V1R7 于 2005 年 9 月 30 日发布，将在 2008 年 9月 30 日结束服务期。z/OS V1R4 已经在 2007 年

3 月 31 日终止了服务。z/OS V1R9 的计划过期日

为 2010 年 9 月。

z/OS V1.9 Library 的大小

z/OS V1R9 Target Library 的大小（ 6400 Cylinders ）已经接近 3390-6 的容量（ 6678 Cylinders）。z/OS V1R9 DLIB 总的大小为 8900 Cylinders。 z/OS V1R9 HFS File System（2900 Cylindesr ）已接近 3390-3 的容量 (3339 Cylinders)。因此，我们强烈建议检查现系统 Target Volume 的空间大小，并为 z/OS V1R9 预留

出所需的 Target Volume 存储空间。同样，我们

建议您将 File System的 ROOT 数据集放存在多个

3390-3 型盘卷上（多卷数据集），或是在容量大

于 3390-3 的盘卷上。

IBM Migration Checker IBM 的Migration Checker for z/OS可以直接从

http://www.ibm.com/servers/eserver/zseries/zos/downloads/网站下载，该工具由几个批量程序组成。

这些程序既可以独立运行，也可以在一个作业中

顺序执行，用于检查当前运行的系统，移植到

z/OS V1.9 后对某些操作的适应性。在您的系统

移植到z/OS V1R9 之前，应该利用这个工具，并

仔细检查其输出结果。

z/OS V1.9 的新地址空间

1. Systems REXX 的 AXR 这个地址空间用于z/OS基础组件 BCP（Basic Control Program）中的System REXX。 AXR 地址空间在 z/OS 初始化过程中自动启动，

且可以手动重启。但是在该地址空间被启动之

前，必须将其加入为系统地址空间初始化而指定

的 RACF Group 中。

2. C 语言客户端的 CEA CEA（Common Event Adapter）可以将z/OS上的

事件发送给C语言客户端，例如，z/OS CIM服务

器。z/OS初始化时，CEA地址空间将会自动被启

动，而且不会终止。

3. ARCnXXXX （用于 DFSMShsm）在调用 DUMP 、 RESTORE 、迁移、备份、

RECOVER 或者 CDS 备份功能的时候，

DFSMShsm会自动启动DFSMSdss中的一个地址

空间。

4. DSSFRDSR （用于 DFSMSdss） DFSMSdss地址空间的作用是自一个或多个Copy Pool备份版本中同时恢复多64个数据集。当数

据集从磁盘中被恢复时，DFSMShsm会自动启动

该地址空间。

5. Telnet Server

TN3270E Telnet Server 是 z/OS V1R6 中新增的地

址空间，在 V1R9 中继续延用，用于支持 Telnet功能。

Processors 处理器

z/OS V1R9 多可以支持 54 个 System z9 EC 服务器上的处理器。处理器总数是 CP、zAAP 和

zIIP 的数量总和。

ASID Reuse 在 z/OS V1R9 版本下，用户可以使用 ASID 重用

功能，该功能可以解决 ASID 耗尽的问题。授权

的应用可以通过启动命令中的

“REUSASID=YES”参数，或者 ASCRE 宏上的

ATTR=REUSASID 请求使用可重用的 ASID。该

功能可以通过 Parmlib Member“DIAGxx”中的

REUSASID（YES）来激活。否则此类请求将被

忽略。默认值为 REUSASID（NO）。

http://www.ibm.com/servers/eserver/zseries/zos/downloads/

http://www.ibm.com/servers/eserver/zseries/zos/downloads/


z/OS 海量信息流自动化处理

这是基于策略的功能，用于自动化处理大流量信

息。该功能支持 Parmlib 定义和操作员命令，用

户可以指定需要监控的信息类型，海量信息流开

始/结束的标准，以及相应的操作。用户可以针对

不同的信息类型、作业和单个信息 ID 采用不同

的处理策略。为了防止发生海量信息，可以采用

以下策略：

不显示

不记入 Log

不排队进入自动化处理

在 Sysplex 环境中不向其它系统扩展

不排队使用 AMRF （ Action Message Retention Facility）

通过发送命令（如 CANCEL）来采取针对发

生海量信息的地址空间的操作

信息流速监控功能可用于帮助制定海量信息流自

动化处理策略。此功能可以通过 IEAVMXIT 出

口程序来实施，并已经在 z/OS V1R6、V1R7 和

V1R8 中作为 SPE（OA17514）交付使用。

Console 定义

z/OS V1R8 已经不支持单字节的 Console ID 了，

z/OS V1R9 也取消了单字节 Console ID 的支持。

用户应检查确认 Parmlib Member 中 CONSOLE 的

定义是否已改为使用 Console 名了。

把 SMF 数据写入系统 Log 中

该功能可支持更快的 CF 写入率（Write Rate），

同时也支持 DASDONLY Log Stream，但是写入

率较低。另外，也提供 SETSMF 支持，在无需

IPL 系统的情况下，将 SMF 记录切换到 Logger或者切换出来。用户可通过定义，将不同系统上

的 SMF 记录合并到一个 Log Stream 中。也可以

在 SMFPRMxx 中，为不同的 SMF 记录类型指定

不同的 Log Stream。IBM 一直期待着更好的可扩

展性（特别是在使用 CF 的情况下更是如此）。

值得注意的是，不同的 Log Stream 可以有不同的

Retention Period。新程序（IFASMFDL）将用于

从 Log Stream 中获取 SMF 数据，并有选择性地

进行存档。该功能可以提供 OUTDD 过滤，减少

Multiple-Pass 处理。没有必要去确定 SMF 数据位

于哪个 Generation Data Set 中。该功能仍然支持

SYS1.MAN 数据集。

IPCS 增强功能

没有特殊权限的用户可以通过 IPCS ACTIVE 访

问那些属于 ASID 的，未授权程序可以看到的

Data Space 。 Facility Class “ BLSACTIVE ADDRSPAC” 读访问允许浏览所有属于 ASID 的

Data Space 。 Facility Class “ BLSACTV SYSTEM”读访问允许访问 ABSOLUTE 存储、

所有的 ASID 和 Data Space。由于 IPCS 不是连续

使用的，因此，可以对系统的静态区域作很好的分析。对于经常改变的系统区域则不可以。

WLM 对删除处理的改进

在 z/OS V1R9 之前，删除作业的善后处理是按照

被删除的地址空间所拥有的调度优先级来进行

的。如果此时所有的处理器都在忙于处理较高优

先级的任务，那么被删除的地址空间就需要较长

时间才能结束。因此，用户有时候希望能够为被

删除的作业重新设置优先级，以加快其终止的速

度，并释放其占有的、可能存在竞争的资源。

在 z/OS V1R9 中，WLM 可以将被删除的地址空

间提升到更高的调度优先级，以保证其得到足够

的 CPU 资源而及时终止。有了 WLM 的自动调整

功能，用户将不再需要手动设置，而且系统管理

将变得更加容易。

System REXX (SYSREXX) 这项新功能可以使 REXX 程序脱离 TSO 环境运

行。该功能支持通过程序接口和操作员命令调用

EXECs。System REXX 支持运行经过授权的

REXX Routine，利用 System REXX 的 EXECs 自动执行复杂的操作员命令和其它系统功能。

SYSREXX 引入了一个新的地址空间（AXR）。

System REXX 中的 Health Checker

Health Checker 可以写在 SYSTEM REXX 中，并

在 SYSTEM REXX 之下按计划运行。SDSF 功能

支持 REXX 的变量使用。这些变量从 SDSF Panel中装载数据。该项功能利用脚本按照程序要求访

问数据。变量值的改变具备类似使用 Action Characters 和重复输入的能力。

3


IBM 文档：新的 Eclipse Doc Plug-ins 已经整合到了 Library Server 中，提供了除传统的 Book Manger Books和 Adobe PDFs 之外的管理及搜索功能。z/OS V1R9 的 Library Server V3.2 标志着 IBM Systems z 技术资料演变的新进展，更快捷地发布相关领

域的技术文档。网页地址如下：

http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp

Communications Server 的改变

Communicaiton Server 具有很多新的功能。

IP Services 提供基于路由（ Routing）的策略，策

略增强以及策略安全性增强功能。此外，还提供

以目标为中心的策略管理。目前可以在 zIIP 处理

器上使用部分 IPSec(Internet Protocol Security)功能。

在 z/OS V1R8 和 z/OS V1R9 中所有用于

ANYNET 的编码都已经被废止。对基于 IP 的

AnyNet SNA 来说，可以考虑实施替代的 SNA/IP整合技术，如 EE（Enterprise Extender）。对基

于 SNA 的 AnyNet Sockets 来说，没有可以替代

的功能。对于此类 SNA 服务，必须从

VTAMLST 中删除 TCP 主节点，从配置文件或

CLIST 中删除或停止所有的 TCP 主节点。

移植到 z/OS V1.9 的重要动作

z/OS V1R8 和 V1R9 不支持单字节 Console ID

删除了 C/C++ IBM Open Class Libraries

（V1R9）上的 Run-time Dependency，使

用标准 C++ Library 来替代。

SNA 服务 — 删除 AnyNet 定义（V1R8），

考虑使用 EE 技术。

将 TN3270E Telnet Server 作为一个独立的地

址空间来运行（V1R9）。用户必须在升级

到 V1R9 之前作调整，以保持 Telnet 功能。

4




DB2 V9 新体验

概述 DB2 9 for z/OS 大的变化是XML，直接支持

pureXML格式的存储，并将面向对象（Object-relational）的XML与DB2集成在了一起。在DB2 V8中，就已经对SQL进行了较多的改进，并引入

了诸多新的功能、语句以及子句。而DB2 V9更是

增加了许多新的SQL语句和数据类型，同时对

LOBs(large objects) 进行了改进，加强了数据处

理的连续性。除此之外，DB2 V9还改进了ROLE和Network Trusted Context的安全性。 DB2 V9还有很多性能方面的创新，如降低了

Load和Reorg 操作对CPU的消耗，处理变长数据

的性能得到改进，Logging和Insert性能的提高。

此外，通过IBM System z 与 z/OS 之间的配合实

现了性能的提高，包括： XML 解析、 zIIP（ System z9™ Integrated Information Processor）、MIDAW 通道性能提高、加密、

IPv6 （ Internet Protocol Version 6 ）和 SSL （Secure Socket Layer)等方面。 DB2 V9增强了对Query的管理，同时改进了Index的性能（包括定义INDEX在表达式上、随机的

Index key和加大Index page size），从而加快了数

据访问的速度，提高了数据访问的准确性。优化

方面的改进包括为Optimizer提供更佳数据，改进

优化技术，以及改善优化服务管理。

性能的提高 DB2 V9 主要的性能改进：降低了许多Utility 执行的CPU时间，提高了LOB性能和可扩展性，

为数据的Update提高了性能和可扩展性，优化了

SQL语句，zIIP对Remote Native SQL过程的处

理，降低了处理变长Column数据的CPU时间，以

及更佳的顺序访问。在Query方面的优化：DB2 V8 SQL过程在大多数

情况下都无法在zIIP上运行，但是在DB2 V9版本

中，改为使用 Remote Native SQL过程语言，则

可以在ZIIP上处理。新的System z9 处理器在

DB2方面的改进是zIIP和新的商务级和企业级的

处理器。DB2 V9 Remote Native SQL过程可使用

zIIP进行处理。DB2 V9充分利用了硬件和操作系

统的新技术，提高了性能和价值，为用户提供

了更强的适应性和更佳的功能。 FlashCopy可以用于DB2备份和恢复。DB2巧妙地

利用了z/Architecture的指令集，新的指令提高

了可靠性、性能和可用性等等。DB2将拓展与硬

件数据压缩、FICON通道、磁盘存储、高级网络

功能以及WLM的协作。

Query 的增强报表方面的改进主要体现在：Query 和 Reporting 性能得到了提高，使用也更加便捷。通过运算法

则的改进，Optimizer能够获得更佳的数据，而且

重新改写了处理性能异常的方法。更多Query可以使用新的增强的 SQL 来表达。另外， INTERSECT和EXCEPT子句的操作使得SQL更容

易编写。 RANK 、 DENSE_RANK 和 ROW_NUMBER 的

OLAP扩展增加了新的功能。其它SQL语句提高

了DBMS的一致性。DB2 V9继续加强了SQL的改

进，增加了许多新的功能、语句和子句。如前所

述，大的改进是在XML方面，DB2 V9增加了

新的SQL数据操纵语句MERGE和TRUNCATE，以及新的数据类型：XML、DECIMAL FLOAT、 BIGINT、BINARY和VARBINARY。 Intersect和Except操作使某些SQL操作更容易定义。在DB2 V9 中数据定义一致性和可用性也得到了提高。

适应性（Resiliency） DB2 V9 加强了可扩展性方面的创新，例如，按

照增长情况对Table Space 进行分区，降低了Log Latch 争夺，增加了创建和修改 STOGROUP SMS架构的功能。DB2 V9 一系列的改进和新功能可

以协助用户加强对关键业务数据的管理，减少计

划内和计划外停机，例如：进行联机重组时不需

要执行BULD2 Phase，可重新命名Column和Index，可修改Index改变Page Size，以及无须IPL就可修改早期代码的功能等。

5


针对少数Partition的联机Table Space重组，通过去

除所有类型 Secondary Index的BUILD2 Phase，性

能将会得到极大的提高。DB2 V9中重要的改进之

一是：可以快速地实现用一个Table替换另一个。

另一个重要的变化是：可以更改Column和Index的名称。一种新的 Table Space 类型综合了

Segmented 和 Partitioned Table Sapce 的属性，而

且无需 Partioning Key。另外，Rebuild Index 运行

中的中断将大大减少，可以更改Table Space和Index Logging。SMS构造中的 MGMTCLAS、DATACLASS和 STORCLAS可以在STOGROUP中定义，而且可以修改。Column Default 也可以

被改变。 DB2 V9 中， Inserting 和 Logging 性能通过

Latching和Archiving得到了极大的提高。磁盘和

通道方面新的改进（DS8000 Turbo, 每秒4GB的通

道, MIDAW），以及大量的Preformat、Prefetch和Deferred Write都在很大程度上提高了数据传输

速率。此外，DB2 V9中，Index Page Size 增大，

使Index 性能得到了进一步改善，减少了Page 分裂的次数并提高了质量。用户可以使用

“APPEND”选项对Insert进行性能优化，而无须

后续的调整。如果需要随机得到数据，为避免出

现插入的热点，可以使用V9中新的 Randomized Index Key。在很多情况下，Segmented Space结构的效率更

高，因此，为大的分区Table Space 增加这种

Space 结构有助于 DB2 的扩展，即使没有

Partitioning Key。 DB2 V9在V8的基础上改善了内存的性能， DDF和DBM1使用了位于2GB线上的共享内存，并将

更多的 Data Structure 转移到2GB线之上，大致可

以释放200至300MB的可用空间。 DB2 V9的“RECOVER”Utility功能也有所改进, 可以使用FlashCopy产生的整卷备份 (BACKUP Utility)，实现object-level 的数据恢复。这样就免

去了为每个database和 table space准备拷贝作业的

工作量。OSC(Optimization Service Center)是个

Windows界面的工具,它提供了一整套监控、分析

和调优工具。另外，借助于DB2 V9的Buffer Pool Size 调整功能，WLM的处理能力得到了进一步

的增强。

6


更为灵活的 DB2 数据库表备份方式

百硕资深工程师吴笳笳

作为主机 DB2 数据库管理员（DBA）的您掌握几种数据库表的备份方式呢？猜想大部分人都很熟悉，

在主机 DB2 中的 IMAGE COPY 分为全量备份（Full Image Copy）和增量备份（Incremental Image Copy）两种。全量备份就是备份数据库表空间中的所有 PAGE，通过在备份作业中指定 FULL YES 参

数来实现；而增量备份则是仅备份自上次全量或增量备份之后，到当前点之间所有发生过修改的

PAGE，通过在备份作业中指定 FULL NO 参数来实现。

在备份作业中还有两种影响数据库表访问的参数可供选择，即 SHRLEVEL REFERENCE 和

SHRLEVEL CHANGE：

• SHELVEL REFERENCE 指的是在数据库表做备份的时候，其他用户对该表只能进行读取操作。

• SHRLEVEL CHANGE 指的是在数据库表做备份的时候，其他用户可以对该表做修改操作。

据了解国内客户用得多的还是全量备份。全量备份的好处在于备份结果可以直接用于恢复，无需保

留大量的 ARCHIVE LOG。但它的缺点在于，全量备份的执行时间长，影响其他用户访问的时间也相

对较长。当然，如果使用 SHRLEVEL CHANGE 可以减少影响用户访问的时间，但会将一些

uncommitted 的 UR 也进行备份。所以 IBM 是不建议用使用 SHRLEVEL CHANGE 的结果，来做

RECOVER TOCOPY 的恢复操作。而增量备份则可以大大缩短备份时间。但众所周知，增量备份的结

果是不能直接用于恢复的。在数据库表进行恢复前，数据库会将增量备份与近一份全量备份进行合

并，合并的结果再追加 DB2 LOG 进行恢复。这将大大延长数据恢复的时间。如果想要缩短数据恢复时

间，用户可以选择每天在做完数据库表的增量备份后，手工提交一个 MERGE 作业，将新的增量备

份与近的一份全量备份进行合并，以备方便数据恢复时使用。

除此之外，是否还有其它可选择的，更为灵活的备份方式呢？在执行速度已经不占优势的今天，许多

第三方厂商的工具在使用的灵活度上下了不少功夫。它们为客户提供了更多的备份方式选择，既满足

了传统的使用需求，尽量缩短影响联机处理的时间，也尽可能地简化了 DBA 的工作流程。

在这里，我们将介绍 CA 公司提供的工具软件中的两种数据备份方式，与大家共同探讨其功能和优

势，希望能够对 DBA 有所帮助。

方式一：利用 MODIFY BIT 功能做增量备份

前面我们介绍过，增量备份是备份表空间中至上次全量或增量备份以来被更改过的 PAGE。一个 PAGE是否被更改是由 space map 中的 MODIFYBITS 来决定的。CA-Quick Copy 可以让用户选择，每天做增

量备份来节省备份的时间，却无需保留多份的增量备份。它是通过做累积的增量备份来实现该功能

的，详细步骤如下：

第一天备份先做一份全量备份，备份作业中使用参数 MODIFYBITS YES。此时在 SYSIBM.SYSCOPY中记录了该备份。

7


之后的每天我们都做增量备份，在备份作业中使用参数 MODIFYBITS NO 以及 MERGE-COPY YES。此后每次所做的增量备份，都包括了本次更改过的 PAGE，以及上次增量备份中包含的所有更改过的

PAGE，并且每次做增量备份都会在 SYSIBM.SYSCOPY 删除上一次增量备份的记录，增加本次增量备

份记录。如此下来，后一次增量备份包含了以前所有的增量备份以及本次的增量备份。我们姑且将

这种备份称为“累积增量备份”。

到了需要恢复数据的时候，用户只需使用近的一份全量备份，加上后一份累积增量备份即可。而

无需再 MERGE 每天的增量备份。

如果采用此方法进行备份，我们建议每周末运行一次 MERGE 操作，将上周末的全量备份与近一份

累积增量备份进行合并，生成一份新的全量备份，这样就可以将增量的 PAGE 控制在一周之内，以缩

短每天增量备份的执行时间。

下面是使用该方法的作业示例，供参考： //QCOPY3 JOB ,MSGCLASS=X,REGION=0K,MSGLEVEL=(1,1), JOB14491

// NOTIFY=&SYSUID,CLASS=B 00002001

//UTIL0001 EXEC PGM=PTLDRIVM,

// PARM='SUFFIX=00,EP=UTLGLCTL/UB11,RESTART(BYPASS)',

// REGION=6M

//STEPLIB DD DISP=SHR,DSN=CAI.DB2.LOADLIB

// DD DISP=SHR,DSN=DSN710.SDSNEXIT

// DD DISP=SHR,DSN=DSN710.SDSNLOAD

//PTILIB DD DISP=SHR,DSN=CAI.DB2.LOADLIB

// DD DISP=SHR,DSN=DSN710.SDSNEXIT


//PTIPARM DD DISP=SHR,DSN=CAI.DB2.PARMLIB

//PTIMSG DD SYSOUT=*

//PTIIMSG DD SYSOUT=*

//SYSOUT DD SYSOUT=*

//SYSUDUMP DD SYSOUT=*

//ABNLIGNR DD DUMMY Suppress Abendaid dumps

//SYSCP101 DD DSN=CAI.DB2.BK.DSN8S71D.D050621.I,

// DISP=(,CATLG),SPACE=(4096,(12,50),RLSE),

// VOL=SER=ES6301,UNIT=3390

//SYSIN DD *

COPY TABLESPACE DSN8D71A.DSN8S71D

DSNUM ALL

SHRLEVEL NONE

MODIFYBITS NO FULL NO

EXCP NO

ALLMSGS

COPY-BUFFERS 80

COPY-TASKS 01

COPIES COPY01(Y,SYSCP101,,LP)

//*

采用该方式进行备份避免了 MERGE 多份增量备份的操作，缩短了备份时间，并且具备自动删除

SYSCOPY 中没用的增量备份记录的功能，减少了 DBA 的人工干预和工作量。

方式二：利用 DB2 LOG 实现联机备份

此方式是 CA-Merge/Modify 工具中提供的 Log Accumulation 的功能。Log Accumulation 是针对指定的表

空间，将近的 Image Copy 和 DB2 log 合并，生成新的备份。它生成的备份可以是全量备份也可以

是增量备份。生成的备份信息会记录在 SYSIBM.SYSCOPY 中，由此生成的全量备份也可直接用于数

据恢复。

8


此方案不同于任何传统的备份方式，其增量部分来自于信息内容丰富、完全的 DB2 Log。其实现

方式如下：

利用 Merger/Modify 的 Log Accumulation，从 DB2 的 Archive 和 Active Log 中抽取 DB2 Object 的变更

数据，生成 Log Accumulation File。再利用 Merge/Modify 将现存的 Image Copy 与 Log Accumulation File 进行合并，生成新的数据备份(Image Copy)。

在使用 LOG ACCUMULATION 生成备份的过程中，被操作的表的状态为 RW，且没有 LOCK。因此，

它的操作完全是后台操作，对数据库表的使用没有任何影响。

作业编写也非常简单，用户无需指定 Image Copy 和 DB2 LOG 的文件名，该工具会自动在数据库中查

找，用户只需指定新的备份文件名即可。

下面就是使用 Log Accumulation 进行备份的作业示例： //ACCUMLOG JOB ,MSGCLASS=X,REGION=0K,MSGLEVEL=(1,1),

// NOTIFY=&SYSUID,CLASS=B

//UTIL0001 EXEC PGM=PTLDRIVM,

// PARM='SUFFIX=00,EP=UTLGLCTL/DNP1',

// REGION=6M

//STEPLIB DD DISP=SHR,DSN=CAI.DB2.LOADLIB

// DD DISP=SHR,DSN=SYS1.DSN710.SDSNEXIT


//PTILIB DD DISP=SHR,DSN=CAI.DB2.LOADLIB

// DD DISP=SHR,DSN=SYS1.DSN710.SDSNEXIT


//PTIPARM DD DISP=SHR,DSN=CAI.DB2.PARMLIB

//PTIMSG DD SYSOUT=*

//PTIIMSG DD SYSOUT=*

//NEWCOPY1 DD DSN=WRKTMP.TSJJ.CACOPY3.F.D080602,

// UNIT=3390,SPACE=(CYL,(500,200),RLSE),

// DISP=(,CATLG)

//SYSOUT DD SYSOUT=*

ACCUMULATE TABLESPACE DBJJ.TSJJ

DSNUM ALL

COPIES COPY01 (Y,NEWCOPY1,,LP)

ARCHIVES-ONLY NO

CHECK-DUPLICATES YES

//*

此方案的大优势在于，它丝毫不影响 DB2 数据的联机访问，而且可以实现准确和新的数据全备

份或增量备份。用户可以在任意时间点采用此方法生成新的数据备份，大大缩短出现故障时的数据

恢复时间。

我们希望通过这个介绍，能够帮助 DBA 了解并掌握更多的 DB2 数据备份方式，从而多几种选择，提

高大家的数据库使用和管理水平。希望与您就感兴趣的技术问题进行探讨、相互切磋、共同进步。

9


DFSMShsm Tips

百硕外籍技术专家 Mohd Shahrifuddin

Introduction

The DFSMShsm Tip is a purpose to use for maintaining daily DFSMShsm. DFSMShsm has hundred of commands but only a few commands are useful for day to day work. The command in these tips can be automate or manually issue. These tips are divided into two Operations.

Maintaining Daily Operation Operation Guide Operation

Maintaining Daily Operation

DFSMShsm requires daily attention to ensure running healthy without unforeseen problem such as CDS or Journal full. This is to makes sure that space is available on Direct Access Storage Device (DASD) volumes so that old datasets can be extended and allocate new ones. DFSMShsm also makes sure that backup copies of data sets are always available if working copies are lost or corrupted. Below are the useful tips commands to use for daily operation:

Query Cancel Expirebv Recycle Hold Release

QUERY functions

To check CDS and Journal full: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,QUERY CDS TSO HSEND QUERY CDS

To check Request in progress: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,QUERY REQUEST TSO HSEND QUERY REQUEST

To check Waiting to process: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,QUERY WAITING TSO HSEND QUERY WAITING

To check any AUTO in progress: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,QUERY AUTOPROGRESS TSO HSEND QUERY AUTOPROGRESS

To check any Held activity: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,QUERY ACTIVE TSO HSEND QUERY ACTIVE

To check any parameter set in DFSMShsm parm: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,QUERY SETSYS TSO HSEND QUERY SETSYS

To check any BIT information can cause Deadlock: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,LIST HOST(n) TSO HSEND LIST HOST(n)

CANCEL functions

10


To cancel the request after request is issued: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,CANCEL REQUEST(nnnn) TSO HSEND CANCEL REQUEST(nnnn)

Eg. F DFSMSHSM,CANCEL REQUEST(360) Eg. TSO HSEND CANCEL REQUEST(360)

Note: nnnn – please refer to query request output.

Example: ARC0101I QUERY REQUEST COMMAND STARTING ON HOST=2

ARC0161I RECYCLING VOLUME 729644 FOR USER SS3JEH, REQUEST 00000360

ARC0101I QUERY REQUEST COMMAND COMPLETED ON HOST=2

EXPIREBV functions

This job is to display expire backup version: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,EXPIREBV DISPLAY TSO HSEND EXPIREBV DISPLAY

Schedule this command everyday to expire backup version and return the tape available for next recycle: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,EXPIREBV EXECUTE TSO HSEND EXPIREBV EXECUTE

RECYCLE functions

To display tape eligible for recycle and return to scratch pool: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,RECYCLE ALL DISPLAY

PERCENTVALID(20)

TSO HSEND RECYCLE ALL DISPLAY PERCENTVALID(20)

To scratch the tape and return to scratch pool: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,RECYCLE ALL EXECUTE

PERCENTVALID(20)

TSO HSEND RECYCLE ALL EXECUTE PERCENTVALID(20)

HOLDING functions

All processing can be held by issuing the following command or CDS or Journal is full: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,HOLD ALL TSO HSEND HOLD ALL

To prevent or interrupt automatic volume and automatic secondary space management, issue either of the following commands:

CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,HOLD AUTOMIGRATION TSO HSEND HOLD AUTOMIGRATION

F DFSMSHSM,HOLD MIGRATION(AUTO) TSO HSEND HOLD MIGRATION(AUTO)

RELEASING functions

To check any activity HELD by issuing the following command: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,Q ACTIVE TSO HSEND Q ACTIVE

Sample message display ARC0101I QUERY ACTIVE COMMAND STARTING ON HOST=1 ARC0144I AUDIT=NOT HELD AND INACTIVE, LIST=NOT HELD AND INACTIVE, RECYCLE=NOT ARC0144I (CONT.) HELD AND INACTIVE, REPORT=NOT HELD AND INACTIVE ARC0160I MIGRATION=NOT HELD, AUTOMIGRATION=NOT HELD, RECALL=NOT HELD, ARC0160I (CONT.) TAPERECALL=NOT HELD, DATA SET MIGRATION=INACTIVE, VOLUME ARC0160I (CONT.) MIGRATION=INACTIVE, DATA SET RECALL=INACTIVE ARC0163I BACKUP=NOT HELD, AUTOBACKUP=NOT HELD, RECOVERY=NOT HELD, ARC0163I (CONT.) TAPEDATASETRECOVERY=NOT HELD, DATA SET BACKUP=NOT HELD, VOLUME ARC0163I (CONT.) BACKUP=INACTIVE, DATA SET RECOVERY=INACTIVE, VOLUME ARC0163I (CONT.) RECOVERY=INACTIVE ARC0276I DATA SET BACKUP=INACTIVE, DATA SET BACKUP ACTUAL IDLETASKS=(ALLOC=00, ARC0276I (CONT.) MAX=02) ARC0642I DUMP=NOT HELD, AUTODUMP=NOT HELD, VOLUME DUMP=INACTIVE, VOLUME ARC0642I (CONT.) RESTORE=INACTIVE, DATA SET RESTORE=INACTIVE

11


ARC0437I - TAPECOPY NOT HELD AND INACTIVE ARC0437I - TAPEREPL NOT HELD AND INACTIVE ARC0415I EXPIREBV=NOT HELD AND INACTIVE, LAST STORED BACKUP VERSION KEY=, LAST ARC0415I (CONT.) STORED ABARS VERSION KEY=, LAST PLANNED END KEY= ARC0460I PRIVATE AREA LIMIT=10M, UNALLOCATED=9044K, LARGEST FREE AREAS=9036K, ARC0460I (CONT.) 8K ARC0460I EXTENDED PRIVATE AREA LIMIT=1930M, UNALLOCATED=1904M, LARGEST FREE ARC0460I (CONT.) AREAS=1904M, 8K ARC6018I AGGREGATE BACKUP/RECOVERY = INACTIVE ARC6019I AGGREGATE BACKUP = NOT HELD, AGGREGATE RECOVERY = NOT HELD ARC1540I COMMON RECALL QUEUE PLACEMENT FACTORS: CONNECTION STATUS=UNCONNECTED, ARC1540I (CONT.) CRQPLEX HOLD STATUS=***,HOST COMMONQUEUE HOLD STATUS=NONE, ARC1540I (CONT.) STRUCTURE ENTRIES=***% FULL,STRUCTURE ELEMENTS=***% FULL ARC1541I COMMON RECALL QUEUE SELECTION FACTORS: CONNECTION STATUS=UNCONNECTED, ARC1541I (CONT.) HOST RECALL HOLD STATUS=NONE,HOST COMMONQUEUE HOLD STATUS=NONE ARC0101I QUERY ACTIVE COMMAND COMPLETED ON HOST=1

The RELEASE command can be issued from the system console or also submitted by a DFSMShsm authorized user from a TSO terminal, using the HSENDCMD.

Below are shown the examples of RELEASE command: CONSOLE LOG COMMAND TSO COMMAND F DFSMSHSM,RELEASE ALL TSO HSEND RELEASE ALL F DFSMSHSM,RELEASE AUTOMIGRATION TSO HSEND RELEASE AUTOMIGRATION F DFSMSHSM,RELEASE RECALL(TAPE) TSO HSEND RELEASE RECALL(TAPE)

Operation Guide Operation

This operation guide is to help Application Support to use or issue DFSMShsm command. The important command we list here:

hmig hrecall hback hrecover

Migrate Command

The command can be issued by batch or TSO command.

Batch commands

Requirement Descriptions =Using Batch to issue commands TSO Commands Test Action Description TSO Commands Comments HSEND Check DFSMSHSM can use in batch

Sample JCL //HSMCOMD JOB (), // CLASS=A, // MSGCLASS=X, // MSGLEVEL=(1,1), // NOTIFY=&SYSUID, // TIME=1440 //RACFRW2 EXEC PGM=IKJEFT01 //SYSPRINT DD * //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * HSEND MIGRATE ABC.DEF.GHI /*

DFSMSHSM COMMANDS Migrate Commands Requirement Description =Migrate Commands

Action Description Comments HMIGRATE or HMIG Migrate from primary volume to

migration volume

12


Sample migration command and message display From dataset list (option 3.4) issue HMIG at command line DSLIST - Data Sets Matching IBMUSER.LOCAL.JCL Row 1 of 1 Command ===> Scroll ===> PAGE Command - Enter "/" to select action ----------------------------------------------------------------------- hmig IBMUSER.LOCAL.JCL OS39M1 ARC1007I MIGRATE REQUEST 00000032 SENT TO DFSMSHSM ARC1000I IBMUSER.LOCAL.JCL MIGRATE PROCESSING ENDED

Recall Command Requirement Description =Recall Commands

Action Description Comments HRECALL or refer (Edit, Browse, View)

Recall from migration volume back to primary volume

Sample recall command and message display From dataset list (option 3.4) issue HRECALL or edit, browse or view command at command line DSLIST - Data Sets Matching IBMUSER.LOCAL.JCL Row 1 of 1 Command ===> Scroll ===> PAGE Command - Enter "/" to select action ----------------------------------------------------------------------- Hrecall IBMUSER.LOCAL.JCL MIGRAT1 ARC1007I RECALL REQUEST 00000033 SENT TO DFSMSHSM ARC1000I IBMUSER.LOCAL.JCL RECALL PROCESSING ENDED

Backup Dataset Command Requirement Description =Backup Command

Action Description Comments HBACK or HBACKDS Backup to tape

Sample backup command and message display From dataset list (ISPF option 3.4) issue HBACK at command line DSLIST - Data Sets Matching IBMUSER.LOCAL.JCL Row 1 of 1 Command ===> Scroll ===> PAGE Command - Enter "/" to select action ----------------------------------------------------------------------- hback IBMUSER.LOCAL.JCL OS39M1 ARC1007I BACKUP REQUEST 00000045 SENT TO DFSMSHSM ARC1000I IBMUSER.LOCAL.JCL BACKUP PROCESSING ENDED

Backup volume Command Requirement Description =Backup volume Command

Action Description Comments HBACK Backup volume to tape with option

dump

Sample backup command and message display Go to ISPF option 6 issue HBACK VOLUMES(VOLUME) DUMP DUMPCLASS(LDAILY) ARC1007I BACKUP REQUEST 00000090 SENT TO DFSMSHSM

Recover Command Requirement Description =Recover Commands

Action Description Comments HRECOVER DSN Recover from backup tape

Sample recover command and message display Go to ISPF option 6 issue HRECOVER DSN(DATASET NAME) ARC1007I RECOVER REQUEST 00000076 SENT TO DFSMSHSM ARC1000I IBMUSER.LOCAL.JCL RECOVER PROCESSING ENDED

13


C:D 使用经验 —为菲律宾某银行实施数据传输

工具（C:D）的几个实例

百硕资深工程师刘京平

作者引言：

本文介绍在菲律宾某银行实施 C:D 数据传输工具的几个实例，与大家分享一种新的数据传输解决方案。希望

借此拓展大家的思路，在选择新的银行数据传输解决方案时，不仅是考虑传输工具应具备的并行高速传输，

断点续传，压缩，加密等功能，还需要考虑工具是否具备传输过程中不同阶段的自动化处理能力，以及完整

的传输监控和统计信息。因为，对于银行关键业务来讲，未来 IT 系统的开发、运行、管理成本会越来越昂

贵，而且安全审计会越来越严格。

目前，伴随国内各家银行向国际化的发展方向，银行数据的安全风险控制越来越受到重视。如何保证

银行数据在不同平台之间安全受控的传输是非常重要的环节之一。

对于大多数的商业银行，在相当长的时间里，跨平台的数据传输使用的是 FTP 这种成本低廉的传输工

具。但是，目前看来 FTP 已很难承担银行敏感数据的安全传输任务。这是因为，当主机作为 FTP 的客

户端，开放平台作为 FTP 的服务端使用 FTP 时，存在以下弊端：

主机上使用 FTP 传输，需要在 FTP 的作业流中以明文方式，指定访问 FTP 服务端的用户名和

密码，且当服务端的用户名和密码变更后，还要相应地变更主机作业流中的内容。不但维护困

难，而且安全隐患很大。

对于文件传输无法有效监控

难以实现诸如断点续传，重传，多线程并行传输之类的高效传输

不支持传输过程中的数据压缩和加密

人工干预较多，难以实现传输过程以及传输后的自动化处理，造成总体传输效率低下。

显然，我们需要使用一种更简单而安全、高效且受控、更趋于自动化的传输处理，更少的人员干预，

更严格安全规范的传输解决方案来替换 FTP。本文就是通过介绍百硕同兴为菲律宾某银行实施 C:D（Connect:Direct）数据传输解决方案的实例，与各位分享如何在主机与开放平台之间，实现更高效、

安全、自动化的数据传输。

菲律宾某银行的主机操作系统是 VSE V2.5。该行选择 C:D 作为数据传输工具，主要是基于以下考虑：

C:D 具有的高效并行传输能力

具有不同程度的压缩选项，以及断点续传的功能

实现自动化传输处理，减少人工干预所造成的滞后及低效

提高传输安全性，容易获取数据传输的统计信息，以满足银行监管部门的审计要求。

该行提出了九项不同的传输需求，每项需求在传输数据的同时都伴随着自动化处理的实施。我们从中

挑选了以下典型实例与大家分享：

14


一、主机触发传输并在传输成功后调用开放平台的批处理程序

很多的银行要求保存每日的批量执行输出结果，以便存档或日后查询等用途。该菲律宾银行要求 C:D自动从 VSE 的 List queue 中，将指定类型的批量作业输出结果传输到开放平台上，并判断传输是否成

功。如果传输成功则自动删除主机 List queue 中相应的 queue，并调用开放平台上的批量程序，对下传

成功的文件进行校验和转储操作。以下为主机端发起的 C:D process 内容： * $$ JOB JNM=PROCLSTQ,CLASS=A,DISP=D * $$ NTFY=YES, * $$ LDEST=*, * $$ CLASS=A // JOB PROCLSTQ // EXEC LIBR A S=CONNECT.PRODLIB CATALOG PROCLSTQ.N EOD=/+ REPLACE=YES PROCLSTQ PROCESS SNODE=CDWIN COPY01 COPY FROM (DSN=&DSN1 - LST=(CLASS=A,DISP=D,CC=NOCC) - DISP=(SHR,KEEP) - PNODE) - TO (DSN=&DSN2 - SYSOPTS="DATATYPE(TEXT) STRIP.BLANKS(NO)" - DISP=RPL - SNODE) RTCODE1 IF (COPY01 <= 4) THEN RTMOVE RUN TASK SNODE (PGM=WINDOWS) -

SYSOPTS="pgm (c:\movecabat\move.bat) desktop(yes)"

ELSE

NOTIFY RUN TASK (PGM=DMNOTIFY, -

PARM=(‘FAIL’,&DSN1)) -

PNODE

EIF

EXIT /+ /* /& * $$ EOJ

上例的要点描述如下：

COPY01：将 VSE LIST QUEUE 中 CLASS=A,QUEUE 名字为&DSN1 的作业输出结果，经由 C:D 下传

到开放平台 C:D 节点名为 CDWIN 的&DSN2 中。如果传输成功，则经由 DISP=D 这个参数，自动删除

LIST QUEUE 中的相应内容。

RTCODE1：判断上一步的传输是否成功，如果成功，则执行 RTMOVE 步骤，否则执行 NOTIFY 步

骤。

RTMOVE：在传输成功的前提下，由 VSE 端远程调用开放平台上的 move.bat 批处理程序，该程序用于

校验传输的文件以及转储文件。

NOTIFY：如果判断传输不成功，则在 VSE 上调用 DMNOFITY 程序，发出 operator console 信息，告

知操作员：传输&DSN1 FAIL。

这里需要特别解释：对于文件名，我们使用了 symbolic 参数。这样，我们可以执行以下的批量程序来

同时提交多个传输任务，而使用相同的传输脚本： * $$ JOB JNM=TRANLSTQ,DISP=D,PRI=3, C

* $$ NTFY=YES, C

* $$ LDEST=*, C

* $$ CLASS=8

* $$ LST CLASS=A,DISP=D

15


// JOB TRANLSTQ

// EXEC PROC=NDMLIBS

// DLBL DMPRINT,'SYSOUT.SYS002'

// ASSGN SYS002,SYSLST

// DLBL DMMSGFL,'CDVSE32.MSG',,VSAM

// DLBL NDMX001,'CDVSE32.BITEMPF',0

// EXTENT SYS003,AB0F0E,1,0,1295,100

// ASSGN SYS003,DISK,VOL=AB0F0E,SHR

// DLBL ESTAE,'SYSOUT.SYS011',0


// DLBL RPLERRC,'SYSOUT.SYS012',0


// EXEC DMBATCH,SIZE=AUTO,PARM='YYSLY',DSPACE=2M

SIGNON USERID=(SUPERUSR,SUPERUSR) -

CASE=YES -

NODE=CDVSE25 -

NETMAP=CDVSE32.NETMAP

SUB PROC=PROCLSTQ, &DSN1=xxxxx -

&DSN2='G:\VSE25\xxxxx.TXT'





SIGNOFF

/*

/&

* $$ EOJ

通过以上的配置，在该银行购买了 5 个 sessions 的情况下，我们可以实现并行传输 5 个所需要的 LIST QUEUE，并对每个传输文件自动的进行传输、判断、校验、转储以及错误报警。对于操作人员，只需

要在工作时间检查 console 上是否有传输失败信息而采取相应的步骤，再没有其它更多的处理了。

同样，我们也可以反向完成上述的动作，即将文件从开放平台传输到主机后，自动判断成功与否并调

用主机上的作业流进行处理等一系列动作。例如在该行就使用了如下的 C:D Utility:DMRTPOWR。

POWER1 RUN TASK PNODE (PGM=DMRTPOWR,PARM=(C"R RDR,VERIFYVS"))

上述语句用于当传输成功后，调用程序 DMRTPOWR，该程序可以发出任何所需要的 POWER 命令，

此处为提交了已经存放在 READER QUEUE 中名为 VERIFYVS 的作业流，用于对上传到主机的 VSAM文件进行数据校验。

二、开放端的数据交换平台触发传输并在传输成功后调用批处理程序

目前，对于许多银行，为了进行总、分行间的各种不同类型、不同应用文件的数据传输和交换，一般

会在信息中心设置一个数据交换平台。主机下传、分行上传的文件都会经由统一的数据交换平台进行

中转，这样既保证了主机的安全性，也便于集中的监控管理。在此，我们也为大家介绍一个由数据交

换平台触发传输并完成一系列自动化处理的案例。

该菲律宾银行提出如下的要求：

16


解释如下：

1、每日各个分行上传批量文件到数据交换平台，该交换平台上的 C:D 监控到指定目录中有文件

存在后，自动触发 PROCESS 上传该文件到 VSE 主机 VSAM 文件中。

2、当交换平台判断上传成功后，调用交换平台上的批程序将文件转储，以便腾空接收目录，用

于第二天使用。

3、交换平台自动触发主机 VSE 上的校验程序对上传文件进行处理。

4、判断主机校验程序成功后，交换平台触发 PROCESS 将校验程序的执行结果从主机 LIST

QUEUE 中取回到交换平台并保存备查。

5、对每一次的不成功处理，将发送信息给交换平台的操作员以提示加以处理。

对应于上述的需求，我们在交换平台上编写了如下的 PORCESS 脚本： /*BEGIN_REQUESTER_COMMENTS

$PNODE$="CDWIN" $PNODE_OS$="Windows"

$SNODE$="CDVSE25" $SNODE_OS$="VSE"

$OPTIONS$="WDOS"

END_REQUESTER_COMMENTS*/

PROC01 PROCESS

SNODE=CDVSE25

PUSH COPY

FROM (

FILE=G:\AAAA\BB\CCC\CAAT017.TXT

SYSOPTS="strip.blanks(no)"

)

TO (

FILE=AAAA.BB.ACCT.DDDD

17


DISP=(RPL,KEEP)

DCB=(DSORG=VSAM)

LABEL=( AAAA.BB.ACCT.DDDD.FILE,,,,)

VSAMCAT=(AAAAAA.USER.CATALOG,1,1,,111)

)

/*TRANSFER CAAT017 TO CDVSE < AAAA.BB.ACCT.DDDD>

<AB2DD9> <VSAM>*/

RTCODE IF (PUSH NE 0) THEN

NOTIFY4 RUN TASK PNODE (PGM=Windows)

SYSOPTS="cmd (net send 10.1.4.106 caat017 file transfer failed check logs)

cmd (net send 10.1.4.9 caat017 file transfer failed check logs)"

EXIT

ELSE

RTMOVE RUN TASK PNODE (PGM=Windows)

SYSOPTS="pgm (c:\movecabat\movecaat017.bat) desktop(yes)"

RUNJCL RUN TASK SNODE (PGM=DMRTPOWR)

SYSOPTS="'R RDR,CAAT017'"

EIF

IF (RUNJCL GT 8) THEN


SYSOPTS="cmd (net send 10.1.4.106 run task failed check logs)

cmd (net send 10.1.4.9 run task failed check logs)"

EXIT

ELSE

DELAY RUN TASK PNODE (PGM=Windows)

SYSOPTS="pgm (c:\call.bat) desktop(yes)"

PULL2 COPY

FROM (

FILE=CAAT017

SNODE

DISP=(SHR,DELETE)

SYSOPTS="LST=(CC=NOCC,CLASS=S,DISP=D)"

)

TO (

FILE=g:\sacarep\caat017.doc

PNODE

DISP=RPL

SYSOPTS="datatype(text)strip.blanks(no)"

)

RTCODE2 IF (PULL2 NE 0) THEN


SYSOPTS="cmd (net send 10.1.4.106 caat017 file transfer failed check logs)

cmd (net send 10.1.4.9 caat017 file transfer failed check logs)"

EIF

18


EIF

PEND

解释上述的各步：

PUSH：传输文件 G:\AAAA\BB\CCC\CAAT017.TXT 到主机的 VSAM 文件 AAAA.BB.ACCT.DDDD中。

RTCODE：判断传输是否成功，如不成功则在交换平台上执行命令，发送信息提示操作员，如成功则

执行下一步。

RTMOVE：执行交换平台上的程序 c:\movecabat\movecaat017.bat 将文件转储，腾空目录用以第二天接

收新文件。

RUNJCL：执行主机端 C:D 的 Utility DMRTPOWR,用以发出 POWER 命令，自动提交 READER QUEUE 中的作业流 CAAT017，执行上传文件的数据校验。

NOTIFY1：判断校验程序是否成功，如不成功，则执行命令发送信息提示操作员，如成功则执行下一

步。

PULL2：将校验程序的执行结果 CAAT017 从主机的 LIST QUEUE 中取回到交换平台上保存。

RTCODE2：判断传输是否成功，如不成功则在交换平台上执行命令发送信息提示操作员，如成功则结

束。

从上例中，我们可以看到，不论文件位于主机或是交换平台，所有的自动触发完全由交换平台发起，

并终保存处理后的文件。这样，如果分行需要，则自行从交换平台上取用即可。主机端仅同交换平

台建立 C:D 连接，并由 C:D 保证传输两端的身份确认。这样处理的好处是：对于处于中心防火墙内部

的主机和交换平台，其安全处理，比如加密、身份识别等，可以根据需要来设置是否启用。

从以上两个实例中，我们可以看到 C:D 的使用除了数据传输功能之外，更多的是解决了该行的传输中

以及传输后的自动处理动作，不但提高了总体的传输效率，而且自动化的受控传输更安全，减少人工

干预引起的失误。

由于篇幅所限，不可能在此讨论所有的实例。我们更多的是希望与大家分享一种数据传输的新解决方

案，而不拘泥于细致地分析每个传输参数的含义。虽然，该案例的实施是在 VSE 环境上，但是其传输

的实现方式、解决方案与 z/OS 上的 C:D 实施是一致的，区别仅在于使用参数的不同。当然，对于更为

先进的 z/OS 系统，C:D 在其之上所提供的安全性，数据加密能力，主机端传输处理的交互式界面，以

及配合监控传输的，基于开放平台上的 Web 友好界面等功能，都是 VSE 平台所无法比拟的。因此，应

该说，C:D 在 z/OS 平台上实现的功能会更为强大。

图片为笔者与该银行工作人员的合影

19


XMS 与 ASN-and-LX Reuse Facility 浅析

百硕工程师应永杰

1. 前言 XMS （Synchronous cross memory service) 早出现在 MVS/SP V1.2，它是一种跨地址空间（AS-address space)的同步程序调用机制。不像 SVC，XMS 不会引起中断，所以它是一种非常高效的机制。由于其

复杂性，在应用系统开发中很少采用，但在 z/OS 内部及 CICS，DB2，和某些 Vendor 的产品中有广泛

应用，了解 XMS 机制有助于加深对这些软件的了解。

2. XMS 环境的建立 XMS 环境主要由 Service Provider AS(SP AS)，USER AS 和 PC routine 三部分组成。SP AS 首先向系统

申请一个 LX(LT 表的索引)，并创建一个 ET 表(ET 表的每个 entry 存放一个 PC routine 的说明)，然后把

ET 表连接到 LT 表中 LX 对应的 entry 上，这样 USER AS 在获得 PC number(由 LT 表的索引和 ET 表的

索引组成)后就可以通过 PC 指令来调用 SP 提供的服务(即 PC routine)。XMS 环境的建立可用下图来说

明：

20


建立 XMS 环境相关的宏和指令在<<MVS Programming Extended Addressability Guide >>中有详细介

绍，本文不再赘述。

建立好 XMS 环境后，SP AS 还需要通过之前协商好的方法把 PC number 等信息传递给 USER AS。如果

专门定义了 subsystem，则 SSVT 是很好的选择，否则 name/token 机制也是不错的传递方法。

对于 system LX，一般由 SP AS 来把 ET 表连接到 LT 中，USER AS 不需要设置，该 ET 表上的 PC routine 对任何 AS 有效；对于 non-system LX，USER AS 需要通过 ETCON 宏把 ET 表连接到自己的 LT表，但执行 ETCON 需要 Supervisor state 或 PKM=0-7，这对于在 problem state 运行的 USER 程序将是

个棘手的问题。一种可行的方法是：SP AS 再申请一个额外的 system LX，并连接一个在 Supervisor state 运行的 PC_cp，这样 USER AS 不需要设置就可以调用该 PC_cp，由 PC_cp 来做一些 RACF 权限检

查等工作，检查通过后再把 ET 表连接到 non-system LX。通过 PC routine 提升 problem 程序权限是除

SVC 外的另一种有效方法，而且这种方法并不会造成 ASID 的损失。

PC routine 定义时，如果指定 SSWITCH=YES，则该 PC routine 是 space switch PC routine(PC_ss)，它运

行时将把 SP AS 作为 PASN；如果指定 SSWITCH=NO，则它将把 USER AS 作为 PASN(PC_cp)。需要

注意的是无论那种运行方式，PC routine 都执行在调用者 USER 的 TCB 下，因而它注定是一种同步的

调用方式。

PC_cp 同时意味着 PC routine 必须驻留在 nucleus 或 LPA 中，或在 SP AS 中通过宏 LOAD GLOBAL=(YES)装入 CSA 中。注意：无论在哪种 ASCMODE 下，系统始终是从 Primary AS 中读取执

行指令，PC_cp 说明 PC routine 将把 USER AS 作为 PASN，如果 PC routine 驻留在 SP AS 的 private storage 中，系统将无法读取到执行指令。

对于 PC_ss，则 PC routine 可以驻留在 SP AS 的 private storage 中，但为了保证 PC routine 驻留在内存

中，SP AS 必须设成 nonswappable，否则调用者 USER 将被导致 0D5 abend。有两种方式可以把 address spaces 设置为 nonswappable：

1.在 SCHEDxx 中通过 PPT 表中定义：

21


PPT PGMNAME(service provider)

NOSWAP

2.在 service provider 程序中通过 SYSEVENT 宏：

SYSEVENT TRANSWAP，ENTRY=BRANCH.

PC routine 开始执行时，一个很大的不同是 R15 中存放的并不是 PC routine 的 EPA，所以必须通过

BASR 指令来建立基址。 R4 指向 PC routine 定义时指定的 latent parameter ，R1 则是 USER 传入的参

数。由于 PC 指令执行时可能会引起 spaces switch，所以当 PC routine 指定了 ASCMODE=AR 时，要特

别注意 ALET 的设置，基址对应的 AR 必须置为 0， latent parameter 对应的 AR4 必须置为 0，对于

SASN=OLD 的 PC_ss，如果传入 ALET 为 0，在使用前必须转换成 1。在 PC routine 通过 TESTART 宏

对 USER 传入的参数及 EAX 做必要的检查是良好的编程习惯，程序片断如下：

SLR 5,5

ESTA 4,5 ;从linkage stack中取出EAX等信息

EREG 1,1 ;从linkage stack中取出GR1和AR1

TESTART ALET=(1),EAX=(5)

SELECT

WHEN (C,R15,EQ,=F'0')

LA 0,1

SAR 1,0 ;由于spaces switch ALET 0需要调整为1

WHEN (C,R15,EQ,=F'4')

This ALET is valid for use

OTHRWISE

This ALET is invalid

ENDSEL

另外要注意 AR ASCMODE 下编程时要严格区分基址寄存器和索引寄存器，例如以下两条指令在

Primary ASCMODE 下作用相同。但在 AR ASCMODE 下，第一条指令中 R3 是索引寄存器，所以 AR3不起作用，在第二条指令中，R3 是基址寄存器，所以 AR3 起作用。

ST R2，0(R3) ;AR 3 not used

ST R2，0(，R3) ;AR 3 is used

Stacking PC routine 比 basic PC routine 更为方便高效，是 IBM 推荐使用的，具有如下优点：系统自动在linkage stack中保存和恢复程序运行环境，不需要额外的程序编码来完成。 PC routine获得控制权后可以在Primary ASC模式下运行，也可以在AR ASC模式下运行。可以指定SASN等于user AS或SP AS。可以为PC routine指定recovery routine(ARR)。可以指定PC routine运行的PSW key，可以灵活调整PKM。

PC routine定义时有很多的参数可用来指定每个PC routine的不同行为和权限： EK：指定stacking PC routine执行时的PSW-key。 AKM：如果USER程序运行在problem state，AKM可用来控制USER是否有权限调用该PC

routine。USER程序的PKM和PC routine中定义的AKM做AND运算，如果结果不为“0”则允许

USER调用PC routine，否则将导致一个privileged operation exception。 EKM和PKM：当PKM=OR时，USER的PKM和PC routine定义的EKM做OR运算，结果作为PC

routin运行的PKM；当PKM=REPLACE时，EKM值作为PC routine运行的PKM。这样PC routine运行时就可以拥有和USER不同的PKM。

EAX：不同于AX，EAX只在PC routine执行时有效，在stacking PC执行前，系统会把该EAX 装入CR 8，在执行PR指令退出PC routine时，CR 8恢复原来的值。在ART(Access-Register

22


Translation)模式翻译地址过程，当访问一个private access list时，该值将首先被用来与

ALEAX(access-list-entry authorization index)进行核对，若相等则允许访问，否则进一步核对AT表EAX对应的S-bit是否为“ON”，如果是ON则允许访问。而AX值则会装入到CR 4中，用于

ASN-Authorization。

3. XMS 相关的 Control Block

XMS 涉及到很多 table 和 index，table 主要是一些 control block 或数据结构，如 LT、ET、AT；index 主

要用来指定在 table 中的入口位置，如 LX、EX 等。搞清这些 table 和 index 关系对理解 XMS 机制至关

重要。

23


24


XMS涉及的大部分control block都驻留在PCAUTH AS的private storage中，唯一例外的是SFT表(system function table)，它驻留在common storage中。z/OS的许多服务实际上都是以PC routine的方式提供，例

如常用的ENQ/DEQ等。SFT是很多PC number的集合，对应系统提供的一组服务，可以在《MVS Diagnosis Reference》中查到每个PC number对应的具体服务。XMS相关的宏，如LXRES、ETCON等实

际上也都是通过调用PCAUTH提供的PC routine来实现的。 AX和LX是XMS中的重要资源，必须要先申请才能使用，系统在LXAT和AXAT中记录了LX和AX的分

配情况。整个系统中还存在一个SAT(system authority table)表和一个SLT表(system linkage table)，LX resue facility enable时，则SLT表拆分为SLFT(System Linkage First Table)和SLST(Ssyetem Linkage Second Table)。 AS创建初始时，ASTE和ASCB中的AT origin都是指向SAT，在AS中通过ATSET宏设置不同的AT值时，系统才会为该AS单独分配一个AT表，并把ASTE和ASCB中的AT origin指向这个新分配的AT表。

AT表是由P-bit和S-bit组成的数组结构，P-bit控制是否允许其它AS把自己设置为PASN，S-bit控制是否

允许其它AS把自己设为SASN。AT表的前4个bit通常都是B’0011’，所以AX 0和AX 1在系统里有特殊的

含义，AX 1意味着有权限把任何AS设为PASN或SASN，AX 0则意味着不能把其它AS设为PASN或

SASN。不能通过ATSET宏来修改AT表的前4个bit，如果传给ATSET宏的AX为0或1将导致一个S052 abend。 AT和AX的关系就象锁和钥匙的关系。AT表相当于房子前一排大门上的锁，AX相当于某扇门的钥匙，

如果要想进入大门，客人必须先向系统申请一把钥匙(即AX)，房主把AX对应的那扇门上的锁置成1，这样房主就可以允许持有钥匙的客人进入房子。如果房主把AX对应的那扇门上的锁置成0，则相当于

从房子里面反锁了大门，即使持有钥匙者也无法从这扇门进入。系统的AXAT表会记录AX的分配以保

证一个AX分配后在收回前不会被重复分配。 AS创建初始，ASTE和ASCB中的LT origin都是指向SLT的，当一个AS需要把ET表连接到一个non system LX时，系统才会为这个AS创建一个单独的LT表，并把ASTE和ASCB中的LT origin指向新分配

的LT表，连接到该LT表上的PC routine只对本AS有效。对于system LX，ET表通常是连接到SLT(或SLST)上的，所以PC routine将对系统中所有的AS有效，包括以后将要创建的AS，系统中所有的ET表通

过ETIB结构串在一起的。作为PC指令输入参数的PC number由LFX，LSX和EX组成，根据ASTE中的LFT origin和PC number中的

LFX，可以定位找到LST origin。同理，LST origin加上PC number中的LSX可以定位找到ET origin，ET origin加上PC number中的EX可以定位找到ETE(entry table entry)。一个PC routine对应一个ETE，PC routine 定义时指定的参数终都保存在 ETE 中。 PC-Number Translation 更详细的信息可参考

<<z/Architecture principles of operation>>。ASTE中的ATO和LTO都是real address，为方便起见，系统在

ASCB中以virtual address的形式另外记录了ATO和LTO的地址。 4. ASN-and-LX Reuse Facility XMS 编程中令人头疼的莫过于LX和ASID的重用问题。程序员必须牢记那些情况下会形成“dormant LX”和”lost ASID”。在引入了ASN-and-LX Reuse facility之前，有可能出现以下几种情况，考虑相互调

用关系，实际情况会变得更加复杂： System LX：在整个IPL期间不能重新分配使用。 Non-system LX：当所有USER AS终止或通过ETDIS断开连接，并且SP AS终止或通过LXFRE

释放该Non-system LX后，系统才会重新分配使用该LX。当SP AS的ET上含有PC_ss，并且该ET表连接到一个system LX，则该SP AS终止后，对应的

ASID在整个IPL期间不能重新分配使用。当SP AS的ET上含有PC_ss，并且该ET表通过non-system LX连接到其它AS的LT表，则该SP AS

终止后，对应的ASID不可重新分配使用，直到建立连接的所有USER AS也都全部被终止。

25


IBM 不重用 ASID 和 LX 的目的是出于系统完整性的考虑，防止“偷梁换柱”。考虑以下情形：如果

SP AS 1 申请一个 system LX，并通过 ET 表把 PC routine 1 连接到该 system LX，然后把 PC number 1 传

给了 USER 1，此时 SP AS 1 终止，系统把该 LX 重新分配给了 SP AS 2，SP AS 2 通过 ET 表把 PC routine 2 连接到该 system LX，那么 USER 1 通过 PC 将会把控制传给 PC routine 2，对于 PC_ss，该 PC routine 将在 SP AS 2 上执行，这将带来严重的系统完整性问题，所以 SP AS 1 终止后，系统在整个 IPL期间不会把该 system LX 重新分配给任何 AS。系统共拥有 32768 个 12 bit 的 LX，其中的 System LX 的个数在 IEASYSxx 中通过 NSYSLX 参数指定，

其余为 non-system LX。由于 system LX 个数是有限的，对于 non-reusable LX，程序员有责任在第一次

申请 SP AS 后记录该 system LX，在 SP AS 终止后，再重新启动时，直接读取先前记录的 system LX，

而不是重新申请新的 system LX。在 z/OS V1.6 引入 LX-Reuse facility 的概念后，LX 分为 12 bit 和 24 bit两种，其中 24 位的 LX 又分为 reusable LX 和 non-reusable LX。12 位 LX 和 24 位 non-reusable LX 的重

用原则和以前相同。对于 24 位 reusable LX，只要 SP AS 终止或通过 LXFRE 释放后，系统马上可以重

新分配使用。那么系统是如何保证安全重用该 LX 的，首先原来的 LT(linkage table)拆分成了

LFT(linkage first table)和 LST(linkage second table)，在 LST 中保存了 LSTESN(linkage second table entry sequence number)。每次系统重新分配一个 reusable LX 给请求者时，LSTESN 将会加 1， SP AS 必须把

该 LSTESN 和 PC number 一起传给 USER，USER 在通过 PC 指令调用 PC routine 时，必须通过 LMH指令把得到的 LSTESN 装入 R15 的高位(bit 0-31)。如果 PC 指令传入的 LSTESN 和 LST 表不一致，将

导致 LSTE sequence exception(002E)。系统通过 LX 加上 LSTESN 的唯一性来保证完整性。在 z/OS V1.6 的 LOADxx 中，系统增加了 LXREUSE 参数来决定是否启用 LX reuse facility。由于 XMS 绑定而导致 ASID 无法重新分配使用，系统一般会给出 IEF352I 信息。例如 CICSPlex CAS终止时出现如下的信息，使用 reusable ASID 可以避免 ASID 损耗。

JOB00069 IEF404I EYUJCS1A - ENDED - TIME=14.19.38

JOB00069 IEF352I ADDRESS SPACE UNAVAILABLE

JOB00069 �HASP395 EYUJCS1A ENDED

我们来设想一下 ASID 重用带来的问题，SP AS 的 ET 表含有 PC_ss，意味着其它 AS 可以在 SP AS 上

执行 PC_ss routine，重用该 SP AS 的 ASID 潜在的威胁是 PC_ss routine 将有可能会在重用该 ASID 的

AS 上执行。假设 SP AS 1 申请了一个 system LX，并把 ET 表连接到该 system LX，USER 1 通过 PC 指令就可以在 SP AS 1 上执行 PC_ss routine，在该 PC_ss 处于 suspension 时，如果 SP AS 1 终止，系统把

SP AS 1 的 ASID 重新分配给了 AS 2，那么当该 PC_ss 被 redispatch 时，它将会在 AS 2 上执行而导致系

统完整性问题。即使 SP AS 终止时通过 ETDES PURGE=YES 清除掉 ET 表也只能阻止随后的 PC 调用

而已，为防止出现类似的系统完整性问题，系统在整个 IPL 期间不会重新分配 SP AS 1 的 ASID 给任何

AS。为避免出现 ASID 耗尽而导致的 reIPL，除了编程上尽量避免造成 ASID 丢失的情形出现外，还可

以通过在 IEASYSxx 中设置合理的 RSVNONR 和 RSVSTRT 参数来缓解。在 z/OS V1.9 之后，IBM 开

始引入 ASN-Resue facility， DIAGxx 中新增了参数 REUSASID，当该参数设定为 REUSASID(YES)时系统提供了一种 ASID 重用机制。 ASN-Resue facility enable 后，系统把 ASID 分成两类：ordinary ASID 和 reusable ASID，初始时所有

ASID 都是 ordinary ASID。当用 start 命令启动一个地址空间（AS），同时指定了 REUSASID=YES 参

数，或通过宏 ASCRE 创建 address spaces 并指定了 ATTR=REUSASID 参数时，该 ASID 开始成为并永

远是 reusable ASID。对于上述两种创建 AS 的请求，系统会首先分配 reusable ASID，如果系统中没有

reusable ASID，则会把 ordinary ASID 转换成 reusable ASID 再分配，此后该 ASID 永久成为 reusable ASID。 Ordinary ASID 的重用限制与以前相同。对于 reusable ASID 终止后可以马上重新分配，系统通过

ASTEIN(address spaces second table entry instance number)来保证系统一致性，ASTEIN 位于在 ASTE 表

26


中。在引入 ASN-reuse facility 之前，当一个 dispatchable unit-of-work 被 suspend 时，系统只会保存

PASN 和 SASN。当该 dispatchable unit-of-work 被再调度时，LASP 指令只会恢复 PASN 和 SASN，实

际上很难保证恢复的 PASN 和 SASN 就是 suspend 前的 AS。当 ASN-reuse enable 时，系统除了保存

PASN 和 SASN，还会保存 PASTEIN 和 SASTEIN，unit-of-work 被再调度时，系统会把保存的 instance number 和 ASN 一起作为参数传给 LASP 指令，LASP 指令会根据 PASN 找到 PASTE 表，并把传入的

PASTEIN 和 PASTE 表中的 ASTEIN 作比较，如果不一致将导致 program check。SASN 也会做同样的

检查.，这样就不会出现上例中的完整性问题。当然ASN-reuse facility提供的完整性保护并不止LASP指令。stacking PC执行前，在linkage stack中还保

存PASTEIN和SASTEIN，通过PR指令返回时，PASTEIN和SASTEIN会被核对，确保PR指令返回正确

的AS。对于reuse ASID，SSAR和PT指令被SSAIR和PTI取代，继续使用SSAR或PT指令将出现Special-operation exception(0013)，并终导致0D3 abend。当需要把一个可重用的ASID设置为SASN时，必须

用SSAIR指令。对于SSAIR_ss(space switch)，目标地址空间和PASID不同时，系统会把SSAIR指令中指

定的ASTEIN(在寄存器高位-bit 0-31)和目标地址空间ASCTE里的ASTEIN作比较，如果不匹配将会出现

instance Exception(002F)。同理，当需要把一个可重用的ASID设置为PASN，必须用PTI指令而不是

PT。对于PTI_ss(space switch)，目标地址空间和PASID不同时，系统会把PTI指令中指定的ASTEIN(在寄存器高位 -bit 0-31)和目标地址空间ASCTE里的ASTEIN作比较，如果不匹配将会出现 instance Exception（002F）。系统通过ASN加上ASTEIN的唯一性，来保证重用ASID后，系统的一致性不会被

破坏。要启用一个usable ASID，需要检查相应的程序是否符合以上规则，特别要注意SYSSTATE OSREL=ZOSV1R6会影响一些宏的展开结果，很多宏展开后会含有SSAR和PT指令，要小心检查。除了 ASTEIN 外，在 ASTE 表中还存在一个 ASTESN（ASN-Second-Table-Entry Sequence Number），

ASTESN 的作用完全不同于 ASTEIN，它和 ALET 相关联。在 ART 过程中，ALE 中保存的 ASTESN 和

目标地址空间 ASTE 中的 ASTESN 必须匹配。当一个 AS 被其它 AS 通过 ALE 访问时，可以通过重置

ASTE 中的 ASTESN 使先前建立的 access list entry 失效，所以 ASTESN 经常被用来作为一个开关来使

用。当 LX-and-ASN Reuse facility enable 时，CVT 中的 CVTFLAG2 栏位中的第 7 个 bit 将置为 ON(“1”)，程

序可以根据该 bit 来判断。在 hercules 上也对应出现了一个新的参数 ALRF，决定是否提供 LX-and-ASN Reuse facility 仿真。

5. 如何确定当前系统中存在的 XMS 连接后我们来看看如何确定系统中当前存在的 XMS 连接。在 PCAUTH 的 private storage 中保存了 XMS

相关的很多信息，不幸的是<<MVS data areas>>和<< z/Architecture Reference Summary>>中并没有提供

某些 control block 的说明，幸运的是在 APAR II08563 中，IBM 对如何确定系统中存在的 XMS 连接作

了些简单的说明。

27


根据上图，我们可以通过程序来扫描 ASVT 表的每个 ASVT entry，如果该 entry 的高位为 0，说明该

entry 已经被分配，此时该 entry 指向一个 ASCB，通过 ASCB 中 ASCBASSB 可以找到对应 ASSB，ASSB 的 ASSBXMSE 指向该地址空间所对应的 XMSE 结构。XMSE 结构中保存了拥有者的 JOBNAME和 HOME ASID 等信息，XMSE 偏移 x04 指向 SETC。如果该 SETC 的偏移 x06 处 bit 0 等于 0，则表示

本 AS 有 ET 表连接到 system LX。SETC 偏移 x14 和 x16 分别记录了 TO connection(本 AS 把 ET 表连接

到其它 AS 的 LX 上)和 FROM connection(其它 AS 把 ET 表连接到本 AS 的 LX 上)两个方向的连接个

数，SETC 中偏移 x20 开始的地址数组记录了连接对方的 XMSE 结构，每一个连接在该数组中占有一

个地址，如果地址低位(bit 31)是 1 说明该地址没有被使用，地址高位(bit0)表示连接方向：1 表示是 TO connection，0 是 FROM connection。这样我们就很容易通过程序来得到系统中存在的 XMS 连接。需要

28


引起注意的是，由于 XMSE 和 SETC 都驻留在 PCAUTH 的 private storage，我们需要一种机制来访问

PCAUTH 的虚存地址，一个简便的做法是可以通过 SSAR 指令把 SASN 设为 PCAUTH(ASID 2)，再通

过 SAC 512 指令切换到 AR 模式来实现，当然在使用 SSAR 之前，必须把 AX 的设成 1，以便有权限执

行 SSAR 指令。相应程序片断示例如下： MODESET MODE=SUP,KEY=ZERO AXSET AX=H’1’ LH R4,=xl2’0002’ ;PCAUTH ASID

SSAR R4 SAC 512

...... EPAR R2 SSAR R2 SAC 0 AXSET AX==H’0’

MODESET MODE=PROB,KEY=NZERO 由于XMSE之间是通过双向指针连接在一起的，所以另一种更方便的办法是通过SVT找到XMD，通过

XMD找到第一个XMSE，再通过XMSE之间的指针遍历所有XMSE，同样可以找出系统中的XMS连接。一些免费的System Information Tools都提供了此功能，例如，在WWW.CBTTAPE.ORG网页上我们

可下载两个非常知名的免费工具：Rob的XMI和Gilbert&Roland的SHOWMVS。

6. 参考资料 <<z/Architecture principles of operation>> <<MVS Programming Authorized Assembler Services Reference>> <<MVS Programming Extended Addressability Guide>> <<z/Architecture Reference Summary>> <<MVS Diagnosis Reference>> <<MVS data areas>>

29

http://www.cbttape.org/


z/OS 中的 APF 机制

百硕工程师罗兴魁前言

APF AUTHORIZED 的程序库毫无疑问是 z/OS 中为重要的库文件之一，一向是安全控管的重点，本

文将对该机制作一些深入的探讨。

什么是 APF(Authorized Program Facility)？ z/OS 提供 APF 机制标示出 authorized 的程序库，APF LIST 通常是在 PARMLIB 的成员 PROGxx 中指定

的，语法如下所示： APF FORMAT(DYNAMIC)

APF ADD

DSNAME(dsname)

SMS | VOLUME(volname)

APF ADD

………….

相对于在 IEAAPFxx 中定义 APF LIST 来说，这里得到的是动态 APF LIST，可以在系统运行期间对其

中的库文件列表进行动态添加和删除： SETPROG APF,ADD|DELETE,DSNAME=SYS1.DSSET.LOG,SMS

除了明确指定的这些库，系统在 IPL 时会自动把以下两个库添加到 APF LIST 中： SYS1.LINKLIB

SYS1.SVCLIB

可以用如下命令来显示当前系统的 APF LIST： D PROG,APF

另外还有两处需要引起注意： 1. LNKLST 中的库，默认情况下，当作为 LNKLST 的一部分被访问时，系统认为该库是 APF-

AUTHORIZED。如果是通过 JOBLIB 或者 STEPLIB 被访问，则不认为是 APF-AUTHORIZED。可以修改 IEASYSxx 中的如下语句来关闭或打开该特性： LNKAUTH=（LNKLST|APFTAB）

2. LPA(包括 PLPA,MLPA,DLPA)中的 Module，系统认为其来自一个 APF-AUTHORIZED 库。 APF-AUTHORIZED 库有何不同

要理解这个问题，我们需要先回顾 z/OS 中，关于运行时状态为 authorized 的定义。

简单说，当程序运行时满足以下三种条件中任意一种，即被认为是 authorized： 1. 处理器(Processor)处于 Supervisor 状态。 2. 处理器的 Access Key 为 0-7。 3. 程序运行在一个 JSCBAUTH 为“ON”的 Job Step TCB 下。

条件 1 和 2 都与 PSW 有关，PSW 的相应 bit 的值决定了处理器是在 Supervisor State 还是 Problem State，以及 Access Key 是多少。

对于硬件来说，当处理器处于 Supervisor State，它可以执行任何指令，包括普通指令，半特权指令和

特权指令；而处理器的 Access Key 如果是 0，它可以读写绝大部分的 Real Storage。（z/Architecture 中

30


对 Storage 的保护一共有四种机制，即 Key-controlled Protection， Page-protection，Low-address Protection 和 Access List Protection。对一个 Frame 的读写必须同时满足以上四种保护机制的条件才能成

功，而 Access Key 为 0 可以彻底 Bypass 掉 Key-controlled Protection，因此也就可以读写大部分的

Frame。）

条件 3 比较特殊，对硬件来说并没有直接意义，是一个只有 z/OS 才能识别的状态。Job Step TCB 的精

确定义是指在 ATTACH 的时候用 JSTCB=YES 参数来生成的 TCB.。考虑到 IBM 一直没有把生成一个

完整的 Job Step TCB 的接口公开（创建 Job Step TCB 并非只在 ATTACH 的时候用 JSTCB=YES 就可

以），我们可以从另外一个角度来理解 z/OS 中的 Job Step TCB： //S1 EXEC PGM=MYPROG

这个 procedure，无论是作为一个批量提交，还是作为一个 Started Task 提交，虽然在 AS（Address Space）内部的 Task Tree 不完全一样（作为批量提交时，AS 内会多一个 Iinitiator 的 TCB），但是

MYPROG 所运行的那个 TCB，都是一个 Job Step TCB。

在这个 Job Step TCB 下的所有 TCB，都属于该 Job Step TCB。首先，每个 TCB 的 TCBJSTCB 都指向

该 TCB 所属的 Job Step TCB，对于 Job Step TCB 而言，TCBJSTCB 指向它自己；其次，整个 STEP 中

的所有 TCB 都共享一些 STEP 级别的资源，比如 JPA(Job Pack Area)，TIOT（Task Input-Output Table）和我们下面要介绍的 JSCB(Job Step Control Block)。

在 JSCB 中有一个 FLAG，即 JSCBAUTH，当这个 FLAG 被打开时，z/OS 会认为整个 STEP 都处于

authorized 状态，这就是条件 3 的含义。

既然条件 3 在硬件层面不具有实际意义，那我们为什么还说满足条件 3 也可以被称作 authorized？这是

因为，authorized 不仅是一个硬件层面的概念，还包括 z/OS 层面： z/OS 提供了大量的需要 Authorized 才能使用的 Service。当某个 Service 被调用时，z/OS 会检查 Caller的状态是否满足条件 1-3 中的一种或多种

以常用的 GETMAIN 为例： 1. 如果申请的 Subpool 不是 0-127，131 和 132，要求 Caller 满足条件 1-3 中的任意一种。 2. 如果要使用 GETMAIN 的 Branch-entry 展开形式，则要求 Caller 必须同时满足条件 1 和条件 2

（Access Key 为 0）。

这时我们会注意到一个问题，前面提到满足条件 1-3 中的任意一个都被认为是 Authorized，可从

GETMAIN 的例子中却可以发现三个条件带来的 Authorized 的程度是不一样的，比如，即使 STEP 的

JSCBAUTH 已经打开（满足条件 3），caller 依然无法使用 GETMAIN 的 Branch-entry 形式，因为要求

caller 同时满足条件 1 和 2。这是因为，在 z/OS 中，当满足三种条件中的任意一种，实际上你已经可以

获得其它两种条件要求的状态： 1. Supervisor State

此时可以用半特权指令 SPKA 来切换到 Access Key 0-7（条件 2）；然后直接找到 JSCB，手

动把 JSCBAUTH 打开（条件 3），因为在 Access Key 为 0 时，是可以修改 JSCB 的。 2. Access key 0-7

此时可以用 MODESET 这个宏来切换到 Supervisor State（条件 1），同样 JSCBAUTH 也可以

手动打开（条件 3）。 3. STEP 的 JSCBAUTH 已经打开

此时同样先用 MODESET 切换到 Supervisor State（条件 1），然后 SPKA 到 Access Key0-7（条件 2）。

31


既然满足这三种条件的任意一种从本质上来说都是一样的，为什么 z/OS 的各种 Service，在要求 Caller满足的 Authorized 状态时，要对这三种条件加以区分？

答案就是，为了保护系统的完整性（Integrity）。

一旦某支程序进入 Auothorized 状态，它就是机器的一个组成部分，能够阻止它做事情的只有它自己，

它可以绕过任何安全产品的限制，破坏一切 z/OS 世界中已经建立起来的规则。

因此，对于这样的程序，要求编写者有极强的自律，而且也只能靠自律，在 SHARE session 2889 中，

IBM 的 Karl Schmitz 做过一场题为<z/OS System Integrity: Authorized Software without Security Holes>的讲座，讲述的就是这个问题。

回到前面的问题，如果程序只需要 Supervisor State 就可以实现想要的功能，为什么要把 access key 切换

到 0？在 Access Key 为 0 下，程序出错而导致内存覆盖的几率会大大增加。作为一个严谨的开发者，

应该只获取必要的权限-即使你有能力获得更高权限。这也解释了为什么 z/OS 会对各种 Authorized 的状

态加以区分。

我们已经了解到了运行在 Authorized 状态下程序对系统的深远影响，很明显，z/OS 需要提供一种准入

机制，对可以进入这种状态的程序做严格控管，这就是 APF(Authorized Program Facility)。

APF 在 z/OS 中的作用

一言以蔽之，APF 为系统程序员提供了这样一种机制：只有经过严格审查的程序才会被放到 APF-授权

程序库中，而只有存放在这种授权库中的程序，才有可能运行在 Authorized 状态下。

下面会以两个例子来说明 APF 是如何发挥其作用的： 1. 写在 JCL 的 EXEC 语句中的程序 //S1 EXEC PGM=MYPROG

如前所述，MYPROG 会运行在一个 Job Step TCB 下，系统在 ATTACH 这个 TCB 的时候，使用了参数

RSAPF=YES，系统将会作如下检查：

1. MYPROG 是否来自一个 APF-AUTHORIZED 的程序库？

2. MYPROG 在 LINK/BIND 的时候，是否设置了 AC CODE 为 1？

如果两个条件都满足，系统会将这个 STEP 的 JSCBAUTH 打开，即整个 STEP 将处于 AUTHORIZED状态。

此处有两点需要注意。首先 JSCBAUTH 如果打开，影响的是整个 STEP。这种‘全局性’是

JSCBAUTH 的重要特点，以 TSO 用户地址空间为例，用户需要在这个 AS 中既能执行普通程序，又能

执行 Authorized 的程序.。为实现这一功能，TSO 用户地址空间中的 TCB Tree 需要额外的考虑，即分成

两个分支： IKJEFT01

|

+-------------+

IKJEFT02 IKJEFT02

| |

IKJEFT09 AUTHPGM <- Authorized Command

|

ISPF <- Unauthorized Command

|

+--------+--------+

32


ISPTASK ISPTASK ISPTASK

Authorized 与非 Authorized 的命令（Command Processor）将在不同的 TCB Tree 下执行。以 SEND 命令

为例，它需要对 SYS1.BROADCAST 这个数据集执行写操作。但通常情况下，普通的 TSO 用户不会在

RACF 中拥有这样的权限，显然，SEND 命令需要运行在 authorized 状态下。

首先该命令需要被加入到 PARMLIB 的 AUTHCMD 的 LIST 中，然后 TMP(Terminal Monitor Program)会设置 RSAPF=YES 参数来 ATTACH 这个命令。如果该命令所在的库是 APF-AUTHORIZED，同时

MODULE 的 AC CODE 为 1，JSCBAUTH 会被打开，命令将运行在 AUTHORIZED 状态。

这里存在的问题是， JSCBAUTH 影响的是整个 STEP，已经存在的 TASK 也都会突然运行在

AUTHORIZED 状态，这对系统的完整性是一个破坏。

因此 TMP 在使用 RSAPF=YES 进行 ATTACH 之前，会先把所有的 UNAUTHORIZED 的 TCB 都停住，

一直到 AUTHORIZED 的命令执行完毕。这就可以避免产生安全上的漏洞。

另外需要注意的就是 LOAD MODULE 的 AC CODE。出于完整性的考虑，JSCBAUTH 一旦打开，随后

整个 STEP 用 MVS Service 调用的任何一支 LOAD MODULE 都必须来自 APF-授权库。但也只是检查

到这里，对那些 MODULE 的 AC CODE 并没有任何要求。事实上，只有使用 RSAPF=YES 的

ATTACH 才会检查 MODULE 的 AC CODE 是否为 1。我们如果浏览 SYS1.LINKLIB，会发现其中

MODULE 的 AC CODE，有些为 1 有些则不是，原因就在这里。 2. PPT(Program Properties Table)

在 z/OS 的 PPT 中，可以为某些 module 指定运行时的初始状态，例如： PPT PGMNAME(IEEMB860)

KEY(0)

NOCANCEL

NOSWAP

SYST

NODSI

NOPASS

IEEMB860 实际就是 MASTER JCL 中执行的那支程序，按照 PPT 中的定义，如果 JCL 的 EXEC 语句中

指定的程序名字是 IEEMB860，系统会帮它把 PSW 的 Access Key 设为 0。

那么普通的 USER 是否可以把自己的程序改名为 IEEMB860，即 PPT 进入 AUTHORZIED 状态？为了

防止此类事情发生，PPT 中的属性生效还有另外一个附加条件：名字匹配的 MODULE 还必须来自一个

APF-AUTHORIZED 的程序库。

总结

APF 作为 z/OS 中一种重要机制，是保证系统完整性和安全性的一道关卡。希望通过本文的阐述，读者

能对 APF 扮演的角色有更深入的了解，方便程序权限的设置和使用。

33


Logger 相关的问题

百硕资深工程师王晓兵

问题 1：如何修改 LogStream 的定义

解答：在使用 LogStream 的时候，如果需要修改 LogStream 的定义，可以使用 IXCMIAPU Utility 或者

IXGINVNT Services 进行修改，但如何进行 LogStream 的定义修改，取决于 LOGR CDS 的 Level。如果

使用 HBB6603 或更低级别的 LOGR CDS，LogStream 的大多数属性都不能在 LogStream 有 Connection的时候进行修改，需要将目标 LogStream 设置为 Quiesce 状态；可以随时进行修改的属性只有 RETPD和 AUTODELETE，但其修改是待之后执行新的 Offload 操作时才能生效；如果使用的 LOGR CDS Level 为 HBB7705 或更高，System Logger 允许用户在任何时间对 LogStream 的大多数属性进行修改，

但这些修改将仍会标示为“Pending Updates”，而且不同参数的修改生效时间是不同的（对于没有

Connection 的 LogStream，修改会立即生效），下表列出哪些参数可以被修改，以及相应的修改操作何

时会生效： Logstream attribute Last disconnect or first

connect to logstream in sysplex

Switch to New offload Data Set

CF Structure Rebuild

RETPD yes yes no AUTODELETE yes yes no LS_SIZE yes yes yes LS_DATACLAS yes yes yes LS_MGMTCLAS yes yes yes LS_STORCLAS yes yes yes OFFLOADRECALL yes yes yes* LOWOFFLOAD yes yes yes* HIGHOFFLOAD yes yes yes* STG_SIZE yes no yes STG_DATCLAS yes no yes STG_MGMTCLAS yes no yes STG_STORCLAS yes no yes STG_DUPLEX (CF) yes no no@ DUPLEXMODE (CF) yes no no@ LOGGERDUPLEX(CF) yes no no MAXBUFSIZE (DO) yes no n/a 说明： *: 这些属性只能是 DASD-ONLY 的 LogStream，在 Switch 新的 Offload Dataset 的时候才会生效，在该时间点，对于 CF Structure-Based 的 LogStream 不会生效。 @：这些属性在 z/OS V1R10 中，可以在 CF Structure Rebuild 时生效。

问题 2：如何处理 LogStream 的 Offload Dataset 处于 Delete Pending 的问题

解答： LogStream 的属性参数 RETPD 和 AUTODELETE 相结合，决定了 Offload 的 DataSet 是如何被执行物理

删除的，Log 数据的删除也与 Offload 处理紧密相关，当 Log Data 被 IXGDELET 标记为删除状态时，

在新的 Offload 处理执行之前，System Logger 不会对 Log Data 或 Offload Dataset 执行物理删除；正常

情况下，在新的 Offload 处理时，过期的 Offload Dataset 会被自动物理删除。当 Offload Dataset 符合被

物理删除的条件，但没有被成功删除的时候，这些 Offload Dataset 会被标示为“Delete Pending”状

态，这些信息可以从通过 IXCMIAPU 的 LIST DETAIL(YES)报告输出中得到： Ext. <SEQ#> Lowest Blockid Highest GMT Highest Local Status

34


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

�00001 A0017157 00000149DBAEBF81 04/23/08 09:17:03 04/23/08 17:17:03 DELETE PENDING

A0017158 00000149E09ABCB8 04/23/08 09:41:02 04/23/08 17:41:02 DELETED

A0017159 00000149E586BA4E 04/23/08 10:32:21 04/23/08 18:32:21 DELETED

00002 A0017160 00000149EA72BA40 04/23/08 12:17:58 04/23/08 20:17:58

A0017161 00000149EF5EBA40 04/23/08 17:15:14 04/24/08 01:15:14

如果出现“DELETE PENDING”的 Offload Dataset，后续符合被物理删除的 Offload Dataset 也将无法

被正常删除，从而形成 Offload Dataset 堆积，如果问题长时间存在，可能造成 LOGR CDS 的 Dataset Directory Extent 不足且浪费磁盘空间。

Offload Dataset 出现“DELETE PENDING”，通常的原因是由于符合物理删除的数据集在 System Logger 执行删除的时候，发现仍有应用或用户在对这些 Offload Dataset 执行 Read 操作，这时可以使用

D LOGGER 命令，检查 LogStream 的 Connection 信息： RESPONSE=BAYA

IXG601I 10.22.10 LOGGER DISPLAY 169

CONNECTION INFORMATION BY LOGSTREAM FOR SYSTEM BAYA

LOGSTREAM STRUCTURE #CONN STATUS

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

SYSV.CICSLOGR.TRAN.FOP1 *DASDONLY* 000002 IN USE

DUPLEXING: STAGING DATA SET

JOBNAME: USERAAA ASID: 004A

R/W CONN: 000001 / 000000

RES MGR./CONNECTED: *NONE* / NO

IMPORT CONNECT: NO

JOBNAME: USERBBB ASID: 0047

R/W CONN: 000000 / 000001

RES MGR./CONNECTED: *NONE* / NO

IMPORT CONNECT: NO

上面的示例可以看到目标 LogStream 分别有 Read 和 Write 的两个 Connection，此时需要对 ASID 为 4A的 Job USERAAA 进行检查，确认该 Connection 的原因，很有可能是该 Read 的 Connection 在对

Offload Dataset 进行着操作，因而造成 Offload Dataset 处于“Delete Pending”状态；如果能够确认，则

需要终止该 Connection。之后，当该 LogStream下一次执行 Offload 处理时，System Logger 会对所有过

期的数据集均执行物理删除操作。

问题 3：如何处理 LOGR CDS 的 Dataset Directory Extent 不足的问题

解答：如果 LOGR CDS 的 Dataset Directory Extent 不足，新的 Offload 处理将会失败（同时系统会发出

IXG261E 或 IXG262A 信息）；在出现此问题之后，可以采取如下步骤进行处理：

使用较大的 DSEXTENT 参数，定义两个新的 LOGR CDS。在定义之前，可以运行 IXCMIAPU 检查

当前的 CDS 定义，使用 IXCL1DSU 对新的 CDS 执行正确的格式化操作。

先将一个新的 CDS 增加为 Alternate LOGR CDS：

SETXCF COUPLE,ACOUPLE=(new_dsname_a),TYPE=LOGR

将新增加的 CDS 激活，此时只有新增加的 CDS 有效，没有 Alternate LOGR CDS：

SETXCF COUPLE,TYPE=LOGR,PSWITCH

将另一个新定义的 CDS 增加为 Alternate LOGR CDS：

SETXCF COUPLE,ACOUPLE=(new_dsname_b),TYPE=LOGR

检查 IXCMIAPU 的输出报告，检查存在过多 Offload Dataset 的原因并进行调整。

35


File transfer time reduced from 7 hours 40 minutes to 3.1 minutes Sterling Commerce Case Study

HSBC Bank Brasil S.A.

Location

São Paulo, Brazil

Industry

Financial Services

Revenues

US$2.15 trillion as of June 30, 2007

Business Challenge

To implement a new file transfer platform, thus enabling banking customers to conduct their electronic business with increased productivity, efficiency, and effectiveness

Solution

Sterling Commerce Managed File Transfer

Benefits

• Increased the number of processing times from 4 to 11, enabling customers to engage in real-time transactions

•By significantly reducing file transfer time from 7 hours 40 minutes to 3.1 minutes — regardless of file type — the new solution enabled the bank to offer customers a unique product that discounted receivables in a few minutes

•Increased bank’s productivity by supporting high data volumes

•Improved overall efficiency by delivering information to customers within a short time

Customer background

HSBC Bank Brasil S.A., a wholly-owned subsidiary of HSBC Holdings, is one of the largest financial groups in the world. Headquartered in London, HSBC Group is present in 83 countries in the Americas, Europe, Asia, Middle East, and Oceania.

Business challenge

HSBC Bank’s electronic banking service is called Connect Bank. Previously, Connect Bank’s file transfer solution was based on queuing and prioritizing, which meant all files were placed in a single queue, according to a given priority. The send/ receive process took, on average, 7 hours and 40 minutes for low-priority files.

In addition, the bank previously operated with four processing cuts (preset times to process files), and the receivables were accumulated. The former file transfer platform also showed some restricted processes and functionalities to meet market needs; high downtime risk; and an inflexible infrastructure to expand the customer base. Besides that, the return files had to be recreated manually, and customers who needed file formatting and translation were required to use other partner channels (VANs, Host-to-Host, and so on), which increased overall costs.

36


Solution

Now HSBC Bank uses Sterling Managed File TransferTM to remove the barriers of traditional file transfer protocol and improve the overall function. This solution enables the bank to manage growth and productivity because it supports high data volumes, ensures security, and offers higher levels of service.

The greatest improvement for HSBC Bank was the development of 11 processing cuts for the billing application, which, among other services, allows customers to cash checks through Connect Bank in real-time. The average time for file transfer also greatly improved. Before Sterling Managed File Transfer was in place, customer files took 7 hours and 40 minutes to process because they were queued and prioritized first. Now they take 3.1 minutes, regardless of file type.

With Sterling Managed File Transfer, hundreds of thousands of files are processed daily at HSBC Bank, more than 50 business applications are supported, and 24,000 customers exchange files with the bank efficiently and effectively.

Key benefits

In addition to developing more processing cuts and greatly reducing file transfer time, Sterling Managed File Transfer also:

• Provided unmatched data security

• Improved customer satisfaction

• Increased agility

• Enabled successful growth management

• Helped HSBC meet market demands

• Led to more business for strategic products, like billing and online check cashing

• Improved performance and reliability

• Decreased costs (now there is no need for connection channels between customers and the bank)

• Increased productivity, efficiency, and effectiveness

“Sterling Commerce Managed File Transfer greatly reduced our file transfer timetable, which not only improves our productivity, but our customers’ as well. Now our electronic banking process is much more efficient and effective.”

Ivo Katz, Senior Executive, Business Channel, HSBC Bank

About Sterling Commerce:

Sterling Commerce helps 80% of the FORTUNE® 500 thrive in a global economy. We provide innovative solutions to process integration challenges between companies and their customers, partners, and suppliers to help them achieve higher levels of performance—and business without borders. With over 30,000 customers worldwide, we have unparalleled experience in the retail, manufacturing, financial services, wholesale distribution, logistics, and communications industries. Sterling Commerce is an AT&T (NYSE:T) company. Learn more at www.sterlingcommerce.com

37

http://www.sterlingcommerce.com/


38 38

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

2008 年 9 月 1 日出版（总第 13 期）

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

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

Darryn Salt Martha Hall

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

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


39 39

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

百硕客户通讯，总第 - bayss.com · rexx routine，利用system rexx的 execs自...

Documents