DBCS support

Code Debug TSO and BMC AMI DevX Code Debug for IMSlets you use the single-byte character set (SBCS), the double-byte character set (DBCS), and mixed (a combination of DBCS and SBCS) data streams in your application programs and Code Debug TSO  and BMC AMI DevX Code Debug for IMSscreen functions, testing functions, and data manipulation during a test session.

The attributes of the SBCS, DBCS, and mixed data streams are as follows:

SBCS
An alphanumeric character set that lets one EBCDIC character occupy one byte. It is used for languages that use 1-byte characters.

DBCS
A graphic character set that lets 1 character occupy two bytes. It is used for languages, such as Japanese, that use ideographic characters that cannot be represented in one byte.

Mixed
Data streams consisting of SBCS and DBCS characters. Special delimiters are used to identify DBCS data in a mixed field. They are:

• Shift-out (X'0E', called SO) to show the beginning of DBCS data
• Shift-in (X'0F', called SI) to show the end of DBCS data
  SO and SI are automatically inserted when you change shift status on the terminal to begin and end DBCS data. SO and SI must always be paired in a mixed data stream and are only displayed by using the appropriate control keys on your terminal.

While most Code Debug functions operate normally with DBCS data streams, there are some differences in how these fields are scrolled and how data is manipulated. This section describes those differences.

Terminal Support

DBCS is supported only on terminal types where the ISPF variable ZDBCS is set to Yes.

When a test session is invoked, Code Debug checks the terminal type and switches the character set translation appropriately to one of the following:

• EBCDIC English (no Katakana)
• EBCDIC Katakana (no lowercase English)
• EBCDIC English with DBCS (lowercase English and SBCS Katakana coexist)
• EBCDIC Katakana with DBCS (no lowercase SBCS English)

EBCDIC English and EBCDIC Katakana character sets are determined by an inquiry to the ISPF terminal type default. DBCS capability is determined by an inquiry to the ISPF ZDBCS variable.

When a Katakana (Japanese) terminal is detected, all lowercase English output strings (messages, title, and text) that appear on Code Debug screens are converted to uppercase English. DBCS lowercase characters are not affected.

Program Support

DBCS is supported by Code Debug in interactive mode only. DBCS can be used in standard TSO, including IMS/DB and BTS, IMS/DC (MPP, BMP, IFP), and ISPF dialog box programs.

DBCS Fields on the Source Display

The following table (see following table) describes the areas on the Code Debug Source display screen where DBCS data is valid. The DBCS Fields on the Code Debug Source Display Screen table indicates whether the area is an input or output area, the field attributes, and a description of what the data consists of.

DBCS user-defined words may contain both double-byte EBCDIC and double-byte non-EBCDIC characters.

DBCS Fields on the Code Debug Source Display Screen

Character set validation is based on field type (attribute) and terminal type. DBCS data in a mixed field is validated using the following criteria:

1. All occurrences of SO are paired with SI (field level check).
2. All DBCS character lengths are even (field level check)
3. Each byte of a DBCS character is within a valid range X'41' to X'FE' and the DBCS blank (X'4040').

If 1 and 2 are not met, the DBCS field is converted to SBCS representation. If 3 is not met, the DBCS character is shown as a nondisplayable character (X'4195').

Scrolling DBCS Data

When the PEEK or KEEP command is used, the data is displayed in fully scrollable windows. 30 bytes are displayed at a time. Data exceeding the 30 bytes limit can be displayed by scrolling left or right using the DLEFT or DRIGHT commands or by using the (,(n,),)n, and :n line commands.

Scrolling is always by byte, not by character. When scrolling mixed or DBCS fields, the display window will be adjusted when the result will split a DBCS character. The basic rule is that if the first byte of a DBCS character is in the window at the left or right boundaries, the complete character is displayed. The right boundary is extended by one byte to display the character. If the second byte of a DBCS character is in the left boundary of the window, the field is truncated by one byte on the left and the character is not displayed.

When a mixed field is truncated, Code Debug inserts and deletes the SO and SI delimiters as needed to maintain the integrity of the SO/SI pairing. These inserted SO/SI delimiters are for display purposes only and are not saved in the underlying data. When a DBCS field is truncated, the field’s attribute byte is inserted to adjust the truncation.

The following pages show examples of the scrolling behavior of mixed and DBCS fields.

Scrolling Mixed Fields

The following 45-byte string is used to show the truncation behavior in a mixed field:
----+----1----+----2----+----3----+----4----+
1234<D1D2D3D4>5678<D5D6D7D8>ABCD<DaDbDcDd>EFG

Example 1

When a SBCS character or SO/SI is at the left or right boundary of the window, no truncation occurs and the character is displayed.

For example, after scrolling the sample string 14 bytes left, the SBCS character 5 is at the left boundary of the Keep window and the SBCS character F is at the right boundary of the window. The result is shown in following figure:

SBCS Example 1—Scrolling the Sample String 14 Bytes Left

Example 2

When the first byte of a DBCS character is at the left boundary of the window, the character is displayed and an SO is inserted outside the window to maintain the SO/SI pairing.

For example, after scrolling the sample string 5 bytes left, the first byte of the DBCS character D1 is at the left boundary of the window. The result is shown in following figure:

DBCS Example 2—Scrolling the Sample String 5 Bytes Left

Example 3

When the second byte of a DBCS character is at the left boundary of the window, the character is not displayed and an SO is inserted at the left boundary to maintain the SO/SI pairing. However, if you displayed the underlying hexadecimal values, the first byte of the window contains the hexadecimal value of the second byte of the truncated character.
For example, after scrolling the sample string 6 bytes left, the second byte of the DBCS character D1 is at the left boundary of the window. The result is shown in following figure:

DBCS Example 3—Scrolling the Sample String 6 Bytes Left

Example 4

When the first byte of a DBCS character is at the right boundary of the window, the window is extended by one byte and the complete DBCS character is displayed. The first byte is displayed at the right boundary of the window and the second byte is displayed outside the window. An SI is also inserted outside the window to maintain the SO/SI pairing.

For example, after scrolling the sample string 5 bytes left, the first byte of the DBCS character Dc is at the right boundary of the window. The result is shown in following figure:

DBCS Example 4—Scrolling the Sample String 5 Bytes Left

Example 5

When the second byte of a DBCS character is at the right boundary of the window, the character is displayed and an SI is inserted outside the window to maintain the SO/SI pairing.

For example, after scrolling the sample string 9 bytes left, the second byte of the DBCS character Dc is at the right boundary of the window. The result is shown in the following figure:

DBCS Example 5—Scrolling the Sample String 9 Bytes Left

Scrolling DBCS Fields

The truncation behavior is slightly different when scrolling DBCS fields. To show the behavior, the 40-byte DBCS string shown here is used:

----+----1----+----2----+----3----+----4
D1D2D3D4D5D6D7D8D9D0DaDbDcDdDeDfDgDhDiDj

Example 6

When the first byte of a DBCS character is at the left boundary of the window or the second byte of a DBCS character is at the right boundary, the character is displayed.
For example, after scrolling the sample string 2 bytes left, the first byte of the DBCS character D2 is at the left boundary of the window and the second byte of the DBCS character Df is at the right boundary of the window. The result is shown in following figure:

DBCS Example 6—Scrolling the Sample String 2 Bytes Left

Example 7

When the second byte of a DBCS character is at the left boundary of the window, the character is not displayed and the attribute byte is inserted in the first byte of the window to adjust the truncation. Although the DBCS character is not displayed, the left boundary still contains the hexadecimal value of the second byte of the truncated character.

When the first byte of a DBCS character is at the right boundary of the window, the window is extended by one byte on the right and the character is displayed.

For example, after scrolling the sample string 9 bytes left, the second byte of the DBCS character D5 is at the left boundary of the window and the first byte of the DBCS character Dj is at the right boundary. The result is shown in following figure:

DBCS Example 7—Scrolling the Sample String 9 Bytes Left

Manipulating DBCS Data

DBCS data displayed in the Keep or Peek windows can be manipulated the same as SBCS data. However, depending on the field attribute (SBCS, DBCS, or mixed), there are some rules that must be observed when you type over, insert, delete, and move DBCS and SBCS data.

Manipulating DBCS data in the Keep and Peek windows follows the same truncation behavior as described in Scrolling DBCS Data and is controlled by the field attribute (SBCS, DBCS, or mixed). However, the underlying data beyond the visible window may be affected. Displaying the hexadecimal values with the PEEKH primary command or the PH or H line command lets you see the actual underlying values.

The following pages describe the behavior when you manipulate DBCS data.

Typing Over Data

Typing over a DBCS field with SBCS data is not allowed. You can type over a mixed field with SBCS or DBCS data. However, the underlying data beyond the visible window may be affected. The same applies when inserting and deleting data. For example, if you type over a DBCS substring with SBCS characters, the SO/SI bytes that are inserted or deleted are saved in the underlying data.

Example 8

The following mixed field is used in this example (see the following figure) of typing SBCS data over DBCS data.

Example 8—Typing SBCS Data Over DBCS Data

Type the SBCS character 1 over the first byte of the DBCS character D1.

Example 9

After pressing Enter, the window appears as shown in following figure:

Example 9—Typing SBCS Character 1 Over DBCS Charter D1

Note that the hexadecimal values have changed. The following describes the result of the changes in hexadecimal values:

• The SO in byte 1 of the window is the original SO in the underlying data.
• The SI in byte 2 was inserted when you shifted to type in the SBCS character 1.
• The SBCS character 1 is displayed in byte 3. D1 does not appear because the first byte was typed over.
• A blank was inserted in byte 4 and a SO was inserted in byte 5 to show the beginning of DBCS data. D2 is not displayed because both bytes could not be displayed.
• Bytes 6, 7, 8, and 9 contain the DBCS characters D3 and D4.
• The SI in byte 10 is the original SI in the underlying data.

Inserting Data

Inserting characters is not allowed unless null characters (blanks) are present in the display window. If you try to insert more characters than the number of null characters, the terminal simply will not accept the extra characters.

Example 10

The following DBCS field is used for this example (see the following figure) of inserting DBCS characters:

Example 10—Inserting DBCS Characters in a DBCS Field

Insert the DBCS character D1 in bytes 4 and 5 and repeat the character D2 in bytes 12 through 17.

Example 11

The result is shown in following figure:

Example 11—Inserting DBCS Character D1 in Bytes 4 and 5

The result is that the inserted characters filled up the window. The hexadecimal values show that the inserted characters are now a part of the underlying data.

Deleting Data

When characters are deleted with the DELETE key, the null characters (blanks) are filled from the end of the window, not from the end of the field. When characters are deleted with the ERASE (EOF) key, the window starting from the cursor position is blanked out, not the entire field.

Example 12

The following mixed field (see the following figure) is used to show the behavior when deleting characters:

Example 12—Display of Behavior When Deleting Characters

Use the DELETE key to delete the DBCS characters D1, D2, D3, and D4. The following is displayed before you press the Enter key.

Example 13

Note that the hexadecimal values (see the following figure) in the example here have not changed.

Example 13—Using the DELETE Key to Delete DBCS Characters

After pressing the Enter key, the following is displayed.

Example 14

In the example (see the following figure), note that the hexadecimal values have changed—the values of the deleted characters are no longer displayed.

Example 14—Deleted Characters No Longer Displayed

Moving Data

The MOVE command can be used to move DBCS or SBCS data into a mixed alphanumeric field. However, you cannot move a G type literal into this type of field.

A DBCS literal can be moved to a DBCS field as long as the appropriate SO/SI are inserted. When the DBCS data is moved to the field, the field is padded with the DBCS blank (X'4040') and the SO/SI pairing is deleted.

Example 15

The following DBCS field (see the following figure) is used to show the behavior when moving DBCS data:

Example 15—Displayed Behavior When Moving DBCS Data

Move the DBCS characters D2D3D4D5D6 to N-NAME.

Example 16

After pressing the Enter key, the move is performed and the window appears as shown in following figure. Note that the new string replaced the existing data and the field was padded with DBCS blanks.

Example 16—Results of Moving DBCS Characters to N-NAME

WHEN Command and DBCS Data

The WHEN command can be used with DBCS data. If the command includes a literal parameter, the literal must be preceded by the G literal identifier. The G literal identifier indicates to Code Debug TSO that the literal contains shift-out/shift-in (SO/SI) characters. You may not mix SBCS and DBCS characters in the literal.

Example 17

Example 17—WHEN Command Example with DBCS Characters in Literal

In above figure, GRAPHICVAR is defined as a graphic variable. The G indicates that the literal includes SO/SI characters. When the compare is executed, the SO/SI characters are disregarded.