Conference azur::mcc

re: .0

>2.
>Sorting windows help topics.

It's safe to ignore this message.  There was a problem with the Notification FM
help file.

>1.
>Processing entity 17 27 19
>%MCCPTB-E-NODICT, Unable to access the dictionary.

The bells are ringing, but I can't put my finger on the problem.  I'll get
back to you ASAP.

>1.
>Processing entity 17 27 19
>%MCCPTB-E-NODICT, Unable to access the dictionary.

I believe there was a bug in PTB that caused it to print this message if
there were no attributes defined for an entity class.  PTB on the SSB kit 
now prints a friendlier message ("No attributes defined for entity class").

I believe you can ignore this message, however, the final word on this should
come from Lynne Izbicki.

The problem with TEST doesn't look good, and I saw it somewhere else already
today.  I'll look into this further.

The two could conceivably be related.

Two questions:

1) When you say the "lastest" TSAM kit, is that the one announced
   in note 3.55:

Directory KITS$:[SAVESETS.TSAM]

MCCTSAM010.A;1       252  13-FEB-1991 14:37:05.00  [CC_3EW,D  (RWE,RWE,RE,RE)
MCCTSAM010.B;1      8100  13-FEB-1991 14:37:41.00  [CC_3EW,D  (RWE,RWE,RE,RE)
MCCTSAM010.RELEASE_NOTES;2
                      70  28-JAN-1991 16:43:08.00  [CC_3EW,D  (RWE,RWE,RE,RE)
MCC_TSAM_PAK.COM;1
                       1  17-DEC-1990 08:22:33.00  [CC_3EW,D  (RWE,RWE,RE,RE)
TSAM_USE.PS;1       9082  11-JAN-1991 08:57:53.00  [CC_3EW,D  (RWE,RWE,RE,RE)

Total of 5 files, 17505 blocks.

2) What version of MCC are you running?  (Kit name/date or a few link dates
   and image idents from some MCC images via ANALYZE/IMAGE.)

>MCC> TEST MCC 0 TERMSERVER_AM
>doesn't work (%MCC-E-ATTRNOTALLOW, no attribute or argument allowed). 

I mentioned that I had seen this error already today.  It turned out in the
other instance that the parse tables had not been updated before the IVP ran.
If this is the case, FCL will give you the error message you see because:

	1) the parse tables don't know yet that TERMSERVER_AM is a child entity
	   of the MCC global entity (so the parser thinks TERMSERVER_AM is an
	   argument/attribut for the TEST directive)
	2) the TEST directive for the MCC entity class accepts no arguments or
	   attributes

So, either the parse tables were out of date at the time the TEST command was
entered, or "TERMSERVER_AM" isn't the correct spelling of the terminal server 
AM's child entity class, or there's a real problem somewhere.

If your parse tables are fine (i.e. all other terminal server functions seem to
work from FCL), and the TEST command still isn't working, check the spelling of
the child entity class name.  You can do this from FCL by:

$ manage/enterprise
MCC> use mode form
test <CR>		! enter "test" in the verb field and press RETURN
mcc 0 <HELP>		! enter "mcc 0" in the entity field and press HELP

FCL should display a list of the valid child entity classes that TEST operates
on.  If TERMSERVER_AM (or something similar, like TSAM_AM) isn't there, try
the following while still in forms mode:

<DO>			! to clear all fields
<DOWN-ARROW>		! move cursor to entity field
<HELP>			! ask for help in the entity field

FCL should display a list of all the valid global entity classes.  If something
corresponding to terminal servers isn't there, the parse tables you're using
don't reflect the TSAM installation you've attempted.

>the parse tables had not been updated before the IVP ran.

It's worth mentioning that the asynchronous releases have a small dilemma which
they may or may not already be addressing.

If the installer is forced to run PTB, installations take forever, and there's
no way to "batch" several installations.

If the installer isn't forced to run PTB, and this product hasn't been installed
before, the IVP for the product can't be successfully run, because the parse
tables don't have an entry for the TEST verb.

We should be documenting this in the installation guides and warning the user 
during the actual installations.

   Re: .0

     Both of the error messages you encountered during installation are save
     to ignore (ie, the parse table and help file errors).  As Matt has 
     stated, these errors are due to problems with the Parse Table builder
     and the Notification FM help file, respectively.

     The error you saw on the TEST MCC 0 TERMSERVER_AM should only be
     returned if the parse tables were not updated (however, as you've
     shown in your note, you did update the parse tables).

     Are you sure you spelled TERMSERVER_AM correctly in your command
     (the command in your note is correct...)

     During the installation, did you see the message: "Processing
     entity 1 15"?  Is the command "TEST MCC TERMSERVER_AM" present in
     the file MCC_COMMON:MCC_PTB_PARSER.DAT?

   Re: .4
   
     You can batch asynchronous AM installations.  If you are installing 
     multiple AMs, you can put off updating the Parse table and the Help 
     files until you get to the final AM being installed (you must update 
     the dictionary for each AM however).    This is because the parse
     table builder processes the entire dictionary at once (ie, builds
     commands for all entities), and the help file builder processes all
     .HELP files at the same time.

     This would save the installer a great deal of time, since the parse
     table building is the most time-consuming part of the installation
     of an asynchronous AM.

Re .2
-----

There was no TERMSERVER_AM as a valid entity so I suppose that something 
went utterly wrong. I just wonder why & what? The terminal server icon is 
in the toolbox so that far it worked.

I tried to register a terminal server just to see what error message I 
should get and it gave me "... is not properly enrolled" from the iconic
interface and "unknown entity: TERMINAL SERVER" from the line interface
(not surprising...)

I'll tried to do an enroll and got the following reply:

%MCC-I-ENRDUPLENTRY, enrollment successful; duplicate entries found and replaced

So I think I'll try to do the installation once more and hope the result is
better this time.

To answer the other replies:

Re .1
-----

1.

Yes It should be, I have the same date (but not the same time, its 00:00:00)

2.

Here follows some output from ANALYZE/IMAGE.

mcc_main:

        Fixed Header Information

                image format major id: 02, minor id: 05

        Image Identification Information

                image name: "MCC_MAIN"
                image file identification: "DECMCC V1.1-MCS"
                link date/time: 30-JAN-1991 22:59:45.17
                linker identification: "05-05"

mcc_kernel_shr:

        Fixed Header Information

                image format major id: 02, minor id: 05

        Image Identification Information

                image name: "MCC_KERNEL_SHR"
                image file identification: "DECMCC V1.1-MCS"
                link date/time: 30-JAN-1991 22:57:55.29
                linker identification: "05-05"


Re: .5

Yes, the command "TEST MCC TERMSERVER_AM" is in the file 
MCC_COMMON:MCC_PTB_PARSER.DAT

We just went through something similar in trying to test the TCPIP SNMP AM.

In our case the parse tables were built after the install (i.e. manually, from
the user's directory), AND THE MCC_PTB_PARSER.BPT FILE WAS NOT COPIED TO
MCC_SYSTEM.

We verified this by checking the DATE on the MCC_SYSTEM:MCC_PTB_PARSER.BPT
file (it turned out to be the "previous" one).

Maybe this is the problem?

					Chris

re: .5 (the re: .4 part)

I know you can currently batch installations, and I think it's a very good
option to allow the user to do so.

My point (question?) was that if the user chooses not to update the parse 
tables, can they still choose to run the IVP?  If so, and if we haven't 
documented the fact that the IVP won't run correctly until you finish your 
batch of installations (by updating the parse tables), lot's of folks are going
to be wondering why their installations "failed" (as reported by the IVP)
when in fact the installation really hasn't been "finished".

What's the strategy for running IVPs when batching installations?

Is there an OPTIONS statement on vmsinstal for just running the IVP?

Are IVPs left around after the installation so the user can go back and run
them by hand?

Pete (aka Matt on the West coast :^)

>> Are IVPs left around after the installation so the user can go back
>> and run them by hand?
    
    Yes, they are. They should be located in the SYS$TEST: directory
    after completion of the installation.

I did the installation one more time and saw an error which I
didn't notice the firs time:


        The startup procedure for the DECmcc Terminal Server
                 Access Module V1.0 is now running.

DECmcc (V1.1.0)

%MCC-I-ENRDUPLENTRY, enrollment successful; duplicate entries found and replaced
%MCC-W-VEINVALID, entity MCC is not valid with verb ENABLE

I have also tried to do the enable manually
	MCC>ENABLE MCC 0 TERMSERVER_AM
and I got the same errormessage as above.

How come?

Re .5

By the way, entity 15 1 was processed in the installation.

Re . 7

There was no problem with the dates on MCC_SYSTEM:MCC_PTB_PARSER.BPT.

   Re: .8

   Oops - Sorry Pete!  I must have had Matt Geurtin's name in my mind
   from some other note when I wrote my reply!

   Re: .10

   This definitely looks like a problem with the parse table not having
   the correct information, although I can't understannd why.  The
   installation procedure updates the dictionary, parse table, and
   help files in the MCC_COMMON directory, so the files should be
   updated in the correct location... 

				Lynne

do a 

$ show logical mcc*/full

and

$ dir mcc_system:mcc_ptb*.*/full

and check that you're using the parse tables you expect to be using.

Make sure that the MCC_SYSTEM:MCC_PTB_PARSER.BPT and 
MCC_SYSTEM:MCC_PTB_PARSER.DAT creation dates are what you'd expect (from
your installation) and make sure that whatever directives you expect to
be able to parse show up in MCC_SYSTEM:MCC_PTB_PARSER.DAT.

I'm no TSAM expert (I just installed it yesterday).  My installation went fine, 
and though I'm not managing any terminal servers, the simple things (test, 
enable) seem to work.

If you have the log of the installation available, that might help us figure
out what's going on.

Just curious to know if this got resolved and if so what user action was
needed to correct the problems seen.

jill

   Jill - 
   
   I have been unable to determine what the problem is here.  I have
   examined the installation log, and everything looks good.  I had
   Anna-Lena show the MCC TERMSERVER_AM class and TERMINAL_SERVER
   class in the dictionary, and they are there.  I also had her send
   me MCC_PTB_PARSER.DAT, and the terminal_server commands are there.
   MCC_COMMON is set to DUA2:[MCC] (ie, no search list).   The only
   other thing I see is that she hasn't deleted old copies of 
   MCC_PTB_PARSER.* - but that shouldn't matter, should it?

					Lynne

Okay, this is something that more and more people are hitting upon as they
start extending their installations to include the asynch modules.

Originally, and I am talking way back when, it was considered an ERROR to
have an entity that had no attributes. This was due to the fact that all
entity classes were required to support the identifiers partition and we
hadn't considered the case of a null identifiers partition. But, as you
can see this has started to become common, entity classes that only support
the null identifiers partition. You can see it in things like the SNMP
extensible MIBs stuff, where all the directives are defined but it is left
to the extensibility stuff to add in the rest.

What we did was to change the severity of the message to "I"nformative instead
of error and add in the second line of text to make it more intelligible as
to what was happening. In due time I expect that section of PTB to be updated
to remove the message complete except as potentially a debug message (which
means you would have to turn on the ptb debug logical to get it). But...I
no longer own/work on PTB it has moved over to the toolkit team so I wil
let them decide if/when it gets changed.

   Again, this error is informational only, and can be ignored during the
   Terminal Server AM installation.  I will certainly include a note
   in our final release notes, indicating that this message is expected,
   and can be ignored.

   In the case of TSAM, it is the Terminal_Server Internet Arp entity which
   has no attributes.

					Lynne