Conference azur::mcc

The MCC Developers toolkit documentation has been sent to Northboro Mass
for coping.  It is due to be done by Friday September 1st.  Copies will
be sent out to those of you that requested them at that time.

Dale

Help is documentation of a sort ... Please review and correct the help files.
I have notice errors, for example 

HELP FUNCTIONS SHOW EXAMPLE .. the example is ...

	MCC> SHOW NODE FRED REFERENCE ... shouldn't it be ...

	MCC> SHOW NODE4 FRED ALL REFERENCE  (since the Phase V stuff is not here)

There are others which as I remember them I'll write a list.   But good
help and correct examples are important.  Also, it would be nice to 
have more and different examples than SHOW NODE4 whatevers.

/Claudia Peters, NSSG

    The writer working on the _DECnet/OSI Phase V AM Use_ manual thinks it is
    too repetitious, and has what might be a good way to reorganize and
    dramatically shorten it.  What do you think?
    
    Currently, at the heart of the Phase IV and Phase V books are a series
    of  chapters, roughly one per child entity.  Each chapter contains a
    series of tasks (written as two-page modules) corresponding roughly to
    the appropriate DECmcc directives.  These are the tasks you need to do
    to manage these child entities, but after a while, the descriptions get
    numbing, viz:

	Managing the REMOTE NODE Entity
		The Remote Node Entity
		Creating a Remote Node Entity
		Deleting a Remote Node
		Displaying Remote Node Attributes
		Modifying Remote Node Attributes
		Initializing Remote Node Attributes
		Zeroing Remote Node Counters

        Managing the CIRCUIT Entity
                The Circuit Entity
                Creating a Circuit Entity
		Deleting a Circuit
		Displaying Circuit Attributes
                Modifying Circuit Attributes
		Initializing Circuit Attributes
                Zeroing Circuit Counters

	(and so forth)

    One of the strengths of DECmcc is that once you learn how to manage one
    thing, you can apply that knowledge to other things.  The directives
    work the same way from entity to entity; only some details differ. 
    From V1.0 we've learned that, for DECnet Phase IV and V child entities,
    there isn't anything   different about most of these operations.  So
    why are we documenting them?
    
    What would you think of compressing our presentation by removing the
    purely repetitious Create, Delete, and Zeroing descriptions?  We could
    document them once in each book and leave it up to you to remember
    where it's written and how to do it.  We would actually be dropping
    tasks, but we think we could save literally hundreds of pages.  (We
    would keep the descriptions of setting and showing attributes as a
    vehicle for talking about those attributes which you really care about
    for management pruposes.)  Would you like to see this, or would it make
    it more difficult for you to use those AMs?

re: .3,

>    What would you think of compressing our presentation by removing the
>    purely repetitious Create, Delete, and Zeroing descriptions?

	Yes!  You have my vote!  Take it from a new kid on the block who
    is desperately trying to read through the pleathora of DECmcc manuals 
    without falling asleep.  There are many good chapters and many sections
    and/or chapters which do get extremely repetitious (almost to the point
    of forgetting who I am and beginning to feel like a programming
    language compiler or something).

	There is a certain potential beauty in the simplicity of this
    product, but it sometimes seems to get lost in the sheer mass and
    scope of all of the associated documentation.  From an outsider's
    perspective, the product might appear to be too complex based on the
    sheer volume of documentation.

	Allow me to explain this point further: you see, if you provide
    the details for each particular sub part of the whole (even if the
    sub part itself is nothing unusual, but it is nevertheless included
    because without its inclusion, it risks appearing incomplete), then
    after a while, the reader finds themselves reading through sections
    with little other than stubs which point to other sections that have
    already defined the given sub section in question.  Ultimately, the
    reader begins to lose interest.

	It is important to maintain the interest of the reader, because
    without this interest level, the reader might eventually give up on
    learning the product.  Either that, or the reader might inadvertantly
    skip an important point which is buried in otherwise repetitious text.

	Text should not be too repetitious either, because the reader
    will eventually become somewhat irritated after having reread the
    same basic point for the fifteenth time while other points still
    remain unstated (forcing the reader to continue reading on to locate
    that occasional hidden clue that is hidden between the repetition).

	Some people only really begin to feel comfortable with a given
    product after they have read the entire documentation set, and if the
    documentation set consists of fifteen 400 page volumes, and the reader
    is reading along slowly to avoid missing anything important, then
    it could take litterally months to get up to speed on the product.

	Don't get me wrong, I do enjoy reading these manuals.  I especially
    enjoy the pictures (in fact, I have posted the illustrations from the
    DECmcc Management Module Programming manual on my cubical wall in hopes
    that the material might sink in a little quicker this way).  However,
    I have begun to get a little bogged down reading the SRM.  I made it
    to chapter 9 - which is the point where it really begins to take on
    more of a reference manual appeal, and is therefore harder to read
    cover to cover.  I have yet to tackle the DECnet AM Use manual(s),
    but from first glance, the point may apply there as well.

	To analyze this point even further, we must look at each element
    of the process of reading DECmcc manuals in general.  There are now
    twenty-five global categories of DECmcc manual characteristics:

Category 1:
Completeness

	Sub-Category 1a:
	Breakdown of details

		DECmcc manuals are designed to breakdown each detail
		to its smallest manageable element.

	Sub-Category 1b:
	Cross references

		DECmcc manuals place pointers to other sections of
		previously discussed topics.

		Sub-Sub-Category 1bi:
		Previously defined terms

			DECmcc terms are first defined, and then referenced
			elsewhere at later points within the same manual.

		
Category #2:
Repetition

	Sub-Category 2a:
	Handling Repetitious Topics

		Sub-Sub-Category 2ai:
		Previously defined terms

			For more information about previously defined terms,
			see section 1bi.


Category #3:
Making a point

	Sub-Category 3a:
	Providing a complete analysis of topic beforehand

		Sub-Sub-Category 3ai:
		Completeness
		
			For more information on completeness, see Category #1.


Category #4:
Humor

	Sub-Category 4a:
	Incorporating Humor into DECmcc Manuals

		Not implemented in release 1.0

.
.
.
you get the idea	(sorry - it's Friday)

    
    	I think one of the most important qualities of user documentation
    is to be able to find the information that you need quickly. Most
    people don't sit down and read manuals cover to cover, they pick them
    up when then need to know something. It's nice to have a few chapters
    to provide background info (which I think you have) then after that be
    able to reference information quickly. Indexes are very important. I
    personally love examples, sometimes I get familliar with commands
    by looking at the examples.
    
    	Another big item is consistency. Once you learn how to use a manual
    efficiently, you should be able to bring that knowledge over to another
    manual in the docset and the knowledge should work for you.
    
    Linda
    
    

    One of the things I find difficult in both the manuals and the HELP
    files is finding the info for typing a command (Directive I guess it is
    called now). Usually you are sitting at the prompt and you do something
    like
    	MCC> SHOW (pause for thought)
    
    and can't remember what the choices are (the FORMS mode in the FCL
    helps of course) so you type HELP expecting (as in most things you have
    used on VMS for the last 10 years) to see something in the top level
    like "Commands" or something like it. Well, it doesn't work that way
    today and that makes it harder. The user is expected to know that they
    need to look under the entity class help for the commands that are
    supported. Well that is how the language is described, but not how
    people discover that they forgot things.
    
    I know that we have (at least)3 different release kits (or whatever
    they are called). The DIR kit, the toolkit kit and the BMS kit.
    
    Since these are finite (untill additional AMs and PMs and FMs are
    added, it might be possible to construct a referance (chapter) for a
    specific kit (like BMS since I bet thats the one we hope to sell lots
    of) that looks like;
    
    <directive> <entity-class> <entity> etc....
    
    Directives
    	DIR, SHOW, REGISTER, etc...
    	Entity Classes
    		NODE4, Station, bridge, etc...
    		Entity
    			(node name) (station name) (bridge name)
    		NODE4
    			Line, Circuit, counter, etc...
    		Bridge
    			Line, counter, etc...
    		Station
    			Address, etc...
    
    You get the idea. A place where you can work accross from left to right
    and find out what things to do. Perhaps a few footnotes would be needed
    to describe the few cases where something is not applicable.
    
    Somehow we have to get people up to speed on this great new complicated
    product with the least stress on them.
    
    s/rob
    		

At the risk of repeating the comments so far...

The idea we had was to eliminate the need to redescribe "Create" for each of
the 100 entities. You'ld only document what was different or unusual about
this particular create. In fact, I would hope that each entity could be 
described in three short lists...

	A list of all the attributes of a FOO
	A list of all the directives that apply to a FOO
	A list of all the events emitted by a FOO.

Attributes would be the longest and most complete. But no need to describe
Show or Set, only if a particular attribute were Showable or Setable.

The list of directives would mainly describe the errors.

The list of events would describe what each meant & the arguments.

A page per directive or event seems excessive.

For the basic stuff for DECnet Phase V entities, I also think that the MCC 
and NCL documentation (for all the implementations) should be a single document.
After all, the basic commands attributes and events are all the same.

Anything we can do to shorten the documentation is worthwhile.

    I don't believe it is a goal to reduce documentaion. Having said that I
    agree that excessive documentation is wrong also. We should also have
    documentation that is easy to find things in.
    
    I think the goal is to make it possible for the user of the product to
    find the answer to their question as easy as possible (translate, least
    time).
    
    I realize that it is not possible for people who have worked on this
    stuff for many years to understand the kinds of problems that new users
    are going to have. Please try to keep in mind that ALL previous
    training and concepts are being tossed out with this and the target
    audience is people who are having to use our existing products daily
    while trying to make sense of the new stuff. We do NOT have the luxury
    of having clean slates to write on.
    
    s/rob

    As a start, Mike Bellusci and I have discussed reorganizing the Phase V
    AM Use Manual so that display (SHOW) and modify (SET, ADD, REMOVE)
    directives are described in their own section with a table listing the
    entities which support each of the modify directives.  (Not all
    entities have settable attributes.)  There will still be sections for
    each module entity and its children.  These will describe action
    directives, including CREATE, DELETE, ENABLE and DISABLE.  We may try
    to cut this down in the future too.
    
    I believe that the long term solution is a doc set with Phase V entity
    desriptions, DECmcc User and NCL User.  Everyone would get the same
    entity description book(s) and one or both of the user manuals
    depending on which director was being used.  Hundreds of pages
    describing the same entities, attributes and directives in more than
    one place is ridiculous.  Is Session Control ever going to be *that*
    different between VMS and Ultrix?
    
    I suppose we could also combine DECmcc and NCL command line into one
    book and only have a separate DECmcc book for Iconic/Forms interfaces.
    
    While we're at it, how about having one help file describing Phase V
    as well?
    
    Why stop at Phase V?
    
    Mike

    I'm glad to see discussion opening up!  So you'll understand the
    context, we're always interested in improving the documentation.  We
    assumed many things for Version 1.0, and I think our assumptions are
    holding up, but we must act on our plans to be successful.  For one
    thing, we are writing task-based documentation, not encyclopedic
    reference documentation.  If you go into the DECmcc information set
    looking for arguments to the directive SET NODE <node> CIRCUIT
    <circuit>, you'll have to go to (1) on-line help or (2) the index,
    because we've not laid out things that way.  If, on the other hand, you
    want to set a circuit attribute, you ought to find the topic right
    away.  We think that people using DECmcc think in terms of tasks, not
    commands.  (DaveO, welcome, and note that we're not supporting your
    quest to read the books cover to cover, though I'll spring for a cuppa
    to keep you awake.  Also, I'm talking about the user documentation, not
    the SRM, which you mentioned.)  Task descriptions should be easily
    and quickly located (as Linda pointed out in .5), procedurally
    complete (no stubs), rigidly accurate, and meaningful.  When
    we pick an example, we want to pick a meaningful one.  That's another
    long-range assumption we made: that over time people would learn how to
    use DECmcc, and that we'd pick their brains.  There's not much of that
    in the V1.0 books, but we're still digging.  You all can help!
    
    Another assumption we made is that the interface preferred by both
    buyer and seller is the Iconic Map PM.  We are thus "turning around"
    the books for V1.1 to reflect the Iconic Map interface as THE
    interface.  (We can't commit to completing the turnaround that fast.) 
    This tends to short-change veterans like Rob Spence, I admit, but as we
    know, he's a rare fellow.  Sometimes implicitly, sometimes explicitly,
    we've favored that interface over the CLI interface.  On-line help is
    an explicit example.  There will be no "finite kits," as Rob called
    them, in a few months.  Once third parties start putting out AMs and
    FMs, no developer will ever know what modules lurk in the hearts of
    directors.  (The Dictionary knows, but that's on in half an hour.)
    Unfortunately, we can never construct a Help library that can do what
    Rob wants in .6.  But that's a CLI-based problem.  Going with
    DECwindows has the benefit of solving that problem (if we can implement
    widget-sensitive help).  Going with DECwindows also offers the prospect
    of reducing our documentation by perhaps an order of magnitude.
    
    Comparing the DECmcc and NCL documentation is instructive.   Mark
    Sylor's suggestion in .7 is reminiscent of the NCL approach.  But I'll
    tell you something, Mark: the number of attributes you folks are
    defining for DECnet/OSI Phase V is almost ten times the number defined
    for DECnet Phase IV, which we thought was grotesquely large at the
    time.  The number of OSI attributes may be ten times more than that. 
    I've calculated that a mythical, printed "Appendix A: OSI Attribute
    Descriptions," even as a summary table, would occupy an entire BOX of
    photocopy paper (that's twenty reams, or 20,000 pages!)  That's just
    APPENDIX A; the actual (mythical) manual would be more.  No, we HAVE to
    get that information on-line at least.  I agree we should share this
    information with NCL, and in fact we've been working on that very
    thing.  The rest of Mark's proposed structure is pretty much the NCL
    approach, but that's an encyclopedic reference, an order of magnitude
    more than what we're doing for DECmcc.  I don't think that is an
    improvement.

>   I've calculated that a mythical, printed "Appendix A: OSI Attribute
>   Descriptions," even as a summary table, would occupy an entire BOX of
>   photocopy paper (that's twenty reams, or 20,000 pages!)  That's just
>   APPENDIX A; the actual (mythical) manual would be more.  No, we HAVE to
>   get that information on-line at least.
    
    Based on the sheer volume of required documentation, and the fact that
    we're targeting IMPM as the "interface of choice", let me ask the
    obvious question: Is anyone looking seriously at BOOKREADER (it sure
    would be nice to have all of those attributes documented on a CDROM).
    

    re: .-1 and .-2  YES!  While we're on that subject, DECnet-ULTRIX NCL
    documentation came out to two whole volumes totalling 500 pages.
    When BJ saw the size of the Phase V documentation, he apparently
    suggested something to the effect that it ought to be 50% smaller.
    
    The DNU doc set was originally modelled after the VMS NCL
    documentation, at the suggestion of the documentation group, but after
    this feedback, we're looking at making it more entity-oriented, like
    MCC's doc set, and describing the standard verbs once up front.  If we
    structure the DNU doc set this way, then it would be much easier to
    share documentation with MCC, am I right?
    
    In fact, I would like to see an entity documentation registry, or some
    central place where you could document an entity ONCE, and have the
    entity-specific documentation just be included in the various products'
    doc sets.  Of course, this requires that the documentation groups use
    the same format.  Otherwise, it is inevitable that the various doc
    sets will be inconsistent and error-prone.
    

    Yes, Bookreader is in our future.  We did not commit to it for DECmcc
    V1.0 because DECmcc PREDATED Bookreader (!).  We have not committed for
    V1.1 (though there's some question on that) because we haven't the time
    to do it.  After V1.1, I expect you'll see DECmcc on Bookreader.  
    
    We may even be able to do it faster if we can use the Interleaf
    Viewstation software, which reads our documentation files directly (no
    translation or conversion required) and is already superior to our own
    Bookreader product (ouch!).
    
    This raises an interesting long-range question, however.  If you have,
    say, ten thousand attributes to describe, printing out the pages is
    clearly unworkable.  If, instead, I put the pages on CD-ROM, are you
    now satisfied that the information is usable?  You might think so,
    but I claim it is not.

We (in  CBN)  are  being  agressive  in  reducing  the  size  of  our  paper
documentation  set.  We are making the paper documentation smaller by making
some  things only available on Bookreader.  Several goals are very important
to us (in no particular order):

1) The  documentation  should  be  easy  to  use.   This  means it should be
primarily   task-oriented.   Our  management  manual  is  task-oriented  and
describes things like "how to create a DDCMP circuit".  

2) The  documentation  should  not  be off-putting.  This means it shouldn't
appear  to  be "too big".  Much of the size is due to duplication to make it
easy  to use (so these two goals conflict).  Online documents don't have the
same  problem.   In  the  future,  we  intend  to make use of Hyper-services
(MEMEX)  to  make  the  online  documentation  more usable (particularly for
Problem Solving).

3) The  reference  information  on  all our attributes, directives, entities
should  be  available  to  people who need it (e.g.  something must at least
mention  all  attributes  of all entities we support and describe datatypes,
legal vaules, etc.).

4) The  documentation  must  be easy to maintain.  This means one source (in
the whole corporation) for the reference material.

This last  point  is  very  important.   To take an example: if MCC have one
source  for reference information on the ROUTING module and we have another,
we  will  review our Routing information (because it is part of our product)
but  we  will  not review MCC's routing information (we don't, as engineers,
have   time   to  review  documentation  for  other  products).   So,  MCC's
information  is  likely  to  be  incorrect  because it has not been properly
reviewed  by  the people who actually write the code! The same problem would
occur  if  DECnet-ULTRIX were to pull out of the agreements to have a common
NCL manual between the various implementations.

.12>In fact, I would like to see an entity documentation registry, or some
.12>central place where you could document an entity ONCE, and have the
.12>entity-specific documentation just be included in the various products'
.12>doc sets.  Of course, this requires that the documentation groups use
.12>the same format.  Otherwise, it is inevitable that the various doc
.12>sets will be inconsistent and error-prone.

I couldn't  agree  more, at least for reference documentation (task-oriented
documentation  will  probably  always have to be different as it is aimed at
different  customers).  It is vital to us, as router builders, that the host
NCL  documentation  is complete and accurate because our customers will turn
to the host documentation for information.  Yet we don't have time to review
MCC's  documentation, DNU's documentation, DECnet-VAXs documentation as well
as  our  own! I have no problem with reducing the size of the NCL manual (as
long as all the reference information is still there) but it must be done by
T&N  as  a  whole, not by one group.  This should be helped by the fact that
DECnet-VAX have now moved back into T&N.

We have  that  agreement  today between us, DNU and DNV.  How long before we
can add MCC?

Graham

�			Going with DECwindows also offers the prospect
�   of reducing our documentation by perhaps an order of magnitude.
    
    Do it.
    
    I know next to nothing about the particular problems of DECmcc, but
    having recently started to work on the DEC OSIrouter configuration 
    program (which doesn't use DECwindows, but is at least forms-based) 
    I've found that excessive documentation can make a well-designed
    online procedure _harder_ to use. Marge Silverman, who was the
    guiding light for the online procedure, plans to make a future
    Configuration guide much shorter.
    
    So if you've got an iconic interface, use it.
    
    b

    
    Please remember one thing, we have an iconic interface, but it is
    NOT our only interface. I would not want to see information ONLY
    accessible from a DECwindows interface. If a manager has a problem
    and only has access to a VT device then the information should not
    be lost to him/her.
    
    This issue can be worked by make using of both the on-line help
    facilities, for that information we want to move out of the manuals
    and want on-line, and bookreader for manuals we want on-line
    accessible.
    

    re .13
    
    Steve,
    
    	I hope your reference to Interleaf was a mistake. DON'T EVEN THINK
    ABOUT IT. We "the field" have to work with multiple products and we do
    not need someone who only works with one product deciding to do their
    own thing because "its much neater - like".
    
    	Also, isn't the current documentation produced with VAX DOCUMENT?
    If so please produce an internal-only coopy using bookreader format.
    All you need is IFT V2.0. It may not be as pretty as when all the right
    bookreader changes have been made but it can save a few trees now.
    
    thanks,
    Andrew

.16>     Please remember one thing, we have an iconic interface, but it is
.16>     NOT our only interface. I would not want to see information ONLY
.16>     accessible from a DECwindows interface. If a manager has a problem
.16>     and only has access to a VT device then the information should not
.16>     be lost to him/her.

Although that is true for MCC in general ("MCC: the platform") it may not be
true  for  unbundled  applications.  It is a product management decision for
each product.  For example, if we were to build an FM to do with our routers
we  might  decide that it is reasonable to require a workstation (we already
require at least a VT220 for our non-MCC based configuration utility).

Graham

    RE .18
    
    That is agreed, but for some of the items we have been talking about,
    they come bundled with the base system director and will be available
    through both UI's. The only way NOT to be available through both
    is by writing a private PM.
    

	Hello world.					Evry 18-FEB-1991:10.11

	What is the System Reference Manual last version oder number?
	Can it be found anywhere in postscript file? or else?


		Thanks for any info.
		Philippe. 

Being new to the area of documenting management modules, I have many daft
questions to ask. 

The Help File Builder produces (as far as I'm aware) a VMS help library
and a DECwindows VMS help library. Will it produce a Hyperhelp library?
If the manager of my products wishes to use a graphic interface, will he/ when
will he receive the benefits of Hyperhelp displays, with hotspots and graphics 
etc? My minimal exposure to the help of management modules suggests that is
very much text based, with simple line-art being the most extravagent it gets.

A second, probably dafter question. Why is help for NCL commands written
using a specific set of tags? Won't any old VMS help library suffice, in which
case, isn't it possible to use any means to produce that library?  Why can't I
use DOCUMENT as the producer of my help library?

Like I said, charmingly innocent questions. Thanks for any enlightenment.

Martin

Okay these questions are more common than you might think. You are right
that text only is what is supported today. At some future point we might
do more, but let me explain the problem.

The VMS help librarian allows you to merge more than one input file 
together (.HLP) as long as the only merging you are interested in is
merging complete branches in a hierarchy. This is *NOT* the case in
MCC. New modules can modify any section in the help hierarchy. This is
necessary if for example a functional module desires to augment the
features for a specific entity class (a specific example is the augmenting
of the statistics partition by the Performance Analyzer FM).

To "augment" help in an existing branh (like help entities bridge) with
a new piece of information (like help entities bridge statistics), you
need to be able to merge in the input text into the correct hierarchy and
then build the help. A bit confusing? you bet! But we weren't able at the
time to come up with any other mechanism that would allow for dynamic
enrollment of new help text, position independent in the hierarchy.

Thanks for the answer. I'm still not sure that we couldn't have used some
subset of SDML tags to supply the help files though. I prefer to avoid having
to learn yet another set of tags, and the MCC tags make my text useless for
other purposes should I wish to reuse them. However, such is life.

Isn't the need to extend help libraries dynamically a perfect problem for
Linkworks/Hyperhelp to solve? 

RE .-1

"Isn't the need to extend help libraries dynamically a perfect problem for
Linkworks/Hyperhelp to solve? "

I personally thought so, but when the help file builder was finally built,
it was only after giving hyperhelp a wait see first. The documentation
on hyperhelp started at least 3+years ago. We looked into it at the time
but when they finally had postponed it we had no choice but to go ahead 
without it. (Just as a FYI, the iconic map PM developement started with
BL5 of DECwindows; that first "generally" available release in house was
over three years ago; while the FCL PM effort started over 4 and a half
years ago.)

Hi Steve,

Excellent work!  Is it *nice* having this info available online,
particularly the index!!

					Chris

Is there any documentation around the MIR, eg specifications on how (formats)
things are stored  etc.

	Anna-LEna
 

    Almost all of the .PS files we make of our documentation begin with a
    blank page.  This makes the pages fall correctly when you print the
    files two-up (two page images on each sheet) on a PostScript printer. 
    However, some people are beginning to use LPS20 printers, which can
    print duplex (both sides of each sheet).  The two methods are
    incompatible.  What to do?
    
    I have placed a file called BLANK.PS in the public directories in which
    we store our .PS files.  If you want to print duplex, simply print this
    file first in a list, for example:
    
    	PRINT/QUEUE=<queue>/PARAM=(DATA=POSTSCRIPT,SIDES=2) blank.ps, <file>.ps
    
    You'll get a blank sheet and then the book in correct assembly.
    
    If you want to print two-up, omit the blank page, for example:
    
    	PRINT/QUEUE=<queue>/PARAM=(DATA=POSTSCRIPT,NUMBER=2) <file>.ps

Steve:

  The [.review] directory is protected:


HAYNES::USER$43:_PLO> dir mcc_arch:[000000]

Directory MCC_ARCH:[000000]

APPROVED.DIR;1                               1  19-JAN-1991 12:51:56.37
BUILD.DIR;1                                  1  19-JAN-1991 12:52:22.61
CMS.DIR;1                             no privilege for attempted operation
CMS_V11.DIR;1                         no privilege for attempted operation
DIS.DIR;1                             no privilege for attempted operation
DRAFTS.DIR;1                          no privilege for attempted operation
FIELDTEST.DIR;1                       no privilege for attempted operation
LISTS.DIR;1                           no privilege for attempted operation
MEMOS.DIR;1                           no privilege for attempted operation
NOTES.DIR;1                           no privilege for attempted operation
OBSOLETE.DIR;1                        no privilege for attempted operation
PUBLIC.DIR;1                                 1  19-JAN-1991 12:57:49.32
REVIEW.DIR;1                          no privilege for attempted operation 
SRC.DIR;1                                    1  19-JAN-1991 12:57:50.27

  Please post a note when this is fixed...

                                                                     - Jerry

You don't need to be able to read the directory in order to copy/print
the file.  You just can't do wildcarding.

dir took""::mcc_arch:[review]eco42.ps

Directory TOOK""::MCC_ARCH:[REVIEW]

ECO42.PS;7

Total of 1 file.

    I just tried copying the bookreader stuff... the pak came across
    alright but the .dec$book file is protected.
    
    					- Alan

Would someone please post the order number for the individual documents in the
documentation kits?  I'm particularly lusting after the 'Basic Management
System Use' manual.

Thanks!
tl

    The currect PAK for the review version of the SRM will be expiring on 
    August 1, 1991.
    
    A new pak is located at:
    
    took""::mcc_arch:[review]mccsrmc011_pak.com
    
    This pak is applicable to all previous review versions of the bookreader 
    SRM, and all of those that will be published through November 1, 1991.
    
    regards,
    
    \steve

What's the current status of making DECmcc documentation available in 
Bookreader format?  The previous reply to this note on that subject is almost
a year old.

Thanks!
tl

    We plan to have Bookreader versions of the DEcmcc user documentation
    available for Version 1.2.  I believe the Developer's Toolkit
    documentation will likewise be available in that timeframe.

Is there a particular place in this conference for problems/errors found in 
the books?  I just installed DECmcc with a co-worker and we found a number of 
things that for some reason don't work.  They should be corrected for the 
next release.


Steve

    Hey Steve, send them to me.

    The v1.2 field test draft of DECmcc Developer's Toolkit Reference is
    available in Bookreader format in
    
    TNPUBS::USER$657:[PUBLIC.NMS.DECMCC_V1_2]
                                DECMCC_DEV_TOOLKIT_REF_FT.DECW$BOOK
    
    More Bookreader books coming soon as we shake the last remaining quirks
    out of our Interleaf-to-Bookreader process.  Watch this space.
    
    Mike 

The EFT draft of the V1.2 DECmcc Planning and Installation for VMS manual is 
available in the following PostScript file:

     WORDY::USER$657:[PUBLIC.NMS.DECMCC_V1_2]DECMCC_INSTALL_VMS_EFT.PS


Jack

The EFT draft of the V1.2 DECmcc Planning and Installation for ULTRIX manual is 
available in the following PostScript file:

     WORDY::USER$657:[PUBLIC.NMS.DECMCC_V1_2]DECMCC_INSTALL_ULTRIX_EFT.PS


Jack

The EFT version of the V1.2 DECmcc TCP/IP SNMP AM Use manual is available in 
the following PostScript file:

     WORDY::USER$657:[PUBLIC.NMS.DECMCC_V1_2]DECMCC_TCPIP_SNMP_AM_USE_V12.PS


Jack

    Bookreader version of Management Module Programming v1.2 FT draft is at
    
    wordy::user$657:[public.nms.decmcc_v1_2]
    			decmcc_mm_programming_v1_2_ft.decw$book;1

    There haven't been any new Bookreader documents since 20-Nov. Given we
    are getting close to product release, will more Bookreader documents be
    made available for review soon?

    I don't believe we've converted anything lately.  We have shifted out
    of test mode; we feel reasonably satisfied with the results.
    
    The plan is to get the printed books finalized, and then convert them
    to (final) Bookreader files.

    As of today I am no longer the lead writer for DECmcc documentation. 
    For the time being, please address all inquiries, complaints, and kudos
    to John Harrison, TNPUBS::HARRISON, DTN 226-5670.

    Re .53, look at TOOK""::MCC_ARCH:[REVIEW] again for the latest stuff.
    
    --svb

  Sorry.  That was an editing problem.  The VMS PAK filespec was wrong.  The
  correct filespecs are:

dir mcc_arch:[review]mccsrmf011_*pak.com

Directory MCC_ARCH:[REVIEW]

MCCSRMF011_ULTRIXPAK.COM;1                 2/3        2-APR-1992 14:50:13.03
MCCSRMF011_VMSPAK.COM;1                    2/3        2-APR-1992 16:14:48.95
 

One of my customers has given me a reference to some DECmcc documentation 
which I can't immediately identify.  It is AA-PDVKA-TE and the customer 
believes the title is DECmcc Management Model.  Now the closest I can come 
to that is DECmcc Management Module Programming but my V1.0 copy of that 
has AA-PD5NA-TE as its ref number.

Could somebody please clarify what AA-PDVKA-TE really is and which doc kit 
it is included in?

Thanks.

    Re: .58
    
    Hi,
    
    We can not find a manual with a part number of AA-PDVKA-TE or title 
    of DECmcc Management Model.  My assumption that your guess is correct, 
    that it is AA-PD5NA-TE (now AA-PD5NC-TE) DECmcc Management Module
    Programming.
    
    Feel free to contact me directly if you receive more information that
    could help us resolve your customer's problem.
    
    bob

    A *very* naive question: where can I get the pak for DECmcc docs in
    bookreader format? I mean one valid for the latest documentation from
    WORDY?
    I'm on a DS3100.
    
    Thanx in advance, Giuseppe.

    The BOOKBROWSER pak should do the trick.  You can get it from VTX PAK.
    
    Mike

I just copied over the Bookreader docs, but can't find a VMS installation
guide.  Is that deliberate?

trying to save trees,
_Mek

    Yes, that was deliberate.  Those Bookreader files were for the August
    (ULTRIX) CD-ROM.  The VMS Installation Guide will be available some
    time before 6 August, when the files are due for the next VMS CD-ROM
    (September).  Watch this space.
    
    Mike

    Hi,
    
    For all those who have been looking for the updated Alarms and
    Notification Service Use manual, the latest revision is now in:
    
    	TNPUBS::PUBLIC$DISK:[PUBLIC.NMS.DECMCC_V1_2]
    	    DECMCC_ALARMS_NOTIFICATION_REV_D.PS
    
    
    This manual will be released at the same time as the EMS kit, and will
    replace the existing manual.  The version corrects a number of syntax
    problems and resolves a number of user issues.
    
    bob

I've updated the TSAM (Terminal Server AM) documentation in the
TSAM$KITS directory again.  There is now a Bookreader version of the
TSAM use manual available.  The postscript version has been renamed/upgraded,
but only change has been to remove the "Digital Confidential" tag at
the bottom of every page.

Here is what is available for TSAM documentation now at TOOK::TSAM$KITS:

Directory TOOK::TSAM$KITS:

DECMCC_TSAM_V1_0_FINAL.PS;1
                       6452  20-AUG-1992 09:38:00.00
MCCTSAM010.RELEASE_NOTES;1
                        109  16-JUL-1992 10:28:55.00
MCCTSAM010_RELEASE_NOTES.PS;1
                        165  16-JUL-1992 13:41:54.00
MCC_TSAM_USE.DECW$BOOK;1
                       6187   8-SEP-1992 14:59:27.00
TERMSERVER_MRM.DECW$BOOKSHELF;1
                          1  26-AUG-1992 17:06:40.00
TERMSERVER_MRM_BOOKREADER.DECW$BOOK;1
                       2353  26-AUG-1992 16:37:36.00

Total of 6 files, 15267 blocks.

-Dave


If you are curious about the MRM, I've what follows is the text
of the note I posted when that was announced:

I have just generated a Bookreader format copy of the TSAM MRM (Module
Reference Manual)  I did not have time to get this in the original
TSAM SSB kit, and had planned on sneaking it onto the Toolkit submission.
Well, they aren't going to put MRMs in bookreader format on the toolkit kit,
so it it now homeless.  (Thankfully.  I'd probably have to spend another
week on it to get it to production quality.  But you will find it
as accurate as the PS & TXT files delivered with the TSAM kit,
save cosmetic errors such as multiple table headers, and one
column running into the next.)

The files are located in the same directory as the TSAM kit:

Directory TOOK""::TSAM$KITS:*.DECW*

TERMSERVER_MRM.DECW$BOOKSHELF;1
                          1  26-AUG-1992 17:06:40.00
TERMSERVER_MRM_BOOKREADER.DECW$BOOK;1
                       2353  26-AUG-1992 16:37:36.00

Total of 2 files, 2354 blocks.

If you are in doubt as to whether what is in this MRM is at all useful,
I'm of the opinion that you are not missing much if you don't look at it.
This one is over 500 pages in printed form, and it is mostly boiler plate
of the worst kind.  Unless you are writing code to call TSAM from the DECmcc
call interface, there is probably no point in killing that tree.

On the other hand the Bookreader MRM might be helpful once in a while
if you set up a lot of alarms on TSAM, or if you can use DECmcc only from
FCL(but then you probably don't have a workstation then do you?)

Have fun!

-Dave

                   -< DECmcc SRM V1.2 - Bookreader Version >-

			    For Internal Use Only


The DECmcc V1.2 SRM is available in Bookreader format.  This corresponds to
the SRM which is shipping with the DECmcc V1.2 Toolkit.  The order numbers
for the hardcopy version of the V1.2 SRM are AA-PD5LC-TE and AA-PE55C-TE for
volumes 1 and 2, respectively.  This SRM supercedes the V1.1 version of the
DECmcc SRM.

The related files for the bookreader version of the V1.2 SRM can be found at:

     took""::mcc_arch:[review]mccsrm012.decw$book 
     took""::mcc_arch:[review]mccsrm012.decw$bookshelf

No PAK is needed for this book.

The same mccsrm012.decw$book file may be used on ULTRIX (named
mccsrm012.decw_book), as on VMS.

								- Dave
    

    Where can I find the most recent version of the SRM in PostScript?
    It doesn't seem to be in the public directory on TNPUBS, unless
    it's under a file name I don't recognize.  
    
    I am specifically looking for information on the Help File Builder
    in order to develop help files for an application built with DECmcc.
    
    If this information is not in the SRM, please let me know where I
    can find it.
    
    Thanks in advance!
    
    <<Linda 
            

Linda, 

    You could try poking around the directory pointed to by the reply just
    before yours:

	$ DIR TOOK""::MCC_ARCH:[REVIEW]*SRM*.PS

	Directory TOOK""::MCC_ARCH:[REVIEW]
	
	MCCSRM012.PS;2         9419/9420     [320,663]        (RWED,RWE,RE,RE)

	Total of 1 file, 9419/9420 blocks.


    re: Help files

    Please reference the following documentation:

     - POLYCENTER Framework Developer's Toolkit Reference (AA-PD5MD-TE), Ch. 5
     - POLYCENTER Framework Management Module Programming (AA-PD5ND-TE), Ch. 8



    /doug

	Where oh where is DecMCC V1.4 documentation located?

Regards

Hi,

V1.4 is a maintenance release. User documentation was not changed from V1.3.

Only doct present on binary Condist is updated : SPD's, cover letters,
release notes, installation guide.

Benoit

    Can someone point me to the latest documentation (postscript, LN03, or
    Bookreader)?  I've searched the following directories without success:
    
	TOOK::MCC_ARCH:[BUILD]
	TOOK::MCC_ARCH:[DOC$TOOLS]
	TOOK::MCC_ARCH:[DOC$TOOLS.TEX]
	TOOK::MCC_ARCH:[SRM]
	TOOK::MCC_ARCH:[SRM.ARTWORK]
	TOOK::MCC_ARCH:[SRM.DOCV2]
	TOOK::MCC_ARCH:[SRM.ECO132]
    
    Thanks,
    Charlie 

Hi Charlie,

Pointers such as TOOK::MCC_ARCH:[...] are obsolete.

Bookreader documentation is available on documentation CDROM.
As these docs where not updated when maintenance release V1.4 was shipped 
you will find V1.3 version.

Installation guide, cover letter, spd were updated when V1.4 was shipped
on Binary VAX/VMS CDROM in march 1995. These docs are present in both TEXT
and Postscript form on the CD.

Hope this helps,

Benoit