From: Daniel Monaghan To: All

I have been asked to present the following problem from an IR that I am currently working with on a software package. If the QSYSOPR message queue is set in the *BREAK mode and the operator fails to respond to the first message received, which does in fact break, then all subsequent messages fail to break until the first message is replied to. Seems to us that the most recent message ought to break also. Are we missing something or is this as it should be, or what?

From: James Coolbaugh To: Daniel Monaghan

Daniel, when a message queue is in break mode, the message that causes the break will be shown. If the operator stays on that screen without answering it or without leaving, no other messages will break. The other messages are there and will break when the message queue is freed up. The operator can hit F10 to show all while staying on the screen. You need to make sure that your operators are alert and attentive to answering messages or at least either 1) leaving the message display or 2) hitting F10 to show all messages.

From: Daniel Monaghan To: James Coolbaugh

Thanks, Jim. The scenario you described is exactly what we found. We hadn't noticed because we use *NOTIFY instead. The vendor we are currently working with for a software package does use *BREAK and had experienced this scenario as a problem, as he put it, "since OS/400 was hatched." He asked me for advice and assistance and I had none. It seems to us that it ought to break at every occurrence. He often has operators using dual session terminals; if they miss the first break and are too careless to notice the message indicator for the flip side, then all subsequent messages go unreported. I suggested that he break a few knuckles, but he didn't buy that suggestion.

From: James Coolbaugh To: Daniel Monaghan

Another solution might be to put a break-handling program on the QSYSOPR message queue. That program then could be written to ensure that all messages were sent at least somewhere.