Processes can communicate with terminal emulators using remote files. The communication data path between the system and the terminal emulator is mapped to stations originated and controlled by the Transaction Server.
When the Transaction Server allocates the pseudostation, those stations are considered originated and controlled by the Transaction Server. Other configurations exist where the underlying station is allocated by another MCS (for example, SYSTEM/STATION/TRANSFER or SYSTEM/TELNET in MCS mode), and control of the pseudostation is transferred in to the Transaction Server.
For more information, see the section, "Pseudostations and Fully Participating MCSs," in the DCALGOL Programming Reference Manual.
The following table details the different cases for remote file output message delivery:
|
Window Type |
Station Origin |
|
|---|---|---|
|
Transferred In |
Transaction Server Allocated |
|
|
Remote file (declared of dynamic window) |
MCP delivers in Transaction Server Primary Queue (2) |
MCP calls Output Router in Transaction Server (1) |
|
Direct |
Application calls Transaction Server |
Application calls Transaction Server |
|
MCS |
Transaction Server Primary Queue (3) |
Transaction Server Primary Queue (3) |
-
Only one pseudostation is involved. The Transaction Server allocates a pseudostation when connected by a protocol specific handler. This station is originated and controlled by the Transaction Server.
-
Only one pseudostation is involved. A secondary Transaction Server, either STATION/TRANSFER or TELNET (in MCS mode), allocates the pseudostation and then transfers the pseudostation to the primary Transaction Server. This station is controlled but not originated by the Transaction Server.
-
Two pseudostations are involved. The Transaction Server allocates a pseudostation that is transferred to the MCS window (for example, CANDE). The Transaction Server maps the remote file output received from the MCS window pseudostation to the underlying Transferred In or Transaction Server Allocated station.
The system uses various methods to regulate the depth of undelivered output to avoid excessive queueing, depending on the type of program involved. The TANKING attribute has no effect on application programs running in Remote File Windows above a station that is not originated by the Transaction Server.
The following types of application programs can run under the Transaction Server:
-
Direct window programs
Direct window programs communicate with terminals through special Transaction Server structures rather than through remote files.
-
Remote file programs
Remote file programs communicate through declare or dynamic Remote File Windows. Declared Remote File Windows appear in the Transaction Server configuration file and are associated with particular programs. Dynamic Remote File Windows are created by the Transaction Server at runtime when a program initiated from a MARC session opens a remote file.
For remote file programs, where the associated station is originated and controlled by the Transaction Server, the TANKING value is used as follows:
If the TANKING value is NONE or UNSPECIFIED, the system does not perform tanking for the remote file. If the TANKING value is SYNC or ASYNC, the system performs tanking as if the TANKING value is ASYNC. The number of messages that can be queued is not limited. The TANKING attribute does not apply if the associated station is transferred in to the Transaction Server. The number of messages you can queue is not limited.
-
MCS window programs
An MCS window program is initiated from a Transaction Server window devoted to a subsidiary MCS. For example, any programs that you initiate by entering a RUN command in a CANDE window are considered MCS window programs. The number of messages that can be queued are described in the following paragraphs.
Tanking on the level of the Transaction Server is provided for programs that run in a Transaction Server environment. Transaction Server-level tanking impacts direct window programs, remote file programs, and MCS window programs. The Transaction Server places output messages in the Transaction Server tank file if the messages are being written faster than the station can receive them or if the messages are sent to a window dialogue that is suspended. For more information on how message tanking is managed, refer to the Transaction Server for ClearPath MCP Configuration Guide.
By default, only messages that are generated for your current window dialogue is displayed at the terminal, and all other window dialogues are considered suspended. You can use an ON command to resume another dialogue by transferring to the dialogue or use a RESUME command that specifies the dialogue. When you resume the window dialogue, the Transaction Server retrieves tanked messages and sends them to the station.
For MCS window programs, the ratio of output and input messages is monitored. When the ratio of output to input messages exceeds 1000 to 1, the system starts monitoring the delivery of output messages. An application that both reads and writes messages is not typically monitored in this way. If the depth of undelivered out messages exceeds several thousand messages, application WRITE and CLOSE operations are suspended until the majority of the messages are delivered. This process waits for messages to be delivered before the WRITE or CLOSE operations can complete. As a result, there might be a delay in process execution, but the process is not suspended and does not appear in the W (Waiting Mix Entries) system command display. The process resumes and the operation completes when a majority of the messages are delivered.
| Note: | A break-on-output request discards the messages and allows the process to resume. |
If the process is abnormally terminated while waiting for output messages to be delivered (for example, DSed), the CLOSE operations waits for approximately 90 seconds to allow the output messages to be resolved. After this time period, the application continues the closure of the remote file and proceeds with terminating the application. Even though the application is released and fully terminated, the association between the remote file and the station continues until the queued output is resolved. The application is released, but the station remains busy and associated with the remote file output.
The queued remote file output messages are eventually resolved, either by delivery to the CANDE window or by being purged. Then, the MCP cleans the association between the remote file and the station.
Transaction Server-level tanking is necessary for a Transaction Server windowing environment and is performed regardless of the value of the TANKING file and task attributes. The monitoring and pacing between remote file operations and the Transaction Server avoids excessive messages in the MCS primary queue, which impacts all operations performed by the Transaction Server.
