Conference azur::mcc

> Is there a call I can make at run-time to obtain the version string
> of the kernel the AM is running against?

	You mean like the response to MCC> show mcc 0 all char ?

	If so, then you could call mcc_call_access() at run time and
	decode Out_P.  ASSUMING that the kernel has implemented this by
	placing the dispatch entry in the call_access tables and not the
	call_function tables.  Since you, as an AM, are not allowed to
	mcc_call_function().  (Or you could just not tell anyone...)


> I figure MCC should appear as a component in the Implementation values our
> AMs return, and to build that I'll need the version.

	If something is going to 'call'	your AM, why can't something also
	call the kernel as above?

	Mike

Mike,

Good questions, thanks. I guess I envisioned one of the uses for the
implementation response as being able to find the versions of  all
components participating in the services provided by the AM. Since most
of the implementation components are assembled at run-time by image
activation and IPC, their versions may be different than what the AM
was linked against.

If something went haywire, asking the customer to do a 
show mcc 0 xxx_am implementation might tell us the versions of
     
     1. the AM
     2. the MCC kernel image
     3. the agent
     4. the MOM (using common-agent-speak)
     5. the server process

Some implementations wouldn't have all those components, of course.

If someone can look at that list and say, "You've got an old MOM" (sorry)
then we're ahead of the game in the distributed plug-and-play environment.

     <<< Note 479.2 by COOKIE::KITTELL "Richard - Architected Info Mgmt" >>>
                   -< Perhaps I'm trying to put too much in >-



Good questions, thanks. I guess I envisioned one of the uses for the
implementation response as being able to find the versions of  all
components participating in the services provided by the AM. 

>> all MMs have a MOM agent, which I thought was *required*, and required
>>  to be in the AM dispatch table. To get the versions of each MM you call,
>> formulate the mcc_call_access for verb show, partition characteristics,
>> (relevant entity, of course), and decode the ILV, as Mike said.  Each
>> MRM has a section documenting its MOM.
>>
>> The Kernel AM is the internal MOM agent of the MCC global entity, containing
>> little except name and version.  This AM comes with the kernel, and is
>> enrolled when the kernel is initialized.  You can get the version of the
>> kernel via mcc_call_access from this AM.  

Since most
of the implementation components are assembled at run-time by image
activation and IPC, their versions may be different than what the AM
was linked against.
>>
>>  We are supposed to be mix-and-match--as long as the
>>  versions of the components an MM uses are the same or greater than
>>  those of the components it was built with.  Retirement or change
>>  of either a routine or service interface is going to be a major
>>  job, with many checks and balances.

If something went haywire, asking the customer to do a 
show mcc 0 xxx_am implementation might tell us the versions of
     
     1. the AM
     2. the MCC kernel image
     3. the agent
     4. the MOM (using common-agent-speak)
     5. the server process

>> NOW, they can do (from FCL ): SHOW xxx all Characteristics
>> where xxx is replaced by the name of each component in question;
>> e.g. MCC 0 for the kernel, MCC 0 yyy for the MoM's version, and
>> Show yyy all characteristics to extract the managed thing's version,
>> specific to the instance of the yyy.
>>
>>I see the difference between what you suggest and what exists as
>>a problem of who issues what calls or commands.  You might look
>> at the mcc_ilv_put_mcc_reply routine and the proposed 
>> mcc_ilv_put_mcc_message and their datatypes
>> to see if they are of any use, and suggest routines, datatypes, or
>> required management services to help out if they are not. 

>>Hope I'm not going off on a wrong tangent.
 
>>Ruth Kohls

Ruth,

  I tried SHOW MCC 0 KERNEL_AM. When that didn't work I ran DAP and had
a look at the children of MCC. There is no KERNEL_AM.

The MCC entity has a Component Version = X1.1.0 attribute, but where
is that value coded? I would guess that comes from MCC_MAIN.EXE, not
MCC_KERNEL_SHR.EXE.

Your comments about image ids are correct, but as we get distributed we
need to do the same protection between the participants in a distributed
session. And on systems that don't have image ids it would be reassuring
to be able to get version info from each participant.

	Hi Richard,

>  I tried SHOW MCC 0 KERNEL_AM. When that didn't work I ran DAP and had
>  a look at the children of MCC. There is no KERNEL_AM.

	There is no entity called kernel_am.  This "AM" is the piece of the
	kernel that enrolls a MOM interface for the kernel to receive 
	requests like "show mcc 0 all attributes"

> Your comments about image ids are correct, but as we get distributed we
> need to do the same protection between the participants in a distributed
> session.

	I couldn't agree with you more.  But such protection should be
	an architected provision of the system.  You shouldn't have to worry
	about it.

	Mike

One point, Richard, you should only include in your Implementation attribute
those components that are actually included in your AM, not those you call.
Presumably, there should be an implementation attribute on the MCC entity,
and one of its components would be the Kernel, and the Version associated with
the kernel would represent which implementation version of the kernel is
part of "this" MCC.

So, what are the components of "your" AM? From what you've said, I'd presume
they include the sharable image of your AM. An executable "background image",
and possible some ancillary files. The intent of the Implemention data type
was to allow you to list each and every component. All you really need do is
register those components in the ComponentName enumeration that Bob Lynch
maintains.  

						Mark

Mark,

Thanks, that clarifies the intended scope of the implementation attribute.
I'll change the title of the base note, since "MCC version" isn't really
the issue.

But I'm a little concerned about being able to find out something about
what the AM is talking to. The AM speaks some management protocol to
an "agent", possibly on a remote node. I'm real naive about the rest of
this, but is the agent an addressable entity so we can look at its 
implementation?

If not, shouldn't the AM be able to report the agent as a component of
its (the AM's) implementation?

Presumably, the entity would have its own Implementation attribute. If the
entity were a global entity, then the agent's Implementation would be a part
of the global entity's Implementation. The AM (as an entity) would have it's
own Implementation. If the entity didn't have an Implementation attribute,
then the AM could cobble one up, but that's probably cheating.

Now this is how it *should* be. As I pointed out, few entities have actually
carried this to completion.

					Mark