When is it allowed to call UnloadConfiguration. Does this depends on the state of the concerned entity, for example SoftwareSystem

No Data Available

For AMS_ConfManagement the possible return values of the operations LoadConfiguration and UnloadConfiguration are not specified

Add the AMS_NOK for those cases.

A number of XSD element definitions contain the optional attribute owner. Mostly the owner of an element is defined implicit by the enclosing element. The specification should explain the use of the owner attribute

Precise the paradigm.

The TargetOperatingSystem attribute of CIM_OSVersionCheck has type int. It may be better to specify it as an enumeration e.g. AMS_OSType.

No Data Available

What is the purpose of an AMS_DeploymentLinkSpec referencing an AMS_DeploymentLinkSpec from another AMS_DeploymentSpec. This implies that one AMS_ESESpec can be used to deploy several AMS_ExecutabeSoftwareElement's. How relates this to AMS_OSUsed and AMS_HostUsed.

No Data Available

The association between a AMS_ExecutableSoftware Element and AMS_DeploymentLink is not drawn in figure 7.7

This association is shown in the figure 7.12 ("Application Deployment class diagram") because it's an element of the Application Deployment package.
Disposition: Closed, no change

The actions (control) associated with the transitions ALLOCATE and RECLAIM are not specified.

No Data Available

The Check specification does not provide an extension mechanism to define implementation specific check as does the Action specification.

No Data Available

Why is the RedInitState attribute of AMS_ESESpecType defined as required while it is optional FTM. Why not specify a default value for RedInitState

Define this attribute as optional in the XSD

It is unclear if the control response will be used when e.g. StartUp method will be successfully executed. If it will be used than AMS_ErrorCode is missing the code AMS_OK.

The PIM does have this value but it was not mapped in PSMs.

The attribute SoftwareElementID of AMS_ESESpec is not specified as required. However in the PIM the SoftwareElementID is defined as a key property.

Define this attribute as required in the XSD.

The AMS_SEStartupCPUDependency defined as an association class between AMS_ESESpec. However it only depends on the CPU load of the system and not on the other AMS_ESESpec.

No Data Available

Missing the relationship to the target ESE spec for AMS_SEShutdownDependency, and AMS_SEStartTimeDependency

No Data Available

CORBA/IDL PSM errors "8.6 page 129-172: Many IDL errors AMS_ApplicationSpecification.idl line 170: ""AMS_SecurityCheck CLASSID"" should be ""AMS_SecurityCheck_CLASSID"" line 173: ""AMS_SecurityCheck List"" should be ""AMS_SecurityCheckList"" line 174: ""AMS_ SecurityCheck ListIterator"" should be ""AMS_SecurityCheckListIterator"" AMS_CIM.idl line 846: missing ""readonly attribute"" definition line 848: missing ""readonly attribute"" definition AMS_AMSManagement.idl line 29: ""uint16"" must be ""AMS_uint16"" line 116: field identifier ""RTHS"" is also used on line 115 AMS_ApplicationSpecification.idl line 170: ""AMS_SecurityCheck CLASSID"" must be ""AMS_SecurityCheck_CLASSID"" line 173: ""AMS_SecurityCheck List"" must be ""AMS_SecurityCheckList"" line 174: ""AMS_ SecurityCheck ListIterator"" must be ""AMS_SecurityCheckListIterator"" AMS_LogicalHardware.idl line 41: Missing "";"" at EOL line 187: field identifier ""RTHU"" is also used on line 188"

fix it

The Naming Convention specifyies that it reuses the DMTF CIM naming convention which is based on so-called "weak" associations. However in the CIM specification a weak association results in the propagation of the key properties to the dependent class. In the AMSM specification this is not the case. For a association link from class A to class B the AMSM specification states that the global name of an instance B is constructed by concatenating the global name of an instance of A with the key values of B. However the AMSM specification does not specify the syntax for the construction of the global names. Further it should provide an example.

Remove any reference to DMTF CIM in section 7.1.2.1. Add an example. Specify more clearly how the global name have to be built.
State that the value of a key attribute shall be unique for all the instance of a class.
Add the class name and the attribute name in the global name in order to avoid the cases where classes have a key relation with themselves and another key relation with another class. These cases lead to mistake because key names are unique per class and not for the whole model.

Unclear what a AMS_DeploymentLinkSpec describes. In the description of the AMS_DeploymentLinkSpec class it is mentioned that a software item (application, software system, or software element) will have to run on some hosts. However an AMS_DeploymentLinkSpec has only an association with an AMS_ESESpec and thus with a software element and not with an application or software system. Explain how an AMS_DeploymentLinkSpec is related to an application or software system.

Applications and software system are not deployed on one host but on a network. Clarify this in the description of the AMS_DeploymentLinkSpec class.

After loading the specification files the SoftwareSystem must be deployed. However the classes in the Management Package do not provide a method to access an AMS_DeploymentSpec directly. What is the way to deploy a SoftwareSystem.

No Data Available

In the ActionCheckCase there is a CASE_START and a CASE_SHUTDOWN. When you call one state START than the other should be named STOP. In common in this document the term startup and shutdown is used, but for ESE and application it would be logical to use start and stop.

Replace CASE_SHUTDOWN with CASE_STOP, CASE_PRE_SHUTDOWN with CASE_PRE_STOP, CASE_POST_SHUTDWON with CASE_POST_STOP.

Paragraphs 7.1.3 to 7.1.14 should be 1 level higher (7.2 to 7.13) Paragraphs 10.1.1 to 10.1.4 should be 1 level higher (10.2 to 10.5) Create a paragraph 11.1.2 “Mapping principle” with paragraphs 11.1.1.1 to 11.1.1.5.4 in it. Paragraphs 11.1.2 to 11.1.6 should be 1 level higher (11.2 to 11.6) Paragraph 12.5.1 should be 12.6

agree

The attribute LinkID of AMS_DeploymentLinkSpecType is not specified as required, while the PIM specifies this attribute as the key.

Move this attribute to optional

XSD specification of AMS_SupportedApplicationModel not consistent with model The AMS_SupportedApplicationModel class as defined in section 7.1.12 is specified to contain uncorrelated collections of AMS_ModelType, AMS_OsType, AMS_State, etc. The XSD specification defines the AMS_SupportedApplicationModel as a collection of records, where each record contains one AMS_ModelType, AMS_OsType, etc. Thus the XSD specifies an unwanted correlation between those element.

Unleash the correlation among these items.

Undefined order The model does not define any order in execution of actions defined by the "CIM_Action" class and the "CIM_ActionSequence". This might be relevant, thus the model must express that. If it is defined in CIM, refer to the CIM document and location or copy the definition.

Specify that actions are ordered and how their execution depends on that order.

AMS_RTSWIndication unpractical/incorrect definition The attribute ElementCase equals the discriminant of the union Element and should be removed. As an preferred solution, the union can be replaced by just one string indicating the referenced topic, the union cases only differentiate in naming of the attribute, not the type. This allows setting a query on this field. The keylist is also incorrect, a union may not be part of the keylist. AMS_RTSW should also not be part of the keylist because an Element can have only one state at a time.

Replace the union Element with a struct as proposed. Modify the keylist as proposed as well.

CIM_NextHopRoute topic defined In the DCPS PSM CIM_NextHopRoute is defined while the PIM defines it as an abstract class. Remove this topic.

Remove the topic.

AMS_SoftwareSystem Owner: The Owner is defined as a bounded sequence of maximum length 1. Expressing a non existing owner can be done by means of an empty string. Thus a sequence is not needed. As an advantage, Owner can be used in a query expression.

modify as proposed

Not all expected ESE state changes are described State changes that are initiated by the managed process are not described in the state diagram. For instance a managed process can terminate with returning a code indicating an error. There is no state change from RUNNING to ERROR however.

Add a state change from RUNINNG to ERROR. This state change doesn't imply a new method since it's caused by the crash of the process.
Specify that the state change "STOP" can be initiated by the process itself.

PIM: No alternative models possible No way to specify alternative model types other than PROCESS, J2EE and CCM

No Data Available

It is unclear why there is a StartUp and a Shutdown method on the AMS_DeploymentConfiguration class. It seems not logical how to manage executable software element through different views on the system

No Data Available

Signed integers in DCPS PSM All unsigned numerical values from the PIM are mapped to signed numbers in the DCPS PSM

All numerical values in the PIM are unsigned numbers, it so 'enough' to change all the numbers to unsigned equivalent.

DCPS PSM: typo in field CIM_ProcessThead must be "CIM_ProcessThread" (2 times). This is AMSM.idl from DCPS PSM line 594 and line 607.

agree

AMS_StdState not explained The referenced class AMS_StdState class is not defined nor explained in the PIM.

Add a section on AMS_StdState.

Inconsistent naming of compositions Composistions SupportedModelType and SupportedOSType should have been defined plural in order to be consistent with the other compositions. This might be an issue for the whole document.

Add an "s" to these compositions.

"optional LBM" stereotype The RedState stereotype is defined to be "optional FTM" and "optional LBM" while the targeted class is only "optional FTM". Remove the "optional LBM" stereotype.

Remove the "optional LBM" stereotype

XML PSM: referenced type name incorrect AMS_SupportedApplicationModel.xsd: AMS_SupportedMechanims_LinkType on line 160 must be AMS_SupportedMechanisms_LinkType.

Change AMS_SupportedMechanims_LinkType with AMS_SupportedMechanisms_LinkType.

Issue: Figures 7.7 and 7.8 on pages resp. 38 and 39 are identical.
Resolution: Figure 7.7 should be replaced by another figure, which will be supplied as part fo the move to the new UML tool.

Cheers,

New figure should be used instead of Figure 7.7

The association with AMS_Host is redundant. AMS_OperatingSystem has an association with AMS_Host, see figure 7.19 and 7.20 on page 96/97. This implies that the association with AMS_Host in Application Deployment Specification class diagram on page 57 is redundant

The association of AMS_DeploymentLinkSpec with AMS_Host on page 59 in figure 7.13 can be removed. Due to this change, Figure 7.12 also needs to be changed. A new association of AMS_DeploymentLink with AMS_OperatingSystem called AMS_OSUsed will then replace the association AMS_HostUsed. Also the PSMs have to be updated.

CIM_Process/CIM_Thread OSName attribute missing According the PIM on page 39, CIM_Process and CIM_Thread have an attribute OSName. In the DCPS PSM there is only an attribute Name and not an OSName.

Add the attribute Name to both of them (CIM_Process and CIM_Thread). Add also the attribute Name to CIM_UnixProcess and CIM_UnixThread, because these inherit the attribute Name from CIM_Process and CIM_Thread.

Strange relation between methods and transitions. The expected state and the methods to use to reach the state depend on the previous state. That is very strange and error prone. e.g. if the wanted state is STOPPED, case the current state is RUNNING, ShutDown must be called. In case the state is HALTED, Stop must be called.The method should denote the wanted state with this limitation that only specified state transitions are possible. Note that there is no operation to enter the HALT state. "

Agree. Let's summarize: the StartUp methods are for reaching state "RUNNING" (transitions LOAD_START, START, LOAD_START_DIRTY; CONTINUE is lacking here), the Shutdown methods are for reaching state "EXECUTABLE" (transitions UNLOAD, RECOVER, RECOVER_DIRTY; STOP have to be removed here), the Load method reaches the state "LOADED" (transitions LOAD, LOAD_DIRTY), the Stop method reaches the "STOPPED" state (transitions HALT, STOP_HALTED; HALT should be replaced by STOP here), and the "Continue" method is a shorthand to reach the state "RUNNING" from the state "HALTED".
Eventually, the state "HALTED" is no more reachable and a method "halt" has so to be added to reach it".

Transition CONTINUE (see fig 7.27) is missing. The description of transition STOP_HALTED does match transition CONTINUE but not STOP_HALTED (see Stopped state in 7.1.14.1.6).

The description of the transition CONTINUE is to be added and the description of the transition STOP_HALTED must be fixed.

States like HALTED can not be realized as easy on platforms like VxWorks. For a single task this is easy, but GNATworks based applications can be multithreaded (thus have a process like model). Supporting a HALTED state for GNATworks on VxWorks would require a special profile to be supported. This state must be made optional.

Move the HALTED state from the Normal Package to the Maximum Control Package as long as the matching functions and transitions

Errors in AMSM.idl: Line 81: Undefined fields in keylist (remove ",CPULoad,MemoryLoad,DskUsage") Line 118: Missing ";" at EOL Line 120: Missing ";" at EOL Line 122: Keylist is defined of an missing structure, insert before line 122: struct AMS_ControlResponse

; Line 154: typo "sequance" must be "sequence" Line 199: typo "sring" must be "string" Line 365: missing prefix "AMS_" before "LOAD_START_DIRTY" Line 372: AMS_State used before it is defined (used on line 154) Line 382: typo "AMS_StdMechanisms" should be "AMS_StdMechanism" Line 44, Line 466, Line 496, Line 524, Line 541, Line 561: Missing ";" at EOL Line 592, Line 594,Line 605,Line 607,Line 613: "list" must be "sequence" Line 635, Line 660, Line 695, Line 722, Line 733, Line 744, Line 755, Line 770, Line 781, Line 792, Line 803, Line 814, Line 825, Line 836, Line 847, Line 865, Line 906, Line 937, Line 954, Line 1153, Line 1171: Missing ";" at EOL

All these issues are syntactic errors.

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

Add motivation value QOS Destination_Order: Motivation for DESTINATION_ORDER BY_SOURCE_TIMESTAMP is unclear. It might be related to the demand for executing different commands on the same element in time order. In that case motivate the choice. BY_SOURCE_TIMESTAMP requires aligned time awareness in order to function.

Reshape the section about QoS for the DCPS mapping.

Remove definition of QoS which are not functional relevant: Unclear why TRANSPORT_PRIORITY, RESOURCE_LIMITS are defined. These QoS policies relate to system design and are functionally irrelevant.

Reshape the section about QoS for the DCPS mapping.

QoS not defined correctly: The section uses the term "topics QoS" incorrectly. In DDS, Topic, DataReader and DataWriter QoS setting are defined independent of each other. This chapter incorrectly merges all QoS policies into one merged list. This should at least not be called topics QoS.

Reshape the section about QoS for the DCPS mapping.

Separate topic for CurrentState: The AMS_ExecutableSoftwareElement CurrentState aggregation is mapped in an AMS_State enumeration within the struct of AMS_ExecutableSoftwareElement. The CurrentState state however will evolve asynchronously from the state of other attributes. Further it is very likely that control over the CurrentState is located somewhere else. For that reason it is more practical to define a separate topic which via a weak reference will identify the state of the AMS_ExecutableSoftwareElement. Note: This statement is probably true for more state/statistics based information.

Separate the CurrentState attribute for the sake of the ease of implementability.

Define history for control topics: As "Control topics" have no key, there will be a single place buffer. The HISTORY QoS policy for "control topics" is defined to be depth 1. This implies that only one control can be issued at the same time (in a system). Proposal would be to define a history for control topics of which the depth can be implementation specific. In that case the OWNERSHIP QoS policy is not needed either.

Reshape the section about QoS for the DCPS mapping.

Inconsistent definition keys of Control Topics This section states that "Control topics" have no key. AMSM.idl however defined "Element" as key for these topics. Remove "Element" as key.

Remove "Element" as key for control topics.

Association AMS_StdHWUtilization missing in PSM: No association to AMS_StdHWUtilization (see fig 7.20 on page 97) is defined. In the DCPS PSM that association is also missing. The figure also defines a 0..* multiplicity while on page 103 in the table 1..1 is specified for "AMS_RTHU <<optional HSM>>".

First, it's not AMS_StdHWUtilization (US way) but AMS_StdHWUtilisation (UK way). Second, it is an enumerate that has to be used as a parameter of the template AMS_Property. Eventually, multiplicity should indeed be 0 .. *. Thus modification of table in page 103

Clarify Owner and Owner object: It is unclear from the specification what an "Owner" or "owner object" is, how does this relate to the PIM

Precise the paradigm.

Clarify inheritance of CIM classes: The PIM uses the inheritance UML symbol to show a relationship which is not really an inheritance relation (e.g. attributes are not inherited from CIM). Clarify the use of this inheritance symbol for these cases.

See issue 13061 for disposition

Clarify inheritance of CIM classes: The PIM uses the inheritance UML symbol to show a relationship which is not really an inheritance relation (e.g. attributes are not inherited from CIM). Clarify the use of this inheritance symbol for these cases.

Precise that the CIM package is not a full copy of CIM but a projection of a part of CIM (the useful part indeed).

Still information about root topics Related to Issue 11517, root topics were removed, but not all info was removed. Also page 278 section 11.1.1.5.2 last bullet ("root" elements).

remove this iformation

Enumeration misses PowerPC e500 family.

We need to find a comprehensive way to deal with all kind of extension. This may be expressed in a discussion paper and/or in future major revisions of the standard. Anyway, since it's still possible to add a new item in the enumeration in a non-standardized way, this issue doesn't preclude implementations.
Disposition: Closed, no change

Typos class and interfaces: 7.1.4.3: "An AMS_Application is an interface" should be "An AMS_ExecutableSoftwareElement is an interface" 7.1.4.8 "An AMS_Application is an interface" should be "An AMS_SoftwareSystem is an interface" 7.1.7.16 "The AMS_SEStartDependency class" should be "The AMS_SEStartCPUDependency class" 7.1.7.18 "The AMS_SEStartDependency class" should be "The AMS_SEStartTimeDependency class"

just do it

Some strange definitions containing "%2B"

remove

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