Re: UPS & AS/400 talking to each other

David:

On Wed, 26 September 2001, David.X.Kahn@gsk.com wrote:

> James wrote:
>
> > Change system value QUPSMSGQ to point to QSYS/QSYSMSG.  Set this
> > message queue in break mode and write a break handling program and
> > assign it to the message queue.
>
> Is a break handling program really the best way to monitor the QSYSMSG
> message queue? My understanding is that break handling programs are best
> suited to interactive jobs. To have the queue in break mode there has to be
> a job that has the queue allocated. In this example it could be the system
> console, but if the console gets signed off the queue goes back into hold
> mode and the messages are not monitored.

I'd say (1) yes, a break handler is best, but (2) QSYSMSG maybe shouldn't be 
allocated to an interactive job. If you want interactive allocation, use 
QSYSOPR. One reason QSYSMSG exists and only receives critical messages is so 
you can respond immediately by program. The system is set up so the messages in 
QSYSMSG also go to QSYSOPR, but QSYSOPR exists by default and is often 
allocated at a console. This makes it difficult to have programs handle 
QSYSOPR. But QSYSMSG must be created deliberately. Normally, the only reason to 
do this is to use a break handler over it.

> OTOH if you have a batch NEP monitoring the queue it can be simply sitting
> on a RCVMSG with WAIT(*MAX) without a separate program having to be
> invoked. The NEP can examine every message that arrives in the queue, take
> the appropriate action, then loop round and go back sleep. Surely this is
> preferable to using a break handler?

The break handler would also be invoked by a batch NEP; I usually use an 
auto-start job to do this. Once CHGMSGQ sets the break handler, the NEP can 
then go into a wait on a data queue or whatever to decide what to do next.

One advantage of break handlers is in how the CHGMSGQ RESET() parameter affects 
execution. This provides a way to 'start where you left off', while RCVMSG 
often requires an external data area or some other means of tracking which 
messages have already been handled.

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788
Fax  253-872-7904
http://www.400Security.com


___________________________________________________
The ALL NEW CS2000 from CompuServe
 Better!  Faster! More Powerful!
 250 FREE hours! Sign-on Now!
 http://www.compuserve.com/trycsrv/cs2000/webmail/