Character mode hosts are supported in SOA applications only. Character mode hosts are character-stream based, which means that the host sends buffers all the time and unlike the situation with block mode hosts, there is no way to divide these buffers to screens. The Session View can work both in character mode and in block mode. You will need to start working in character mode (the default mode) - in that mode the Session View acts like a regular emulator: each key is sent to the host. By using the character mode, you can navigate through screens.
In character mode based hosts, the whole screen received from the host is defined as unprotected. ApplinX is unable to determine where there are fields within the screen; therefore ApplinX needs to be taught where the fields are. To do this, create screens, define and map application fields. After you mapped the necessary application fields for a screen, you can transfer to block mode in the Session view (Refer to Navigating within a Session: Character Mode (VT) Hosts). Using Block mode means that you can type data in all the fields, but the data will not be sent to the host until a submit key such as ENTER or a PF key is pressed. The behavior in Path Procedures will be similar: in the Step node instructions for the whole screen are provided, but ApplinX sends the data character by character.
As in VT the host continuously sends data. When sending a submit key such as ENTER or a PF key, the host immediately returns the same screen that was sent (the correct screen content will only be displayed if the Synchronize with host icon is pressed), and only afterwards the actual screen is received. Therefore, in Path Procedures it is necessary to use Wait Conditions to define to wait for the screen to arrive from the host. Refer to Path Procedures to implement Wait Conditions. You may need to use different types of Wait Conditions for different use cases. Refer to Wait Conditions for further details.
Follow the step-by-step instructions for creating a new application.
VT parameters are defined per application. Sometimes it is necessary to override these parameters for a specific screen. This can be implemented by opening the relevant screen in the Editor view and in the VT parameters tab, changing the configuration.
Screen Editor: VT Parameters tab
VT parameters are defined per application. Sometimes it is necessary to override these parameters for a specific field, for example when it is necessary to define that a field is a password type field. This means that characters are sent from ApplinX to the host, but only asterisks are retrieved from the host. In order to validate that the correct data has been received from the host, it needs to be indicated that this field's characters are hidden. This option is selected in the by opening the relevant screen in the Editor view and in the Fields tab, changing the VT Parameter's configuration (in the Host field behavior field). Additional parameters can also be configured here.
Fields tab: VT Parameters section
Character mode (VT) host screens consist of unprotected fields only. Therefore the regular working mode of navigating through screens - typing data in input fields and pressing a key in order to send data to the host, cannot be implemented for VT hosts. There are two alternatives to working with VT applications: working in character mode or working in block mode.
Character mode: Simulates the host behavior where each key stroke is submitted to the host.
Block mode: Simulates ApplinX behavior, where the whole screen is sent to the host when clicking the Enter key at the end.
In the application development process, character mode should be used in the early process of development, mainly for screen navigation. In advanced stages of development, block mode should be used in order to resemble the SOA working mode (which is, by definition, block mode).
The desired mode is determined by clicking on the Block mode/Character mode icon in the Session View.
As in character mode hosts, each key is submitted to the host. The host returns the same screen and immediately after sends the updated screen. This being so, a Wait Condition is required in order to wait for the following screen.
