Rational Developer for System z

Bidirectional data in terminal flows

You can specify the bidirectional attributes of screen SFMXSD files. You must enable bidirectional support before creating a service flow project.

Recording a screen dialog or flow

The service flow project tools make the following assumptions:
  • Bidirectional host screens are Visual.
  • Bidirectional host screens can have either left-to-right (LTR) or right-to-left (RTL) orientation.
  • (Arabic sessions) Symmetric and numeric swapping only apply to screens with right-to-left (RTL) orientation.
  • (Hebrew Sessions) By default, symmetric and numeric swapping is disabled.

Note that the screen orientation is dependent on how an application is designed. Data input and recognition criteria are not sensitive to screen orientation. However, some screens are prepared based on the assumption that the user will reverse them in order to enter or view data, and some applications expect that data will be typed in reverse order (push mode). Therefore, screen and field orientation are important for correct data interpretation in bidirectional terminal flows.

Extract considerations

The bidirectional algorithm for terminal flows assumes that the user extracts from and prompts to the screen that has the correct orientation.

Consider a screen with all fields in Hebrew or Arabic that contains the English string ADDRESS. In a reversed screen, the string is displayed correctly, but in an LTR screen it is displayed as SSERDDA. The CICS® Service Flow Runtime environment does not recognize bidirectional keystrokes such as Screen Reverse. If you extract the field in an LTR screen, the SFMXSD file that describes the field contains the VISUAL LTR attribute. Assume that this field will be extracted from the LTR screen and used as input for other applications. The input will be incorrect: SSERDDA instead of ADDRESS.

The user must do a screen reverse before doing an extract. When a screen extract is done in an RTL screen, the SFMXSD file is updated with the VISUAL RTL attributes. Usually, extracts are mapped to message elements, which will have the default attributes (here, VISUAL LTR). In this situation, bidirectional conversion is generated for the extracted string, and ADDRESS is stored in the message element, instead of SSERDDA.

Consider another situation in which a field has an orientation that is the opposite of the screen orientation. Here, the string ADDRESS could incorrectly appear as SSERDDA in an RTL screen. If you extract this field, it should not be converted when being mapped into message element; although the whole screen has RTL orientation, this specific field has LTR orientation. For the field to be extracted correctly, set the Opposite attribute using the screen message editor.

Prompt considerations

Unlike extracts, data input such as a prompt is not typically sensitive to screen orientation. Therefore, data from message elements is not converted when it is mapped to a prompt field. For example, when you type the letters a d d r e s s in an RTL screen , the result (the buffer submitted to the host) is the same as if the string address was entered in an LTR screen.

However, in some cases the application assumes that bidirectional data is entered in reversed order (push mode). For example, the bidirectional application sometimes expects that you will enter the word address. In that situation, you see ADDRESS on an RTL screen, while the actual buffer sent to the host is SSERDDA. In this case, you must set the Opposite attribute for the field, because the application expects to receive reversed data.

Numeric fields are another special case. Such fields always have left-to-right typing orientation. Bidirectional applications reverse the numeric fields inserted in right-to-left screens, but they do not reverse the numeric fields inserted in left-to-right screens. Therefore, when you specify the numeric attribute for the field, it is reversed for right-to-left screen prompts only.

Working with existing screens

You can use the screen message editor to edit screen and field bidirectional attributes. If the existing screen is recognized during flow recording, the editor uses the default orientation that is specified in the SFMXSD file.
Do not change the bidirectional attributes for screens that were previously used in a screen flow, if extracts or prompts were generated from these screens. Instead, create another SFMXSD file using screen capture, and specify different recognition criteria for these screens.

Terms of use | Feedback

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