从UNIX到IBM主机系统的程序移植探讨要点

1、从UNIX到IBM主机系统的程序移植探讨从UNIX到IBM主机系统的程序移植探讨摘 要：本文介绍了 UNIX平台与IBM主机系统平台之间的差异，并对跨平 台移植过程中应考虑的主要问题和解决方法进行了探讨。关键词:IBM主机系统；移植；作业控制语言；初始化器1 引言IBM主机系统,又称IBM大型机,是20世纪60年代发展起来的计算机系 统, 在全世界各大国家中肩负着银行、保险、证券、通讯等行业的数据与信息处 理工作 , 因为其独具的高安全性、高稳定性和强大的数据处理能力 , 迄今无可替 代。近几年来,主机系统的前景不断看好。从1994年起,IBM开始对大型机 进行深入的技术改造，采用了新的CMO

2、技术,极大地缩小了大型机的系统体积， 降低了能耗和散热成本 , 提高了性能价格比。另一方面 , 分布式计算开始变得庞 杂起来 , 许多公司的管理费用激增 , 而且由于数据分散 , 在数据的互访和集中管理 方面 , 安全和准确性都不够高 , 许多企业开始转向使用大型机。大型机在总体拥 有成本上已经比分布计算廉价 , 制造业、保险、航空、运输及大型零售企业的大 量事务处理对大型机的要求越来越高 , 这是大型机重新被人们认可的原因之一。2 分布式与大型机分布式计算在短期内给企业带来了高效 , 但随着时间的延续 , 企业系统扩 大, 数据分散存放在上百台服务器上 , 数据的查询成为问题 , 数据的互访

3、和对大量 数据的开采利用变得困难起来 , 一个新的趋势再集中开始出现。如何将分布 处理和集中计算结合起来 , 成为许多企业考虑的问题。大型机的系统完整性和大 存储量的优势显示出来 , 开始承担用户再集中需求的任务。在总体拥有成本上 , 随着时间的推移 , 小型机系统渐渐显现出极高的使用 成本。或许人们在使用一年 UNIX后,会说UNIX性价比高，但随着业务的增加，系 统变得分散庞杂起来 ,维护费用增加。大型机挺过了关键的 10年暗淡期,终于峰 回路转。因此，越来越多的企业开始关注IBM主机系统，将自己的系统移植到主 机系统上来。3 移植平台间的差异3.1 主机操作系统Z/OS与UNIX目前IB

4、M主机的主流操作系统Z/OS是使用最广泛的基于64位Z体系结 构大型机操作系统 , 它给在大型机上的应用程序员提供了稳定、安全和可持续运 行的环境。从本质上来说,UNIX是一个计算密集型的操作系统,CPU利用率较高,更 适用于需要大量计算的环境；而主机操作系统Z/OS依赖于其强大的硬件后盾，除 了强大的计算能力之外 ,更突出的是它强大的 I/O 处理能力,依托硬件上的 FICON ESCOI等光纤通道,可同时应对大规模的并发用户,因此它是一个I/O密 集型的操作系统。两种系统在很多内容上有着不同但又类似之处。3.2 进程与地址空间在UNIX下,一个程序的执行通常称为一个进程，操作系统为每个进程

5、分 配一定的CPU内存资源，使其运行,进程与进程之间可以通过信号量机制协同 工作实现并发；而在Z/OS下没有进程的概念，与之对应的是地址空间(Address Space)的概念,任何用户的登录、程序的执行、作业的提交,系统都会为其生成 一个地址空间。地址空间之间在批处理方式下一般没有通信 , 而通过联机交易处 理方式实现程序间通信。在UNIX下通常会有守护进程(daemon)的概念,在主机环境中通常是一个 长时间运行的作业的提交 , 可以从控制台为这个守护作业提供输入输出对象处 理。3.3 文件的组织与编辑方式从文件和数据格式上来说 ,UNIX 系统是树状的目录结构 , 数据的组织以 文件夹与

6、文件的方式保存、管理 ； 而在主机上 , 数据都保存在数据集里 , 数据集分 顺序数据集、分区数据集与 VSAM数据集,其组织方式没有多层树状结构,分区数 据集下可包含称为membe的顺序数据集，顺序数据集或VSAM数据集存储实际的 数据。数据的格式在UNIX下是面向字节,而在Z/OS下是面向记录的。数据的 编辑在UNIX下通常是用VI;而在Z/OS下用的是ISPF编辑器。3.4 交互系统的区别UNIX 下用户登录并在 Shell 环境下执行 Shell 会话, 可以通过发送远程 登录 rlogin 命令或者远程登录 telnet 命令连接系统 , 一个用户可以同时打开多 个用户会话。在主机环

7、境下,用户通过TSO/E和它的菜单驱动接口 ISPF登录系 统, 一个用户一次只能有一个活动的会话。在UNIX系统中,用户可以通过后缀Shell命令观察处理进程和线程，可 通过 Kill 命令结束一个任务。在主机环境中 , 用户通过作业处理子系统提供的 SDSF查看他们提交作业的执行情况,并可以终止作业任务的执行。4 移植实例 下面以一个实际项目实例来阐述一套移植过程中要考虑的具体问题。项 目以一个在UNIX平台上实际应用的后台结息系统为移植对象，考虑系统处理的 各种运行机制和平台差异,最终将整个系统移植到Z/OS下。原系统的操作系统为AIX5.0,数据库为INFORMIX 10X开发语言为C

8、语 言,移植后的操作系统为Z/OS 1.5,数据库为DB2版本8,开发语言为C语言。4.1 针对多进程考虑 在原系统中有一个主控程序设计 , 主控程序是一个主调度程序 , 主要负责 控制并发的进程数量及状态 , 系统支持的并发数量由主控程序的参数设置 , 通常 设置为 30。主控程序控制的每一个并发进程代表一个部门结息流程。假设一次 性有 1000个部门运行结息过程 , 主控程序负责调度 , 它轮寻所有进程 , 当一个进 程结束时启动下一个进程 , 直到所有部门完成。在Z/OS上没有进程的概念，针对这种后台批处理的结息方式，我们通过 作业的方式实现,方案是为每个部门的结息准备一个 JCL作业。

9、所谓JCL(Job Control Language) 是作业控制语言 , 通过它写一段作业脚本提交给系统 , 可以让 系统执行相应的程序或进行相关的工作。为每个部门结息准备一个JCL作业,再准备一个主JCL作业,这个主JCL的任务就是去提交所有部门的JCL作业。把结息过程定义为作业的好处是,在Z/OS里控制作业的并发数量以及作 业调度的任务都可以由系统里的作业处理子系统JES2自动完成。在JES2里,有多个被称为Initiator的地址空间,每个Initiator都相当于UNIX下的一个守 护进程, 专门处理提交的作业。Z/OS 中的 Intiator 是一个自动调度和处理提交的多个作业的地

10、址空间 它主要负责处理如下任务 :(1) 确保同时运行的各项作业不会产生数据集使用上的冲突 ;(2) 为作业分配必要的硬件设备 , 如磁带等 ;(3) 从库中找到每个作业需要调用的可执行程序 ;(4) 当一个作业运行完毕之后 , 在作业队列中清除该作业并要求处理下 一个作业。每个 Initiator 在同一时刻可以处理一个作业 , 而多个 Intiator 可以并 发处理多个作业 ,各个 Initiator 并发处理各个作业都是在保证不出现死锁的前 提下进行的。 Initiator 的数量可以在系统中设置 , 这样一来就自动实现了并发 数的控制。比如我希望将并发数控制为 50, 我们在系统中设

11、置 50 个 Initiator, 然后提交主JCL作业,主JCL作业再一次性提交1000个部门的作业,这些作业由 JES自动调度给50个Initiator, 并实现负载的均衡。4.2 Makefile 的替代在UNIX平台上,通常会在准备好源代码之后使用 make工具进行编译，在 执行make之前,需要一个命名为Makefile的特殊文件来告诉make需要做什么， 该怎么做。通常make工具主要被用来进行工程编译和程序链接。当使用make工具进行编译时，以下几种文件在执行make时将会被编译 或重新编译 :(1) 所有的源文件没有被编译过,则对各个C源文件进行编译并进行链 接, 生成最后的可

12、执行程序 ;(2) 每一个在上次执行make之后修改过的C源代码文件在本次执行 make时将会被重新编译；(3) 头文件在上一次执行make之后被修改，则所有包含此头文件的C源 文件在本次执行make时将会被重新编译。Makefile文件是一个非常有效的文件，而在Z/OS平台中,没有类似的文 件可用,通常的编译都是通过使用一个JCL作业去调用系统相关的针对编程语言 的编译器去执行。考虑到Makefile文件的对应参数、编译流程、依赖关系与JCL作业有很多相似点，我们的方案是还是使用JCL作业去编译程序，但将相关的源程序写 在同一个JCL作业中。在Z/OS环境下一个JCL作业可以有多个作业步，每

13、个作 业步可以指定进行不同的操作或调用不同的程序 , 一个作业最多可以有 255个作 业步。因此 , 我们可以将相关联的源程序或者头文件放到同一个作业的不同作业 步中, 用于编译、链接 ,当有程序做了修改需要重新编译链接时 ,还是提交同一个 编译作业就可完成。4.3 信号量机制的考虑在实际结息流程中 , 通常每个进程都需要从数据库表里申请一个唯一的 编号作为结息流程的流水号 , 最终保存到数据库。流水号是一个递增数列 ,无论 进程执行是否成功 , 此流水号都必须唯一且不可让其他进程使用 , 即使进程执行 失败 , 此流水号也必须作废而不可给后续进程使用。在UNIX平台下,允许进程间通信，信号量

14、机制就是用来解决进程同步与 互斥问题的。通过P、V操作,保证并发进程互斥地访问数据库里的流水号资 源。而在Z/OS平台下，特别针对后台批处理方式下，用户的程序之间，作业与 作业之间一般不允许相互通信 , 资源的互斥使用是通过 Initiator 调度实现的。考虑到进程使用的流水号最终需要保存到数据库 , 而且流水号要求是递 增数列,我们针对DB2数据库直接操作，DB2里面有个Sequenee Object,它是一 个递增数列 , 其递增幅度与初始值都可以在建立的时候设定。我们可以针对不同 类型的流水号建立一个或多个 Sequence Object, 之后在任何需要用到流水号的 地方 , 通过调

15、用 Sequence Object 的 next value 取其当前值的下一个值 , 这样不 管多少进程并发 , 在同一时刻其 next value 永远不可能重复 , 保证流水号的唯一 性。4.4 程序的准备移植初期首先需要将程序与数据导入到 Z/OS环境下。程序的导入可以通过FTP上传或3270终端直接上传的方式。首先需要 在主机上针对不同属性的文件建立不同属性的数据集。由于主机上不是树状文 件系统结构 , 所以要建立几个分区数据集 , 将相关文件保存成为相关数据集的 member如源文件可以建立一个数据集,名为userid.SRC,库文件可以建立为 userid.LIB 等, 数据集的

16、大小根据实际情况指定 , 我们的项目考虑可扩展性 , 建 立的每个分区数据集以M为分配单位，初次分配量为300,再次分配量为100,目 录空间大小为 100。将文件保存成文本格式上传 , 如果上传后都成了顺序数据集 , 可以写一个 简单的JCL,使用IEBGENE将其拷贝到分区数据集里。4.5 数据的导入对于数据库的导出导入 , 我们的方案是先将数据库创建脚本导入到数据 集，使用主机上的SPUFI运行脚本创建好数据库、表空间和相关表、索引等。将 原 Infomix 数据库的数据以文本方式导出 , 再导入到主机 , 最后导入到数据库。在DB2里，数据库的导入有Import和Load两种方法。Im

17、port以SQL为 基础,会写日志,可以对视图操作 ,表上定义的各种约束都将被检查 ,可以在目标 表不存在的情况下通过 ixf 格式的文件创建表 , 不能在 Import 过程中搜集统计 信息。 Import 成功后表就可以使用。Load 操作属于偏底层的操作 ,不写日志,不可以对视图操作 ,除了唯一性 约束之外的各种约束都不在Load过程中被检查，不可以在目标表不存在的情况 下创建表,可以在Load过程中搜集统计信息。Load过程成功后也有可能将表空 间置于 pending 等的特殊状态 , 管理相对比较复杂。总的来说，由于Load操作底层，因此速度很快，适合用于大量数据的导 入;Impor

18、t速度慢但管理简单，适用于少量数据导入。由于我们的数据量非常大 , 因此选择使用 Load 导入数据。我们将导出的 数据保存到主机的数据集里，通过写一个Load作业，从相关数据集导入需要的数 据。在 Load 过程中 , 可能会因为参数或数据出错导致表空间置于 reorganize pending 状态 , 或者将某个表的 Index 置于 rebuild pending 状态, 这时只需要 将相应的表空间做一个 REOR或者对相应的Index做一个rebuild就可以解 决。5 总结在决定对一套应用软件进行移植前 ,首先要明确移植的目的 ,选用适当的 平台和语言,然后充分地分析移植前后软件运行环境的异同 ,决定要采取的技术 和需要进行的结构调整 , 这样就可以系统而有序地完成大中型软件的移植工作 , 并可有效地提高软件质量 ,延长软件生命期。通过几个月的实践 , 我们的方案在 可行性上得到了验证 , 作为实际的应用