TWS Automatic Recovery Options



Ask queries about other IBM Tools like Tivoli, COBTEST, Fault Analyzer, z/OS File Manager, Workload Simulator, APA, SCLM, Merge & Migration Tools etc...

TWS Automatic Recovery Options

Postby ramu65 » Sat Apr 05, 2014 11:13 pm

Hi....

I am currently learning about automatic recovery options.I read that using ADDAPPL option , it is possible to run another application when a job fails.

1.I wanted to know if there is any option to pass parameters to the application which is invoked using addappl??
ramu65
 
Posts: 29
Joined: Sat Feb 08, 2014 10:51 pm
Has thanked: 0 time
Been thanked: 0 time

Re: TWS Automatic Recovery Options

 

Re: TWS Automatic Recovery Options

Postby NicC » Mon Apr 07, 2014 1:36 pm

Please do not append new topics to the end of topics on other subjects. You have already specified that the problem in the other subject was resolved so this is, obviously, a new topic.

Topic split.
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 2690
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisys (almost)
Has thanked: 4 times
Been thanked: 105 times

Re: TWS Automatic Recovery Options

Postby ramu65 » Mon Apr 14, 2014 9:19 pm

Hi..

I would like to provide detailed explanation regarding my earlier query.I went through the post regarding TWS job scheduling and this doubt popped up in my mind.Suppose I have an OPC recover statement like this:

//*%OPC RECOVER RESTART=N,ADDAPPL=APL

APL has a job JB1 implementing SDSF batch utility.

JB1 code snippets

/ISFIN DD *
ST
PRE JOBNAME1

I would like to use the same OPC recover statement in different jobs and want the JB1 program to copy contents from spool to dataset for the failed job where the OPC recover statement is placed.Is it possible to modify the JB1 program in such a way that the jobname1 parameter in the JB1 program can assume values based on the program ending in error.To sum up,Is it possible to reuse the (JB1) program in OPC recover statements of different jobs??Can you please provide your inputs on the query?This way a single job can be used to copy contents from spool to dataset for each job ending in error instead of creating different job for each job ending in error.
ramu65
 
Posts: 29
Joined: Sat Feb 08, 2014 10:51 pm
Has thanked: 0 time
Been thanked: 0 time

Re: TWS Automatic Recovery Options

Postby NicC » Tue Apr 15, 2014 2:58 am

You are mixing terminology - you mention JB1 as being a job but then you repeatedly call it a program. Which is it? And are you asking if the same job can appear in more than one AD? If so - yes: and looking through ADs already present should show such things.
The problem I have is that people can explain things quickly but I can only comprehend slowly.
Regards
Nic
NicC
Global moderator
 
Posts: 2690
Joined: Sun Jul 04, 2010 12:13 am
Location: Pushing up the daisys (almost)
Has thanked: 4 times
Been thanked: 105 times

Re: TWS Automatic Recovery Options

Postby ramu65 » Tue Apr 15, 2014 6:48 am

Hi nick

What I actually meant is , whether it is possible to pass the jobname as parameter to the applicaion invoked using opc recover statement??
ramu65
 
Posts: 29
Joined: Sat Feb 08, 2014 10:51 pm
Has thanked: 0 time
Been thanked: 0 time

Re: TWS Automatic Recovery Options

Postby Blackthorn » Tue Apr 15, 2014 3:13 pm

There is no built in function for doing this. I am sure I have heard some talk of it from IBM, so it may be available in a future release but it's not currently.

Two possibilities spring to mind -

1) Get your recovery job to do a PIF enquiry in TWS to find the jobs that are in error. The latest one should be the one that caused your recovery job to be added. Not 100% accurate though - you may get two jobs fail at the same time.

2) Have a common auto recovery job but have them in different applications. That way your failing job would add a unique application to the current plan, and you can then work out what the associated job name is that caused it to be added. Either pass in the Application ID as a variable to your job and have your job cross reference the job name from there, or use JCL variable tables to associate the application that the job is running in with the failed job that added it. That way you could achieve what you want, i.e.; pass failing job name in to your recovery job, but you would need a seperate application for each one and an entry in the JCL variable table. It depends on how many you're talking about doing as to whether you think this is viable.

The other question is whether this is the best way to achieve your goals. Why not use system automation to initiate a job whenever the EQQE036I message is issued to the syslog? That way it would be simple to pass in the failing job name as a paramter.
Blackthorn
 
Posts: 98
Joined: Tue Feb 01, 2011 7:12 pm
Has thanked: 0 time
Been thanked: 2 times


Return to Other IBM Tools

 


  • Related topics
    Replies
    Views
    Last post