The purpose of the Dialog entity is to develop and generate the online applications of the OnLine Systems Development function or the TUI applications.
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.
You cannot generate a whole Dialog but you can generate each of its Screens, one at a time.
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.
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
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 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.
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. They are created to answer logical considerations (client components working in the same domain) or system considerations (for different tasks, such as 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.
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 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 which 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, using the identifier. Each Screen is a subprogram of the monitor.
For the instances 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.