SQL存储过程直接调用QUSRJOBI API返回空值问题排查

直接在SQL存储过程中调用QUSRJOBI API失败，但通过RPG间接调用成功，核心原因在于参数传递模式不匹配以及SQL与ILE程序调用API时的上下文差异：

1. 参数传递模式未显式指定 #

QUSRJOBI API的第一个参数（接收数据缓冲区）和第六个参数（错误信息缓冲区）是输出参数，需要API向这些变量写入数据。但在SQL存储过程中调用外部程序时，默认会将参数视为IN类型（仅传入值，不接收返回数据），如果不明确指定OUT或INOUT模式，API无法向vData和vErr写入结果，最终导致这两个变量为空。

而中间的RPG程序在定义参数时，正确将输出缓冲区（outData、inErr）标记为非const类型，调用QUSRJOBI时会按输出参数传递，API能正常写入数据。

2. SQL与ILE的参数处理细节差异 #

QUSRJOBI是为ILE（集成语言环境）设计的系统API，RPG作为ILE原生语言，在参数对齐、字符集（CCSID）处理、内存缓冲区分配等方面完全匹配API的要求。而SQL存储过程在调用外部API时，参数的底层传递逻辑与ILE程序存在差异：

• SQL的字符类型变量可能默认使用不同的CCSID，导致API写入的数据无法被正确解析；
• 内存缓冲区的对齐方式可能不符合API的预期，导致写入失败。

3. 错误信息未被正确捕获 #

虽然SQL存储过程定义了CONTINUE HANDLER，但由于参数模式错误，API调用时可能已经触发了SQL错误，但vErr缓冲区未被API写入，导致用户无法通过VERRMSG看到具体错误。实际上可以通过GET DIAGNOSTICS在调用API后直接获取错误信息，排查调用失败的具体原因。

要让SQL存储过程直接调用QUSRJOBI成功，需要调整参数传递模式，并确保类型匹配：

1. 显式指定参数模式
   在调用QUSRJOBI时，为输出参数明确标记OUT，输入参数标记IN：

call qusrjobi( 
    vData OUT, 
    vDataLx IN, 
    vFmtName IN, 
    vJob IN, 
    vJobId IN, 
    vErr OUT, 
    VRESETFLAG IN 
) ;

2. 确保参数类型严格匹配
   验证SQL变量类型与QUSRJOBI的参数定义完全一致：

• 接收缓冲区和错误缓冲区使用CHAR(2000)（与RPG的2000a匹配）；
• 缓冲区长度使用INTEGER（与RPG的10i 0匹配）；
• 字符参数（格式名、作业名等）确保长度和CCSID与API要求一致。

3. 完善错误排查
   在调用API后立即检查SQL状态码，获取详细错误信息：

call qusrjobi( ... ) ;
IF SQLCODE <> 0 THEN
    GET DIAGNOSTICS EXCEPTION 1 vErrText = MESSAGE_TEXT;
    CALL SYSTOOLS.LPRINTF('QUSRJOBI CALL ERROR: ' || vErrText);
END IF;

内容的提问来源于stack exchange，提问作者RockBoro