Issues for Mailing list of the Lightweight Log revision Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 7203: section 2.4.2
Issue 7204: line from item 1
Issue 7205: treatment of currentId should be consistent
Issue 7206: add ection to retrieveRecords description
Issue 7207: Log Consumer Interface functions
Issue 7208: HALT mode
Issue 7209: WRAP mode
Issue 7210: Suggest adding following to the description of clearLog in section 2.6.4
Issue 7211: Section 3.3.4.1
Issue 7212: Suggest breaking up the IDL across the interface boundaries
Issue 7214: lack of shalls in specification
Issue 7215: ISO format conformance
Issue 7216: Provide IDL files that allows for name space implementations
Issue 7776: Mismatch between the methods' notification
Issue 8691: Section: 2.2.2, 4.1.2
Issue 10349: Page: 4-1 to 4-4
Issue 12202: Sections 2, 3 and 4

Issue 7203: section 2.4.2 (lwlog-rtf)

The line “If there are no further records available, currentId will be set to zero.” in section 2.4.2 should be deleted. This would make the behavior consistent with the other record retrieval functions. For readability, consider explicitly stating that the line previous to this concerns the case where currentId exists. This last comment applies to the other record retrieval functions as well.

If the line from item 1 is not deleted, the retrieveRecords function should explicitly state when the log is considered exhausted, i.e. “no further records available”, for purposes of setting the howMany and currentId fields. This comment is made in order to prevent a possible interpretation that may lead to failures in third party test suites (the result of a retrieve contains the howMany requested records with the last record in the log as part of the sequence – possible that a test could expect currentId to be set to zero since there are no more records available).

As discussed in item #1, the treatment of currentId should be consistent across the retrieveRecords and retrieveRecordsBy* functions. Further, the wording used in the descriptions with regard to the currentId and howMany parameters should be the same

The section of the note at the end of the retrieveRecordsBy* descriptions that informs of the need to reestablish a recordId due to the potential modification of the currentId parameter should be added to the retrieveRecords description as well.

The Log Consumer Interface functions should identify when the InvalidParam exception is raised. (i.e., what constitutes an invalid supplied parameter to these functions?)

 

The desired behavior of the log service when the log full action type is set to WRAP needs to be explicitly defined. This comment is based upon experience with the SCA 2.2 JTeL JTAP tests. Open interpretation of this item led to failures characterized by the following questions:

 

a.       Is a log with a log full action type of WRAP ever considered full? The JTeL JTAP tests expect this, but there is a semantic issue here – writes to a “full log” will be successful. Further, if a log in WRAP mode can become full, then…

 

b.      When is it considered full? Since log records use variable amounts of storage, a log nearing capacity may have a handful of bytes available, yet not have enough space to store even the smallest of records.

 

c.       When should the log service detect that the log is full? JTAP expects a log to be set full as soon as storage is exhausted, i.e., at the completion of a write that exactly fills the log. While this does not seem to be what the specification suggests, it illustrates an example of an area left up to interpretation.

 

Declaring a log full only in HALT mode and only when a write is attempted would avoid these questions.

When in WRAP mode, should the writeRecord(s) function delete as many records as needed to make room for a new record, or only a single record? An explicit statement would mitigate a possible interpretation issue. Further, the functional descriptions should be updated to include the desired behavior in WRAP mode and the management of the log full status once it is resolved.

Suggest adding the following to the description of clearLog in section 2.6.4:

 

a.       A subsequent invocation of the getNumRecords operation will return 0 (zero).

b.      A subsequent invocation of the getAvailabilityStatus operation will return a log Full field of false.

In Section 3.3.4.1, the “Difference to the Telecom Log Service” indicates that a return result has been added. The set_max_size function return type is void

Suggest breaking up the IDL across the interface boundaries. This allows the users of the log the ability to only include the interface(s) they need to

Recommendation add shalls to specification to help with testability of
specification and conformance

Recommendation: When making changes to specification, conform the format to
OMG's new specification format

Provide IDL files that allows for name space implementations
Recommendation: Separate idl files for each interface as another Annex

Mismatch between the methods' notification in the first section of the document (diagrams and chapters names like in SCA document, v2.2) and the methods' references used in the idl section. Please confirm/clarify which method's reference name has to be used by external users. Example: method's name: getMaxSize method in idl: get_max_size 

In section 2.2.2 it says LogLevel values 10-26 are reserved for programmer debugging purposes. In section 4.1.2, in the IDL there is the following comment: // Values ranging from 10 to 26 are reserved for // 16 debugging levels. There are 17 values in the range 10-26, which contradicts the comment

The IDL in Section 4 does not match the descriptive text in Section 2. Some examples: struct AvailabilityState: offDuty (p 2-6) vs off_duty (p 4-2); logFull (p 2-6) vs log_full (p 4-2). interface LogStatus: getMaxSize (p 2-8) vs get_max_size (p 4-3); getCurrentSize ((p 2-9) vs get_current_size (p 4-3); getNumRecords (p 2-10) vs get_n_records (p 4-3); etc. etc. (many other mistakes!!). What takes precedence, the IDL in section 4, or the text in section 2? I can provide a detailed list of all the mistakes that need to be corrected. Please contact me for the details. /mike.gudaitis@L-3com.com, 315-339-6184

I have a question about the OMG Lightweight Log version 1.1. (Note: I am aware that the Lightweight Log is not required by SCA 2.2.2. My questions assume that I am testing a radio that has a Lightweight Log.) Section 2 states "...the class Log does not communicate directly with the rest of the environment. Communication with the surrounding environment is handled through three distinct interfaces." It lists these as the LogProducer, LogConsumer, and LogAdmin interfaces. Section 3 defines the CORBA mapping for the LogProducer, LogConsumer, and LogAdministrator interfaces. Section 4 defines a new Log interface: module CosLwLog { interface Log : LogAdministrator, LogConsumer, LogProducer {}; }; The Log interface combines the functionality of the LogProducer, LogConsumer, and LogAdministrator interfaces. This appears to contradict Section 2, which says Log communication is through three distinct interfaces. Should the radio provide the Log interface defined in Section 4? Or should the radio only provide the LogProducer, LogConsumer, and LogAdministrator interfaces to comply with Section 2?