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?
Joined: 20 Oct 2006 Posts: 6970 Location: porcelain throne
instead of trying to fix the symptom - job ending because mq full,
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.
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.