Conference azur::mcc

    RE:.0
    
    That looks pretty good.   Note that when a directive takes a long time,
    it generally falls into one of two categories:
    
    1)  Computational in nature.  You MUST wait for an answer.  For
    example, "Calculate the cubed root of Pi, to the 10,000th decimal
    position".
    
    2)  Batch-like in nature.  You do not have to wait for an answer
    (there may not BE an answer).  For example, "Delete all subentities
    which begin with the letter I, have more than 20 characters, and
    were created on a Sunday which fell on an even date."
    
    Note that with the second type, you still need to know whether it
    completed successfully.  It's just that you can assume it probably
    will, unless told otherwise.  Supplying state information, and an
    event when it is done, provides all the needed information (as in
    a Print Server model).
    
    You don't ask about implementation, but I'm going to express my
    concerns anyway:
    
    The problem with executing the second type of request in a "foreground"
    MCC (i.e., forking off a thread to do the work), is that the user may
    type the "exit" command from FCL.  And, oops, the operation gets
    aborted.  Sometimes this is okay, but usually it is not good.
    
    The common solution used by the FMs that I have dealt with is to have
    a "background" process (which you might call a "Mulcher") which runs
    detached from MCC, and handles requests such as "mulch".  Defining the
    Mulcher as an (child) entity with management parameters solves a lot of
    problems, since it can then be tuned, monitored, and diagnosed, as well
    as shared by multiple foreground MCCs (you have to be careful with
    accounting and security, though).
    
    Just one man's opinion...
    -Matt.

Matt,

Thanks for the feedback. It looks like we'll have "services" being
delivered by a "server" implemented as NETSERVERs or detached processes
or forked processes. At any rate, starting a mulch and then exiting
MCC won't stop the mulch.

Good point about the abort. In some instances we'll need to be able to
find out how far along it got before we aborted. In others, the mulch
will be atomic: if we abort it before it completes, it will look like
it never started.

Ah, this is a good discussion point for the folklore. I'll post it to a wider
audiance after a little more thought.

						Mark

Your starting point was fine, but I'd suggest a couple of additional nuances.

The action that starts the "task" running (mulch) applies to an object (troy).
But the "task" ought to be an entity related to the TROY object, most likely a
child entity of TROY. Say CASSANDRA... Nah lets call it a Mulcher class, the
metafores are becoming too mixed.

Anyway, each Mulcher has a State and a Progress (if that's predictable). Each
mulcher would have some kind of identifier (most likely called Name). The Name
could be supplied in the command (as you showed) or it could be generated by
the Troy entity to be unique. Note if the manager supplies a name on the Mulch
action, you need a "there's a mulcher with that name already running"
exception. Also note that the response should include thee name of the mulcher
created.

When the mulcher finishes, what happens to the Mulcher entity? It *probably*
should
a)  report an event saying "I'm Done".
b)  Stick around for "awhile", so the manager can see it's completion status
    (did it finish? did it do the righ thing?...).

If you can't report a numeric progress reliably (which really means you need to
have a good metric on the work to go, most likely that means you need to
predict how long the command will take in seconds, and then reflect "elapsed
time" in the percentage). There are other choices.

    If the task goes through 15 subtasks, name each and define an enumeration
    of the 15 subtasks and report the current subtask the mulcher is working
    on.

    If the task processes n units, (say you are deleting 50 files) then report
    Progress = 23/50 files (this requires a ratio data type, hmm that could be 
    generally useful...)

The general point is that "progress" is hard to measure in a task independant
way. You'ld be better off reporting a real measure of progress based on knowing
what mulching does.

If you *must* see commands :-) they'd be

	NCL/MCC> mulch Troy <args> ! generates a name
		Mulcher X_123 started

	NCL/MCC> mulch Troy Name=Framitz, <args> ! provides a name
		Mulcher Framitz started

	NCL/MCC> Show Troy Mulcher *
		Troy Mulcher X_123
			Name = X_123
			State = Running
			Progress = Mulching Matilda
			Files Mulched = 33
			Total Files to Mulch = 98
		Troy Mulcher Framitz
			Name=Framitz
			State = Running
			Progress = Barely Started
			Files Mulched = 0
			Total Files to Mulch = 7000
		Troy Mulcher Did-it-yesterday
			Name=Did-it-yesterday
			State = Done
			Progress = Done
			Files Mulched = 21
			Total Files to Mulch = 21

Note that the State and the enumeration of the Progress could be merged into a
single list of "states".

Ah yes. "starting time" and "completion time" attributes would be appreciated.

All for now.
				Mark
			

    A point that came up .-2(3?) ago about the user "exit"ing DECmcc with
    some threads running. This isn't a new issue. Alarms are threads.
    
    I think that the "Do you really want to EXIT DECmcc" (when the user
    selects QUIT - but that's another storey) really needs to supply more
    info like "DECmcc - 14 Alarm rules currently active - do you really
    want to exit?"
    
    Untill such time as we have a (I will call it) Detachable DECmcc so the
    terminal can leave and return without disrupting things we need to
    make sure that users don't get out of DECmcc to easily or at least make
    sure they have some idea of the consequences.
    
    s/rob

RE: .4

Rob, the design we're proposing doesn't rely on director context (threads)
for the long operations. In fact, one of the motivations for modelling
them this way is so you can start an operation and exit DECmcc.