Skip to content
CA Gen - 8.6
Documentation powered by DocOps

Properties for Action Diagram/Operation

Last update July 28, 2016

The Properties dialog enables you to specify properties for a new or existing action diagram or operation.

When adding a new action diagram, type a name and a description. When you are adding an online non display procedure step, verify if the default online procedure displays in the pull-down list.

These properties are used to define an action diagram or operation:

  • Name of the action diagram.
  • Owning entity type or subtype name for an operation.
  • Protection setting for action blocks and operations of encapsulated or restricted entity types.
  • Operation type.
  • Operation package setting. This option is not available unless the operation is a procedure step.
  • Execute Statement Number option.
  • High performance view passing option. This option is not available for procedure steps.
  • Generate MISSING flags in the code option (for external action blocks only).
  • Name of the Business System to which the action diagram belongs, if any.
  • Description of the action diagram.

Several of the controls are disabled unless certain conditions are met.

  • The Action Diagram type drop-down list box is enabled only when you are creating an Operation using the Data Model Browser, the Data Model List, or the Component Architecture Diagram. Otherwise, the type is disabled and only displays the type for the current action diagram.
  • The Protected option is disabled unless you are creating an operation for an encapsulated or restricted entity type.
  • The name of the entity type or subtype to the right of the Operation of: field will state <<NONE>> unless you select to make a new or existing action diagram into an operation. You would use the Choose Entity button to select the owning entity type or subtype name.
  • The Operation Package option only becomes enabled if the current action diagram/operation is also a procedure step.

The following are the fields in the dialog:

  • Action Diagram
    Action Diagram Name identifies the name of the current action diagram or lists the names of candidate diagrams when adding an operation.
    If entering a new name, assign a unique name with no more than 32 characters. Do not name the action block "Main". A general protection fault can occur if an action diagram or procedure step name is "Main".

    Note: If the action diagram is also an operation, the Operation of field shows the name of the owning entity type or subtype.
  • Action Diagram Type List
    This list displays the type of action diagram currently selected. An action diagram can be one of four types:
    • BAA Block-must not be an elementary process.
    • BSD Block-must not be associated with a procedure step.
    • Elementary Process-must have an association with a process definition.
    • Procedure Step-must have an association with a procedure step.
    The list is enabled when you add an operation using the Data Model Browser or the Data Model List tools. When you add an operation, you can select the type of action diagram needed to perform that operation. Depending on the type of action diagram you select, names of candidate action diagrams appear in the Action Diagram Name field. You cannot change the type of the action diagram if it is are already defined as an operation.
  • Choose Entity Type
    This drop-down list displays the type of action diagram currently selected. An action diagram can be one of four types:
    • BAA Block-must not be an elementary process.
    • BSD Block-must not be associated with a procedure step.
    • Elementary Process-must have an association with a process definition.
    • Procedure Step-must have an association with a procedure step.
    The list is enabled when you add an operation using the Data Model Browser or the Data Model List tools. When you add an operation, you can select the type of action diagram needed to perform that operation. Depending on the type of action diagram you select, names of candidate action diagrams appear in the Action Diagram Name field. You cannot change the type of the action diagram if it is are already defined as an operation.
  • Protected Operation
    Protected operations are only visible to the implementations of the owning entity type.
    The Protected Operation option is enabled when you add an operation to a Restricted or Encapsulated entity type or subtype. If an operation is protected, the visibility of its attributes and relationships is restricted.
    Protected operations can be altered, removed or added to a model, and the impact will be confined to the implementation of the owning entity type.
    Rules
    Protected operations may only be USE'd by a calling action diagram where the caller is:
    • An operation of the (protected operation's) owning entity type
    • An operation of a subtype or supertype of the (protected operation's) owning entity type.
    • Procedure steps, and operations of open entity types, may not be protected.
    • Elementary processes and common action blocks owned by restricted or encapsulated types may be protected.
    • A protected operation can only be called by another action diagram if the following conditions of the calling action diagram are true:
    • It is an operation of the same owning entity type, or
    • It is an operation of a subtype or supertype of the same entity type.
    By default, all operations are unprotected.
    Use
    Protected operations have several uses:
    • To define processing that is common to many (unprotected) operations of an entity type, but which need not be directly invoked by the rest of the application.
    • To break up the logic of large (unprotected) operations.
    • To isolate a piece of logic within an (unprotected) operation that is subject to frequent change.
  • Instance Operation
    An instance operation focuses on a single existing occurrence (instance) of the owning entity type.
    Operations that update or delete an existing entity occurrence (instance) should ideally be registered as instance operations. Operations that read an existing instance and then retrieve data about that instance or its associated instance (or update associated instances) should also be registered as instance operations.
    CA Gen automatically adds an import view which defines the primary identifier of the instance, and an entity action view for the instance (if the type was defined as persistent).
    Rules
    An instance operation must:
    • Import the primary identifier of the owning type (not a supertype or subtype of the owning type), or must
    • Import a persistent view of the owning type (not a supertype or subtype of the owning type)
    Only the transient import view is allowed for external action blocks, operations of transient types, and procedure steps.
    The primary identifier must be in mandatory views, and may not appear within a repeating group view.
    In the second option, the persistent view may be imported as a <persistent, mandatory> import view, or a <persistent, imported> export view.
    Instance operations may not be defined for no-occurrence entity types.
    Instance operations may update or read other instances of the same or other types, as long as the encapsulation options allow. it. Instance operations may invoke any non-protected operations of other types. Hence, the instance operation is not restricted to acting on a specific instance, but that instance is the central focus of the operation.
    Action block synthesis will automatically classify update, delete and read actions as instance operations.
    For instance operations in action diagrams:
    • Each action diagram may update, delete, or simply read this occurrence.
    • Each action diagram may also read or update other occurrences of the same or different entity types.
    • If a procedure step or an external action diagram is defined as an Instance Operation, the primary identifier of the owning entity type must appear within the import views of the procedure step.
    • The occurrence of the operation may be identified by being imported as a persistent view, or the primary identifier of the owning entity type may be imported in one or more transient import views of the action diagram.
    Use
    Instance operations typically result in more clearly defined operations. The subject of the verb/action part of the operation name refers to the subject instance, as identified by the imported persistent view or primary identifier. Operations on occurrences of different types should be given the same verb/action for equivalent instance operations. This helps developers to decompose the functionality of the business in a uniform way by developers.
    In the object paradigm, operations on instances (objects) are the more usual, and instance operations assist to develop "think objects". However, the operation classification defaults to "type operation" since any operation can be validly classified as a type operation. Some projects may prefer to forgo this aspect of the object modeling approach.
  • Type Operation
    A type operation is one that is NOT focused on a single existing occurrence (instance) of the owning entity type.
    A type operation is focused on a single non-existent occurrence (such as a create operation) or is focused on multiple occurrences (such as a list operation or a find operation employing a non-unique search key).
    Rules
    • A type operation must contain a view of the entity type that owns it (not just a view of its subtype or supertype).
    • Type operations may update or read instances of the owning type or other types, as long as the encapsulation option allows it. Type operations may invoke any non-protected operations of other types. Hence the type operation is not restricted to acting on occurrences of a single type, but that type should be the main focus of the operation.
    • Action block synthesis will automatically classify create and list blocks as type operations.
    For type operations in action blocks:
    • Each action diagram may update, delete, or simply read this occurrence.
    • Each action diagram may also read or update other occurrences of the same or different entity types.
    • If a procedure step is defined as a Type Operation, it must contain a view of its owning entity type (not a subtype or supertype).
    Use
    Any operation that contains a view of a type can be validly defined as a type operation of that type; thus, it is the default.
    Procedure steps that contain commands are classified as operation packages.
  • Operation Package
    An operation package is a procedure step that represents a packaging together of several operations.
    Procedure steps may offer several discrete units of functionality, and the consumer uses an input command to distinguish which piece of functionality is to be executed. Each command, then, effectively represents a separate operation within the procedure step.
    If you select the Operation Package option, a procedure step performs several different functions that are invoked at run-time using different command values. For example, the procedure step might have a CASE OF COMMAND structure with ADD, DROP, CHANGE, and DISPLAY commands, which all perform separate functions.
    Rules
    • The classification "operation package" is only available for procedure step operations (also known as transaction operations).
    • A procedure step that has no input commands may not be classified as an operation package, but a step with input commands need not be classified as an operation package.
    For the operation package:
    • Each procedure step may update, delete, or simply read this occurrence.
    • Each procedure step may also read or update other occurrences of the same or different entity types.
    • The primary identifier of the owning entity type must appear within the import views of the procedure step.
    • An elementary process cannot be defined as an operation package.
    Use
    On the Data Model Browser, the operations within an operation package are listed by command name, so the user can see all the operations of the package. The commands are only displayed for operations classified as operation packages.
  • Execute Statement Number
    The Execute Statement Number option determines whether COBOL code is generated with action diagram statement numbers.
    The statement number can be useful when debugging a generated application. When the option is selected, the last statement number will be shown when an abend occurs during processing.
    Once testing is complete, clear the selection of this option and regenerate the action block or procedure step. This will cause the load module to be generated without the extra code required to execute the statement numbers.
    If an abend occurs when the option is not selected, the abend message displays a null value for the last statement number.
  • High Performance View Passing
    This option makes it possible to efficiently pass data between action blocks. The High Performance View Passing feature is available for process action diagrams and action blocks. The feature is not available for derived algorithm action blocks and procedure action diagrams.
    Selecting this feature enables the action block to be called as externals by another model.
    High Performance View Passing is the default value for action blocks and process action blocks created using COOL:Gen version 3.0 and higher.
    The High Performance View Passing option can be selected for process action diagrams and action blocks created before COOL:Gen 3.0. After selecting this option, it is necessary to regenerate the action block and all of the action blocks, process action diagrams, and procedure action diagrams that USE the selected action block.
    If you are using Component Based Development methods, keep the High Performance View Passing checkbox selected. This is required to pass the whole globdata structure to the component call. If you do not select the option, only a pointer to the substructure containing just the ENVIRONMENTDATA is passed. This prevents the component from successfully interacting with the database.

    Note: It is recommended that you NOT change the globdata contents by an external action block.
  • Generate MISSING flags in code
    This option determines whether internal flags are generated for views that are passed to an external action block. Views contain flags that are used internally by CA Gen. This option lets you disable the generation of these flags for external action blocks only. By not generating these flags, you eliminate passing unnecessary data in views and reduce system overhead.
  • Description
    Description provides a multi-line field in which to clearly and concisely document the purpose of the action diagram.
Was this helpful?

Please log in to post comments.