## Pegasus Telecon

9 November 2001

## Attendees

Roger Kumpf

Karl Schopmeyer

Rudy Schuet

Mike Day

Mary

Barbara Packard

## Agenda

- Status of the build and updates today and inputs expected next week
- BuildMakeFile - What is this file and what it it for.
- Shutdown - Discussion of the paper and decision to proceed
- Other open items.

## NOTES

### Status:

Major changes today are those being done by Mike Day. Mike will let other developers test with the current build and proceed with a next set of changes Monday.

Current problems with build. We have some problems today with the startup process, installation of services (at least on NT) that we need to work on.

### Shutdown

This was a discussion of the paper prepared by Jenny Yu, HP.

The conclusion is that we should proceed based on this working paper. Any outstanding problems we can clear up later. There were some proposed extensions in the area of allowing initialization and termination options on all modules in the system.

Mike Day - We need to have startup and shutdown for every queue in the system. A queue represents a block of functioanlity. We need a way for all of these entities to be intialized and terminated. We need specifically to add a means to issue a terminate to each queue.

Roger - Question: "Is there an error message so we can respond to a client that we are shutting down?" There is not such message or response today. W need to generate a standard response. We need to find a specific code or means of response that would tell current client connections that we are blocking them now but may open them again. The listen sockets would be closed so no new connections would be allowed but current connections need this response. If you are engaged with a complex dialog with the server and the server closes down between a couple of messages this termination couldcause a problem. Need to figure out a message that says that the server is some kind of blocked state right now or something like this.

ACTION: Define a return code that would support the blocking of a connection without terminating it.

Mike Day defines the need for something that allows the grouping of interactions. Is there a need to expand the standard since other than batch operations, there is no concept of grouped dialog in CIM today. QUESTION: Is there sufficient need for this so that we should propose a change to the standards? Do we have any specific use cases that would support this request for a standard change?

ACTION: ALL Explore any use cases that would support the requirement for dialog grouping and document them in at least the email.

### Modules and Statistical Information - Status of dialogs

Roger noted that there is a need for information from some parts of the system to support the shutdown. In particualar they need a way to determine if there are any dialogs in process (probably by provider). Mike Day indicated that the dispatcher will be maintaining this level of info so that the question is how to share the information now.

This generated the more general qquestion about capturing and gathering statistical information on the state and flow through the system.

ACTION: We need to define this but it is open today.

We know if the provider is processing a CIM request. So we should be able to treat the provider with the existing interface. It is also very difficult for the general provider to make the shutdown in a time frame decision.

We agreed to the following: If the provider has something that requires long operations that simply cannot shutdown it is the problem of the provider to be able to continue this operation of the CIMOM shuts down. The provider will not have the capability to force the CIMOM to stay operational We agreed that this could be a significant burden on certain providers but it was the only way to insure that we could shutdown the CIMOM. Examples of this type of provider include things like Disk Format, Disk reorganize, etc.

Note that providers only get told to shutdown if there are no current operations.

We need a command also to be able to kill off a particular provider. This should also an admin command. Also need to be able to block request to a particular provider for things like upgrade. Should also consider a deregistration for a provider.

Questions from Roger

Roger - Client side of authentication - Do we plan to support a client to be multithreaded operating on the same client API? Should the multiple threads to set up a separate connection? We propsed that Roger make the simplest assumption.

Roger - Property List problem. Cannot distinguish between Null and empty property list. We need to create a propertylist type. The alternative would be to treat the propertylist as a value. The problem with the CIMvalue approach is that we could get the wrong type. Could we also go into the array class and do NULL for the array class.

ACTION: Mike Brasher - Solve the propertylist and NULL problem.

Roger - Enumerate Instance was not implemented on the client side. Roger implemented it. There is a problem with. Mike thought we had something called namedObject or NamedInstance. There is a problem with enumerateInstances and namedInstances. This needs to be fixed. There is a problem with ModifyInstance. You cannot change keys on a modifyInstance. There is a CR today in DMTF to limit the properties that will be changed. Need to add instanceName argument to modifyInstance. We have objectWithPath today. WIll have to create a type called CIMNamedInstance.

ACTION: Mike and Roger.