企业官网建设流程全解析

用 Ubuntu 把 Hercules 模拟器编译出来，再把 z/OS 的引导安装流程完整跑通，这件事我最近重新做了一遍，踩过的坑比预想的多，也踩出了不少值得记下的细节。这类教程其实不少，但大多停在“./configure && make”这一步，后端配置文件怎么写、设备地址怎么映射、IPL（初始程序加载）和安装流程里哪些选项需要提前想清楚，往往讲得很碎。这篇就以“Ubuntu 编译 Hercules 主机安装 z/OS 教程”为主线，把我从环境准备、源码编译、实例配置到实际做引导安装的完整链路说清楚。

适合看这篇的人有两类：一类是刚接触大型机模拟，手上只有一台普通的 x86 Linux 机器，想低成本把大型机操作系统跑起来的人；另一类是已经有合法授权镜像，但不太清楚 Hercules 设备定义和控制台操作的运维或开发人员。我会尽量把每个命令、每个配置项背后的原因讲明白，而不是丢出一堆“照抄就能用”的片段。

1. 项目概述与整体设计思路

1.1 为什么要在 Ubuntu 上运行大型机模拟器

大型机硬件不是普通开发者能随时接触到的，动辄上百万的购置成本、机房租用和运维门槛，让大多数人很难直接在一台真实的大型机上做实验。Hercules 这类模拟器解决的就是这个痛点：它能在一台普通的 x86 服务器上模拟大型机的处理器、内存、通道和设备子系统，让大型机操作系统镜像在本地环境里跑起来。

从使用场景看，这套环境的价值主要体现在四个方面。第一是开发测试，某些遗留系统还在大型机上运行，开发和测试人员需要本地环境复现问题；第二是系统编程学习，很多人想研究大型机操作系统的内存管理、JCL 批处理、VTAM 通信或者磁盘管理，但没有真实硬件；第三是灾备演练，模拟环境可以帮你验证备份恢复流程；第四是可造性评估，在引入大型机系统之前，团队可以用模拟器快速验证功能可行性。

用 Ubuntu 作为宿主系统也有现实考虑。Ubuntu 是 Linux 发行版里社区资料最全、包管理最方便的系统之一，编译所需的依赖基本都能通过 apt 安装，遇到问题也容易查到现成案例。我在这台机器上的实践也验证了这一点，从安装依赖到编译完成，耗时比预想中短得多，瓶颈反而在后续的配置和镜像准备上。

1.2 模拟器选型与整体技术路线

在大型机模拟器领域，可选项其实不止一个，但目前主流且持续更新的只有 Hercules 系列。选型时还要区分两个版本分支：旧分支对老操作系统镜像兼容性更好，新分支则对 z/Architecture 和现代操作系统的支持更完整。我在实际操作中更偏向新分支，因为它对后续 z/OS 安装流程中的地址转换、64 位内存寻址等特性支持更到位。

整体技术路线可以拆成几个阶段：在 Ubuntu 上安装编译工具链和依赖库；获取 Hercules 源码并编译安装；编写 Hercules 实例配置文件，把模拟的 CPU、内存、设备地址定义清楚；准备磁盘镜像卷并做设备映射；启动模拟器后执行 IPL 引导 z/OS 安装程序，最后完成系统初始化。

这里有个概念要提前说清楚：你在一台 x86 机器上编译 Hercules，编译出来的可执行程序是 x86 平台的代码，但它在运行时会动态模拟出大型机的 z/Architecture 指令集。也就是说，Hercules 本身是“宿主机原生程序”，它负责解释执行大型机的指令流。很多新手在这里会有误解，以为模拟完以后连编译器都要换成 S/390 版本，其实完全不需要。

另一个重要提醒是：z/OS 是商业授权系统，不能随便从网上找一个镜像就往环境里放。教程里做安装步骤的前提是你已经通过合法渠道获得了安装介质，比如通过厂商的试用授权计划获取的允许教学评估使用的镜像。如果拿不到，可以选择同样能在 Hercules 上运行的教学型 MVS 镜像，流程会简化不少，但核心概念和操作路径是一致的。

2. Ubuntu 环境准备：编译前需要做对的几件事

2.1 系统更新与编译依赖安装

拿到一台全新的 Ubuntu 系统后，第一件事不是直接下载源码，而是先把 apt 源刷新一遍。不要跳过这一步，很多编译失败都是因为系统自带的包索引过期，导致装到一个旧版本的依赖库，后续链接阶段就会出现诡异报错。

sudo apt update sudo apt upgrade -y

更新完成后，安装 Hercules 编译所需的依赖包。以 Ubuntu 22.04 LTS 和 24.04 LTS 为例，我惯用的安装命令是：

sudo apt install -y build-essential autoconf automake libtool \ flex bison libltdl-dev libbz2-dev zlib1g-dev libssl-dev

逐个说下这些包是干什么的。build-essential 是一整套编译工具链，包含 gcc、g++、make 等核心组件，没有它一切都无从谈起。autoconf、automake、libtool 这组工具是用于生成 configure 脚本和实现共享库链接的，Hercules 源码发布时不会把最终的 configure 文件直接提交到仓库，而是通过 autotools 体系在本地生成。flex 和 bison 是词法分析和语法分析工具，模拟器解析配置文件时依赖它们生成的解析器。libltdl 是 libtool 的动态加载模块支持库，Hercules 的特性模块加载机制会用到。bz2 和 zlib 则涉及磁盘镜像的压缩和解压处理，特别是那种打包成归档格式的卷文件，没有对应库会解不开。

2.2 目录规划：源码、运行实例和磁盘镜像分离

我在实际部署时养成了一个习惯：源码目录、安装目录、运行配置和磁盘镜像分开管理，不要让所有东西混在同一个目录下。混在一起的后果是升级时要整个重来，排查问题也不容易定位。

我的目录结构大致如下：

/opt/hercules-src # 存放 Herzules 源码 /opt/hercules # 编译安装后的可执行程序和库文件 /srv/hercules/conf # 每个实例的配置文件 /srv/hercules/dasd # 磁盘镜像卷文件 /srv/hercules/panlog # 控制台日志和硬拷贝输出

这样划分的另一个原因是权限管理更清晰。Hercules 运行实例通常不需要 root 权限，只要运行用户对/srv/hercules/conf和/srv/hercules/dasd有读写权限即可。我用的是一个专门的业务账号，而不是 root 直接跑，避免因为权限过高导致误删镜像文件。

创建目录和授权的过程很简单：

sudo mkdir -p /opt/hercules-src /opt/hercules sudo mkdir -p /srv/hercules/{conf,dasd,panlog} sudo chown -R $USER:$USER /opt/hercules* /srv/hercules

2.3 检查编译工具链和目标平台

开始编译之前，花 30 秒检查一下编译器版本和目标平台，能省掉后面大量的定位时间。用下面两条命令确认：

gcc --version uname -m

uname -m输出应该是 x86_64 或 aarch64。需要牢记的是：Hercules 编译产物是针对宿主机架构的，不是针对大型机架构的。只要宿主机架构能被 gcc 正常支持，编译本身不涉及交叉编译问题。

gcc 版本同样值得关注。如果你拿到的是比较老的 Hercules 源码版本，在 gcc 10 及以上版本编译时可能会遇到老式 C 代码的兼容性问题，常见的报错是“multiple definition of ...”。这不是大问题，后续章节我会给出一个稳妥的解决方式。

3. 从源码编译 Hercules 模拟器

3.1 获取源码与版本选择

编译 Hercules 的第一步是拿到源码。官方源码托管在公开的代码托管平台上，用的是 git 仓库方式发布。我建议用 git clone 的方式获取，这样后续想要切换到不同版本或更新代码都很方便。

cd /opt/hercules-src git clone <hercules 官方仓库地址> hercules cd hercules

关于版本选择，我在实际使用中会优先考虑新分支的最新稳定版本，因为旧分支的新版本在 z/Architecture 模拟深度上明显更好，对 z/OS 这类现代大型机操作系统的支持也更完善。如果你只是跑上古的 MVS 教学镜像，旧分支也够用，但既然目标是 z/OS，就没必要从一开始给自己设限。

拉取源码后，可以先看一眼目录里的 RELEASE 说明文件，里面会写清楚当前版本的特性支持情况和已知问题。这一步很多人会忽略，但确实能帮你避免踩到版本相关的坑底。

3.2 configure 参数选择与常见编译问题

Hercules 的编译流程遵循经典的 autotools 流程：先运行 autoreconf 生成 configure 脚本，再运行 configure 生成 Makefile，最后执行 make。

由于 git 克隆出来的源码没有自动生成 configure，你需要先执行：

autoreconf -f -i

这条命令会调用 autoconf、automake 和 libtool 工具链，生成完整的构建系统。如果机器上缺少这些工具，会直接报 command not found 或者 libtoolize 相关错误，这时回到上一章把依赖包装全就行。

生成 configure 后，我惯用的配置命令是：

./configure --prefix=/opt/hercules

指定--prefix的目的是让安装路径可控。如果不指定，默认会装到/usr/local，后续升级卸载会不方便。其余参数保持默认即可，因为默认配置已经包含了 z/Architecture 模拟支持、动态模块加载和常见设备驱动。不要为了追求“纯净”去随意禁用一些模块，很可能禁用掉的正好是你后续安装流程里需要用到的东西。

接下来开始编译。我建议先用单线程编译一次确认没有基础性错误，再用多线程加速。直接执行make -j$(nproc)虽然省事，但一旦出现编译错误，排错时的输出会交错在一起，非常影响判断。

make

如果这一步顺利通过，再执行：

make -j$(nproc)

编译时间取决于机器性能，通常几分钟到十几分钟不等。这个过程实际上是宿主机上的 gcc 在生成 x86 代码，所以不用幻想它能编译出大型机的二进制文件——我之前已经强调过，Hercules 是解释执行大型机指令的。

老版本源码在 gcc 10 以上编译器上容易碰到的问题，我也在这里说清楚。表现是链接阶段报出大量multiple definition of '变量名'错误，根源是 gcc 10 把 C 语言全局变量的默认规则从-fcommon改成了-fno-common。解决方式是在 configure 前设置 CFLAGS：

export CFLAGS="-fcommon" make clean ./configure --prefix=/opt/hercules make

如果你用的是新分支源码，这个问题基本已经修复了，不需要手动处理。

3.3 安装验证与路径配置

编译完成后，执行安装：

sudo make install

安装完成后，验证一下可执行文件是否正常生成：

/opt/hercules/bin/hercules -v

如果输出版本号和编译日期，说明核心程序已经可以运行。如果提示缺少动态链接库，例如 libltdl.so，说明编译时 ltdl 的支持没有正确链接进去，可以用ldconfig检查系统库缓存，或者把/opt/hercules/lib加入动态链接搜索路径。

为了让后续操作更顺手，我习惯把 Hercules 的 bin 目录加入 PATH，并写入 shell 配置文件：

echo 'export PATH=/opt/hercules/bin:$PATH' >> ~/.bashrc source ~/.bashrc

到这里，模拟器本体已经准备就绪。但严格意义上说，你还没有一个能跑 z/OS 的“主机环境”，接下来要做的就是给这台虚拟的大型机接上外设——磁盘、控制台终端，这些都靠配置文件来完成。

4. 编写配置文件并准备启动实例

4.1 认识 hercules.cnf 的组成

Hercules 使用一个文本化的配置文件来描述整台模拟大型机的硬件拓扑。这个文件习惯上叫hercules.cnf，但文件名可以任意，启动时通过-f参数指定即可。

一个最小可用的配置文件至少包含几个要素：处理器类型、架构级别、内存大小、设备定义和控制台设置。我用的基础模板大致如下：

# 实例基础定义 archlvl z/Arch cpu 1 memory 2048M maxhsize 2048M # 设备定义 000C 3390 /srv/hercules/dasd/zos_install_vol.cckd 000D 3390 /srv/hercules/dasd/zos_target_vol.cckd 000E 3390 /srv/hercules/dasd/zos_spool_vol.cckd

archlvl z/Arch告诉模拟器按照 z/Architecture 模式运行，这是 z/OS 安装所必需的前提。cpu 1定义了一个处理器，memory 2048M定义了 2GB 内存。实际安装 z/OS 时内存需求可能会更高，这取决于你拿到的镜像版本和安装组件规模，我建议至少给到 4GB。

配置里最容易被忽略的是每行设备定义开头的那个十六进制地址。以000C为例，完整的设备地址可以理解为“通道号.控制单元号.设备号”。在主机世界里，CPU 不直接访问磁盘的一个扇区，而是通过通道子系统向设备控制单元发出指令，再由控制单元驱动磁盘设备。这个机制和普通 PC 的 SATA 控制器直连完全不一样，也是大型机 I/O 模型的核心概念之一。

类比来说，形象一点：通道像是大楼里的电梯井，控制单元是电梯，设备是你要去到的楼层。CPU 只需要告诉通道“去 12 楼”，电梯会自动把你送到对应的设备面前，CPU 不需要关心底层硬件怎么走线。

4.2 磁盘镜像卷与设备地址映射

z/OS 镜像通常以卷文件的形式提供，最常见的磁盘类型是 3390 型。在 Hercules 里，这些卷文件以cckd格式保存，即“count-key-data”格式的模拟实现，对应的是大型机磁盘最底层的物理记录格式。你拿到的镜像可能是预生成的.cckd文件，也可能是原始 pack 的映像，后者需要额外转换，这个环节对新手来说比较麻烦，建议优先用现成的镜像卷。

设备地址的映射逻辑要特别注意。IPL 时，引导程序会从指定设备地址读取初始程序。如果你把安装介质卷映射到000C，那么后续执行ipl 000C就是从该设备引导。安装过程中系统写入的目标卷通常映射到旁边的地址，比如000D、000E。如果地址冲突或重复映射，Hercules 会在启动时直接报错，所以每次加卷之前都要检查已有配置。

权限问题容易被忽略。如果镜像文件是 root 拷进去的，而 Hercules 是用普通用户运行的，设备文件没有读权限就会导致启动失败。保证运行用户对这些文件有读写权限，因为安装程序需要向目标卷写入数据。

4.3 启动模拟器和进入控制台

配置文件准备好以后，启动模拟器的命令很简单：

hercules -f /srv/hercules/conf/hercules.cnf

正常启动后，终端会出现一个交互式控制台界面。这个控制台就是模拟器的“面板”，你可以在这里输入ipl、stop、start等操作命令，模拟真实大型机上的硬件操作面板。大多数时候，真正的操作界面不在这里，而是在一台 3270 终端上。

z/OS 的安装和日常操作依赖 3270 终端界面，Hercules 通常会开启一个 3270 终端监听端口。你需要用 3270 终端模拟软件连接这个端口，才能看到系统的面板界面。我一般习惯先把 3270 客户端准备好，这样后续 IPL 时的输出就能直接看到，而不是盯着单调的文本日志。

控制台上还能做一些即时检查，比如输入help查看支持的命令列表，输入show dasd查看当前加载的磁盘卷状态。这些命令在正式安装前很有用，能确认设备是否被正确识别。

5. z/OS 安装引导实战记录

5.1 先合法获取安装介质再动手

在开始安装流程前，必须先拥有合法的 z/OS 安装镜像。这里我想说点实际的：z/OS 是商业授权软件，没有厂商授权就擅自使用属于违规行为。正规处理方式是通过厂商的试用/评估计划申请许可镜像，拿到以后通常是一组卷文件，附带安装说明和初始配置要求。如果你的申请还没下来，又急于熟悉流程，可以考虑在 Hercules 上运行教学类 MVS 镜像，那些镜像是专门用于学习目的的，流程原理和 z/OS 安装高度相似，未来切到 z/OS 也不会有太大障碍。

我实际操作时会把镜像文件先放入/srv/hercules/dasd/，并按卷用途重命名：安装介质卷、目标系统卷、用户数据卷。这一步看似简单，但能显著减少后续配置文件的出错概率。

5.2 第一次 IPL：从安装设备引导

IPL 全称 Initial Program Load，相当于大型机上的“开机引导”步骤。当你想让机器开始执行程序时，在 Hercules 控制台输入 IPL 指令，模拟器就会从你指定的设备读取引导记录。

在安装场景下，通常是把安装介质卷放在某个低地址设备上，比如000C，然后执行：

ipl 000C

输入后，Hercules 会从该设备读取初始程序，并把控制权交给引导程序。此时安装程序开始运行，输出会出现在 3270 终端上。如果没有 3270 客户端，你只能看到控制台面板上有一些简单的状态信息，但没法进入交互式安装界面。

3270 终端连接不复杂，只需要确认 Hercules 配置里已经开启了 3270 监听。连接成功后会看到一个蓝色或黑色的终端窗口，显示系统启动信息和安装面板。这时候你的“裸机”已经引导到安装了。

这里有个操作经验：IPL 之后不要立刻乱输命令，安装程序可能在一段时间内没有任何输出。它正在加载启动 JCL、初始化系统库，这个过程受磁盘性能和模拟器 CPU 速度影响，可能从几十秒到几分钟不等。保持耐心，等待第一个面板出现。

5.3 安装流程中的关键选项

不同版本和镜像的 z/OS 安装界面存在差异，但核心环节是相通的。第一次安装时，需要做的主要决定集中在下面几个点上。

第一是语言和编码设置。安装程序会询问终端语言和显示字符集，默认英文即可，字符集要选对，否则后续面板上中文或特殊字符会乱码。第二是系统类型和工作负载组件，也就是说你要安装成一套标准的系统，还是只带某些子系统的定制系统。新手建议选择标准组件安装，尽量别先做减法，等后续熟悉了再定制。第三是目标卷选择。安装程序会扫描可用的 DASD 卷，你要明确告诉它把系统数据集写到哪一卷，绝对不要把安装介质卷当目标卷，否则会在安装过程中把源程序卷覆盖掉，导致循环失败。第四是安全配置。设置系统操作员口令、安全管理员口令时，建议用容易记住但在生产环境不会使用的测试值，毕竟模拟环境主要是学习用。

还要处理网络参数。z/OS 的 TCP/IP 协议栈需要指定主机名、IP 地址和子网掩码，如果你想在安装完成后从宿主机访问大型机上的服务，这些地址要事先规划好。可以把模拟出来的大型机看作一个虚拟的网络节点，它需要一张虚拟网卡和一套独立的地址配置。

5.4 安装后引导进入系统

安装过程结束时，安装程序通常会自动执行一次或多次重启，把后期配置脚本跑完。最终看到登录面板出现，说明系统已经成功落地。

在 Hercules 控制台执行一次新的 IPL，这次引导的设备不再是从000C的安装介质，而是刚刚安装完系统的目标卷，比如000D：

ipl 000D

系统启动后，3270 终端上会出现登录界面。用安装时设置的管理员账号登录，你就能进入 z/OS 的交互式环境。到这一步，整个“Ubuntu 编译 Hercules 主机安装 z/OS”的主链路就已经走通了。

我自己第一次走完这个流程花了小半天，主要时间消耗在安装过程的反复确认和等待上，真正编译 Hercules 只占了不到二十分钟。学会 VAM 形态地看待这套环境后，后续做几百个批处理测试就顺畅多了。

6. 常见问题排查与性能经验纪录

6.1 编译和链接阶段的常见故障

编译阶段出问题并不可怕，关键是能准确定位原因。我把实际操作中最常碰到的几类问题整理成了表格，方便对照排错。

我在新分支源码上很少遇到老版本那种兼容性错误，所以如果你刚入门，直接用新分支是最省心的。

6.2 启动和配置阶段的排查要点

模拟器能编译出来不代表能顺利跑起系统，启动阶段的问题几乎都集中在配置文件和镜像文件上。

如果你看到设备无法初始化之类的提示，第一反应应该去检查配置文件里设备路径是否写错、文件是否存在、运行用户是否有权限。我遇到过最多次的就是卷文件路径写了一个不存在的位置，程序启动后卡在设备初始化阶段，看起来像是模拟器死掉了，实际上只是路径的最后一个字母打错了。

如果hercules -f没有报错但面板没有任何输出，可以加-l参数把日志输出到独立文件，再打开日志文件看详细执行过程。日志里有非常详细的设备初始化记录，能帮你快速定位是哪个设备挂掉了。

还有一个容易被忽略的问题是内存不足。配置文件给了 4GB 内存，宿主机却只有 4GB 物理内存，系统会疯狂换页，模拟器几乎卡死。宿主机内存至少要给模拟器预留两倍空间才比较稳妥。

6.3 磁盘性能与调优心得

大型机镜像文件通常不小，动辄几个 GB。Hercules 在运行时会频繁读写宿主机上的卷文件，磁盘 I/O 成为模拟性能的最大瓶颈之一。我在实际操作中的经验是，尽量让卷文件放在 SSD 上，不要位于机械盘的深处。如果宿主内存足够，甚至可以把常用卷文件放到内存文件系统里跑，能明显减少启动等待时间。

不过内存文件系统有个风险：一旦宿主机重启，内存里的数据全没了。我惯用的方式是把原始卷文件放磁盘，在需要做性能测试时复制一份到内存文件系统，测试完再把改动同步回来。

调优还有一个小细节：不要在一台宿主机上同时启动多个 Hercules 实例。每个实例都要解释执行大型机指令，CPU 占有率会很高，多实例不仅起不到并行效果，反而会让 I/O 排队冲突，整体吞吐量反而下降。

一点实际操作后的心得

最后分享一个我个人的经验。很多人在 Hercules 控制台输入ipl 000C后发现没反应，就开始怀疑模拟器有问题，其实多数时候是 3270 终端还没连接就绪，或者安装介质卷还没被正确识别。这类问题不看日志很难猜对。我后来养成了一个小习惯：在每次启动实例时，先把日志开启，确认设备加载清单里出现了预期的卷，再做任何 IPL 操作。这个顺序看起来不起眼，但在排障时能省掉大把时间。

整个流程走下来，我对大型机的“通道—控制单元—设备”三层 I/O 模型理解比之前更深了，也更能体会为什么大型机在高并发 I/O 场景下依然很稳。Hercules 只是模拟器，但只要你愿意把每个配置项背后的设计逻辑弄清楚，它完全能发挥出接近真实环境的训练价值。后续如果你想继续扩展这个环境，可以把 z/OS 上的网络服务、批量作业和 RACF 安全设置都测一遍，那又是一个很大的话题了。