IBM Mainframe Forum

As I understand you have 3 tasks: First you have to submit jobs on behalf of someone, then you have to monitor the job execution and catch the return code, and finally you have to inform the client about the final job status.
I see several different approaches which cover these tasks more or less:
1. Provide a JCL proc which everybody has to use in his private job as a final step. This procedure might invoke Lionel B. Dyck's XMITIP to send an eMail from z/OS to the requester.
2. Provide a JCL proc which everybody has to use in his private job as a final step. This procedure invokes a command file on your Windows workstation via ISPF workstation agent. This command file could trigger anything you want, such as creating a trigger file, sending an eMail, starting a fancy full-colored dialog box, or whatever you like.
3. Send the JCL via FTP to the mainframe. Retrieve the output via GET subcommand and parse it with SED or some perl program to get the return code programmatically.
Hope this helps

Stefan wrote:As I understand you have 3 tasks: First you have to submit jobs on behalf of someone, then you have to monitor the job execution and catch the return code, and finally you have to inform the client about the final job status.

yes

Stefan wrote:1. Provide a JCL proc which everybody has to use in his private job as a final step. This procedure might invoke Lionel B. Dyck's XMITIP to send an eMail from z/OS to the requester.

What happens if job takes a jcl error? The final proc won't be executed, right?

Stefan wrote:2. Provide a JCL proc which everybody has to use in his private job as a final step. This procedure invokes a command file on your Windows workstation via ISPF workstation agent. This command file could trigger anything you want, such as creating a trigger file, sending an eMail, starting a fancy full-colored dialog box, or whatever you like.

Same problem as above.

Stefan wrote:3. Send the JCL via FTP to the mainframe. Retrieve the output via GET subcommand and parse it with SED or some perl program to get the return code programmatically.
Hope this helps

Do you mean something like this http://www.lbdsoftware.com/Submitting_J ... ng_FTP.pdf ?
Parsing output is not a big problem, but this means that first I have to get job's jcl from mainframe and resend it to the mainframe? Can I avoid this step?

dick scherrer wrote: However, this is not a developer issue. This is a management issue. If management believes it is proper for you to spend so much time doing this manually, you may be stuck for a while.

I know, but i have to try.

dick scherrer wrote:Why can each user not have "their own" job and dataset for the submission and the first thing the process does is to generate whatever is needed for the actual run?

There are different reasons, one are users habits, and for me is easier change my work instead of users habits. Other reasons are:

• control user activities
• generate reports
• create dynamic "autorized" intervals
• other stuff that can be useful

I know all of this can be implemented on zos but for me it's easier to do this server side.