COBOL生成合法XML需手动转义特殊字符、避免BOM和非法控制符，用STRING/INSPECT构建标签；CICS下调用WEB POST时须设CONTENT-TYPE、CONVERT(YES)、显式CONTENT-LENGTH，并预留字节余量。
COBOL程序里怎么生成合法XML字符串
COBOL本身不内置XML序列化能力，必须手动拼接符合XML规范的字符串。关键不是“生成XML”，而是避免生成非法内容：比如未转义的 &、、>，或含控制字符的字段值。
实操建议：
- 用
STRING或MOVE+INSPECT构建标签，不要依赖硬编码换行或空格——CICS区域对不可见字符敏感 - 所有字段值必须过一遍转义逻辑：
&→&，→zuojiankuohaophpcn，>→youjiankuohaophpcn，单双引号按需处理（尤其当XML被嵌入JSON或HTTP body时） - 避免动态构造
——CICS TS 5.3+ 对BOM和声明行位置有校验，直接写死在WORKING-STORAGE更稳 - 用
OCCURS DEPENDING ON处理重复节点时，确保计数器在XML打开/关闭标签前已正确设置，否则会生成错层结构
CICS下用EXEC CICS WEB POST传XML的必要配置
不能直接把XML字符串塞进 EXEC CICS WEB POST 的 REQUEST 参数就完事。CICS需要明确告知服务端内容类型、编码、长度，且XML必须是纯字节流（EBCDIC → ASCII 转换必须由CICS完成）。
实操建议：
-
REQUEST区域必须定义为PIC X(n)，且n要 ≥ 实际XML字节数（注意：EBCDIC下中文占2字节，转ASCII后可能变3字节，预留20%余量） - 必须显式指定
CONTENT-TYPE('application/xml;charset=UTF-8')，漏掉charset会导致API返回400或乱码 - 启用
CONVERT(YES)——否则CICS默认不转换EBCDIC到UTF-8，服务端收到的是乱码字节 - 若API要求带认证头，用
HEADER参数传入，格式为'Authorization: Bearer xxxxx'，不能混在XML里
常见失败现象和对应检查点
上传返回 RESP(16)（INVREQ）或 RESP(22)（NOTFND）不是网络问题，大概率是数据层违规。
典型错误与定位方式：
-
RESP(16) + RESP2(37)：XML根节点名与API文档要求不符，或命名空间URI拼错（比如少了个末尾斜杠） -
RESP(22) + 响应体含"Invalid XML"：检查是否有多余BOM（x'EFBBBF'）、字段值含未转义&、或标签未闭合（- abc
- abc
- HTTP状态码
411 Length Required：没设CONTENT-LENGTH——CICS不会自动计算，必须用FUNCTION 'LENGTH'算出XML实际字节数再传入 - 超时（
RESP(18)）：不是调大TIMEOUT就行，先确认XML大小——CICS默认限制单次WEB请求不超过1MB，超限需改DFH$HTTP的MAXREQSIZE参数
要不要在COBOL里验证XML结构
不推荐。COBOL做XML Schema校验成本高、易出错，且CICS环境下无现成库支持XSD解析。
更务实的做法：
- 在测试阶段用外部工具（如
xmlstar --validate）批量校验COBOL输出样本 - 在CICS程序中加轻量级守卫：检查首尾是否为
和，用INSPECT统计和出现次数是否匹配（仅防明显语法断裂） - 把XML生成逻辑抽成独立子程序，配合固定测试用例（含特殊字符、空字段、长文本），每次变更都跑一遍
真正卡住上线的，往往不是语法错误，而是服务端对命名空间、时间格式（YYYY-MM-DDTHH.MM.SS 还是 ISO8601）、空元素写法（
