How to - Diagnose the errors of a "MVSExec"

[FALLAI-Denis]

Hi,

When debugging and executing our language.groovy scripts, we are regularly confronted with execution errors internal to an MVSExec, and we have great difficulty in diagnosing.

These errors may concern the file allocations managed in the background by BPXWDYN, or the various utilities called by MVSExec, as COBOL compiler.

Unlike a regular job that has JESMSGLG and JESYSMSG outputs that can be parsed, running an MVSExec produces nothing, at least no output or log we succes to find.

Sample use case of our Cobol.groovy:

[2023-07-12T16:00:48.336Z] [18-00-37.000] : JOB Start ; Executing steps ----------
[2023-07-12T16:00:48.336Z] [18-00-38.000] : precompile COBOL ; RC = 0 ; Duree Step : 1.660 seconds
[2023-07-12T16:00:48.336Z] [18-00-41.000] : PreCompil DB2 ; RC = 4 ; Duree Step : 2.749 seconds
[2023-07-12T16:00:48.336Z] [18-00-44.000] : Compil ; RC = 14905344 ; Duree Step : 3.365 seconds
[2023-07-12T16:00:48.336Z] *! The compile return code (14905344) for CEAT5/pacbase/COBOL/SQII11K.cbl exceeded the maximum return code allowed (4)

No Java exception is thrown... No log is produced... Not even the log containing the SYSPRINT output of the COBOL compilation step... The return code of the MVSExec step is not significant... Nothing to analyze...

For information, in this specific case, after long research, we assumed that it was the PDS-E file (library) receiving the object modules at the compilation output which had reached its limit: 16 extensions, 99% use... But that's just a guess...

Is there a way to parse something at an MVSExec run, or at MVSJob level, that would be the equivalent of a JESMSGLG or JESYSMSG output?

Thanks.

[dennis-behm]

@FALLAI-Denis Unfortunately, the BPXWDYN and the processing from z/OS Unix is not equal to a JCL process.

I just posted a response to https://github.com/IBM/dbb/issues/170 . Let's do the same for you ... with the return code of 14905344

Converting this into a Hex-value: https://www.rapidtables.com/convert/number/decimal-to-hex.html?x=14905344 gives us a E37 .

Looking into the zOS documentation for E37: https://www.ibm.com/docs/en/zos/2.5.0?topic=codes-e37

Then lets move on to IEC032I: https://www.ibm.com/docs/en/zos/2.5.0?topic=messages-iec032i

The return code in the system log will give you the reason why the compile abend'ed.

Hope that helps.

[dennis-behm]

I created an documentation enhancement request for this: https://ibm-z-software-portal.ideas.ibm.com/ideas/DBB-I-51

[FALLAI-Denis]

Hi @dennis-behm

Thanks for the information about decoding the return code and for opening a documentation enhancement request on DBB.

After that remains rather empirical... we know that the code 14905344 corresponds to an E37, but that does not tell us which file is concerned.

I don't think that it is directly DBB which is in question, but rather the JZOS component which must be the base of development of DBB.

[mhardin18]

@FALLAI-Denis Unfortunately, the BPXWDYN and the processing from z/OS Unix is not equal to a JCL process.

Yes, decoding/debugging MVSExec issues is a pain because of this.

What about incorporating https://www.ibm.com/docs/en/zos/3.1.0?topic=output-message-processing somehow? I'm out of my comfort zone here, so please tell me if I'm off in left field.