The problem is when one of the programs has a error , my job queue goes into MSGW
 
If that’s what you want to resolve, then handle the problem that causes the job to go to MSGW status. Either handle the error directly or respond to the message that’s waiting.
 
We can’t tell you how because you haven’t shown any code that gives the problem.
 
Tom

Hi Tom , 

beacase of a wrong DATA ,
 
How can you have wrong data? Fix the data and the data won’t cause errors.
 
Theres no specific code where we have a error , 
Its like we can get a machine error in a COBOL program
 
Then the COBOL program is where the error should be handled. Why is that a problem? Don’t you test data before using it the first time? Do you use ON ERROR clauses? Do you use procedure-level condition handlers set? Is this ILE or OPM COBOL?
 
A couple examples of actual errors and the statements that failed would make this easier.
 
 
Tom

The data comes from other systems , so thay may be wrong sometimes , What we want is if data is wrong and there is a error we need to avoid the MSGW so as the other incoming datas dont bgets stucked in data Queue .It is a ILE COBOL its just like we got a MCH1202 (decimal data error and so on) , which comes during runtime , In a CL we can do a MONMSG but how we avoid this in a COBOL

The data comes from other systems , so thay may be wrong sometimes
 
Raw data from another system should always be tested and cleaned before being used.
 
In a CL we can do a MONMSG but how we avoid this in a COBOL
 
Set a condition handler for unanticipated errors. It’s best to ensure data items are valid before using them, though.
 
Code Declaratives sections for procedures. Use a [IF identifier NUMERIC] test before doing any arithmetic operations with any raw value. Or use INSPECT to verify valid characters in a string. For any arithmetic operation, use ON SIZE ERROR to help with reasonableness tests.
 
You can check (monitor) for any kind of data error in COBOL. It would be best if you called a routine to validate any data before calling your COBOL with raw data. Only call the COBOL if that piece of data passes your tests.
 
Tom

The data comes from other systems , so thay may be wrong sometimes
 
Raw data from another system should always be tested and cleaned before being used. Test it and fix it first.
 
In a CL we can do a MONMSG but how we avoid this in a COBOL
 
Set a condition handler for unanticipated errors. It’s best to ensure data items are valid before using them, though.
 
Code Declaratives sections for procedures. Use a [IF identifier NUMERIC] test before doing any arithmetic operations with any raw value. Or use INSPECT to verify valid characters in a string. For any arithmetic operation, use ON SIZE ERROR to help with reasonableness tests.
 
You can check (monitor) for any kind of data error in COBOL. It would be best if you called a routine to validate any data before calling your COBOL with raw data. Only call the COBOL if that piece of data passes your tests.
 
Tom

Apparently for some reason I can’t add my intended comment to this thread. It just keeps disappearing. — Tom

 if possible you can email me the solution at ashish.sakla@gmail/com

I think the post will show up sometime in the morning. I realized it had a couple links and will need to be approved. It’s not a solution. The solution is to fix the data (or discard it) before calling the processing programs. Other parts link to COBOL reference pages for error handling. — Tom