Qsysopr Break Handling Programa
Folks - model 820 V5R1The following code is run from the console daily for our backup.DLYJOB RSMTIME('23:30:00')ENDSYS DELAY(120)MONMSG MSGID(CPF0000)DLYJOB DLY(180)INZTAP DEV(TAP01) NEWVOL(DAILY) NEWOWNID(CFP) +CHECK(.NO)MONMSG MSGID(CPF0000 CPA0000)DLYJOB DLY(60)- followed by the various save commandsSTRSBS SBSD(QCTL)occasionally there will be a problem with the tape, or a failure to putone in, or a write-protected tape. Last night, the INZTAP failed, andthe system waited for.
The following message was in the log.Additional Message InformationMessage ID.: CPA4086 Severity.: 99Message type.: InquiryDate sent.: 03/10/03 Time sent.:23:34:02Message.: Device TAP01 was not ready or next volume was notloaded.(C R)Cause.: Either the device TAP01 is not ready or the nexttapevolume is not loaded on TAP01.Recovery.: Do one of the following:- Type C to cancel processing.- Make device TAP01 ready, and type R to try the open operationagain.- Put the next volume on device TAP01, and type R to try the openoperation again.My question is. Why did the MONMSG on the INZTAP not trap thiserror and continue on? I want to add code to have an email generated,but if the error is not caught that code is useless.TIA - Tom J.THIS MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, downloading, storing or forwarding of this communication is prohibited.
If you have received this communication in error, please notify us immediately via email and delete the message from your computer files and/or data base. Thank you.This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing listTo post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/.@public.gmane.orgTo subscribe, unsubscribe, or change list options,visit: email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/.@public.gmane.orgBefore posting, please take a moment to review the archivesat http://archive.midrange.com/midrange-l. The following code is run from the console daily for our backup.DLYJOB RSMTIME('23:30:00')ENDSYS DELAY(120)MONMSG MSGID(CPF0000)DLYJOB DLY(180)INZTAP DEV(TAP01) NEWVOL(DAILY) NEWOWNID(CFP) +CHECK(.NO)MONMSG MSGID(CPF0000 CPA0000)DLYJOB DLY(60)- followed by the various save commandsSTRSBS SBSD(QCTL)occasionally there will be a problem with the tape, or a failure to putone in, or a write-protected tape. Last night, the INZTAP failed, andthe system waited for. The following message was in the log.Message ID.: CPA4086 Severity.: 99Message type.: InquiryMy question is.
Why did the MONMSG on the INZTAP not trap thiserror and continue on? I want to add code to have an email generated,but if the error is not caught that code is useless.Hi Tom!MONMSG only traps the messages indicated in the command help. It doesn'ttrap inquiry messages destined for the system operator (like 'Make the tapedrive ready' or 'Change the paper on the printer') To see the messages thatcan be trapped, go to a command line, type INZTAP, press F1 for help and F2for complete help. You'll see a list of messages there.What you really need is to have a break handling program on QSYSOPR inaddition to the error trapping in your CL. There are commercial productswhich perform this very task. Robot is one that springs to mind, but thereare others.-buckThis is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing listTo post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/.@public.gmane.orgTo subscribe, unsubscribe, or change list options,visit: email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/.@public.gmane.orgBefore posting, please take a moment to review the archivesat http://archive.midrange.com/midrange-l. But if the error is not caught that code is useless.Hi Tom!MONMSG only traps the messages indicated in the command help.
Itdoesn'ttrap inquiry messages destined for the system operator (like 'Make thetapedrive ready' or 'Change the paper on the printer') To see the messagesthatcan be trapped, go to a command line, type INZTAP, press F1 for helpand F2for complete help. You'll see a list of messages there.What you really need is to have a break handling program on QSYSOPR inaddition to the error trapping in your CL.
There are commercialproductswhich perform this very task. Original Message-Sent: Tuesday, March 11, 2003 12:51 PMSubject: RE: MONMSG not monitoringThanks.
QSECOFR (security officer); QPGMR (programmer); QUSER (user); QSYSOPR (system operator); QSRVBAS (basic service representative); QSRV (service representative). To enter new. In this chapter, I'll explore three methods of message processing: the system reply list, break handling programs, and default replies. VRC-PRO is the world's best RC Racing simulator. Join the other thousands of drivers for. Sign up for your Free-to-Play today and see why all the top drivers use VRC-PRO. In your break handing program, pass any messages that need attention to the QSYSOPR2 queue. AS/400 msgq break handling program. Qsysopr Break Handling Program Proposal Template. If no break appears, the flow of control will fall through to subsequent cases until a break is reached. A switch statement can have an optional default case, which must appear at the end of the switch. The default case can be used for performing a task when none of the cases is true. No break is needed in the default case. Flow Diagram Example.
I did not know you could find the monitorable messages on thehelp, was it recently added?Regarding the problem. Given that this is the only thing going onon the system after hours the purchase of software to manage QSYSOPR isoverkill. Any thoughts regarding the wisdom of adding an entry to theSYSRPYL for this message? At that point the.escape message should getback to the program, right?Take care. But if the error is not caught that code is useless.Hi Tom!MONMSG only traps the messages indicated in the command help.
Itdoesn'ttrap inquiry messages destined for the system operator (like 'Make thetapedrive ready' or 'Change the paper on the printer') To see themessagesthatcan be trapped, go to a command line, type INZTAP, press F1 for helpand F2for complete help. You'll see a list of messages there.What you really need is to have a break handling program on QSYSOPR inaddition to the error trapping in your CL.
There are commercialproductswhich perform this very task. Robot is one that springs to mind, butthereare others.-buckThis is the Midrange Systems Technical Discussion (MIDRANGE-L)mailinglistTo subscribe, unsubscribe, or change list options,visit: posting, please take a moment to review the archivesat MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITYTO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT ISPRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLELAW.
If the reader of this message is not the intended recipient, orthe employee or agent responsible for delivering the message to theintended recipient, you are hereby notified that any dissemination,distribution, copying, downloading, storing or forwarding of thiscommunication is prohibited. If you have received this communicationin error, please notify us immediately via email and delete themessage from your computer files and/or data base.
Another option is to put the necessary code within your CL backup program toreceive the inquiry messages using RCVMSG and handle it all within yourprogram.You can then use the SNDRPY command to send a reply to the inquiry messageand answer it so the the program can retry, end, or whatever. Then performa CHGJOB LOG(4 00.SECLVL) LOGCLPGM(.YES) so the job will produce a job logand send yourself, the QSYSOPR message queue, or both a message indicatingthat the backup job ended in error.The only potential problem is that SNDRPY must gain exclusive control of theQSYSOPR message queue in order to reply to the message. To prevent thisproblem, you could change the device description of the tape drive to use amessage queue other than QSYSOPR (maybe call it BACKUP), one that you knowno one will have allocated or in break mode.HTH,Steve LandessAustin, Texas(512) 423-0935- Original Message -From: 'Bob Crothers' To: 'Midrange Systems Technical Discussion' Sent: Tuesday, March 11, 2003 12:26 PMSubject: RE: MONMSG not monitoring. Original Message-Sent: Tuesday, March 11, 2003 12:51 PMSubject: RE: MONMSG not monitoringThanks.
I did not know you could find the monitorable messages on thehelp, was it recently added?Regarding the problem. Given that this is the only thing going onon the system after hours the purchase of software to manage QSYSOPR isoverkill.
Any thoughts regarding the wisdom of adding an entry to theSYSRPYL for this message? At that point the.escape message should getback to the program, right?Take care. But if the error is not caught that code is useless.Hi Tom!MONMSG only traps the messages indicated in the command help. Itdoesn'ttrap inquiry messages destined for the system operator (like 'Make thetapedrive ready' or 'Change the paper on the printer') To see themessagesthatcan be trapped, go to a command line, type INZTAP, press F1 for helpand F2for complete help. You'll see a list of messages there.What you really need is to have a break handling program on QSYSOPR inaddition to the error trapping in your CL.
There are commercialproductswhich perform this very task. Robot is one that springs to mind, butthereare others.-buckThis is the Midrange Systems Technical Discussion (MIDRANGE-L)mailinglistTo subscribe, unsubscribe, or change list options,visit: posting, please take a moment to review the archivesat MESSAGE IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITYTO WHICH IT IS ADDRESSED AND MAY CONTAIN INFORMATION THAT ISPRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLELAW. If the reader of this message is not the intended recipient, orthe employee or agent responsible for delivering the message to theintended recipient, you are hereby notified that any dissemination,distribution, copying, downloading, storing or forwarding of thiscommunication is prohibited. If you have received this communicationin error, please notify us immediately via email and delete themessage from your computer files and/or data base.
But if the error is not caught that code is useless.Hi Tom!MONMSG only traps the messages indicated in the command help. Itdoesn'ttrap inquiry messages destined for the system operator (like 'Make thetapedrive ready' or 'Change the paper on the printer') To see the messagesthatcan be trapped, go to a command line, type INZTAP, press F1 for helpand F2for complete help.
You'll see a list of messages there.What you really need is to have a break handling program on QSYSOPR inaddition to the error trapping in your CL. There are commercialproductswhich perform this very task. Regarding the problem.
Given that this is the only thing going onon the system after hours the purchase of software to manage QSYSOPR isoverkill. Any thoughts regarding the wisdom of adding an entry to theSYSRPYL for this message? At that point the.escape message should getback to the program, right?It doesn't hurt to try to give iSeries software houses a bit of business.One never knows. Anyway, I would hesitate to use the SYSRPYL for thisapplication.
I'm not one to blindly terminate a running process withouthaving a person look at it first. As Bob says, a break handling programseems more the order of the day.-buckThis is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing listTo post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/.@public.gmane.orgTo subscribe, unsubscribe, or change list options,visit: email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/.@public.gmane.orgBefore posting, please take a moment to review the archivesat http://archive.midrange.com/midrange-l. The following code is run from the console daily for our backup.DLYJOB RSMTIME('23:30:00')ENDSYS DELAY(120)MONMSG MSGID(CPF0000)DLYJOB DLY(180)INZTAP DEV(TAP01) NEWVOL(DAILY) NEWOWNID(CFP) +CHECK(.NO)MONMSG MSGID(CPF0000 CPA0000)DLYJOB DLY(60)- followed by the various save commandsSTRSBS SBSD(QCTL)occasionally there will be a problem with the tape, or a failure to putone in, or a write-protected tape.
Last night, the INZTAP failed, andthe system waited for. The following message was in the log.What you really need is to have a break handling program on QSYSOPR inaddition to the error trapping in your CL. There are commercial productswhich perform this very task. Robot is one that springs to mind, butthere. If you want a cheap way to guarantee your SBS will be started, add aSTRSBS SBSD(QCTL) to the job scheduler at the 'dropdead' time yoursystem has to be up.How's the scheduled job going to run if no subsystems are active?Cheers,Martin.-Martin McCallionSenior Technical ConsultantWork: martin.mccallion-.@public.gmane.orgHome: martin.mccallion-0OF+.@public.gmane.orgMisys International Banking Systems1 St George's Road, London, SW19 4DR, UKT +44 (0)20 8486 1951F +44 (0) 20 8947 3373www.misys.comThis email message is intended for the named recipient only.
It may beprivileged and/or confidential. If you are not the intended namedrecipient of this email then you should not copy it or use it for anypurpose, nor disclose its contents to any other person.
You shouldcontact Misys International Banking Systems as shown below so that wecan take appropriate action at no cost to yourself.Misys International Banking Systems Ltd,1 StGeorge's Road, London, SW19 4DR, UK. Email: ibs.postmaster-9zZPVWNGod1fmgfxC/sS/.@public.gmane.orgTel: +44 (0) 20 8879 1188 Fax: +44 (0) 20 8947 3373Misys International Banking Systems Ltd isregistered in England and Wales under company no. 971479This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing listTo post a message email: MIDRANGE-L-Zwy7GipZuJhWk0Htik3J/.@public.gmane.orgTo subscribe, unsubscribe, or change list options,visit: email: MIDRANGE-L-request-Zwy7GipZuJhWk0Htik3J/.@public.gmane.orgBefore posting, please take a moment to review the archivesat http://archive.midrange.com/midrange-l.
So I am trying to create a very generic error handling procedure so that at the very least every program in our shop has it. Right now it is just wrapping a main procedure in a monitor and if it errors pass the psds to a service program. The service program logs the error so that we can set up tickets to get them fixed.
Simple enough except that with the sub procedure the line number in the psds reflects the procedure and not actually where the error was, is there a way to change that or a better way? So basically you would do the below.
Then use the QMHSNDPM to push the error up if it is not handled. That was my next step to figure out how to keep an error from getting ignored and make sure it stops programs up stream depending on if it is an interactive job or batch job. An interactive job we just want to pop a simple message to the user saying there was an issue. And batch jobs we still want to pop up the normal halt as we have a monitoring job that looks for messages, emails the group, and lets us answer through email if we want.
I have been developing this when I have time, I have used the QMHSNDPM to send job log messages and QMHSNDBM to send break messages which is getting us closer to what we want though needs more work. The one request I had from my manager was the ability to send the regular system message when the program is in development. So in a sense remove the monitor/messaging handling automatically so that when someone is developing they see the normal message and are able to give a response. Not sure this is possible as once the monitor is tripped I don't think you can just send it back to where it was and let it continue. I'm not sure that I understand where you are stuck.ESCAPE messages do cause an exception, so you should monitor for that unless you want the OS to handle them (causing your program to 'crash')One I approach that I sometimes use (and like a lot) is to send an.ESCAPE message to my caller. The caller will, in turn, monitor for any exceptions and re-send them to it's caller, etc.
So if an exception occurs in a service program, it gets sent back to the program that used it. That program monitors for, and re-sends the escape message to the program that called it, etc. How to install dbms_network_acl_admin package in 11g. This percolates all the way back up the call stack until it gets to something that I didn't write (such as an OS screen, like a menu) where the OS says the program ended in error.Obviously, that is for 'unexpected' errors. For expected errors, the program just handles them and continues on it's merry way.You say that yours is failing when you get to the 'top of the call stack'. But the top of the call stack should be an OS program, right? So in a batch job, the job would go to MSGW.
Qsysopr Break Handling Programacion
In an interactive program, it would show the error at the bottom of the screen saying that it failed. If that's not working, it sounds like you're not percolating the message all the way to the OS program?Unfortunately, the English language is not very precise. It'd be much easier to understand if you showed us exactly how to reproduce the problem you're stuck on. I think I got it now, I was not putting the correct number into the call stack counter and that was causing it to blow up when sending escape message instead of displaying it once it got back to the OS.
Either way here is some code if anyone has any other suggestions, so far it seems to be working well in my tests. The goal was just to provide some very easy to use code and guidelines on new programming so that at the very least we don't splash up system messages to our users. So far it does it and does not let the programs continue since our users would just give a C anyway. Code:// header specifications/Include misjd/qcpysrc,copyhspec// include procedure definitions/Include misjd/qcpysrc,copyallprc// copy psds/Include misjd/qcpysrc,copypsdsMonitor;Main;MiscPSndMsg('prctest3 continued');On-Error;MiscPGeneralError(pgmsds);EndMon;.inlr =.on;return;Dcl-Proc Main;Dcl-S result packed(1);dcl-s one packed(1) inz(1);dcl-s zero packed(1) inz(0);Monitor;result = one / zero;On-Error;MiscPGeneralError(pgmsds);EndMon;MiscPSndMsg('prctest3 main continued');End-Proc;Service Program code.
Qsysopr Break Handling Programas
The one request I had from my manager was the ability to send the regular system message when the program is in development. So in a sense remove the monitor/messaging handling automatically so that when someone is developing they see the normal message and are able to give a response. Not sure this is possible as once the monitor is tripped I don't think you can just send it back to where it was and let it continue.I don't know of a way make it go back to the statement following the one that caused the error, JJ. The only way I know of to run it one way in production & another in test is to use compiler directives to condition the monitor message. Something like this.