• Effective Ball Handling Program
• File Handling Program

Is it a rule that a message queue break handling program cannot be called recursively? Chgmsgq msgq(qsysopr) dlvry(.break) pgm(mypgm) When a message arrives in the message queue my break handling program is called.

Message break-handling program helps you monitor inquiry messages. Message queue is in *BREAK mode and a + break handling program is. In QSYSOPR, you get a.

The issue I am having is when a 2nd message arrives in the message queue before the break handling program has returned from handling the first message, the 2nd message does not break into the break handling program. Is this clear? Am I correct that the message queue break handling program has to return before the system calls the break handler program with the next message? Thanks, -Steve. I also found that behaviour.

I think that the msgq knows the break handling program is already active so even if the program is recursive/re-entrant it will not be called. It dosnt always seem to be called when the user is displaying messages including program messages like the 'enter CDIR' type. I use a remote screen view program which uses this method to interrupt the users job & grab their screen.

The other alternative I have considered is strsrvjob then trcjob with an exit program specified. It works OK on a 1 off basis (eg a 1 line cl pgm with rollback as the command) but the exit program is called multiple times & you have to take that into account. The advantage is that a batch job with no workstation message queue can also be targetted. That is the behavior I see also. The system appears to call the break handler for every message in the queue, regardless of when the message arrives in the queue. What I am trying to do is mimic the behavior of the QSYSOPR message queue when it is in break mode, with the addition of automated handling of some of the messages. The problem is that when the break handler calls my DSPMSG equivalent program to display the contents of the message queue, the break handler does not get called again until the message queue display program exits.

To get around this I am spawning a 2nd job which will run the break handler code. Then I have a 2nd message queue that is used to break into the interactive job and display the just arrived QSYSOPR messages. A bit more code than I had planned for.

I dont think I studied it so well as you - I imagined some messages did not lead to the break program running. I think its behaviour makes som sense though. If you had so many messages the break handler might never complete before the next message arrives and so at th end of the day just as everyone leaves the final message will be processed & appear on the 2nd users screen, followed by the penultimate message & so on leaving the 1st message to come out last. Or am I just being a bit pessimistic?

I think you would get some swapping of messages if it was allowed to happen. Maybe you could try making the 1st instruction of the handler could reset the message Q to be in break mode & point to the correct program & see if this overrides its waiting. That seems to be overly restrictive wording on the part of IBM.

Regardless of what is done by the msgq break handler, you can still dspmsg qsysopr to display and respond to messages in the qsysopr msgq. What you lose is ability to break the qsysopr messages on the display.

There are many shops that dont have someone monitoring the message queue, so I dont see the reason for high concern. Anyway, I have written my own version of DSPMSG QSYSOPR to break and display the messages to the operator. Because I only want the messages that are not automatically responded to to break on the display in the computer room for the operator to respond to.

If an.inq message breaks on the qsysopr message queue the operator will assume a response is needed. But if the background job is responding every interval to some messages things could ge confusing. Or perhaps IBM knew that it wasn't going to be that easy to do it - as you are now finding out.;-) So, why not have a second message queue (QSYSOPR2) also in break mode in the QSYSOPR job. In your break handing program, pass any messages that need attention to the QSYSOPR2 queue.

In your break handling program, loop around before returning and read any messages that have arrived in the meantime. This (should) hopefully get around the not-being-called-if-already-active problem and the operator will still respond to break messages in his/her usual way.

Similar Threads 1. I'm trying to do what I thought would be simple in SQL. That is making an old fashion control break, where one field only prints when it changes and the other fields print for each record. I've hunted and hunted for an examples of this with out success, leaving me to believe that no one does this any more or it's so simple no one needs to discuss it. Thanks in advance for any help.

Sample SQL statement is. I want 'Board Name' to only print when it changes. SELECT ADMLIB.ADP0001.CMLNAM AS 'Board Name', Trim(BDMFST) ' ' BDMLST AS 'Member's Name', substr(BDMFDT,1,2) '/' substr(BDMFDT,3,2) '/' substr(BDMFDT,5,4) AS 'First Term', substr(CDMCDT,1,2) '/' substr(CDMCDT,3,2) '/' substr(CDMCDT,5,4) AS 'Current Term Started', substr(BDMEDT,1,2) '/' substr(BDMEDT,3,2) '/' substr(BDMEDT,5,4) AS 'Current Term Ends' FROM ADMLIB.MEMBERS INNER JOIN ADMLIB.ADP0001 ON ADMLIB.MEMBERS.BDCODE = ADMLIB.ADP0001.CMCODE ORDER BY 'Board Name' ASC 2. Hi Steve, You can use the 'List ILE Program Information (QBNLPGMI)' API, format PGML0200 to retrieve a list of all service programs bound to a program.

Furthermore the 'List Service Program Information (QBNLSPGM)' API, format SPGL0800 can be used to get a list of all signatures of a given service programs. So basically combine these two APIs to check for signature violations. Thomas Raddatz. PS: I do not have any idea how to automatically handle a MCH4431 message.

Steve Richter wrote: any ideas how to automatically handle escape message mch4431 - program signature violation? it is easy enough to write a cl program that would read the message data and rebind the program in error. But how to call that program automatically, without using monmsg that uses custom code to redo the call that failed. baring that, can I check every program and service program in a library for existing program signature violations? I have this external USB HD that I only turn it on when needed. One time, when trying to mount, it asked if I would like to check the HD. I clicked yes, and it started checking for a while but stopped at 99%.

Maybe I was too impatient, I turn it off and tried to mount it again. After attempting with disk reading noise, it couldn't. It gave a message that the HD needed to be formatted to use. The drive changed its name to 'Local Drive.' I tried a few programs and it seems that I can recover files with programs such as R-Studio but I can't mount the drive. It's rather inconvenient to retrieve files this way. I'd like to mount the drive and copy some files and then reformat the drive.

Is there a program to mount a HD like the condition my HD is in? Thanks, liu 6. Hi All, I have a break-handler program on the QSYSOPR message queue. Everything works exactly as advertised except that the operators are complaining that they can not interact with the QSYSOPR from the green-screen 5250 using DSPMSG.

Stated differently, when I issue the CHGMSGQ command to associated the break-handler program with the QSYSOPR message queue, CHGMSGQ obtains an exclusive lock on the message queue. The break-handler program does not manipulate or remove the messages, it only reads from the queue. Is it possible to have a break-handler program that does not obtain an exclusive lock? Here is the CHGMSGQ command: CHGMSGQ MSGQ(QSYSOPR) DLVRY(.BREAK) PGM(LIB/PGM.ALWRPY) SEV(10) Thanks in advance, Tony 8.

Effective Ball Handling Program

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the and the. Mode for every 'Job completed.' However, I don't want inquiry messages sitting without response for long periods. Instead, I have a break-handling program that manages incoming messages according to what kind of message is received. Messages requiring a response will break into my current job. Other messages display, as they are received, on the message line without interrupting me.

/. The following three input parameters are standard for a + 'Break Handling' program./ PGM PARM(&MSGQ &MSGQLIB &MSGKEY) DCL &MSGQ.CHAR 10 /. Queue where the msg is./ DCL &MSGQLIB.CHAR 10 /. Queue library./ DCL &MSGKEY.CHAR 4 /. Key of the received msg./ DCL &MSGID.CHAR 7 /.

ID of the received msg./ DCL &RTNTYPE.CHAR 2 /. Type of the received msg./ DCL &MSG.CHAR 78 /. Msg text./ DCL &OPEN.CHAR 1 VALUE(X'21') /. Rev img./ DCL &CLOSE.CHAR 1 VALUE(X'20') /. Normal attrib./ /.

When your message queue is in.BREAK mode and a + break handling program is assigned, the program + is automatically called when a message arrives + and the three parameters are apssed so that the + message can be received./ RCVMSG MSGQ(&MSGQLIB/&MSGQ) MSGKEY(&MSGKEY) + RMV(.NO) MSG(&MSG) MSGID(&MSGID) + RTNTYPE(&RTNTYPE) /. Message type '05' is an.INQ type message. Show + the 'Display Messages' screen so that the message + can be responded to./ IF COND(&RTNTYPE = '05') THEN(DSPMSG + MSGQ(&MSGQLIB/&MSGQ)). /. When a batch job you have submitted gets an error + message in QSYSOPR, you get a CPI2404 sent to you.

File Handling Program

+ Display QSYSOPR msgq so that you can respond./ ELSE CMD(IF COND(&MSGID = CPI2404) THEN(DSPMSG + MSGQ(QSYSOPR))) /. All others just display as a.STATUS message./ /. The &OPEN and &CLOSE are hex display attributes that + cause the status message to be shown in reverse + image./ ELSE CMD(SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) + MSGDTA(&OPEN.CAT &MSG.TCAT ' - '.CAT + &MSGID.CAT &CLOSE) TOPGMQ(.EXT) + MSGTYPE(.STATUS)).