How to avoid MSGW in a DATA Queue

240 pts.
Tags:
AS/400
Data Queue
MSGW
I have a Program A which sends a message to a data queue , There is a job running on the System i , which monitor this data queue , and when it receives a message in this queue a set of programs is called . The problem is when one of the programs has a error , my job queue goes into MSGW , and the next set of messages which arrives remains in the data Queue and does not gets processed . Why we made it like this as the frequency of the messages arriving to data ques is high , so if instead of doing this if we have submitted a job then each time a new job is submitted , a lot of resourcess and CPU time is utilized , How can i resolve this issue ????

Software/Hardware used:
AS400 COBOL , AS400 version V6R1M
ASKED: December 19, 2012  4:35 AM

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 9  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • asakla
    Hi Tom , 

    Theres no specific code where we have a error , 
    Its like we can get a machine error in a COBOL program at any point of time , beacase of a wrong DATA , 


    240 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • asakla
    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
    240 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report
  • TomLiotta
    Apparently for some reason I can't add my intended comment to this thread. It just keeps disappearing. -- Tom
    125,585 pointsBadges:
    report
  • asakla
    :( :( :( if possible you can email me the solution at ashish.sakla@gmail/com
    240 pointsBadges:
    report
  • TomLiotta
    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
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following