Issues for AMSM Finalization Task Force 2
To comment on any of these issues, send email to amsm-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 11404: AMS_Property template
Issue 11405: Typo error (AMS_Propoerty instead of AMS_Property).
Issue 11406: The numbering of the table is in some cases incorrect
Issue 11505: DCPS/f and DCPS/m profiles issue
Issue 11506: Section: 7.1.8
Issue 11507: Section: 7.1.9.36
Issue 11508: Section: 7.1.3.2
Issue 11509: Section: 7.1.11.10
Issue 11516: Update reference
Issue 11517: PSM DCPS
Issue 11518: Add prefix to the topic names
Issue 11519: Vista is missing in the OS type enumeration
Issue 11613: Section: 7.1.5
Issue 11404: AMS_Property template (amsm-ftf)
Click here for this issue's archive.
Source: SELEX SI (Mr. Fabrizio Morciano, fmorciano@selex-si.com)
Nature: Revision
Severity: Significant
Summary:
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.
Resolution: Generalize the use of *_NONSTD
Revised Text: Search and replace HU_NOSTD with HU_NONSTD
Search and replace HU_NON_STD with HU_NONSTD
Search and replace ST_NOSTD with ST_NONSTD
Search and replace MS_NOSTD with MS_NONSTD
Replace Figure 7.7 on page 37 with the following figure:
Replace Figure 7.20 on page 97 with the following figure:
Disposition: Resolved
Actions taken:
September 14, 2007: received issue
Issue 11405: Typo error (AMS_Propoerty instead of AMS_Property). (amsm-ftf)
Click here for this issue's archive.
Source: SELEX SI (Mr. Fabrizio Morciano, fmorciano@selex-si.com)
Nature: Revision
Severity: Minor
Summary: Typo error (AMS_Propoerty instead of AMS_Property).
Resolution: Correct the typo error.
Revised Text: Find and replace AMS_Propoerty and AMS_Property.
Actions taken:
September 14, 2007: received issue
Issue 11406: The numbering of the table is in some cases incorrect (amsm-ftf)
Click here for this issue's archive.
Source: SELEX SI (Mr. Fabrizio Morciano, fmorciano@selex-si.com)
Nature: Revision
Severity: Minor
Summary: 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
Resolution: Modification in the numbering of the tables.
Revised Text: Re-number Table 7.4 (pages 115, 116 and 117) with 7.1, 7.5 (page 112) with 7.2, 8.6 (page 125) with 8.1, 8.7 (page 125) with 8.2, 8.8 (page 126) with 8.3, 8.9 (page 126) with 8.4.
Actions taken:
September 14, 2007: received issue
Issue 11505: DCPS/f and DCPS/m profiles issue (amsm-ftf)
Click here for this issue's archive.
Source: Naval Surface Warfare Center (Mr. Paul V. Werme, paul.werme@navy.mil)
Nature: Revision
Severity: Significant
Summary: 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.
Resolution: 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"
Revised Text: Replace first bullet of paragraph 11.1.1 with: "The DCPS/f ('/f' stands for full) PSM which relates to the full DCPS PSM as described in this section. This PSM along with the XML PSM is intended to be equivalent to the CORBA/IDL and CIM profile, and thus compliant implementations are not required to deploy any elements of the CORBA and/or CIM profiles. The DCPS/f PSM shall access the static configuration information through the mandatory XML PSM."
Replace the second bullet of paragraph 11.1.1 with: "The DCPS/m ('/m' stands for monitoring) PSM which is a subset of the DCPS/f PSM, and contains those elements which are required for asynchronous monitoring of states of the different (software and hardware) elements. The DCPS/m PSM is defined to allow other PSMs (CORBA and/or CIM) to import it and use it for asynchronous monitoring tasks. Note that the inclusion of DCPS/m profile in CORBA and/or CIM PSM is not a mandatory, but an optional (convenience) mechanism. Whenever the DCPS/m profile is implemented along with CORBA and/or CIM PSM, the CORBA and/or CIM profile work in their usual way, independently of the DCPS/m profile."
Actions taken:
September 21, 2007: received issue
Issue 11506: Section: 7.1.8 (amsm-ftf)
Click here for this issue's archive.
Click here for this issue's attachments.
Source: Naval Surface Warfare Center (Mr. Paul V. Werme, paul.werme@navy.mil)
Nature: Enhancement
Severity: Significant
Summary: Clarification of capabilities for control of J2EE and CCM applications is requested.
Resolution: 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).
Revised Text:
Actions taken:
September 21, 2007: received issue
Discussion: close, no change
Issue 11507: Section: 7.1.9.36 (amsm-ftf)
Click here for this issue's archive.
Source: Naval Surface Warfare Center (Mr. Paul V. Werme, paul.werme@navy.mil)
Nature: Clarification
Severity: Significant
Summary: 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.
Resolution: On POSIX systems, this attribute is the process ID (resp. thread)
On Win32 systems, this attribute is the process handle (resp. thread)
Revised Text: Section 7.1.9.36, replace the 1st bullet with:
· "Handle:" A string used to identify the Process. On POSIX systems, this attribute is the process ID. On Win32 systems, this attribute is the process handle.
Section 7.1.9.50, replace the 1st bullet with:
· "Handle:" A string used to identify the Thread. On POSIX systems, this attribute is the thread ID. On Win32 systems, this attribute is the thread handle.
Actions taken:
September 21, 2007: received issue
Issue 11508: Section: 7.1.3.2 (amsm-ftf)
Click here for this issue's archive.
Source: Naval Surface Warfare Center (Mr. Paul V. Werme, paul.werme@navy.mil)
Nature: Enhancement
Severity: Significant
Summary: 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.
Resolution: 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.
Revised Text: Replace the last bullet of the bullet list of paragraph 7.1.3.4 with the following:
· The element that caused the error referenced by a string that contains the full name of this element. When an action fails to be executed, this attributes gives a reference to the CIM_Action that actually fails.
Actions taken:
September 21, 2007: received issue
Issue 11509: Section: 7.1.11.10 (amsm-ftf)
Click here for this issue's archive.
Source: Naval Surface Warfare Center (Mr. Paul V. Werme, paul.werme@navy.mil)
Nature: Enhancement
Severity: Significant
Summary: 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...
Resolution: deferred
Revised Text:
Actions taken:
September 21, 2007: received issue
Discussion: Full study of these points need more time.
Issue 11516: Update reference (amsm-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary: Light weight logging specification (realtime/2002-06-14) referenced is not newest version. Possible solution: Use the formal/05-02-02.
Resolution: Use the formal/05-02-02
Revised Text: Page 5, 5th bullet: replace "realtime/2002-06-14" with "formal/05-02-02".
Actions taken:
September 26, 2007: received issue
Issue 11517: PSM DCPS (amsm-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary: 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.
Resolution: Remove all info related to the root topics.
Revised Text: Section 11.1.1.1, replace the 1st line with:
There are three 'types' of AMSM topics:
Section 11.1.1.1, delete the last bullet of the page (starting with "The root topics type …").
Section 11.1.1.2, delete the bullet starting with "The root topics have…" and the table below (table 11.1). Rename following tables (11.2 to 11.8) in consequence.
Remove all the section 11.1.1.5.4 "Root Topics Data Type".
Section 11.1.5, replace the last bullet with:
The DCPS/m ('/m' stands for monitoring) relates to the "element topics" and "indication topics" - i.e., all of them but "control topics." DCPS/m profile is therefore a subset of the DCPS/f profile.
Section 11.1.6, remove all lines between
// root topics
(included) and
// Indication topics
(excluded)
Actions taken:
September 26, 2007: received issue
Issue 11518: Add prefix to the topic names (amsm-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary: 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
Resolution: Add Prefix AMS to Topic names
Revised Text: In Section 11.1.1.2, replace the first bullet with:
The name of an "element topic" is the concatenation of "AMS_" and the name of the class of the corresponding AMSM object.
In Section 11.1.1.2, replace the names in the first column of the second table by (in the same order): AMS_CT_LoadConfiguration, AMS_CT_UnloadConfiguration, AMS_CT_ShutDownESE, AMS_CT_CreateHardwareGroup, AMS_CT_ShutDown, AMS_CT_StartUp, AMS_CT_StartUpOnHost, AMS_CT_StartUpOnSpec, AMS_CT_ActivateAsPrimary, AMS_CT_ForceShutDown, AMS_CT_Load, AMS_CT_Stop, AMS_CT_ClearLog, AMS_ControlResponse
In Section 11.1.1.5.5, replace the first line with: " "Control topics" have specific data types which names are the same as the topic names (cf. table in paragraph 11.1.1.2).", and remove the following table. In the reminder of the paragraph 11.1.1.5.5, replace "ControlResponse" with "AMS_ControlResponse").
In Section 11.1.1.5.5, replace the last code snippet with:
struct AMS_ErrorStruct {
// message
string Message;
// errno
long Number
// error code
AMS_ErrorCode Code;
// full path to the element
string Element
};
struct AMS_ControlResponse {
// identifier of the request
long request_id;
// the ErrorStruct
AMS_ErrorStruct Error;
}
#pragma keylist AMS_ControlResponse request_id
Actions taken:
September 26, 2007: received issue
Issue 11519: Vista is missing in the OS type enumeration (amsm-ftf)
Click here for this issue's archive.
Nature: Enhancement
Severity: Significant
Summary: 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.
Resolution: Add vista to the OS type enumeration
Revised Text: Add the item "Windows Vista" at the end of the enumerations:
· "TargetOperatingSystem" in paragraph 7.1.9.1
· "TargetOperatingSystem" in paragraph 7.1.9.32
· In paragraph 7.1.9.33
In paragraph 8.6.11, replace the first occurrence of "z_OS" with "z_OS, WindowsVista".
In paragraph 9.6.10, add after the first occurrence of "<xsd:enumeration value="z/OS" />" the following line: <xsd:enumeration value="Windows Vista" />
In paragraph 11.1.6, replace the first occurrence of "z_OS" with "z_OS, WindowsVista".
Actions taken:
September 26, 2007: received issue
Issue 11613: Section: 7.1.5 (amsm-ftf)
Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, Hugues.VINCENT@fr.thalesgroup.com hugues.vincent@fr.thalesgroup.com hug.vincent@laposte.net)
Nature: Revision
Severity: Minor
Summary: Paragraph 7.1.5 ("AMS_BAlancingStyle") should be numbered 7.1.4.2.
Resolution: Paragraph 7.1.5 is to be numbered 7.1.4.2
Revised Text: Renumber the section "AMS_BalancingStyle class" (page 42) with 7.1.4.2 and the following section accordingly.
Actions taken:
October 15, 2007: received issue
Discussion: