Conference azur::mcc

    I can't really answer this for you directly, but I was alerted to this
    note by ::Kennedy (sorry never got the first name)
    
    I've started work on a Cross-Network tracker for ALL-IN-1 IOS.
    The basic idea will be to send a probe message (to avoid fanout on
    multi-user messages and to avoid the problem of 'rollover' of logfiles.
    
    It will then use a mailbox and /Run to exceute a comfile on each node
    to figure out the fate of the stated Mr-id, then pass on to the next 
    destination. 

    There are some hairy bit here, such as figuring out what to go next -
    is MRGATE a default_decnet node or the MRGATE we know and love...
    Also passing back the final status report might be a bit dodgy
    (initially I might just use MAIL-11 :-) )     
                                                  
     I keep getting told, that there is NO REQUIREMENT FOR THIS (by Mail
    Engineering), yet you are the second or third person who seems to think
    this is not a bad feature at all. If you could forward me customer
    opinion (internal or external), that backs the need for this
    feature,then contact me on IOSG::WDAVIES
    
    Thanks,
       Winton 
     

    Chuck,
    you pose an interesting question. The need is obvious. What is less
    obvious is that the existing presentation modules in DECmcc are
    sufficient to meet your needs.
    
    It is perhaps possible, and maybe someone else will suggest exactly
    how, to use the existing FCL or IMPM to help present the information
    you want to show to your user/manager.
    
    However, the existing PMs are mostly geared around the request/response
    paradigm that is user to express most of the (dare I call them) simpler 
    management operations. Thus, if your problem is capable of being
    expressed in terms of requests and responses, then the existing PMs
    will work just fine for you.
    
    Unfortunately, your problem (and those of others) does not seem to lend
    itself to such a representation. Therefore, what seems to be more
    likely to be needed is that you need to write an "application" that
    encompasses both PM and FM capabilities. Note that we have already done
    this with Notification Services (which has its own PM and its own FM
    to do what it does) and the Autoconfiguration applications (which are
    command script based).
    
    Assuming that the basic objects (in your case, parts of the X.400 mail
    system) are manageable, and there is an Access Module  that supports
    these objects, then your application (which you might consider to be
    a combined PM/FM) can get to the operations and data it needs, and 
    present the results, or inquire of the user, in any way you see fit.
    
    If, as occurs in some scenarios, you wish to separate the user
    interface aspects from the 'functional' aspects (normally done so you
    may reuse the functions for other purposes) then you would want to
    have your own FM and PM as separate units. This is exactly the scheme
    that Notification Services chose to use.
    
    Hope this helps, some.
    
    Regards
    Colin

    RE <.1> 
    
    Clinton, There is a need for such a tool, We are working with customers
    that press the envelope (love that term) of our current messaging
    products. Perhaps with a little field input we can get such a tool in
    the new MTA. I will send you a mail message as soon as things settle
    down here a little.
    
    RE <.2> Colin,
    
    Thanks for the great input, this sound exactly like the functionality 
    we need. Are there any documents, or samples, of this type of
    functionality? By samples I mean code that we might use as a starting
    point. 
    
    We have a prototype due the end of June do you have any hints for work
    arounds that we might be able to use for the prototype?
    
    				Thanks
    				Chuck
    

.3>    Thanks for the great input, this sound exactly like the functionality 
.3>    we need. Are there any documents, or samples, of this type of
.3>    functionality? By samples I mean code that we might use as a starting
.3>    point. 
    
    I don't know of any "existing code" or templates to point you to.
    However, I don'see why any DECwindows or Motif code would not
    be appropriate to use as the basis for your application's user
    interface. Based on your original description, you have a
    single-purpose application in mind, so it would probably not need to
    interact (much) with the iconic map - other than being launched as
    an "application". Yes, I know this is less desireable than being
    selected from the 'operations' menu, but......
    
    Colin