TomLiotta   7740 pts.  |   Nov 16 2009  7:52AM GMT

Please clarify what you mean by “calls the cobol program in Batch mode”, “it stops processing with a system generated error massage” and “control go backs to CL program”.

If you used SBMJOB to run the COBOL program, then control never left your CL program. Therefore, control can’t “go back” to your CL program. Control never leaves your CL program. The execution of the COBOL program is totally unrelated to your remaining CL instructions.

The SBMJOB executes and that causes a request to call the COBOL program to be placed on a job queue. The COBOL might run practically immediately, it might wait on the queue for seconds, or minutes or forever.

Regardless of whether or not the COBOL runs and whether not the COBOL succeeds, your CL doesn’t wait. Control has never left. The next instructions in your CL are already running and probably have completed long before the COBOL will have a chance to start. The CL instructions that follow the SBMJOB have no relationship to the submitted job at all.

So, please review your CL and rephrase your question.

If you want your CL to respond to errors in the COBOL program, you can’t use SBMJOB. Your CL will need to call the COBOL directly.

(There are ways around that, but you seem to need a lot more experience before attempting more complex operations.)

Tom

Rlsantucijr   355 pts.  |   Nov 16 2009  2:31PM GMT

And what you are describing is simple data verification - which can be done within the COBOL program. You read the record, verify its data, and based on what your find either process it or write it to an error report and reject it. No need for system messages - or leaving the COBOL program. What you describe is way too complicated for the results you desire.

TomLiotta   7740 pts.  |   Nov 17 2009  1:06AM GMT

Note that a MONMSG in the CL will have no connection to any error messages that might be signaled in a submitted job. A MONMSG can follow the SBMJOB command and react to errors in the SBMJOB command itself, but those errors will be totally unrelated to the COBOL instructions.

Tom

WoodEngineer   2240 pts.  |   Nov 17 2009  5:05PM GMT

Its been a long time since I programmed in COBOL but I believe the same file handling features are available that are in RPG. Based on that assumption, can you add a file control data structure to your COBOL program - this will give you lots of good info about the file you are inspecting. It should also return the record number from the file in question. You could pass that number back to your CL along with the error number, which is also available in the finl control data structure. Then your CL program could take action such as displaying a message with the record number and error number.

TomLiotta   7740 pts.  |   Nov 19 2009  1:17AM GMT

can you add a file control data structure to your COBOL program…

About the only related element for COBOL is FILE-STATUS which is generally a two-character field. (I think it can be up to 6 bytes for some file types.) AFAIK, there’s nothing in COBOL like the RPG INFDS. Each language is free to make available whatever that group chooses. I’d guess that the COBOL group is hampered by (1) having to adhere to COBOL standards while (2) serving 15-20% or less of the number of RPG developers.

Tom