Subject: Re: nailing down transactions

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 1 Sep 1999 17:02:10 -0400

[[TomT]]  ...
        The problem I have with this one is that the MGC is a set of
software, not a programmer.  How does it know when to add the O-?

> 2)  If you do not care whether a command fails or not, then you mark it as
> optional (in ABNF, we proposed in an earlier msg to prefix a command with
> O-, e.g. O-Modify).
>
> Example 1: You send an Add to create a new context for a new call. In the
> transaction you also put a Modify with the call display information. If
> the
> Modify fails, you still want the Add to go ahead.
>
> Example 2: Add * and O-AuditValue in one transaction. If the Add fails,
> i.e.
> no terminations are added, the MG does not need to execute the AuditValue,
> so it is marked as optional, and the MG would set the return code to
> not-executed.
>
> An optional command that is not executed is marked with the error code
> "not
> executed". If the optional command fails, it contains the appropriate
> error
> code. If it executes successfully, it returns the response parameters as
> usual.
>
> The difference between an optional command failing and a mandatory command
> failing, is:
> a) that the transaction continues to execute commands after a failed or
> non-executed optional command, instead of stopping, and
> b) it sends back a TransactionAccept instead of a TransactionReject.
>
>
> 3) A transaction groups together commands that need to be done together.
> Thus, if the list of commands the MGC wants to do, do NOT need to be
> performed together, they MUST not be put in the same transaction.
>
>
> 4) Handling errors when wildcarding is used: If the command that failed
> was
> applied to many terminations we do not return the id of the termination
> that
> failed. We assume the MGC will need to do an audit to find out the state
> of
> things. In fact this brings out some problems in the current definition of
> AuditValue - I address them in a different email. See also example 2
> above.
>
> Brian, John, Is this summary satisfactory? Let's get it into the draft
> then,
> and move on.
>
> Nancy
>
> --------------------------------------------------------------------------
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
>
> --------------------------------------------------------------------------
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:[email-masked]