Conference azur::mcc

(1) The VMS datatype is an historical artifact, and I don't think any of DECmcc
uses it any longer -- Please someone correct me if I'm wrong
[ then tell me why it's still in there! 8) ]

So - I don't think it is really necessary to set the 'mcc_b_dtype' field of
an MCC Descriptor - likewise, the values in the YOURMM static tables aren't
of any importance either.

(2) You'll have to give me more information regarding your Generic AM.

Are you trying to say you want only 1 Reply Table, etc... and share it between
multiply Directive Entry Points? rather than one table per directive ??

I am very interested in your comments regarding the Design Framework, as I
am currently thinking about v2 - which I'd like to see more Object Oriented;
ie, Some C++ techniques, but using regular C.

Keith Roberts
DECmcc Toolkit Team

With one of our other partner, I started reviewing  their report after
a 4 months pilot project.
	I can already tell you that most of the negative ( but constructive ) 
observations and conclusions are not on the architecture or the API 
functionality, but about the design framework, for example :

- lack of function prototype use and proper use of .h files 
(preliminary steps in direction of OO programmin ).
- lack of useful /  understandable / without spelling errors comments.
- lack of design choices explainations ( table driven effects...)
- lack of documentations on the design framework routines library.
...
The problem being that the design framework is presented as " a model for 
PROPER CONSTRUCTION of AM...".
So the partners have the right to expect the product quality associated with it. 

	I will wait the report to be finalized ( mid-July ) to send it to NME,
 and I am glad you seem interested in it. If NME wishes I could publish some
of this report sections in the notefile...

 I hope you will help me to bring them a feedback on the improvements
 you are working on.

	Jean-Michel

	European EMA SVP project manager 

Jean-Michel,

    We certainly appreciate any and all comments (Good & Bad) regarding the
    DECmcc Design Framework.

>> lack of function prototype use and proper use of .h files

    DECmcc *needs* function prototypes for all the documented routines. 
    The simple reason it wasn't added was because the U**X C compiler
    didn't support them.  But using a very clean macro, function prototypes
    can be added. I will (try to) get this into the v1.2 kit for the
    Toolkit (ie, Design Framework).  I can't make any promises for the
    Kernel routines however.

    What other 'proper use of .h file' are you refering too ?

>> lack of useful / understandable / without spelling errors comments

    Another nail on the head !!  I will be cleaning up the comments in the
    'yourmm' code.  Also, I have written an Example FM - and (I think) have
    put in extensive comments...I hope you think so too  8)

>> lack of design choices explanations ( table driven effects...)

    I'm not quite sure what it is you mean here .. could you explain; give
    an example ?

>> lack of documentation on the design framework routines library

    Again - if you could point out some specific areas which need
    improvement we'll try our best to correct as much documentation as
    possible for the v1.2 release.


    Please - send all your questions and comments to us.  Use of the DECmcc
    notes file makes the most sense, as we want to keep this topic
    interactive.


Keith Roberts
DECmcc Toolkit Team

I didn't find the existing examples very useful when trying to use "callable
MCC".  The existing examples are very much aimed towards people writing MMs,
rather than just trying to use MCC to solve a relatively simple problem like
fetching the value of a counter.

Expanding and  shipping  the  examples  provided by Pierre Lavillat (which I
found  very  useful) and/or the program I provided in a recent note would be
useful.

Graham

    I just want to second Graham's comments in .4   Customers want
    simple examples of callable MCC, it convinces them that DECmcc is
    'open' and it can be integrated with their existing applications
    without super-human effort.  Some sample code that extracts alarms
    to a client process via a mailbox or pipe would be really
    appreciated.  This would give us an easy way to funnel alarms into
    user applications without the overhead of creating processes to execute
    DCL scripts.  Providing well documented examples increases the
    confidence of the field organizations to suggest 'creative'/custom
    solutions to customers.  
    
    - Mike
     

Currently I believe there is only a small amount of documentation for the
Toolkit which explains how to use the Callable MCC feature.

I understand why you would like such elaborate source code examples,
but please understand - if we publish lots of examples we must also maintain
them.

Maintaining a few good examples (well, getting much better) like the Sample
Access Module and (new for v1.2) the Example Functional Module is all we
can provide with our current head-count and schedule.

We're working on the next version of the Design Framework, which should minimize
a lot of the template code you're now including in your MM's - and thinking
about a Run Time Library of useful routines.  Also, in demonstating the MIR
(in the Example FM) a more 'user-friendly' interface has been developed
(I'd really like feedback on this when v1.2 field test comes out in the next
few months).

Back to Callable MCC -- We can't provide all those wonderful examples that
you'd like to see ... but that doesn't stop *you* from submitting your
code to this notes file.  As far as what can be shipped to customers on a
kit - more examples will come with time.

I will, however, in reviewing the section of the Toolkit guide, see what I can
do for Callable MCC.  If time permits, we will be adding an example of an
Event Sync - which utilizes Callable MCC.

Keith Roberts
DECmcc Toolkit Team