204   Reporting of setting values

Created: 14 Sep 2005

Status: In Force (green)

Part: Part 7-3 (2003)

Links:

Page: 45-48

Clause: 7.7 and 7.8

Paragraph:

Category: Issue for edition 2 of this part

Issue

The tables 39 and 42 (basic templates) indicate that setting values can be set and reported. Currently there are no trigger options (TrgOp) defined in the tables 40/41 and 43/44. Data sets of settings could not be reported, because there are no trigger options defined.

Proposal

Add TrgOp dchg for "SP" and "SG,SE" for setVal and setMag.

Discussion Created Status
no negative vote --> accepted 27 Mar 06 In Force (green)
Editor meeting December 11, 2005
- also add trigger option dchg for the attributes with FC SV
- in the tables of part 7-3, we should also explicitly mark, which attributes do not trigger a report 		11 Dec 05 Ballot Period
Editor phone conference December 9, 2005
- For CF and SP attributes: add trigger option dchg
- With the possibility to report changes of parameter revisions (see TISSUE 13 of part 6 which adds attributes to LPL) we can trigger a report if any parameter (e.g. a value in a setting group) changes. We then have to read the parameters to figure out new values. 		09 Dec 05 Ballot Period
The tissue is also related to TISSUE 250 of 7-1 09 Dec 05 Discussion (red)
I suggest to postpone this for an editor meeting or a phone conference. We would have the following solution for CF and SP attributes:
- add trigger option dchg to all CF attributes
- add trigger option dchg to all SP attributes

But this does not solve the issue, how a client can be informed about a change of values in a setting group. And for that, I currently see no easy solution. In order to have a consistent approach at the end, I suggest to solve the issue in a meeting. 		03 Oct 05 Discussion (red)
With regard to adding TrgOp to "SP" and "SG,SE", I have the following proposal:

ok to add TrgOp "dchg" to SP attributes

unclear what it means, to add it to "SG,SE" attributes. What shall the server report, if a setting group has been edited? The reporting mechanism would not work here; at least, the setting group number to which the value belongs can not be transmitted. (to handle this properly, the EditSG attribute of the SGCB would be needed to include in the report) 		26 Sep 05 Discussion (red)
ok - the question then is, if we need a new trigger option cchg - configuration attribute change, similar to qchg - quality change, that we have already?

Maybe this is not required. A client may create specific datasets with the CF attributes and use these dataset with a specific report control block.

So, my final proposal would be: add dchg to ALL [CF] data attributes in 7-3. 		26 Sep 05 Discussion (red)
I believe that changes of parameters should be reported since we can have multiple clients. Therefore the one that changes a CF attribute does not necesarily requires a report but the others do. 23 Sep 05 Discussion (red)
I support Christophs view. Normally it is not necessary to report chagnes of parameters. This means, that according to the current reporting concept the FCs for reporting should be restricted to ST and MX. However, we have just decided to make an enhancement that as special option on any (ST,MX) change all values of a data set (also CF, DC, SP, SG - only exception: SE)can be reported, e.g. to indicate protection settings in case of a trip. Conclusion: leave this as it is (may be, introduce exception for fc=SE) 15 Sep 05 Discussion (red)
Is there really a requirement, to create a report, when I change the value of an entry in a (not active) setting group? What I need to have reported is the fact, that I change from one setting group to another. And in that case, I would like to have the setting values for that group reported. 14 Sep 05 Discussion (red)

 

Privacy | Contact | Disclaimer

Tissue DB v. 23.3.6.1