Subject: Descriptor processing order

From: Chip Sharp <[email-masked]>
Date: Mon, 13 Mar 2000 17:33:29 -0800

Due to a previous question on event handling, I went through the output of
SG16 (TD37) looking for text on the ordering of processing of descriptors.

However, I could find no text in the document that describes in what order
a MG or MGC should process descriptors.  I was specifically wondering if
the TerminationStateDescriptor was processed before the
EventsDescriptor.  This has implications in that the order of processing
the value of the EventBufferControl parameter in the
TerminationStateDescriptor and the EventsDescriptor will affect how events
in the EventBuffer are processed.

If TerminationStateDescriptor is processed first and EventBufferControl=Off
(previous LockStep), then all events are discarded.  If EventsDescriptor is
processed first then at least one more event will be reported before the
EventBuffer is flushed (ignoring the previous discussion as to whether this
is desirable or not).

It seems there may be any number of conditions like this that will depend
on ordering of processing of descriptors in the command.

Shouldn't there be some basic text in the spec that either specifies that
the receiver of a command should process the descriptors in the order
received or that the receiver can process them in any order desired?  I
prefer the former.  The latter seems a little indeterminate.

If there is already text of this nature in the document, please educate me
as to its location.

Thanks,
Chip
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 14 Mar 2000 09:30:39 -0500

I believe there is an agreement that commands are atomic, either
succeed or fail and no partial commands. but I agree with you that
there is no text, up to my knowledge, saying that descriptors are
attempted in order. The closest  we get to this is in Section 8,
"Transactions guarantee ordered Command processing. That is, Commands
within a Transaction are executed sequentially. Ordering of Transactions is
NOT guaranteed - transactions may be executed in any order, or
simultaneously."

I propose adding the following sentence to the above paragraph,
" All commands are atomic operations, either succeed or fail as a whole,
and descriptors within commands are processed in sequence of their
order."

Abdallah Rayhan

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 16 Mar 2000 19:45:57 -0800

Sounds good to me.

-- Flemming

---

From: Christian Groves <[email-masked]>
Date: Fri, 17 Mar 2000 15:39:08 +1100

G'Day Abdallah,

I can buy saying that descriptors are processed in order but what do we
gain by adding "All commands are atomic operations, either succeed or
fail as a whole". What does this really mean??
If one decriptor is executed and the next descriptor fails what does the
MG do?

Christian

---

From: Chip Sharp <[email-masked]>
Date: Fri, 17 Mar 2000 08:26:34 -0800

I'll leave it up to the experts, but I imagine it would be similar to a
Q.931 SETUP message.

If the switch executes one Information Element and the next one fails, the
switch treats the entire SETUP message as in error.

I believe there should be atomicity at some level.  If we go one level
deeper, we could look at what happens within a descriptor in the ordering
of parameters.  If one parameter succeeds and the next fails, the MG has to
recover.  I tend to think that a command should be atomic.  It either
succeeds or fails.  I think independence of execution of descriptors would
make it even more difficult than it already is for the MGC and MG to remain
in synch (and sane).

Chip

---

From: Christian Groves <[email-masked]>
Date: Mon, 20 Mar 2000 17:09:41 +1100

G'Day Chip,

I completely agree with what you say. Command's should either succeed or
fail. What I was concerned about is something like playing a signal from
a signal descriptor and then the MG changes a property in a local
descriptor which fails. This is all done in a modify command. The
command fails because of the error.

Hopefully the MG doesn't try to return the state to what it was before
the command. ie. Once a signal is played you can't get it back. It was
this clarification about what the MG does that I was looking for.

Cheers, Christian