Jobs on iSeries autoanswer by itselfs.

I have some scheduled jobs that when those fail, and a message is being sent, these jobs get an autoanswer from the system. Do anybody know why?  I need to avoid these "autoanswers"  from the iseries server.

Thanks
C--Users-mx071654-Pictures-iserieserr2.j
C--Users-mx071654-Pictures-iserieserr1.j
Apolo VictoresIT Infrastructure Supervisor and Networking Sp.3MAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Gary PattersonVP Technology / Senior Consultant Commented:
You can configure the system to automatically reply to certain messages using the WRKRPYLE command.  Some third-party software can also be used to automatically respond to messages.
tliottaCommented:
I read the problem as "I do NOT want the messages responded to, but only for specific jobs."

Since these seem to be batch jobs, you might review the DLVRY() setting for the QSYSOPR *MSGQ. Then review the INQMSGRPY() parameter of the job description used for those jobs. Post those back here.

Also, post the message IDs that (1) indicate what the *ESCAPE problems are and (2) indicate that the *ESCAPE message received a response (this one will probably be a *COMPLETION message). Pick any couple of jobs that have the problem.

The fix will be according to the details of the problem.

Tom
Gary PattersonVP Technology / Senior Consultant Commented:
@Tom,  I read it that way, too.  Tight for time at the moment I wrote that and thought the pointer to the reply list might be a nudge in the right direction.
Exploring ASP.NET Core: Fundamentals

Learn to build web apps and services, IoT apps, and mobile backends by covering the fundamentals of ASP.NET Core and  exploring the core foundations for app libraries.

Apolo VictoresIT Infrastructure Supervisor and Networking Sp.3MAuthor Commented:
Thank you Mr. Liotta, let me explain myself better, This job is a call program procedure, I  didn't do this program,, but certainly I was asked about why this job was doing this weird behavior (it was answering the error message by itself). I can attach another picture about this job in order to explain better the process, and as you can see, all the related messages are answered by itself.

In any way, I have done your recommendations and hope it can be solved.
Other important thing is that this situation started when we migrated from V6.1  to V7R1  OS version.
C--Users-mx071654-Pictures-iSeries-seque
tliottaCommented:
For future questions, images are often less useful than simple copy/paste of text. It's hard to copy text like message IDs and error text out of an image in order to run searches. If a simple typo causes a search for the wrong message ID, it might give incorrect results or at least delay results.

Also, the message IDs aren't shown. The first message appears to be RPG1218 and the program would be in ILE RPG.

The correct direction is to have program OP09141 handle the record allocation problem. It fails because it was programmed to fail. The developer didn't tell the program what to do when this error occurs, so the program has to turn the error over to the default RPG error handler with error RPG9001. And since there is no handler assigned for that, the RPG default is to signal a system error with CPF9999. And since there is no handler assigned for that, the job fails.

Given the various alternatives, what do you want to happen when RPG1218 happens in this job? The only two reasonable alternatives would be 'R'etry or nothing. A 'R'etry for this in a batch job is very likely not a good idea. That could start a loop that could cause more trouble than a canceled program. Unlikely, but possible. So the most reasonable action is "nothing".

For RPG1218, a reply list entry (seen with WRKRPYLE) would reference RNQ1218, the *INQUIRY version of RPG1218. But it's not clear what "reply" you'd want to send. I would assume that you want it to be '*RQD' to force a manual reply.

However, since there is no standard reply entry for RNQ0000 messages by default and you are getting a reply from somewhere, I'd guess first that your QSYSOPR *MSGQ is set to send the default reply.

You could create a reply list entry to indicate '*RQD', but with QSYSOPR set to reply with the default reply of 'C'ancel, you'll be right back where you are now. QSYSOPR is where batch inquiries are sent.

The reply list would only be accessed if the batch job has the INQMSGRPY(*SYSRPYL) attribute. You might instead submit the job with INQMSGRPY(*RQD) to force a manual reply, but that would again come back to QSYSOPR providing the *DFT reply and 'C'ancel being the result.

To me, it comes back to fixing program OP09141. Avoid the whole mess. Otherwise, what exactly do you want to happen? If you change the QSYSOPR DLVRY() attribute, will that cause trouble for other jobs?

Tom
Apolo VictoresIT Infrastructure Supervisor and Networking Sp.3MAuthor Commented:
Thanks for your help!,, and  I would like your advise if you can teach me how to add the *RQD parameter in the WRKRPYLE  command. Please! , I also have talked with the programmer in order to check and modify the code.

Thanks!
Gary PattersonVP Technology / Senior Consultant Commented:
Tom is suggesting that you might need to change the SBMJOB command that is used to submit this job to batch (assuming that is how it is submitted).  When you submit a job using SBMJOB, you have a choice about how to handle inquiry messages,and that choice is controlled by the INQMSGRPY parameter.  This is right form the help text for the command:

Help               Inquiry message reply (INQMSGRPY) - Help              
                                                                         
    Specifies the way that predefined messages that are sent as a result
    of running this job are answered.  You can specify that the inquiry  
    message reply control is taken from the job description, or that all
    inquiry messages require a reply, or that a default reply is issued,
    or that the system reply list is checked for a matching reply as    
    each predefined inquiry message is sent.                            
                                                                         
    *JOBD                                                                
        The inquiry message reply control specified in the job          
        description used with this job is used.                          
                                                                         
    *RQD                                                                
        A reply is required by the receiver of the inquiry message for  
        all inquiry messages that occur when this command is run.        
                                                                         
    *DFT                                                                
        The default message reply is used to answer any inquiry messages
        issued when this command is run.                                

    *SYSRPYL                                                            
        The system reply list is checked to see if there is an entry for
        any inquiry message that is issued as a result of running this  
        job that has a message identifier and any comparison data that  
        match the inquiry message identifier and message data.  If a    
        match occurs, the reply value in that entry is used.  If no    
        entry exists for that message, a reply is required.            
                                                                       
Take a look at the SBMJOB command used to submit the job in question, and post the INQMSGRPY value currently being used.
tliottaCommented:
I'm also suggesting that a reply list entry might not make any difference if QSYSOPR *MSGQ is configured to send the "manual" reply automatically.

It seems as if that's the case. If so, a reply list entry will just change the logic route and the reply will still be sent. The result will be the same as it is now.

The QSYSOPR *MSGQ needs to be changed to DLVRY(*HOLD) in order to stop the replies from being sent (assuming it's not *HOLD now). But that will possibly change things in other parts of the system. It's necessary first to verify the QSYSOPR *MSGQ mode, and second to determine why that mode is currently assigned.

Tom

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Apolo VictoresIT Infrastructure Supervisor and Networking Sp.3MAuthor Commented:
Thank you!,, for certain I will check the QSYSOPR mode. And then discuss with the IT development people.

Thanks!!
Apolo VictoresIT Infrastructure Supervisor and Networking Sp.3MAuthor Commented:
Excellent advise!

Thnks!!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
IBM System i

From novice to tech pro — start learning today.