public interface AbstractDialog extends AbstractRadicalElement
The purpose of the Dialog entity is to develop and generate the online applications of the OnLine Systems Development function or the TUI applications of the Pacbench C/S function.
A Dialog represents the interaction between Screens that are logically related to each other. A Dialog is therefore made up of a logical family of Screens. It is described independently of the physical characteristics of the environment or the TP monitor in use.
For each Dialog, you define the characteristics common to all the Screens which make up the Dialog. These characteristics, which become the default values of the Screens, are the:
Presentation options, specified on the Dialog Definition tab:
The number of lines and columns on the Screen,
The type of label used for Data Elements (long, short, relational, column),
The general presentation of these Data Elements (number of elements per line, alignment...),
The presentation attributes (intensity, color) according to the nature of the data (displayed fields, input fields, labels, error messages...).
Common files (common area, error messages file), and some processing options, specified on the Dialog Complement tab.
These default options can be modified for each Screen of the Dialog.
There are two types of Dialogs:
Standard Dialogs, which implement the OnLine Systems Development function. This function includes the following features:
Description of all online Screens,
Prototyping and generation of all online Screen layouts,
Generation of programs, including the procedures described for each Screen, and the screen flow of the Dialog.
TUI Dialogs, which implement the Pacbench C/S function. This function includes the following features:
Description of all client components using the TUI entities of the Pacbase metamodel,
Automatic generation of TUI Screen layouts,
Generation of client components and the TUI screen flow and the client/server components flow.
Two basic types of architecture are possible: one which uses a monitor, and the other which does not:
In an architecture without monitor, the client components directly calls the server components (a server monitor or a Business Component).
These calls are indicated in each client component.
Each client sends its data to the service, according to the communication mode in use. The return to the client is performed just after the call function and the processing is performed in sequence.
You can always add specific processing by inserting code before or after the service call.
In an architecture with monitor, the client monitor calls a server monitor, or directly calls the Business Component in question. The server monitor calls the appropriate service and gives the control either to the client monitor or directly to the client.
A monitor groups common information and processing (communication management, compacting, trace, COMMIT/ROLLBACK, site-specific features). For some platforms, like MICRO FOCUS and TUXEDO, using a monitor is a requirement.
Moreover, using a monitor are sometimes justified by application requirements (confidentiality, data encryption) or technical constraints (communication protocols). The monitor option enables you to interface more easily with your own communication method and to insert data security and encryption/decryption processing
Modifier and Type | Field and Description |
---|---|
static java.lang.String |
copyright |
getGCLines
getCalledEntities, getDescriptionTypes, getDesignId, getEntityVersion, getKeywords, getLabel, getName, getPackage, getProject, isResolved
static final java.lang.String copyright
java.lang.String getCobolFolder()
Returns the folder where the cobol is generated.
java.lang.String getCobolProject()
Returns the project where the cobol is generated.
CobolTypeValues getCobolType()
In this field, you have the COBOL variant for the generated Screen.
java.util.List<CPLine> getCPLines()
List of called predefined Macros into the generated program.
java.util.List<AbstractCSLine> getCSLines()
It indicates how Segments are accessed in the validation, update and display processing associated with the Screen.
DialogTypeValues getDialogType()
In this field, you can see if the Dialog or Screen type is a standard online type or a TUI type.
ColorAttributeValues getDisplayColorAttribute()
Color attribute of display fields presents on Screen.
IntensityAttributeValues getDisplayIntensityAttribute()
Intensity attribute of display fields presents on Screen.
PresentationAttributeValues getDisplayPresentationAttribute()
Presentation attribute of display fields presents on Screen.
ColorAttributeValues getErrorFieldColorAttribute()
Color attribute of error fields presents on Screen.
IntensityAttributeValues getErrorFieldIntensityAttribute()
Intensity attribute of error fields presents on Screen.
PresentationAttributeValues getErrorFieldPresentationAttribute()
Presentation attribute of error fields presents on Screen.
ColorAttributeValues getErrorMessageColorAttribute()
Color attribute of error messages presents on Screen.
IntensityAttributeValues getErrorMessageIntensityAttribute()
Intensity attribute of error messages presents on Screen.
PresentationAttributeValues getErrorMessagePresentationAttribute()
Presentation attribute of error messages presents on Screen.
java.util.List<GLine> getGELines()
The -GELines indicate :
the list of the automatically generated error messages which have been replaced,
the declaration of explicit error messages,
the help on a Screen, a Data Element or an error message.
Library getGenerationLibrary()
Indicates the Library on which we can find the generation parameters for the entity.
Parameters are related to the adaptation to the operating system in use.
java.util.List<GLine> getGGLines()
These lines on a given Screen or Dialog are used to override some of the values of the generated constants.
java.util.List<GLine> getGOLines()
The GOLines indicates the list of the generation options.
java.lang.String getHelpCharacterElement()
You can have any character in this field. It must be left-aligned.
It is recommended to reserve this character for field help.
The documentation request is automatically recognized by the generated program.
The character for documentation request at the Data Element level is taken into account.
Note: If the Generated language specified in the Library Definition tab is COBOL II or 85, the tests generated in F8150 to detect the characters for documentation request are carried out on the first character of the field only. They are not carried out on the whole field as it is the case for standard COBOL.
For the environments which authorize the use of PF keys, you can enter a specific PF key to call the documentation associated with a field.
The documentation request is automatically recognized by the generated program when the user moves the cursor to a an element and presses the PF key.
Depending on the type of COBOL to generate, some specificities are added:
IBM CICS, IBM IMS, AS/400 variants: If the field is coded with a specific character, numeric fields are not generated as such at the map level.
CICS variants: The following values can also be used:
A1 for the AP1 function key,
A2 for the AP2 function key,
EN for the Enter key,
00 for the Clear key.
BULL multi-screen variant: PF keys can be used if the screens are of the 3270 type. They work as in an IBM environment.
TANDEM variant: Entering a character is not authorized. Only the values ranging from 01 to 32, corresponding to 'F1' to 'SF16', can be used.
DEC/VAX variant: Values 01, 02, 03, 06 to 11 and 14 to 20 can be used for the PF keys.
MICRO FOCUS variant: Values ranging from 01 to 24 can be used for the PF keys.
HP3000 variant: The help function can only be activated by a character. Since the screen reception does not authorize cursor positioning, it would be impossible to find which element was selected.
java.lang.String getHelpCharacterScreen()
This character is to be used to request documentation on a screen. You can enter any character, left-aligned.
It is recommended to use this character only for the call of screen help. The documentation request is automatically recognized by the generated program
Note: If the Generated language specified in the Library Definition tab is COBOL II or 85, the tests generated in F8150 to detect the characters for documentation request are carried out on the first character of the field only. They are not carried out on the whole field as it is the case for standard COBOL.
For the environments which authorize the use of PF keys, you can have a specific PF key to call the documentation associated with the screen.
Depending on the type of COBOL to generate, some specificities are added:
IBM CICS, IBM IMS, AS/400 variants: If you enter a character here, the numeric fields are not generated as such at the map level.
CICS variants: The following values can also be entered:
A1 for the AP1 function key,
A2 for the AP2 function key,
EN for the Enter key,
00 for the Clear key.
BULL multi-screens variant: PF keys can be used on 3270 screens. They work as in an IBM environment.
TANDEM variant: Entering a character is not authorized. Only the values ranging from 01 to 32, corresponding to 'F1' to 'SF16', can be used.
DEC/VAX variant: Values 02, 03, 06 to 11 and 14 to 20 can be used for the PF keys.
MICRO FOCUS variant: Values ranging from 01 to 24 can be used for the PF keys.
HP3000 variant: The help function can only be activated by a character.
java.lang.String getInitialCharacter()
This field indicates the default initial value for the variable Data Elements called in the Screen.
This initial value is set in the program associated with the Screen.
ColorAttributeValues getInputColorAttribute()
Color attribute of input fields presents on Screen.
IntensityAttributeValues getInputIntensityAttribute()
Intensity attribute of input fields presents on Screen.
PresentationAttributeValues getInputPresentationAttribute()
Presentation attribute of input fields presents on Screen.
ColorAttributeValues getLabelColorAttribute()
Color attribute of labels presents on Screen.
IntensityAttributeValues getLabelIntensityAttribute()
Intensity attribute of labels presents on Screen.
LabelPresentationValues getLabelPresentation()
The values of this field correspond to the association between the Data Element and the presentation characteristics for these labels (left-aligned...).
At the Screen level, it is used to override the selection made at the Dialog level.
There are four possible labels:
The long label (36 positions), entered on the Data Element Definition tab.
The short label (18 positions), entered on the Data Element -D Lines tab.
The relational label (18 positions), entered on the Data Element -D Lines tab.
The column heading label, entered on the Data Element -D Lines tab.
PresentationAttributeValues getLabelPresentationAttribute()
Presentation attribute of labels presents on Screen.
java.lang.String getMapFolder()
java.lang.String getMapProject()
MapTypeValues getMapType()
In this field, you have the variant of the TP monitor for the generated Screen.
java.lang.String getProgramExternalName()
The name entered here is the name of the file generated from this instance. The generated file name can then differ from the instance name.
int getScreenColumnNumber()
This field indicates the number of columns per Screen. This number must range between 1 and 80 inclusive. The default value is 80 at the Dialog level.
The format (number of lines and number of columns) specifies the overall dimensions of the Screen.
When Screen 'X' calls Screen 'Y', the size taken by Screen 'Y' is the size specified on its Definition tab. The relative positioning of the Data Element immediately following the called Screen therefore depends on the format of the called Screen.
int getScreenLineNumber()
This field indicates the number of lines per Screen. This number must range between 1 and 62 inclusive. The Default value is 24 at the Dialog level.
int getTabs()
This field indicates the number of tabulation points per line. The default value is 1 at the Dialog level. The maximum number authorized is 50.
It is used to automatically position the Data Elements on the screen. The tabulation points are the invisible points on the screen, which divide each line into equal parts.
Each Data Element for which no absolute positioning is indicated is automatically moved to the next available tabulation point.
java.lang.String getTransactionCode()
This field corresponds to:
The four-character transaction code (Dialog default code) for a CICS variant.
The transaction code associated with the Dialog for an IMS variant. This field is displayed on all the Dialog Screens except if the MONITOFF option (one transaction code for each Screen, no generated monitor) option is specified.