cschneid-the-elder/mapa

## 主机应用程序组合分析 本仓库包含用于 CICS API 和 SPI、COBOL（至少是 IBM Z 方言，但已尽力遵循 ISO COBOL 202x 草案标准 N=1207，日期为 2020-11-23）DB2z SQL、SQL/PL 以及在线实用工具的语法分析器，还包括 EXEC DLI 和 EXEC SQLIMS 接口以连接 IBM 的 IMS，以及 JCL。这些语法分析器本身可能具有独立用途。 其目标是创建至少一部分当我被支付报酬担任主机应用程序开发工具人员时所期望的功能。 我经常被问到应用程序影响分析相关的问题，例如哪些程序在运行、运行频率如何、哪些程序调用了其他程序等等。 在 `cobol` 目录中，你将找到一个 COBOL “调用树”工具，该工具提取 CALL、EXEC CICS LINK、EXEC CICS XCTL、EXEC SQL CALL 以及程序输入输出等信息，以帮助了解应用程序组合的整体结构（shape），通过静态代码分析实现。 在 `jcl` 目录中，你可以找到类似适用于 JCL 的工具。 在这两种情况下，目标都是生成一个平面文件，可以加载到数据库管理系统（DBMS）中，并作为配置管理系统的一部分使用。结合 CICS 定义的转储以及 DB2 目录中选定的条目（主要是触发器），你可以为自己构建一个漂亮的组合映射。 当然也存在商业产品可以实现这些功能，但它们价格昂贵。也许我提供的免费内容已经足够好用；如果不够，那你就有理由购买那些商业产品了。 ### 静态代码分析 静态代码分析关注源代码本身。该过程不了解代码执行时的实际行为。就应用程序组合分析而言，这会产生一种**可能**发生的情况的表示，而非**实际**发生的情况。请考虑…… ``` if a = b then call subroutine x ``` ……静态分析无法得知变量 `a` 是否永远不会等于 `b`（由于某些业务规则），因此子程序 `x` 可能永远不会被调用。 ### 运行时行为分析 运行时行为分析关注代码实际执行时的行为，通常通过某种形式的插装（instrumentation）实现。就应用程序组合分析而言，这会产生一种**实际**发生的情况的表示，而非**可能**发生的情况，并且仅限于**所分析的某次运行**。请考虑…… ``` if a = b then call subroutine x ``` ……运行时行为分析仅知道在已分析的所有运行中，`a` 从不等于 `b`，因此子程序 `x` 从未被调用。无法断言子程序 `x` 永远不会被调用。 ### 两者各有其用 为了理解应用程序组合，必须同时结合静态代码分析与运行时行为分析。仅凭某个程序从未被执行这一事实，并不能作为其已废弃的充分证据。毕竟，该程序可能仅在发生错误条件时才被执行；异常处理本来就应该是例外情况。 ### 构建 每个子目录都包含一个 Makefile intended to be used with GNU make。源代码由 ANTLR4 语法文件（`*.g4`）组成，对于 COBOL 和 JCL 语法还包括额外的 Java 代码。在 `cobol/Makefile` 顶部有一些说明，指导如何从头开始构建（即从全新克隆的 Git 仓库开始）。

标签：ANTLR, CICS, COBOL, DB2, DBMS, EXEC DLI, JCL, JS文件枚举, SQLIMS, 主框架, 云安全监控, 代码映射, 免费工具, 商业分析, 大型机, 安全专业人员, 应用组合分析, 源码分析, 程序依赖, 程序调用关系, 解析器, 语法, 调用树, 错误基检测, 静态代码分析, 静态分析