The Usg level value refers to the level of usage of a given object to the original object that is displayed on the subfile control. This value may be changed by the user and will control the data shown in the subfile. By manipulating the range of levels available, all possible usage levels can be viewed individually or in combination.
The Usg type column in the subfile refers to the reason for the usage. The following table shows the possible reasons for usages between model objects. Actual usages to a given model object depend upon the model object type.
|
Obj Type |
Used by |
Usage |
Reason |
Note |
|
All |
|
*ENTRY |
Displayed only on the first panel when you access the YDSPMDLUSG panel for a model object list rather than for a single list entry; for example, by using the YDSPMDLUSG command or F20 from the YEDTMDLLST panel. It indicates that each list entry displayed has simply been updated to reflect its current state in the model; no usages have been expanded. Your original list is not changed. You can now perform impact analysis on single list entries using the selection options. See also the online Help for the panel and the Impact Analysis topic in chapter 1 of Generating and Implementing Applications. |
|
|
ACP |
ACP |
*ACPENT |
For joining access path. |
|
|
|
ACP |
*ASSACP |
For associated access path. |
|
|
|
ACP |
*REFACP |
For referring access path. Subject access path is used as referenced access path due to file-to-file relation. |
|
|
|
ARR |
*ARRDTL |
For array detail definition. |
|
|
|
FUN |
*BASED |
Function based on access path. |
|
|
|
FUN |
*FUNPAR |
For function/message parameter definition. |
|
|
|
FUN |
*RELFUN |
For functions using related access path. That is, access path is present as a *REFACP and FUN uses access path, such as for validation. |
1 |
|
APP |
FIL |
*APPFIL |
For association in application area. |
|
|
ARR |
FUN |
*BASED |
Function based-on array. |
|
|
|
FUN |
*FUNPAR |
For function/message parameter definition. |
|
|
CND |
ACP |
*ACPCND |
For access path condition. |
|
|
|
CND |
*LSTCND |
Member of list condition. |
|
|
|
FIL |
*MAPFLD |
For field mapping (user-defined field types). |
|
|
|
FLD |
*DFTFLD |
Default field condition. |
|
|
|
FLD |
*FLDCND |
Field condition. |
|
|
|
FUN |
*ABOCND |
Action bar condition. |
|
|
|
FUN |
*ACTCND |
Action diagram condition. |
|
|
|
FUN |
*DEVCND |
Device entry condition. |
|
|
|
FUN |
*DFTDEV |
Default device entry condition. |
|
|
|
FUN |
*INPOVR |
Device input override condition. |
|
|
|
FUN |
*OUTOVR |
Device output override condition. |
|
|
|
FUN |
*PARAM |
Action diagram parameter. |
|
|
|
FUN |
*SCRMAP |
For screen field mapping (user-defined field types). |
|
|
FIL |
ACP |
*REFFIL |
For owning file. |
|
|
|
APP |
*APPARA |
For application area. |
2 |
|
FLD |
ACP |
*ACPCND |
For access path condition. |
3 |
|
|
ARR |
*ARRENT |
For array entry. |
|
|
|
FIL |
*ENTAUX |
For entry redirection. |
|
|
|
FIL |
*FILENT |
For key/attribute entry. |
|
|
|
FIL |
*MAPFLD |
For field mapping (user-defined field types). |
|
|
|
FIL |
*VRTENT |
For virtual entry. |
|
|
|
FLD |
*REFFLD |
For domain definition. |
|
|
|
FLD |
*RNMFLD |
For rename by entry. |
|
|
|
FUN |
*ACTION |
For action diagram action. |
|
|
|
FUN |
*ACTCND |
Action diagram condition. |
|
|
|
FUN |
*ACTCMP |
Action diagram compare. |
|
|
|
FUN |
*DEVCND |
For device conditioning. |
|
|
|
FUN |
*DEVENT |
For device entry. |
|
|
|
FUN |
*FUNPAR |
For function/message parameter definition. |
|
|
|
FUN |
*FUNPDT |
For function/message parameter detail definition. |
|
|
|
FUN |
*PARAM |
For action diagram parameter. |
|
|
|
FUN |
*SCRMAP |
For screen field mapping (user-defined field types). |
|
|
FUN |
ACP |
*SELRCD |
For select record override function. |
|
|
|
ACP |
*ACPFUN |
For access path function. |
|
|
|
FLD |
*EXTINT |
For external/internal conversion function (user-defined field type). |
|
|
|
FLD |
*FLDUSR |
Field-attached user source function (enabled) |
|
|
|
FLD |
*INTEXT |
For internal/external conversion function (user-defined field type). |
|
|
|
FUN |
*ARCVSN |
For archived version. |
1 |
|
|
FUN |
*ACTION |
For action diagram function. |
|
|
|
FUN |
*DFTDBF |
Default database function. |
|
|
|
FUN |
*DEVSTR |
For device structure usage. |
|
|
|
FUN |
*DEVUSR |
Device-attached user source function |
|
|
|
FUN |
*ENTUSR |
Entry-attached user source function |
|
|
|
FUN |
*FLDUSR |
Field-attached user source function (disabled) |
|
|
|
FUN |
*FMTUSR |
Format-attached user source function |
|
|
|
FUN |
*RPTUSR |
Report-attached user source function |
|
|
|
FUN |
*SCRUSR |
Screen-attached user source function |
|
|
|
FUN |
*SELRCD |
For select record override function. |
|
|
MSG |
FIL |
*RCDEXS |
For record exists message. |
|
|
|
FIL |
*RCDNFD |
For record not found message. |
|
|
|
FUN |
*ACTION |
For action diagram function. |
|
|
|
MSG |
*ARCVSN |
For archived version. |
1 |
The Note column indicates whether or not there is a reciprocal entry in the reference table by the using object. The numbers in the column refer to the following explanations as to why there will not be a corresponding reference entry:
The using object is not required by the used object as part of its definition. Thus, it is not shown in the reference table.
FIL objects are not included as defining an application area because this would make the scope of APP references too large. For this reason there is no corresponding entry for the APP object type in the reference table.
The reference of ACP to FLD is accomplished through the Access Path Condition (*ACPCND on the reference table).
Developers will note from the table that there is no direct relationship between objects of type FLD and ACP. That is, a change to a FLD has no direct effect on the ACP objects that use it. The change is propagated through the FIL objects on which the FLD appears as a file entry. This is a valuable feature in the product, where it provides the capacity to accommodate changes to the data model. When an ACP is required for DDS source generation, or for the construction of a device design, the structure is determined dynamically, incorporating any changes that may have occurred since the last time the structure was required. The dynamic nature of ACP objects means, however, that there is no database representation available for interrogation by impact analysis. The result is that changes to a FLD impact the FILs which use it and are propagated to all ACP objects, even if the FLD is not used by each individual ACP.
| Copyright © 2011 CA. All rights reserved. | Tell Technical Publications how we can improve this information |