To run the same job multiple times if a condition is met.

yogalakshmi · New User Joined: 20 Sep 2007 Posts: 17 Location: cheenai

We have a problem that I have explained below.

We have a job that reads records from the file and writes it to the MQ. Sometimes, the job fails because the MQ that it is writing to is full. If the job is restarted after some time, the job will run successfully because by that time the MQ woud have become available.

As the job frequently abends , we are looking for a permanent solution.

1. The program will set a particular return code when the MQ is full and end.
2. The subsequent step in the proc will check for this return code, it will create a new GDG version.
3. This new GDG version should trigger the same job again via CA7 and the triggered job should run after some time delay.

Is it achievable via CA7.Is there any other solution to the problem?

Thanks a lot.

dbzTHEdinosauer · Posted: Sat Jun 18, 2011 1:05 pm

instead of trying to fix the symptom - job ending because mq full,
either

cure the illness - insure the process that reads the queue is provided the resources to keep it empty
insure the 'write' job does not simply end, but waits and retries until the queue has room and successfully PUTs to the queue

explanations for the above:

1. you do not want a queue to fill-up. using mqs to warehouse messages is not good. you can add another task to 'read' the queue.
you are using mqs because it facilitates the process of moving 'important information' from one place to another in a timely manner. Otherwise you would just send datafiles.

2. you can put a 'WAIT' on an mq GET, probably can put a 'WAIT' on an mq PUT. if not, use an assembler routine to 'WAIT' without using resources. makes no sense to stop a job that encounters something that 'time' will cure. If the queue is not there, that is one thing, but if it is full, it makes not sense to stop, create yet another file and start another task. That is too resource intensive. Plus, since you are working with GDG's, you are running the risk of losing a file due to jcl construct error.

Increase your resouces for 'draining' the queue.

yogalakshmi · New User Joined: 20 Sep 2007 Posts: 17 Location: cheenai

Hi Dick,

There is a server program that reads the messages in the MQ parallely. The speed at which it reads the messages from the MQ is slower than the speed at which the messages are put to the MQ. We have checked with server side if they can run multiple instances that will read messages from the MQ.They said it is very difficult and it requires a huge design change. The reading application is powercentre component and the putting application is mainframe batch.So, we are left with fixing the problem.

Yes. We are thinking of introducing the WAIT. But we are not sure if it is acceptable as per our standards, and we are yet to check it with our Batch Service Team.

Meanwhile, we are thinking of some other solutions that are feasible.

dbzTHEdinosauer · Posted: Sun Jun 19, 2011 7:58 pm

is this question the same as this thread? ibmmainframes.com/viewtopic.php?t=53926

sounds as if Powercenter is a piece of crap.

you never design a system where the receiver cannot drain the queue in an adequate timeframe.

just because the powercenter people are incompetent,
does not mean that the batch side has to make concessions.

why don't you do this:

when powercenter realizes that the que is empty, send a message to batch, which will trigger a job to start the puts.

but, if this question is the same as the other thread - where the online is also PUTting, you are going to reach a point where the batch will never run.

this reminds me of Mcmillan's Joke:
could not fix the breaks, so we made your horn louder.

dbzTHEdinosauer · Posted: Sun Jun 19, 2011 7:59 pm

as an answer to your basic question:

can ca7 be set up to re-run all the time.

yeah, but, you are going to reach a point of saturation where the batch will never be able to run.

dbzTHEdinosauer · Posted: Mon Jun 20, 2011 3:29 am

the WAIT option is not available for an MQPUT.

so, either CALL an assembler routine which CALLs BPX1SLP (sleep/WAIT macro),
or figure out a good restart strategy which adequately handles gdg's properly.

the problems to surmount with the later are insuring that you are accessing the appropriate generation.

the reason I continually reiterate the gdg problem is that potentially you could have more than one job that needs to be restarted due to the queue full problem.

i would not place the 'messages to be sent' into a gdg until the messages were sent. (second step in the MQPUT job to be executed upon successful completion of the MQPUT).

you could generate a multiple node dsn based on date and time,
that would be constant until the messages are written. then the date&time ds would be copied to a gdg and then deleted.

This method would make the restart process very easy and you would never have to worry that the proper generation is being referenced,
especially if you had, e.g. 3 files to transfer.