Conference share::zap

	ZAP broadcasts its messages via the $BRKTHRU service using broadcast
class USER16.  If this class is enabled on the user's terminal, they should
receive any messages send from ZAP.  Warning messages must be enabled in the
exception rule for that group of users.

	Since you have multiple rules in the exception file that may apply to
the same group of users, it is possible that a rule specifies a subset of users
to have a different action.  In order to diagnose any problems, I would need to
see a copy of the exception database.  (The fastest means is to generate a
REPORT from ZAP and send that as it shows what ZAP sees and how it is applying
the rules).

						Keith Maconi

	Hello,

It's a bit late to reply but thanks for your advice Keith. 

First item : if A1 is started with the qualifier /BROADCAST_HANDLING the terminal 
device gets a NOBROADCAST and a BRDCSTMBX characteristic. This is meant to catch the
reply and format it so it can be displayed at line number 24.

I think that the problem occurs at this point, because the contents of ZAP$WARNING.DAT 
are formatted so that they'll appear at the top of the screen. I suspect that this format
info what is added to the ZAP$WARNING contents causes the mailbox to screw up.

I already decreased the warning message to 1 line, but this causes the same problem. 
When A1 is started /NOBROADCAST_HANDLING everything works fine.

Second item: the processes that aren't stoppped by the EXIT action. This is still the case.

I suspect that it has nothing to do with multiple action lines for a group of users but 
that is is caused by HOLDSCREEN/POWERED DOWN terminals. Because the history file shows 
that those particular users are exitted lots of times without success.

Hope you can give me a workaround or something, because the customer evaluates ZAP
and he don't want to buy it if these problems aren't solved.

	Kind regards, Erwin.

Hi,

	I would like to try to respond to your concerns.

						Keith Maconi

Problem: All-in-1 processes aren't warned before they are stopped. 
	   This only occurs when All-in-1 is started /BROADCAST_HANDL

	ZAP uses the standard $BRKTHRU service to send the message.  I have
	included the actual coded call below to show the call.  The values
	are as follows:

		WARNING_MSG.MESSAGE is a string containing the actual message
		GLOBAL_RECORD.TERMINAL is the terminal name
		BRK$C_DEVICE indicates that the message is being sent to a term
		STATUS_BLOCK is for call completion message
		BRKTHRU_FLAGS varies as follows:
			if %l is set, then it is 0
			otherwise it is BRK$M_Screen + #lines in message
		BRK$C_USER16 indicates the message class.

        I_Status := $Brkthruw ( Msgbuf := Warning_Msg.Message,
                                Sendto := Global_Record.Terminal,
                                Sndtyp := BRK$C_Device,
                                Iosb := Status_Block,
                                Flags := Brkthru_Flags,
                                Reqid := BRK$C_User16,
                                Timout := 5 );

	As you indicated in your message.  If A1 does not try to intercept the
	message, it works.  If A1 intercepts the message, it fails...

	One suggestion:  Use the following message:

		%lZAP - Idle time remaining %r

	Make sure the file does NOT contain ANY blank lines (All other lines
	must begin with !).  You may be getting a blank line in the mailbox
	which is confusing A1.

Problem: The processes that aren't stoppped by the EXIT action. 

	As stated in the documentation, processes are NOT stopped by the EXIT
	action but with the STOP action.  The EXIT action only issues a
	$FORCEX to the process which should cause the image to exit, but does
	not log out the process.

Hi,

Problem : ALL-IN-1 processes aren't warned before they are stopped if 
	  ALL-IN-1 is started /BROADCAST_HANDLING


We test your last suggestion and we have decreased the warning mesage to 1 
line (%lZAP - Idle time remaining %r) and we got the same problem.

Do you have ideas to run both ZAP and ALL-IN-1 /BROADCAST_HANDLING ? 

Regards
Marie-Dominique

                                                                     

	This problem has been resolved and will be included in the next release,
Version 5.2, of ZAP.  The problem is that A1 could not handle the length of the
message, or that the message was padded with null characters.  ZAP has been
modified to issue warning messages in a different format that A1 can handle.

						Keith Maconi