Rational Developer for System z

The Dialog (standard or TUI client) entity

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: 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:

C/S Screen or TUI client

This entity is reserved for TUI applications.

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

It receives the data entered, validates it and manages any detected errors, 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:
  • Initializes the conversation,
  • Ensures the link between the different client components
  • Calls the requested service or the server monitor which corresponds to this service.
The monitor and the clients components exchange information through a communication area which includes the following data:
  • Technological data specific to the clients,
  • Data required to call the Business Component and to retrieve its answer, such as the:
    • Name of the service to call,
    • Name of the server monitor (this name is defined in the Dialog which includes the services),
    • Code of the Logical View processed by the client.

The TUI client submonitor

This submonitor is reserved for TUI applications. It:
  • Ensures the link between the client components of this submonitor,
  • Ensures the link to another submonitor for the call of a client component which does not belong to this submonitor,
  • Calls the requested service or the server monitor which corresponds to this service.

Each client component that depends on a client monitor can be defined in that client submonitor. A submonitor is therefore a group of client components whose choice can depend on logical considerations (client components working in the same domain) or system (division in function of tasks: consultation or updates, running priority ...).

The use of submonitors and of the list of client components (that make up 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 developed with the OnLine Systems Development function into an HTML format.

The Dialog description must include information related to the communication.

In the host part, you must generate a logical message which will allow the management of Screen display or the sending of the message to the Internet communication monitor.

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

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


Terms of use | Feedback

This information center is powered by Eclipse technology. (http://www.eclipse.org)