Typo error (AMS_Propoerty instead of AMS_Property).

Correct the typo error.

In the spec the AMS_Property template have been used several times; it has been used in the PIM for instance as: AMS_Property<AMS_StdState,ST_NOSTD> or AMS_Property<AMS_StdMechanism,MS_NONSTD>. Now, it could be useful to always use the same convention to define the names of such “non stardard” enumeration values (such as ST_NOSTD or MS_NONSTD) since sometimes in the document it is used ST_NONSTD instead of ST_NOSTD, or MS_NOSTD instead of MSNONSTD and so on…In this way it would be easier to catch these little inconsistencies. For instance in the diagram 7.16 it is used MS_NONSTD instead of MS_NOSTD... but it is just an example since this kind of error can be found in various parts of the document.

Generalize the use of *_NONSTD

Light weight logging specification (realtime/2002-06-14) referenced is not newest version. Possible solution: Use the formal/05-02-02.

Use the formal/05-02-02

The specific set of HW Utilizations and semantics should be reviewed to remove ambiguities. In particular, the time scale over which utilizations are measured should be explicitly stated. In addition, the specific set of HW Utilizations should be reviewed to determine whether additional information is needed, e.g., 1) network data input and output values and rates. 2) Per cpu statistics, 3) per network connection statistics, 4) page faults and rates, 5) size of the process ready queue, etc...

Add a new template sub-classing AMS_Property to have the ability to accounts hardware and software resource usage with time, duration and units; and use it in AMS_Host and AMS_LANEndPoint.

Clarification of capabilities for control of J2EE and CCM applications is requested.

The resolution does not require a change in the spec, it is an implementation detail: a set of CIM_Action(s) needs to be inserted to drive the CCM start (see image below).

Clarification of the intent and approach is requested concerning 1) how the DCPS/f profile will access static configuration information and 2) how the DCPS/m profile when used with the CORBA/IDL and CIM PSMs will map the Subscription methods to DCPS/m topics, i.e., the CORBA/IDL PSM subscription methods currently pass in an object with an interface to receive CORBA one-way callbacks, which would not be needed or used if the DCPS/m profile is used.

Point (1): DCPS/f accesses static configuration information through the mandatory XML PSM
Point (2): "they work in their usual way, independently of each other"

The CIM_Action that the error is associated with should be added to the AMS_ErrorStruct (Section 2.4.2.4) so that it will be clear which Action failed. This is important for determining where a problem occurred within a set of actions.

Precise in the CIM_ActionStruct class that the attribute "Element" must be the full path to the action that caused the error when the error comes from the execution of an action.

Clarification is needed that the CIM_Process Handle/key is the Process ID (pid). This is implied but not explicitly stated. Likewise, clarification is requested in Section 7.1.9.50 to state that the CIM_Thread Handle/key is the Operating System Thread ID.

On POSIX systems, this attribute is the process ID (resp. thread)
On Win32 systems, this attribute is the process handle (resp. thread)

Add prefix to the topic names, because they are global and should be unique within the whole system. B.t.w.: For the type definitions the prefix is not necessary because the are in the namespace AMSM. Proposed solution: Add Prefix AMS or CIM to Topic names. Topic name = Data type name

Add Prefix AMS to Topic names

PSM DCPS: Root topics are not needed because the lists can be retrieved from other topics. This would give redundant info in the system and unnecessary overhead. For example for software systems no root topic Software systems is needed. The list of software systems are accessible via SoftwareSystem topic. Proposed solution: Remove all info related to the root topics.

Remove all info related to the root topics.

Vista is missing in the OS type enumeration. Proposed solution: Replace the enumeration of the OS type to a string, because it will be changed in the future many times. And it than easy to a add an OS type, at least for the DCPS PSM.

Add vista to the OS type enumeration

The numbering of the table is in some cases incorrect… for instance in chapter 7 it starts from 7.4 and in chapter 8 starts from 8.6

Modification in the numbering of the tables.

Paragraph 7.1.5 ("AMS_BAlancingStyle") should be numbered 7.1.4.2.

Paragraph 7.1.5 is to be numbered 7.1.4.2