${taskforce.name} Avatar
  1. OMG Task Force

Telecom Log Service FTF — All Issues

  • Key: TLOG
  • Issues Count: 60
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
TLOG-60 bug in the Telecom Log Service IDL TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-59 Section: 1.2.5.1 TLOG 1.1.2 open
TLOG-58 Section: 1.2.5.1 TLOG 1.1.2 open
TLOG-55 Section: 1.2.4.11 TLOG 1.1.2 open
TLOG-54 Section: 1.2.5.1 TLOG 1.1.2 open
TLOG-52 AttributeValueChange event section 1.4.4 TLOG 1.1.2 open
TLOG-51 Chapter 2.5, page 2-33 TLOG 1.0 open
TLOG-57 Section: 1.4.3 TLOG 1.1.2 open
TLOG-53 support QoS properties TLOG 1.1.2 open
TLOG-48 Chapter 2.3.1, page 2-26 TLOG 1.0 open
TLOG-47 Chapter 2.2.7.2, page 2-25. destroy operation TLOG 1.0 open
TLOG-50 Chapter 2.4.1, page 2-29 TLOG 1.0 open
TLOG-56 Section: 1.4.3 TLOG 1.1.2 open
TLOG-49 Chapter 2.4 TLOG 1.0 open
TLOG-41 Chapter 2.2.4.4, page 2-11 TLOG 1.0 open
TLOG-40 3. Appendix 1, page A-5 has missing definition of write_recordlist method TLOG 1.0 open
TLOG-46 Chapter 2.2.7.1, page 2-24 copy and copy_with_id operations TLOG 1.0 open
TLOG-45 Definition of DAG topology TLOG 1.0 open
TLOG-44 Chapter 2.2.5.5, page 2-22. set_record_attribute operation TLOG 1.0 open
TLOG-39 Page 2-19. Description of write_recordlist TLOG 1.0 open
TLOG-38 missing LogOffDuty exceptions TLOG 1.0 open
TLOG-43 Chapter 2.2.5.4, page 2-21 TLOG 1.0 open
TLOG-42 Chapter 2.2.5.1, page 2-19 TLOG 1.0 open
TLOG-1 The text for the copy() and copy_with_id() operations TLOG 1.0b1 open
TLOG-13 $issue.summary TLOG 1.0b1 open
TLOG-12 $issue.summary TLOG 1.0b1 open
TLOG-4 $issue.summary TLOG 1.0b1 open
TLOG-3 $issue.summary TLOG 1.0b1 open
TLOG-9 $issue.summary TLOG 1.0b1 open
TLOG-8 $issue.summary TLOG 1.0b1 open
TLOG-6 $issue.summary TLOG 1.0b1 open
TLOG-5 $issue.summary TLOG 1.0b1 open
TLOG-11 $issue.summary TLOG 1.0b1 open
TLOG-10 $issue.summary TLOG 1.0b1 open
TLOG-7 $issue.summary TLOG 1.0b1 open
TLOG-2 $issue.summary TLOG 1.0b1 open
TLOG-25 Clarify specification text in section 3.4 Log Generated Events TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-24 Argument in CapacityAlarmTresholdList tresholds doesn"t appear in IDL TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-23 Change references to "LogFactory" to "BasicLogFactory" TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-22 Adopt current OMG style of using CONST TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-28 Typos in Log Service TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-27 Text unclear to a log"s behavior when off_duty TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-26 Clarify text TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-34 StateChange or a ProcessingErrorAlarm event not defined TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-33 Specification inconsistent in generating AttributeValueChange events TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-21 DsLogNotification::ObjectDeletion in Telecom Log Service TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-20 OMG Document formal/01-04-08 --IDL issue TLOG 1.0 open
TLOG-19 TelecomLogService/2000-01-04 -- typo TLOG 1.0 open
TLOG-30 slight conflict on pg 3-16 TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-29 get_capacity_thresholdlist() and set_capacity_thresholdlist() TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-32 Clarification for untyped events TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-31 "in Anys records" description on page 3-18 is unclear TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-15 Telecom logging -- illegal IDL TLOG 1.0 open
TLOG-14 $issue.summary TLOG 1.0b1 open
TLOG-18 Viewing old logs TLOG 1.0 open
TLOG-17 Initial references? TLOG 1.0 open
TLOG-16 Telecom Log Service issue TLOG 1.0 open
TLOG-36 Availability status under wrap condition TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-35 Clarification for proper value of AvailablityStatus TLOG 1.0b1 TLOG 1.0 Resolved closed
TLOG-37 Reset of Capacity Alarm Threshold under wrap condition TLOG 1.0b1 TLOG 1.0 Resolved closed

Issues Descriptions

bug in the Telecom Log Service IDL

  • Key: TLOG-60
  • Legacy Issue Number: 3752
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I have just noticed a bug in the Telecom Log Service IDL. The
    "Log" interface defined in the "DsLogAdmin" module defines "set_qos"
    and "get_qos" operations. And, the DsNotifyLogAdmin::NotifyLog
    interface inherits both the DsLogAdmin::Log interface (indirectly,
    through inheritence of DsEventLogAdmin::EventLog) and the
    CosNotifyChannelAdmin::EventChannel interface. Note that the
    CosNotifyChannelAdmin::EventChannel interface inherits from
    CosNotification::QoSAdmin, which also defines "set_qos" and "get_qos"
    operations! This is invalid IDL inheritence as of CORBA 2.3!

    The same problem exists for the DsTypedNotifyLogAdmin::TypedNotifyLog
    interface. It indirectly inherits both DsLogAdmin::Log and
    CosNotification::QoSAdmin, and thus two versions of "set_qos" and
    "get_qos".

    There are a couple of possible solutions to this problem, but perhaps
    the easiest would be to simply rename the "set_qos" and "get_qos" operations
    defined in the Log interface as "set_log_qos" and "get_log_qos",
    respectively. If only there were an RTF that could do this...

  • Reported: TLOG 1.0b1 — Wed, 19 Jul 2000 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Section: 1.2.5.1

  • Key: TLOG-59
  • Legacy Issue Number: 9262
  • Status: open  
  • Source: Identity Engines, Inc. ( J.T. Conklin)
  • Summary:

    The specification says that "The write_recordlist() operation is provided ass a convienience operation to allow the output of a query of one log to be written to another log. In this case, only the "info" field (event content) of the RecordData struct is written to the log, the LogRecord id and logging time will be assigned by the log.". This is the only place in the spec that RecordData is used, I believe that LogRecord was intended. Also, it is unclear whether the attr_list field should be copied. While it says "only the info field" is written, attr_list is among the fields listed that will be "assigned by the log". For what it's worth, the Orbix Log Service implementation appears to copy the attr_list. Their Enterprise Messaging Guide for ORBIX 6.2 says "write_recordlist() is functionally identical to write_records(). It writes data directly to the log and raises the same exceptions. The major difference is that the record's data is stored in a LogRecord. This allows you to add a series of name/value pair attributes to assist in querying the log". The TAO log service implementation, which I currently maintain, also copies the value of attr_list.

  • Reported: TLOG 1.1.2 — Tue, 24 Jan 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 1.2.5.1

  • Key: TLOG-58
  • Legacy Issue Number: 9311
  • Status: open  
  • Source: Identity Engines, Inc. ( J.T. Conklin)
  • Summary:

    The specification says that "The write_recordlist() operation is provided ass a convienience operation to allow the output of a query of one log to be written to another log. In this case, only the "info" field (event content) of the RecordData struct is written to the log, the LogRecord id and logging time will be assigned by the log.". This is the only place in the spec that RecordData is used, I believe that LogRecord was intended. Also, it is unclear whether the attr_list field should be copied. While it says "only the info field" is written, attr_list is among the fields listed that will be "assigned by the log". For what it's worth, the Orbix Log Service implementation appears to copy the attr_list. Their Enterprise Messaging Guide for ORBIX 6.2 says "write_recordlist() is functionally identical to write_records(). It writes data directly to the log and raises the same exceptions. The major difference is that the record's data is stored in a LogRecord. This allows you to add a series of name/value pair attributes to assist in querying the log". The TAO log service implementation, which I currently maintain, also copies the value of attr_list.

  • Reported: TLOG 1.1.2 — Wed, 25 Jan 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 1.2.4.11

  • Key: TLOG-55
  • Legacy Issue Number: 9259
  • Status: open  
  • Source: Identity Engines, Inc. ( J.T. Conklin)
  • Summary:

    The specification states "If the capacity of a log exeeds that of one of its log capacity alarm thresholds, ..." This wording is confusing: The log capacity (as set by set_max_size()) is not compared with the capacity alarm thresholds; it does not state that the ThresholdAlarm is sent once when the threshold has been met, which may lead some to believe the alarm events will be sent continuously; and the word "Exceed" means that a alarm would never be sent for a threshold of 100%. I think that something like "If after a log record has been written, the current size of a log, as expressed as a percentage of max log size, is greater or equal to the next log capacity threshold, then a ThresholdAlarm event is generated ..." might be clearer.

  • Reported: TLOG 1.1.2 — Tue, 24 Jan 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 1.2.5.1

  • Key: TLOG-54
  • Legacy Issue Number: 8829
  • Status: open  
  • Source: Identity Engines ( J.T. Conklin)
  • Summary:

    I am in the process of updating TAO's Logging Service implementation. Section 1.2.5.1 stats "The Telecom Log Service proposes to define the following OMG Standard exception codes for use with the CosEvent and CosNotification push operations..." and goes on to mention a LOGFULL and LOGOFFDUTY minor code for the NO_RESOURCE [sic] SystemException, a LOGLOCKED minor code for the NO_PERMISSIONS SystemException, and a LOGDISABLED minor code for the TRANSIENT SystemException. TAO does not define these minor codes, so I checked the latest CORBA spec (3.0.3 / formal/04-03-12) and they are not in Appendix A either. What exactly does the spec mean "proposes to define" and what should an implementer do to handle these errors in the here and now.

  • Reported: TLOG 1.1.2 — Tue, 31 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

AttributeValueChange event section 1.4.4

  • Key: TLOG-52
  • Legacy Issue Number: 8827
  • Status: open  
  • Source: Identity Engines ( J.T. Conklin)
  • Summary:

    Section 1.4.4 states that the "AttributeValueChange event is generated by a log factor when one of its log changes one of changes one of the following attributes..." The description of the set_* methods state "An AttributeValueChange is generated whenever the * is set". The former implies that the event will be sent if the value is changed, the latter imples the event will be sent even if the value is the same.

  • Reported: TLOG 1.1.2 — Fri, 27 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 2.5, page 2-33

  • Key: TLOG-51
  • Legacy Issue Number: 5637
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    · Chapter 2.5, page 2-33. The paragraph of the second bullet point can also contain the TypedRecordIterator.

  • Reported: TLOG 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 1.4.3

  • Key: TLOG-57
  • Legacy Issue Number: 9261
  • Status: open  
  • Source: Identity Engines, Inc. ( J.T. Conklin)
  • Summary:

    I am the current maintainer of the TAO logging service implementation. The specification is unclear what the interactions between set_max_size(), set_log_full_action(), and set_capacity_alarm_thresholds() have on the current processing of capacity alarms. For example, consider a log with DsLogAdmin::halt log full action and 0 (ie. infinate) max size, and a capacity alarm threshold list of [50, 75, 90, 100]. If the log has 80KB of records, and the max size is set to 100KB, are ThresholdAlarms supposed to be sent for crossing 50 and 75%, or should a threshold alarm only be sent once the log grows to 90%? Similar questions arise when the log full action is changed to/from DsLogAdmin::halt from/to DsLogAdmin::wrap, as the capacity alarm threshold processing changes from a percentage to a "gauge". Or when the capacity alarm threshold list is changed from one set of values to another.

  • Reported: TLOG 1.1.2 — Tue, 24 Jan 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

support QoS properties

  • Key: TLOG-53
  • Legacy Issue Number: 8828
  • Status: open  
  • Source: Identity Engines ( J.T. Conklin)
  • Summary:

    I'm working on TAO's Log Service implementation, and I'm not sure how I'm supposed to support QoS properties. The spec for get_log_qos() method states it "returns a list of the quality of service properties supported by the log." This is different from the other get_* methods, which return the current value of the settings. If this is the intent, it should be emphasized, and perhaps a new method introduced to fetch the current QoS settings. The three defined QoS settings QoSNone, QoSFlush, and QoSReliability are mutually exclusive. But unlike the Notification Service Spec's section on QoS settings, there is no guideance wrt. semantics of a property list with multiple properties or what should be returned in the denied list in the UnsupportedQoS exception.

  • Reported: TLOG 1.1.2 — Fri, 27 May 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 2.3.1, page 2-26

  • Key: TLOG-48
  • Legacy Issue Number: 5634
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    · Chapter 2.3.1, page 2-26. It is more correct if it is said that BasicLogFactory creates BasicLog but not Log (similar to that EventLogFactory creates EventLog).

  • Reported: TLOG 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 2.2.7.2, page 2-25. destroy operation

  • Key: TLOG-47
  • Legacy Issue Number: 5633
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    · Chapter 2.2.7.2, page 2-25. destroy operation is not only inherited from CosEventChannelAdmin::EventChannel but also defined in BasicLog interface. It is worth to mention it, since destroy operation can also be invoked on BasicLog objects.

  • Reported: TLOG 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 2.4.1, page 2-29

  • Key: TLOG-50
  • Legacy Issue Number: 5636
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    · Chapter 2.4.1, page 2-29. Definition of the ObjectCreation struct contains logref field. This is different from the same definition in appendix 1 on page A-7. I think the correct version is on page 2-29. Then ObjectDeletion struct (page 2-30) does not have logref field. Is it OK? If yes, then "NOTE" in appendix 1 on page A-7 is wrong and not needed at all. If not, then the definition of that struct both on page 2-30 and in the appendix 1 should be modified.

  • Reported: TLOG 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 1.4.3

  • Key: TLOG-56
  • Legacy Issue Number: 9260
  • Status: open  
  • Source: Identity Engines, Inc. ( J.T. Conklin)
  • Summary:

    The IDL for the ThresholdAlarm event defines three constants for the percieved_severity field: critical, minor, and cleared. The text says the "percieved_severity is minor if log is not full, and critical otherwise". If these are the only valid values, why is there a definition for cleared?

  • Reported: TLOG 1.1.2 — Tue, 24 Jan 2006 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 2.4

  • Key: TLOG-49
  • Legacy Issue Number: 5635
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    · Chapter 2.4. Within the whole chapter in the description of every generated event "the log field" is used instead of "the logref field". Should be changed in every occurrence.

  • Reported: TLOG 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 2.2.4.4, page 2-11

  • Key: TLOG-41
  • Legacy Issue Number: 5627
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    · Chapter 2.2.4.4, page 2-11. To have one style in the document and make it more readable I propose to change ulong to unsigned long.

  • Reported: TLOG 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

3. Appendix 1, page A-5 has missing definition of write_recordlist method

  • Key: TLOG-40
  • Legacy Issue Number: 5618
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    3. Appendix 1, page A-5 has missing definition of write_recordlist method in the Log interface and has doubled definition of write_records method.

    All these issues are applied to version 1.0 as well (formal/2000-01-04).

  • Reported: TLOG 1.0 — Fri, 30 Aug 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 2.2.7.1, page 2-24 copy and copy_with_id operations

  • Key: TLOG-46
  • Legacy Issue Number: 5632
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    · Chapter 2.2.7.1, page 2-24. What is so resource consuming in the copy and copy_with_id operations? Why it can raise NoResources exception and any factory cannot? Factories also create logs and the log server also can have not enough resources to do it, but according to the specification factories do not raise NoResources exception. If NoResources should leave there then appendix 1 should be corrected since definitions of these copy operations do not contain NoResources exception in the list of raised exceptions and appendix 1 does not have definition of NoResources exception at all (should be put in DsLogAdmin module). Or if NoResources can be omitted then description of those copy operations should be modified

  • Reported: TLOG 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of DAG topology

  • Key: TLOG-45
  • Legacy Issue Number: 5631
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    · Chapter 2.2.6, page 2-24. It is not clear for reader what is DAG topology. I propose to explain this. At least write what it stands for, like "DAG (directed acyclic graph)".

  • Reported: TLOG 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 2.2.5.5, page 2-22. set_record_attribute operation

  • Key: TLOG-44
  • Legacy Issue Number: 5630
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    · Chapter 2.2.5.5, page 2-22. set_record_attribute operation does not raise InvalidGrammar and InvalidConstraint exceptions. These exceptions should be deleted from the description of the operation

  • Reported: TLOG 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Page 2-19. Description of write_recordlist

  • Key: TLOG-39
  • Legacy Issue Number: 5617
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    2. Page 2-19. Description of write_recordlist says "In this case, only the "info" field (event content) of the RecordData struct is written to the log, the LogRecord id and logging time will be assigned by the log." Why doesn't it say anything about attr_list field of RecordData struct? Seems to me that this field (list of name/value pairs) can also be modified and written to the log.

  • Reported: TLOG 1.0 — Fri, 30 Aug 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

missing LogOffDuty exceptions

  • Key: TLOG-38
  • Legacy Issue Number: 5616
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    1. Page 2-19 has missing LogOffDuty exception in the signatures of write_records and write_recordlist methods.

    Currently there is:
    void write_records(in Anys records)
    raises(LogFull, LogLocked, LogDisabled);
    void write_recordlist(in RecordList list)
    raises(LogFull, LogLocked, LogDisabled);

    Should be:
    void write_records(in Anys records)
    raises(LogFull, LogOffDuty, LogLocked, LogDisabled);
    void write_recordlist(in RecordList list)
    raises(LogFull, LogOffDuty, LogLocked, LogDisabled);

  • Reported: TLOG 1.0 — Fri, 30 Aug 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 2.2.5.4, page 2-21

  • Key: TLOG-43
  • Legacy Issue Number: 5629
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    · Chapter 2.2.5.4, page 2-21. delete_records operation does not raise InvalidAttribute exception. This exception should be deleted from the description of the operation.

  • Reported: TLOG 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Chapter 2.2.5.1, page 2-19

  • Key: TLOG-42
  • Legacy Issue Number: 5628
  • Status: open  
  • Source: nokia.com ( Ivan Bodunov)
  • Summary:

    · Chapter 2.2.5.1, page 2-19. What are the values for minor codes: LOGFULL, LOGOFFDUTY, LOGLOCKED, and LOGDISABLED? Should those be defined in IDL?

  • Reported: TLOG 1.0 — Tue, 3 Sep 2002 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The text for the copy() and copy_with_id() operations

  • Key: TLOG-1
  • Legacy Issue Number: 2726
  • Status: open  
  • Source: Anonymous
  • Summary:

    The text for the copy() and copy_with_id() operations defined on the DsLogAdmin::Log
    interface should specify that a DsLogNotification::ObjectCreation notification will
    be generated as a result of the copy operation.

  • Reported: TLOG 1.0b1 — Sun, 13 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-13
  • Legacy Issue Number: 2774
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Tue, 29 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-12
  • Legacy Issue Number: 2773
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Mon, 28 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-4
  • Legacy Issue Number: 2757
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Fri, 18 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-3
  • Legacy Issue Number: 2756
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Thu, 17 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-9
  • Legacy Issue Number: 2764
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Tue, 22 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-8
  • Legacy Issue Number: 2763
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Tue, 22 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-6
  • Legacy Issue Number: 2759
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Fri, 18 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-5
  • Legacy Issue Number: 2758
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Fri, 18 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-11
  • Legacy Issue Number: 2771
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Mon, 28 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-10
  • Legacy Issue Number: 2768
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Fri, 25 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-7
  • Legacy Issue Number: 2762
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Tue, 22 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-2
  • Legacy Issue Number: 2755
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Thu, 17 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify specification text in section 3.4 Log Generated Events

  • Key: TLOG-25
  • Legacy Issue Number: 2666
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The specification text is unclear and should make a note in
    section "3.4 Log Generated Events" to explain that the manner
    in which logs send log generated events to their corresponding
    log factories is an implementation detail.

    The idea is that applications (log/LogFactory clients) are only consumers
    of log emitted events, they do not send events to the factory. Therefore, the
    LogFactory does not need to expose the SupplierAdmin interface. How the log
    actually forwards events to the factory is left up to the implementation -
    use a SupplierAdmin object, or other means.

  • Reported: TLOG 1.0b1 — Thu, 27 May 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    resolved, see revised text below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Argument in CapacityAlarmTresholdList tresholds doesn"t appear in IDL

  • Key: TLOG-24
  • Legacy Issue Number: 2665
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the specification text, the BasicLogFactory::create() and
    BasicLogFactory::create_with_id() operations have an extra
    argument, in CapacityAlarmThresholdList thresholds, which does
    not appear in the specification IDL. The reference to thresholds
    in the specification text should be removed from the definitions
    of BasicLogFactory::create() and BasicLogFactory::create_with_id().

    The paragraphs in the specification text that describe the create()
    and create_with_id() operations for the other log factories
    (ie. EventLogFactory) should explain that they have an additional
    argument, thresholds, besides the ones defined in the BasicLogFactory.

  • Reported: TLOG 1.0b1 — Thu, 27 May 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    resolved, see revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Change references to "LogFactory" to "BasicLogFactory"

  • Key: TLOG-23
  • Legacy Issue Number: 2664
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the specification text, all references to "LogFactory" should be
    changed to "BasicLogFactory" to match what is defined in
    the specification IDL.

  • Reported: TLOG 1.0b1 — Thu, 27 May 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    completed, see revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Adopt current OMG style of using CONST

  • Key: TLOG-22
  • Legacy Issue Number: 2663
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: there are a few enums defined in the
    IDL. Perhaps it would be a good idea to adopt the
    current OMG style of using CONST declarations for
    these values as this allows easy extension of the values (which
    enums do not). It is also nice to define the const types
    as signed and to reserve all positive values for OMG
    use and leave the negative values for vendors.

  • Reported: TLOG 1.0b1 — Thu, 27 May 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    The following are the enums defined in the Specification IDL and proposed changes:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Typos in Log Service

  • Key: TLOG-28
  • Legacy Issue Number: 2673
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There are various Typo's that need to be corrected:
    Page 1-5 "Allows a log factory emits"
    Page 1-5 "Allows multiple push or pull consumers can register"
    Page 2-20 "An InvalidAttribute exception..." (delete_records does not raise Invalid exception)
    Page 2-21 "interface Iterater"
    Page 2-21 "When an invoking the get() operation..."
    Page 2-22 "...initialized to the save values as the log..."
    Page 2-26 "...TypedNotifyLogFactory interfaces create() new EventLog..." (no parens)

  • Reported: TLOG 1.0b1 — Fri, 28 May 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    Correct typos.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Text unclear to a log"s behavior when off_duty

  • Key: TLOG-27
  • Legacy Issue Number: 2668
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The specification text is unclear to a log"s behavior when off_duty.
    What should the log do when it"s not functioning due to being
    outside the interval or shut down according to the weekmask? I assume it"s
    still available for adjusting weekmask parameters, but does it just drop
    log requests on the floor?

  • Reported: TLOG 1.0b1 — Thu, 27 May 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    rersolved, see revised text below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarify text

  • Key: TLOG-26
  • Legacy Issue Number: 2667
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The specification text is unclear to a log"s behavior when disabled.
    If the log is disabled ("due to some run time catastrophy"), how should
    the log respond to requests? Since it is active enough to respond to
    "get_operational_state ()" requests, shouldn"t it throw exceptions? Is it
    allowed to drop log requests on the floor in that case? It could throw a
    LogLocked exception, but in that case, should the log lock when it enters
    the disabled state?

  • Reported: TLOG 1.0b1 — Thu, 27 May 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    resolved, see revised text

  • Updated: Fri, 6 Mar 2015 20:58 GMT

StateChange or a ProcessingErrorAlarm event not defined

  • Key: TLOG-34
  • Legacy Issue Number: 2730
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The specification does not define a StateChange or a ProcessingErrorAlarm event
    which are referenced in X.735 section 11.2.3, "Notifications".

  • Reported: TLOG 1.0b1 — Sun, 13 Jun 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    resolved, se revised text below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Specification inconsistent in generating AttributeValueChange events

  • Key: TLOG-33
  • Legacy Issue Number: 2728
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The specification is inconsisent in specifying which attributes generate
    AttributeValueChange events. Currently AttributeValueChange events are
    generated for:
    capacityAlarmThreshold
    logFullAction
    maxLogSize
    startTime
    stopTime
    weekMask
    filter

    An AttributeValueChange event should also be generated when the other
    attributes of a log are changed:
    administrativeState
    maxRecordLife
    qualityOfService
    forwardingState

  • Reported: TLOG 1.0b1 — Sun, 13 Jun 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    resolved, see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

DsLogNotification::ObjectDeletion in Telecom Log Service

  • Key: TLOG-21
  • Legacy Issue Number: 2348
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Documents: telecom/98-12-04 (text)
    telecom/99-01-05 (IDL)

    In module DsLogNotification, the event to be sent on log deletion is
    defined as

    struct ObjectDeletion

    { Log logref; LogId id; TimeT time; }

    ;

    Here, "logref" is a reference to the Log object that has just been deleted,
    and hence cannot be used for anything – would it be better to abolish this
    field? (Even though doing so would reduce the symmetry with ObjectCreation).

  • Reported: TLOG 1.0b1 — Wed, 27 Jan 1999 05:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    Remove logref from the ObjectDeletion struct.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OMG Document formal/01-04-08 --IDL issue

  • Key: TLOG-20
  • Legacy Issue Number: 4799
  • Status: open  
  • Source: Anonymous
  • Summary:

    I think the OMG Telecom Log Service IDL (DsLogAdmin and DsNotifyLogAdmin
    modules) isn't in accordance with the CORBA 2.6 "OMG IDL Syntax and
    Semantics" specification.

    Indeed the DsNotifyLogAdmin::NotifyLog interface inherits from both
    DsLogAdmin::Log.get_qos and CosNotification::QoSAdmin.get_qos
    operations, this is illegal according to section 3.7.5 (page 3-20) of
    the CORBA 2.6 specification.

    I've tried to compile the OMG Telecom Log Service with 2 differents ORBs
    (ORBacus 4.0.5 and JacORB 1.4beta2) without success.

  • Reported: TLOG 1.0 — Wed, 2 Jan 2002 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

TelecomLogService/2000-01-04 -- typo

  • Key: TLOG-19
  • Legacy Issue Number: 4279
  • Status: open  
  • Source: Anonymous
  • Summary:

    There is a typo on the first sentence on page 2-13. The words "enabled lock" should be "enabled log" in the following sentence : The stop field indicates the date and time at which an unlocked and enabled lock stops functioning.

  • Reported: TLOG 1.0 — Fri, 20 Apr 2001 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

slight conflict on pg 3-16

  • Key: TLOG-30
  • Legacy Issue Number: 2678
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There seems to be a slight conflict on pg 3-16: "New events delivered to a
    halt log will simply be discarded, these events may still be forwarded if
    the log forwarding state (described below) is on". How can events be
    discarded and forwarded?

  • Reported: TLOG 1.0b1 — Tue, 1 Jun 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    A log in the halt state only effect the logs ability to log new records.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

get_capacity_thresholdlist() and set_capacity_thresholdlist()

  • Key: TLOG-29
  • Legacy Issue Number: 2677
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Should the Log interface define the get_capacity_thresholdlist()
    and set_capacity_thresholdlist() operations? The BasicLog interface
    inherits from Log and yet thresholds are meaningless in the context
    of the BasicLog Why are they defined in Log and not in event and
    notify log? And should BasicLog even bother checking the parameters or
    doing anything?

  • Reported: TLOG 1.0b1 — Tue, 1 Jun 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    resolved , see text below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification for untyped events

  • Key: TLOG-32
  • Legacy Issue Number: 2725
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A clarification needs to be made when untyped events are inserted and retrieved
    from a typed log.

    A client can use the standard "push" operation with a TypedProxyPushConsumer as
    well as the type event operations defined on the interface generating the event.
    What happens if a client invokes the typed_query() operation where some of the events
    that pass the constraint were "push"ed as untyped events? Are those records ignored?
    Are the type related fields of the TypedEventRecord left empty? Should we raise an exception?

  • Reported: TLOG 1.0b1 — Sun, 13 Jun 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    No action to be taken.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

"in Anys records" description on page 3-18 is unclear

  • Key: TLOG-31
  • Legacy Issue Number: 2679
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The description of the "in Anys records" parameter of the write_records()
    operation on page 3-18 is unclear as to what the records should contain.

  • Reported: TLOG 1.0b1 — Tue, 1 Jun 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    The specification text should state that each Any contains the event to be logged.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Telecom logging -- illegal IDL

  • Key: TLOG-15
  • Legacy Issue Number: 2920
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The Notification Service defines:

    module CosNotification {
    // ...
    interface QoSAdmin

    { QoSProperties get_qos(); void set_qos(in QoSProperties qos) raises(UnsupportedQoS); // ... }

    ;
    // ...
    };

    module CosNotifyChannelAdmin {
    // ...
    interface EventChannel :
    CosNotification::QoSAdmin,
    CosNotification::AdminPropertiesAdmin,
    CosEventChannelAdmin::EventChannel

    { // ... };
    // ...
    };

    The Logging Service defines:

    module DSLogAdmin {
    // ...
    interface Log { // ... QoSList get_qos(); void set_qos(in QoSList qos) raises(UnsupportedQoS); // ... };
    };

    module DsEventLogAdmin {
    interface EventLog :
    DsLogAdmin::Log,
    CosEventChannelAdmin::EventChannel {};
    // ...
    };

    module DsNotifyLogAdmin {
    interface NotifyLog :
    DsEventLogAdmin::EventLog,
    CosNotifyChannelAdmin::EventChannel { // ... }

    ;
    };

    The net result is that DsNotifyLogAdmin::NotifyLog inherits get_qos()
    and set_qos() twice, once from QoSNotification::QoSAdmin, and once from
    DSLogAdmin::Log, which is illegal. This makes the Logging Service
    unimplementable right now.

    Looks like the operations in DSLogAdmin::Log will have to be renamed or
    the inheritance structure will have to change.

  • Reported: TLOG 1.0 — Fri, 1 Oct 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

${issue.summary}

  • Key: TLOG-14
  • Legacy Issue Number: 2777
  • Status: open  
  • Source: Anonymous
  • Summary:
  • Reported: TLOG 1.0b1 — Wed, 30 Jun 1999 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Viewing old logs

  • Key: TLOG-18
  • Legacy Issue Number: 3695
  • Status: open  
  • Source: Scientific Research Corporation ( Rob Ruff)
  • Summary:

    Assuming a log is persistent, how does one access the logged data after the system has been shut down? It seems important to be able to view this data after the system shuts down to determine if there were any glitches while the system ran or to troubleshoot any problems that occured.

  • Reported: TLOG 1.0 — Mon, 12 Jun 2000 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Initial references?

  • Key: TLOG-17
  • Legacy Issue Number: 3458
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    The Log Service spec doesn't state how a client gets access to the
    intial references for the service (namely, the various factories).

  • Reported: TLOG 1.0 — Fri, 24 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Telecom Log Service issue

  • Key: TLOG-16
  • Legacy Issue Number: 3120
  • Status: open  
  • Source: Anonymous
  • Summary:

    This issue concerns the Telecom Log Service as described in
    the dtc/99-07-02 document.

    I think the following statements in the spec are not compatible
    together:

    "Log forwarding is determined solely by forwarding state, it is not
    affected by the log's administrative state, availability state, log
    duration, scheduling, or log full action."

    "A log may be not be able to create any new log records because it is
    full, locked, or disabled. If a log cannot create new log records when
    a push operation is invoked, then the push operation should fail and a
    SystemException should be raised."

    If the log records are forwarded, then throwing system exceptions to
    the supplier doesn't make sense.

  • Reported: TLOG 1.0 — Wed, 15 Dec 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Availability status under wrap condition

  • Key: TLOG-36
  • Legacy Issue Number: 2753
  • Status: closed  
  • Source: Fujitsu ( Tom Rutt)
  • Summary:

    The AB raised an issue regarding an ambiguity on the proper value
    for the availability status, when the log is in the wrap condition.
    The FTF editor added the following sentence at the top of page 2-12
    of to telecom/99-05-01, in an effort to clarify the AB issue:

    "When a log is full its availability status will change to
    indicate the log full condition. If a log's full action is set to
    'wrap', it will never be in 'full' condition."

    This same ambiguity was discussed the ITU-T group which
    originally wrote the X.735 spec, and their proposed resolution
    has the opposite affect:

    Add the following explanation to the availability status value as a
    separate para after the text discussing wrap event behaviour :

    "The availability status indicates "logfull" when the capacity of
    the log is exceeded. In the case where halt behaviour is
    specified for the log the value implies no more records can be
    added. If wrap behaviour is specified, the value continues to
    remain as log full even though forthcoming records will be added
    by overwriting existing records. The wrap mode combined with
    logfull condition indicates that old records are lost as
    overwriting takes place. If records are deleted from the log, the
    logfull status value is removed from the availability status in
    either halt or wrap mode."

    The reason the ITU group has recommended "full" status is that it
    gives the information that records are being overwritten. When
    the log is full, records will be lost in response to forthcoming
    events. In Halt mode new records are not logged (i.e., lost),
    while in the wrap mode the oldest records are overwritten (i.e.,
    lost). If a client comes and deletes records, then
    availabilitystatus can be reset. Otherwise one needs to have a
    different behaviour for halt and wrap in terms of the value for
    availability status.

  • Reported: TLOG 1.0b1 — Thu, 17 Jun 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    Accept the ITU-T proposal, when in wrap mode, the log is considered to be full.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clarification for proper value of AvailablityStatus

  • Key: TLOG-35
  • Legacy Issue Number: 2731
  • Status: closed  
  • Source: Anonymous
  • Summary:

    would like to formally raise the following Issue for resolution
    by the FTF (jointly with the ITU-T group responsible for X.735)

    Location: section 2 : Log full action, page 2-12

    The AB raised an issue regarding an ambiguity on the proper value for the
    availability status. When the log is in the wrap condition. The FTF input text
    added the following sentence:

  • Reported: TLOG 1.0b1 — Sun, 13 Jun 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    This is a duplicate of Issue 2753 – closed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reset of Capacity Alarm Threshold under wrap condition

  • Key: TLOG-37
  • Legacy Issue Number: 2754
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This behaviour does not seem correct. Under a wrap condition, a
    capacity alarm gauge threshold should retrigger once in each
    period between wraps, but if the counter resets every time it
    crosses the thresold it will trigger more often. Thus the reset
    of the gauge , under wrap conditions, needs to be reworded as
    follows:

    "
    When a log object is created with the wrap option the capacity
    threshold alarms are triggered as if coupled to a gauge that
    counts from zero to the highest capacity of the log defined
    (reached each time the log wraps) and then resets to zero.

    If a log wraps, and no records are deleted to free space,
    capacity threshold events shall be emitted only when all the
    records in the log prior to the previous wrap occurance are
    completely overwritten. In other words, the gauge threshold is
    reset to zero each time the end of log marker is crossed by the
    addition of a new log record. For example if a log has a capacity
    of 2 Gigabytes a wrap event will occur only when every time 2
    Gigabytes of data have been written to the log.
    "

  • Reported: TLOG 1.0b1 — Thu, 17 Jun 1999 04:00 GMT
  • Disposition: Resolved — TLOG 1.0
  • Disposition Summary:

    resolved, see revised text below

  • Updated: Fri, 6 Mar 2015 20:58 GMT