The Dialog (standard or TUI client) entity

The purpose of the Dialog entity is to develop and generate the transactional applications or the TUI clients of the client/server applications.

A Dialog represents the interaction between Screens that are logically related to each other. Therefore, a Dialog is constituted 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 common characteristics of all the Screens that constitute the Dialog. These characteristics, which become the default values of the Screens, are as follows:
  • The presentation options in the Dialog Definition:
    • The number of lines and columns on the Screen
    • The type of label that is used for Data Elements (long, short, relational, column)
    • The general presentation of these Data Elements (such as the number of elements per line and alignment)
    • The presentation attributes (intensity, color) according to the nature of the data (displayed fields, input fields, labels, or error messages for example)
  • The common files (common area and error messages file), and some processing options in the Dialog Complement tab
You can override these default options for each Screen of the Dialog if necessary.

You cannot generate a whole Dialog but you can generate each of its Screens, one at a time.

There are two types of Dialogs:
  • Standard Dialogs of transactional applications, with the following features:
    • Description of all online Screens
    • Prototyping and generation of all online Screen layouts
    • Generation of programs, including the procedures that are described for each Screen, and the screen flow of the Dialog
  • TUI Dialogs of client/server applications, with the following features:
    • Description of all TUI client components
    • 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.
    • In an architecture without a monitor, the client components directly call 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 completed just after the call function and the processing is completed in sequence.

      You can always add specific processing by inserting code before or after the service call.

    • In an architecture with a monitor, the Client Monitor calls a Server Monitor or directly calls a Business Component. 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 environments like MICRO FOCUS and TUXEDO, a monitor is required.

      Moreover, using a monitor is sometimes justified by application requirements (confidentiality, data encryption) or technical constraints (communication protocols). With the monitor option, it is easier to interface with your own communication method and to insert data security and encryption/decryption processing.

C/S Screen or TUI Client

This entity is reserved for TUI applications.

The client program submits service requests to the Server and manages the user interface.

It receives the data that is entered by the user, validates it and manages any errors. It then calls the access or calculation services before formatting and displaying the application data.

The TUI Client Monitor

This monitor is reserved for TUI applications. It completes the following operations:
  • Initializes the conversation
  • Links the client components
  • Calls the requested service or the Server Monitor that corresponds to this service
The monitor and the client components exchange information through a communication area that includes the following data:
  • Technological data specific to the clients
  • Data that is required to call the Business Component and to retrieve its answer, such as:
    • The name of the service to call
    • The name of the Server Monitor
    • The Logical View that is processed by the client

The TUI Client Submonitor

This submonitor is reserved for TUI applications. It completes the following operations:
  • Links the client components of this submonitor,
  • Links to another submonitor when a client component that does not belong to this submonitor is called,
  • Calls the requested service or the Server Monitor that corresponds to this service.

Each client component that depends on a Client Monitor can be defined in that Client Submonitor. Therefore, a submonitor is a group of client components. They are created to answer logical considerations (client components that work in the same domain) or system considerations (for different tasks, such as consultation, updates, or running priority).

The use of submonitors and of the list of client components (that constitute the submonitors) is specified in the WORKING-STORAGE SECTION.

The monitor for web communications

This monitor is reserved for Dialog web revamping applications. This function revamps the applications that are developed with the OnLine Systems Development function into an HTML format.

The Dialog description must include information that is related to the communication.

In the host part, you must generate a logical message to manage the Screen display and to send the message to the web communication monitor.

Upon the first communication, the monitor calls the first Screen and creates a file that contains a backup field of the Dialog common area. Upon the next communications, the Dialog common area is retrieved and the Screen program is called.

After each return from the Screen, the monitor sends the message to the web and saves the Dialog common area, by using the identifier. Each Screen is a subprogram of the monitor.

Generation

For explanations on a generated Screen, see the COBOL description of a generated Screen.

Note: For the instances that are imported from Pacbase, the skeleton language of the local generation is identical to the Pacbase skeleton language. This piece of information is retrieved from the extraction of the Pacbase models and from the import. It is stored in the Library.

Feedback