IBM Mainframe Forum

Hi,

A couple of days of googling and reading the TWS manuals has not given me an answer so hopefully someone here might be able to help.

In order to run an IMS recovery job, it needs to have the same jobname as the original failing job. This presents various difficulties in automating the recovery in TWS. I can submit the recovery job through automatic recovery options, and due to this having a different member name to the job name I can track it with an ETT application. However the issue is that the recovery job has OPC recovery statements in it which are not then used by TWS.

Is there a normal way to automate IMS recovery through TWS? I've not had to deal with the issue of a recovery job needing the same name as the failing job before.

thanks in advance for any help.

It's a while since I've used TWS, and I don't have any direct experience of this as far as I recall, but it presents an interesting problem. As I see it, there are a few possibilities:

1) Your recovery job has a different TWS operation name, but the actual name on the job statement in the JCL matches the original failing job name. This is fraught with problems since TWS won't be able to track it (I assume that's what you mean by your comment about tracking it with an ETT application) and may not even submit it depending on your TWS configuration. I'm not sure what you mean about the recovery job having OPC recovery statements that are then not used by TWS. If it is a different job, why does it need to have recovery statements? And if they are not needed (ie; the job does not fail), they are ignored. Why is this an issue?

2) Rerun the failed job, but with appropriate ADDPROC or DELSTEP statements such that this effectively becomes your recovery job. I really think this would be your best approach, and depending on the structure of your JCL and how the original job differs from the recovery job, there are multiple possibilities.

3) The recovery job runs with an entirely different name but merely copies the JCL for your "real" recovery job (with the same name) from the JCL library to the internal reader. That way you can control the source of the recovery job, rather than relying on TWS's EQQJBLIB concatenation which cannot easily change. You would then need something in this job to set the original failed job to complete. Again, really not very nice - submitting jobs with the same name as a TWS operation outside of TWS control can get messy. This is similar in effect to option 1.

4) Some of the exits may achieve what you want, perhaps EQQUX001 to tailor the submitted JCL or EQQUX002 to read an alternate list of EQQJBLIB datasets. Probably unnecessarily complicated.

I would definitely try and go with option 2 I think if it were me.