You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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 byMVSExec
, as COBOL compiler.Unlike a regular job that has
JESMSGLG
andJESYSMSG
outputs that can be parsed, running anMVSExec
produces nothing, at least no output or log we succes to find.Sample use case of our Cobol.groovy:
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 atMVSJob
level, that would be the equivalent of aJESMSGLG
orJESYSMSG
output?Thanks.
The text was updated successfully, but these errors were encountered: