端口与体系
424 对应 IANA 登记的 opc-job-track（IBM Operations Planning and Control Track），登记人 Conny Larsson，与 423 构成一对：423 负责作业启动，424 负责作业状态跟踪，两者共同支撑主机作业调度体系的状态上报链路。单独看到 424 而找不到 423，通常说明只起了跟踪组件，这种半启动状态往往伴随作业状态不上报的问题。
基本信息
| 服务名称 | opc-job-track |
|---|---|
| IANA 登记说明 | IBM Operations Planning and Control Track |
| 传输协议 | TCP 与 UDP |
| 所属体系 | IBM 主机作业调度 |
| 配对端口 | 423 opc-job-start |
| 当前状态 | 存量主机环境仍在使用 |
典型使用场景
- 状态不上报排障：作业实际已执行但监控侧看不到状态时，检查跟踪链路
- 组件重启后核对：调度组件重启后确认 423 与 424 都已恢复监听
- 管理网段策略审计：跟踪通道的连接来源应限于调度与管理网段
- 扫描报告解读：扫描器标注 opc-job-track，与主机侧清单比对
- 未知服务处置：无对应调度组件时按未知服务流程取证
定位与成对核查
定位与成对核查
# Linux：查看 424 的监听进程
ss -lntup 'sport = :424'
# 与 423 成对核查，确认两个组件都在
ss -lntup | grep -E ':(423|424)\b'
# 观察是否有跟踪流量进来
ss -tnp | grep ':424'
# Windows：取 PID 后反查进程
netstat -ano | findstr :424
tasklist /FI "PID eq 1234"排查步骤
| 步骤 | 动作 | 期望结果 |
|---|---|---|
| 确认组件 | 检查调度与跟踪进程是否存在 | 两个组件都在运行 |
| 确认监听 | 核对 423 与 424 的监听状态 | 两端口均处于监听 |
| 确认链路 | 查看连接来源与主机网络配置 | 来源限于调度与管理网段 |
| 确认作业 | 比对作业清单与状态记录 | 状态与实际执行一致 |
跟踪组件本身不产生作业，只负责上报状态。如果主机侧日志显示作业已在执行而监控看不到，问题通常在这个上报链路上，而不是作业本身。
判断上报链路是否健康，最直接的办法是做一次小规模演练：挑一个非关键作业，记录它在调度侧、跟踪侧与监控侧出现的时间点，三个时间点对得上，链路才算通。只有端口监听而没有端到端的时间戳对照，很难定位问题出在哪一段。