Model 204 language support: Difference between revisions

From m204wiki
Jump to navigation Jump to search
(deleted $Alphnum description; linked to $Alphnum page instead)
m (link repair)
 
(10 intermediate revisions by one other user not shown)
Line 1: Line 1:
<div class="toclimit-3">__TOC__</div>  
<div class="toclimit-3">__TOC__</div>  
Model 204 contains a language support feature for customers who sort and display Model 204 data using single-byte character sets other than U.S. English or Japanese double-byte character set (DBCS).  
Model 204 contains a language support feature for customers who sort and display Model 204 data using single-byte character sets other than U.S. English or Japanese double-byte character set (DBCS).  


Line 76: Line 75:
<table>
<table>
<caption>Character sets supported in Model 204</caption>
<caption>Character sets supported in Model 204</caption>
<tr class="bold">
<tr class="head">
<th>Written language</th>
<th>Written language</th>
<th>Parameter value</th>
<th>Parameter value</th>
Line 126: Line 125:
<table>
<table>
<caption>Valid character sets</caption>
<caption>Valid character sets</caption>
<tr class="bold">
<tr class="head">
<th>Written language</th>
<th>Written language</th>
<th>Model 204 LANGFILE value</th>
<th>Model 204 LANGFILE value</th>
Line 170: Line 169:
<table>
<table>
<caption>Valid languages for a thread's I/O device</caption>
<caption>Valid languages for a thread's I/O device</caption>
<tr class="bold">
<tr class="head">
<th>Written language</th>
<th>Written language</th>
<th>Model 204 LANGUSER value</th>
<th>Model 204 LANGUSER value</th>
Line 242: Line 241:
<P CLASS="syntax">FIND [ALL] RECORDS {FOR WHICH | WITH} <span class="term">fieldname</span>
<P CLASS="syntax">FIND [ALL] RECORDS {FOR WHICH | WITH} <span class="term">fieldname</span>
     IS [NOT] LANGLIKE '<span class="term">pattern</span>'</p>
     IS [NOT] LANGLIKE '<span class="term">pattern</span>'</p>
====Where====
Where:
<p>
<p>
The LANGLIKE keyword indicates that <var class="term">pattern</var> is the set of characters to match, using LANGUSER and LANGFILE as previously described.</p>
The LANGLIKE keyword indicates that <var class="term">pattern</var> is the set of characters to match, using LANGUSER and LANGFILE as previously described.</p>
Line 252: Line 251:
<table>
<table>
<caption>$Functions for language-specific processing</caption>
<caption>$Functions for language-specific processing</caption>
<tr class="bold">
<tr class="head">
<th>$function</th>
<th>$function</th>
<th>Description</th>
<th>Description</th>
Line 265: Line 264:
</tr>
</tr>
<tr>
<tr>
<td>[[#$CHKPAT|$CHKPAT]]</td>
<td>[[$ChkPat|$ChkPat]]</td>
<td>Verifies the syntax of a pattern.</td>
<td>Verifies the syntax of a pattern.</td>
</tr>
</tr>
<tr>
<tr>
<td>[[#$LANGSPC|$LANGSPC]]</td>
<td>[[$LangSpc|$LangSpc]]</td>
<td>Returns a string containing the language-specific hexadecimal value of a special character on a particular terminal.</td>
<td>Returns a string containing the language-specific hexadecimal value of a special character on a particular terminal.</td>
</tr>
</tr>
<tr>
<tr>
<td>[[#$LANGSRT|$LANGSRT]]</td>
<td>[[$LangSrt|$LangSrt]]</td>
<td>Transforms a string into a language-specific sequence value.</td>
<td>Transforms a string into a language-specific sequence value.</td>
</tr>
</tr>
<tr>
<tr>
<td>[[#$LANGUST|$LANGUST]]</td>
<td>[[$LangUst|$LangUst]]</td>
<td>Restores a transformed string back to its original value.</td>
<td>Restores a transformed string back to its original value.</td>
</tr>
</tr>
<tr>
<tr>
<td>[[#$LIKE|$LIKE]]</td>
<td>[[$LIKE|$LIKE]]</td>
<td>Controls parsing and evaluation languages used in pattern matching.</td>
<td>Controls parsing and evaluation languages used in pattern matching.</td>
</tr>
</tr>
<tr>
<tr>
<td>[[#$LOWCASE|$LOWCASE]]</td>
<td>[[$Lowcase|$Lowcase]]</td>
<td>Translates an uppercase case or mixed-case string into a lowercase string.</td>
<td>Translates an uppercase case or mixed-case string into a lowercase string.</td>
</tr>
</tr>
<tr>
<tr>
<td>[[#$UPCASE|$UPCASE]]</td>
<td>[[$Upcase|$Upcase]]</td>
<td>Translates a lowercase or mixed-case string into an uppercase string.</td>
<td>Translates a lowercase or mixed-case string into an uppercase string.</td>
</tr>
</tr>
</table>
</table>
===$CHKPAT===
<p>
The $CHKPAT function verifies the syntax of a pattern. If the pattern is valid, a null string is returned; otherwise, an error message string is returned.</p>
====Syntax====
<p class="syntax">$CHKPAT(<span class="term">pattern</span>[,<span class="term">language</span>])</p>
====Where====
<p>
The required <var class="term">pattern</var> argument is the string of characters to verify as a valid pattern, which can be a literal enclosed in quotation marks or a %variable.</p>
<p>
The optional <var class="term">language</var> argument specifies the language to use. The language argument is handled as follows:</p>
<ul>
<li>When <var class="term">language</var> is omitted, Model 204 performs the validation in U.S. English, even if the value of the LANGUSER parameter is not US, and lowercase characters are not recognized.</li>
<li>An asterisk enclosed in quotation marks ('*') instructs Model 204 to use the value of the LANGUSER parameter.</li>
<li>
You can enter the name of a valid language enclosed in quotation marks or a %variable containing a valid language. If the value you enter is not supported, the request is canceled with an error message. See [[#LANGUSER: Setting the language definition of a user thread|LANGUSER]] for valid values.</li>
</ul>
<p>
Without $CHKPAT, pattern syntax errors can cause cancellation of the request or require the coding of complex ON units.</p>
====Examples====
<p>
For U.S. English:</p>
<p class="code">%PAT='ABC*'
%X=$CHKPAT(%PAT)
IF %X NE '' THEN
PRINT %X
JUMP TO ERROR.RETURN
END IF</p>
<p>
For French Canadian:</p>
<p class="code">%PAT='p&ecirc;ch&eacute;'
%X=$CHKPAT(%PAT,'FRENCHC')
IF %X NE '' THEN
PRINT %X
JUMP TO ERROR.RETURN
END IF</p>
===$LANGSPC===
<p>
The $LANGSPC function returns a string containing the hexadecimal value of the specified character in the specified language. You can use $LANGSPC to scan user input for a special character in a language-independent manner. A print-out or display of the returned value will be the character representation based on the language argument.</p>
<p>
You can also use the $LANGSPC function to ensure that any special character that has a different hexadecimal code value is displayed correctly.</p>
====Syntax====
<p class="syntax">$LANGSPC('<span class="term">charname</span>'[,<span class="term">language</span>])</p>
====Where====
<p>
The <var class="term">charname</var> argument is a string containing one of the following values:</p>
<table>
<tr class="head">
<th>Valid charname</th>
<th>US character</th>
<th>Description</th>
</tr>
<tr>
<td>AT</td>
<td>@</td>
<td>At sign</td>
</tr>
<tr>
<td>BACKSLSH</td>
<td>&#92;</td>
<td>Backslash</td>
</tr>
<tr>
<td>DOLLAR</td>
<td>$</td>
<td>Dollar sign</td>
</tr>
<tr>
<td>DQUOTE</td>
<td>&quot;</td>
<td>Double quotation mark</td>
</tr>
<tr>
<td>EXCLAMAT</td>
<td>!</td>
<td>Exclamation point</td>
</tr>
<tr>
<td>NOT</td>
<td>&#172;</td>
<td>Not sign</td>
</tr>
<tr>
<td>RBRACE</td>
<td>]</td>
<td>Closing square brace or right square brace</td>
</tr>
<tr>
<td>SHARP</td>
<td>#</td>
<td>Number sign or pound sign</td>
</tr>
<tr>
<td>VERTICAL</td>
<td>|</td>
<td>Vertical bar</td>
</tr>
</table>
<p>
The optional <var class="term">language</var> argument specifies which language to use to obtain the desired hexadecimal code for the specified character. The request is canceled with an error message if the name is not found in NLANG. The language argument is handled as follows:</p>
<ul>
<li>
When you omit the <var class="term">language</var> argument, Model 204 performs the validation in U.S. English, even if the value of the LANGUSER parameter is not US, and lowercase characters are not recognized.</li>
<li>
An asterisk enclosed in quotation marks ('*') instructs Model 204 to use the value of the LANGUSER parameter.</li>
<li>
You can enter the name of a valid language enclosed in quotation marks or a %variable containing a valid language. If the value you enter is not supported, the request is canceled with an error message. See [[#LANGUSER: Setting the language definition of a user thread|LANGUSER]] for valid values.</li>
</ul>
====Example====
<p>
In the following example, the %PATH variable, supplied by the user from the terminal, is searched for the backslash character in the code table designated by the user's LANGUSER value:</p>
<p class="code">%BACKSLASH IS STRING LEN 1
%BACKSLASH = $LANGSPC('BACKSLSH','*')
%DIR = $SUBSTR(%PATH,$INDEX(%PATH,%BACKSLASH)+1)
</p>
===$LANGSRT===
<p>
The $LANGSRT function translates a given string according to the specified language into a language-neutral hexadecimal string against which you can sort. A print-out or display of the returned value will be the character representation based on the language argument.</p>
<p>
By determining whether one string is greater or less than another string, you can use the $LANGSRT function to compare two strings. First apply the $LANGSRT function to the strings and then compare them using the SOUL greater-than (GT) and less-than-or-equal-to (LE) operators.</p>
====Syntax====
<p class="syntax">$LANGSRT('<span class="term">string</span>'[,<span class="term">language</span>])</p>
====Where====
<p>
The <var class="term">string</var> argument is a literal enclosed in quotation marks or a %variable containing the original data to be translated into collating sequence.</p>
<p>
The optional <var class="term">language</var> argument is the name of one of the defined languages, which specifies which collating sequence to use. The language argument is handled as follows:</p>
<ul>
<li>When you omit the <var class="term">language</var> argument, Model 204 performs the validation in U.S. English, even if the value of the LANGUSER parameter is not US, and lowercase characters are not recognized.</li>
<li>An asterisk enclosed in quotation marks ('*') instructs Model 204 to use the value of the LANGUSER parameter.</li>
<li>You can enter the name of a valid language enclosed in quotation marks or a %variable containing a valid language. If you enter a value that is not supported, the request is canceled with an error message. See [[#LANGUSER: Setting the language definition of a user thread|LANGUSER]] for valid values.</li>
</ul>
<p class="note"><b>Note:</b> The $LANGSRT function returns the string unchanged when the language is U.S. English. </p>
====Example====
<p>
The following procedure stores the value of NAME from each record into array %STR. <br />The $LANGSRT function translates each value of NAME into a language-specific collating sequence and stores the value into the array %SORTSTR. <br />The procedure then calls a user written subroutine, MYSORT, that sorts the %SORTSTR array in ascending order. <br />At this point the procedure invokes the $LANGUST function to translate the collating string back to its original form and prints the names in language-specific order.</p>
<p class="code"><nowiki>BEGIN
DECLARE SUBROUTINE MYSORT (STRING LEN 20 ARRAY(*))
%STR STRING LEN 20 ARRAY (20) NO FS
%SORTSTR STRING LEN 20 ARRAY (20) NO FS
*
FD1: IN DATA FIND ALL RECORDS
    END FIND
    %I = 1
    FOR EACH RECORD IN FD1
      %STR(%I) = NAME
      %I = %I + 1
    END FOR
    FOR %J FROM 1 TO %I-1
      %SORTSTR(%J) = $LANGSRT(%STR(%J),'TURKISH')
      END FOR
*
* SORT NAMES
*
CALL MYSORT(%SORTSTR)
*
    FOR %J FROM 1 TO %I-1
      %STR(%J) = $LANGUST(%SORTSTR(%J),'TURKISH')
      PRINT %STR(%J)
    END FOR
END</nowiki></p>
===$LANGUST===
<p>
The $LANGUST function translates back to its original form a string previously translated by $LANGSRT processing, which is useful for applications that maintain sorted arrays of data and need to display the values.</p>
====Syntax====
<p class="syntax">$LANGUST('<span class="term">string</span>'[,<span class="term">language</span>])</p>
====Where====
<p>
The <var class="term">string</var> argument is a literal enclosed in quotation marks or a %variable containing the data in collating sequence to be translated back to its original form.</p>
<p>
The optional <var class="term">language</var> argument is the name of one of the defined languages, specifying which collating sequence to use. The language argument is handled as follows:</p>
<ul>
<li>You can enter the name of a valid language enclosed in quotation marks or a %variable containing a valid language. If the value you enter is not supported, the request is canceled with an error message. See [[#LANGUSER: Setting the language definition of a user thread|LANGUSER]] for valid values.</li>
<li>An asterisk enclosed in quotation marks ('*') instructs Model 204 to use the value of the LANGUSER parameter.</li>
<li>When you omit the <var class="term">language</var> argument, Model 204 performs the validation in U.S. English, even if the value of the LANGUSER parameter is not US, and lowercase characters are not recognized.</li>
</ul>
====Example====
<p>
If your site maintains more than one type of terminal and keyboard that store and display the same character set, individual characters might be assigned differing hexadecimal codes on different keyboards. You can translate the character equivalents back and forth as follows:</p>
<p class="syntax">$LANGUST($LANGSRT(<span class="term">string</span>,<span class="term">source-language</span>), <span class="term">target-language</span>)</p>
<p>
A character without an equivalent converts to its base character. A special character without an equivalent converts to a space.</p>
===$LIKE===
<p>
The $LIKE function provides user control over the parsing and evaluation languages used in pattern matching. It has two language arguments: one to assign the parsing language, LANGUSER, and one to assign the evaluation language, LANGFILE.</p>
<p>
The LANGLIKE operator and $LIKE function in expressions coordinate to provide consistency between the FIND statement and the IF statement, and avoid complicating the interpretation of the evaluation language parameter.</p>
====Syntax====
<p class="syntax">$LIKE(<span class="term">string</span>,<span class="term">pattern</span>[,<span class="term">parse-lang</span>][,<span class="term">eval-lang</span>])</p>
====Where====
<p>The <var class="term">string</var> argument represents the characters to verify. It must be one of the following:</p>
<ul>
<li>A literal enclosed in quotation marks.</li>
<li>A %variable.</li>
<li>A field name without quotation marks. In this case, the function call must be embedded in a FOR EACH RECORD loop where the current value of the field is verified.</li>
</ul>
<p>
The required <var class="term">pattern</var> argument is the string of characters to verify, which you can specify as a literal enclosed in quotation marks or as a %variable.
</p>
<p>
The optional <var class="term">parse-lang</var> argument specifies the language to use for parsing. The <var class="term">parse-lang</var> argument is handled as follows:</p>
<ul>
<li>Omitting this argument instructs Model 204 to use U.S. English parsing rules, even if the value of the LANGUSER parameter is not US.</li>
<li>An asterisk enclosed in quotation marks ('*') instructs Model 204 to use the value of the LANGUSER parameter.</li>
<li>You can enter the literal name of a valid language enclosed in quotation marks. If you enter a name that is not supported, the request is canceled with an error message. See [[#LANGUSER: Setting the language definition of a user thread|LANGUSER]] for valid values.</li>
</ul>
<p>
The optional <var class="term">eval-lang</var> argument specifies the language to use for evaluation. Its requirements are identical to the <var class="term">parse-lang</var> argument.</p>
====Example====
<p>
In the following example, we are matching the value of field NAME against the pattern (A-Z)*@ using US as the parsing language and TURKISH as the evaluation language. </p>
<ul>
<li>
The parsing language, LANGUSER, determines the special characters that can be used in a pattern. The pattern is checked for syntax against these characters. The evaluation language, LANGFILE, is used when the pattern is matched against the data. </li>
<li>
The evaluation language, LANGFILE, determines the collating sequence and the definition of alphabetic characters. </li>
</ul>
<p>
In this example, the evaluation language is Turkish. therefore all character matching is done against the Turkish alphabet and the range operation, (A-Z), uses the collating sequence of the Turkish language.</p>
<p class="code">BEGIN
FD1: IN DATA FIND ALL RECORDS
  END FIND
  %PAT='(A-Z)*@'
  FOR EACH RECORD IN FD1
    %RC = $LIKE(NAME,%PAT,'US','TURKISH')
    IF %RC EQ 0 THEN
    PRINT 'STRING: 'WITH NAME WITH 'DOES NOT MATCH PATTERN: -
          '  WITH %PAT
    END IF
  END FOR
END</p>
===$LOWCASE===
<p>
The $LOWCASE function translates an uppercase or mixed-case string into a lowercase string. The translation affects only characters with uppercase and lowercase pairs, for example, A to a through Z to z in U.S. English. These are not strictly keyboard pairs. If the first character in the string is alphabetic, the character is converted to uppercase.</p>
====Syntax====
<p class="syntax">$LOWCASE(<span class="term">string</span>[,<span class="term">language</span>])</p>
====Where====
<p>
The <var class="term">string</var> argument represents the characters to verify, which must be entered as follows:</p>
<ul>
<li>A literal enclosed in quotation marks.</li>
<li>A %variable.</li>
<li>A field name without quotation marks. In this case, the function call must be embedded in a FOR EACH RECORD loop where the current value of the field is verified.</li>
</ul>
<p>
The optional <var class="term">language</var> argument specifies the language to use, which is handled as follows:</p>
<ul>
<li>
Omitting the <var class="term">language</var> argument instructs Model 204 to perform the validation in U.S. English, even if the value of the LANGUSER parameter is not US.</li>
<li>
An asterisk enclosed by quotation marks ('*') instructs Model 204 to use the value of the LANGUSER parameter.</li>
<li>
You can enter a literal name of a valid language enclosed in quotation marks. If the name you enter is not supported, the request is canceled with an error message. See [[#LANGUSER: Setting the language definition of a user thread|LANGUSER]] for valid values.</li>
</ul>
====Example====
<p>
The following example returns the string 'Name and address' in U.S. English:</p>
<p class="code">$LOWCASE('NAME AND ADDRESS')</p>
<p>
The following example returns the string '&Ccedil;&agrave; et l&agrave;' in French Canadian:</p>
<p class="code">$LOWCASE('&Ccedil;&Agrave; ET L&Agrave;','FRENCHC')</p>
===$UPCASE===
<p>
The $UPCASE function translates a lowercase or mixed-case string into an uppercase-only string. The translation affects only the uppercase letters of character pairs in the specified language.</p>
====Syntax====
<p class="syntax">$UPCASE(<span class="term">string</span>[,<span class="term">language</span>])</p>
====Where====
<p>
The <var class="term">string</var> argument represents the characters to verify. which must be entered as follows:</p>
<ul>
<li>A literal enclosed by quotation marks.</li>
<li>A %variable.</li>
<li>A field name without quotation marks. In this case, the function call must be embedded in a FOR EACH RECORD loop where the current value of the field is verified.</li>
</ul>
<p>
The optional <var class="term">language</var> argument specifies the language to use. The language argument is handled as follows:</p>
<ul>
<li>Omitting this argument instructs Model 204 to perform the validation for U.S. English, even if the value of the LANGUSER parameter is not US.</li>
<li>An asterisk enclosed in quotation marks ('*') instructs Model 204 to use the value of the LANGUSER parameter.</li>
<li>A literal name of a valid language enclosed in quotation marks. If the name you enter is not supported, the request is canceled with an error message. See [[#LANGUSER: Setting the language definition of a user thread|LANGUSER]] for the valid values.</li>
</ul>
====Examples====
<p>
The following examples return uppercase strings for mixed case entries.</p>
<table>
<tr class="head">
<th>Function code...</th>
<th>Returns...</th>
<th>Language</th>
</tr>
<tr>
<td><code>$UPCASE('Name and address')</code></td>
<td><code>'NAME AND ADDRESS'</code></td>
<td>U.S. English</td>
</tr>
<tr>
<td><code>$UPCASE('&Icirc;le d'Orl&eacute;ans','FRENCHC')</code></td>
<td><code>'&Icirc;LE D'ORL&Eacute;ANS'</code></td>
<td>French Canadian</td>
</tr>
<tr>
<td><code>$UPCASE('&Icirc;le d'Orl&eacute;ans')</code></td>
<td><code>'ILE D'ORLeANS</code></td>
<td>U.S. English</td>
</tr>
</table>
<p class="note"><b>Note:</b> In U.S. English no accented characters have case translation.</p>


==Terminal interface requirements==
==Terminal interface requirements==
Line 658: Line 323:


==Control characters==
==Control characters==
For a list of the control characters found in IBM computers and the sequence in which they are sorted, see [[Control characters]].  
For a list of the control characters found in IBM computers and the sequence in which they are sorted, see [[Control characters and Model&nbsp;204 language support]].  


==Special characters==
==Special characters==

Latest revision as of 14:55, 20 December 2016

Model 204 contains a language support feature for customers who sort and display Model 204 data using single-byte character sets other than U.S. English or Japanese double-byte character set (DBCS).

This feature is included in the SOUL (User Language), HLI, and SQL interfaces. This topic describes the facilities that perform this language-specific processing for Model 204 data display, sequencing, and collating.

Overview

Language support in computer data storage means being able to receive, store, and redisplay differing character sets and devising algorithms to handle the correct sorting procedures. Worldwide use of the computer to store, transmit, share, and compare data exposed the need to:

  • Analyze the character sets used by written languages to determine which characters are shared and which characters are unique to a character set.
  • Respect the collating sequence or order of precedence rules used by a written language.

Language support terminology

A character set is a set of symbols or marks used in a writing system, such as a letter of the alphabet. Character sets differ in the number of characters, the specific characters included, and their collating sequence.

Once a character set is identified, the next task is handling the collating sequence. Collating sequence is the sequence in which characters are ordered for sorting, merging, and comparing. Specifically it is the order assigned to the characters of a character set (in computers, for example, ASCII, U.S. English, and EBCDIC) used for sequencing purposes. Usage determines the correct collating sequence for each writing system. The commonplace examples of collating sequences are telephone directories and dictionaries.

Language support documentation

For a thorough discussion of the decisions surrounding language support, consult the following documents:

  • Canadian Alphanumeric Ordering Standard for Character Sets of CSA Standard CAN/CSA-Z243.4, Canadian Standards Assoc., Rexdale (Toronto), Ontario, Canada, 1992.
  • The Unicode Standard: Worldwide Character Encoding, Version 1.0, Volume 1, The Unicode Consortium, Addison-Wesley, Reading, MA, 1991.

Adding other languages

Adding a language to those already developed for Model 204 language processing is a cooperative venture between a customer and Rocket Software. If you are interested, please consult your sales representative.

A note about User Language and SOUL

Model 204 versions 7.5 and higher provide a significantly enhanced, object-oriented, version of User Language called SOUL. All existing User Language programs will continue to work under SOUL, so User Language can be considered to be a subset of SOUL, though the name "User Language" is now deprecated. In this topic, the name "User Language" has been replaced with "SOUL."

Collating sequence support

The language support feature in Model 204 currently sorts using the expected collating sequence for U.S. English and limited support of Japanese.

NLANG, the language support module

Model 204 modules are linked with a set of language support tables in the NLANG module that define written languages. A Model 204 supported language consists of translation tables and flag tables containing information about:

  • Alphabetic characters, lowercase to uppercase
  • Alphabetic characters, uppercase to lowercase
  • LANGSORT tables
  • Pattern matcher
  • Characters you can enter at the keyboard
  • Characters you can display on the terminal
  • ASCII to EBCDIC translation

Supported languages

After installing Model 204, you can select one of five variations of the internal language table. The LANGUSER and LANGFILE parameter settings you select sets the terminal and print capabilities. The NLANG module contains internal language tables for the following languages:

  • Cyrillic
  • French Canadian
  • Japanese
  • Turkish
  • US English

The internal language table provides the same input and output translation tables, uppercase or lowercase translation, and $ALPHA support as the coordinating Model 204 parameters, LANGUSER and LANGFILE, but does not determine collating sequences for sorting or B-tree indexes.

Language support parameters

After installation set the correct LANGFILE and LANGUSER parameter options to support applications for your language requirements. The value of the LANGFILE and LANGUSER parameters determine which internal language table in NLANG that Model 204 consults for collating sequence, character storage, and uppercase or lowercase translation.

IBM code pages

IBM assigns a code page number to correspond to various sets of characters. Each IBM code page assigns a particular set of character shapes to a corresponding binary code. Model 204 depends on the binary code definition in the IBM code page to handle language support.

The following table lists the Model 204-supported character sets and designated IBM code pages.

Character sets supported in Model 204
Written language Parameter value Refers to IBM code page
Cyrillic CYRILLIC 880
French Canadian FRENCHC 037
Japanese JAPAN 290
Turkish TURKISH 1026
US English US (the default) 1047

LANGFILE: Choosing a character set definition for a file

Class

FPARMS

Default

US, meaning U.S. English

Setting

During file creation or resettable by file manager

Meaning

Use the LANGFILE parameter to specify the language for file processing operations such as the ordering of data and processing LIKE and LANGLIKE patterns. The LANGFILE parameter determines the valid character set in a file.

The value of LANGFILE must be one of the following, listed in this table.

Valid character sets
Written language Model 204 LANGFILE value
Cyrillic CYRILLIC
French Canadian FRENCHC
Japanese JAPAN
Turkish TURKISH
US English US (the default)

Note: You cannot specify a LANGFILE parameter setting other than US for sorted files (FILEORG X'01' setting).

LANGUSER: Setting the language definition of a user thread

Class:

USER

Default:

US, meaning U.S. English

Setting:

On the user's parameter line, resettable

Meaning:

Use the LANGUSER parameter to specify the language that is in use by the thread's I/O device. Different terminals in the same Model 204 run can use different languages. HLI or SQL threads can use different languages from each other and from SOUL or terminal threads.

The value of LANGUSER must be one listed in the following table:

Valid languages for a thread's I/O device
Written language Model 204 LANGUSER value
Cyrillic CYRILLIC
French Canadian FRENCHC
Japanese JAPAN
Turkish TURKISH
US English US (the default)

Data Management Language enhancements

This section describes language support enhancements to Data Management Language.

SQL Server

SQL Server ordering operations for an SQL table use the collating sequence specified by the file's LANGFILE parameter. Model 204 SQL does not permit joins across files that do not have the same LANGFILE parameter settings.

SQL language support requires an additional four bytes in QTBL per compiled query. You can set QTBL on the User 0 line or with the UTABLE command.

Statements that support language-specific ordering

The following SOUL statements and their corresponding HLI calls provide language-specific ordering:

  • FIND (various inequality operators such as index and direct search)
  • FOR EACH RECORD IN ORDER BY (including FROM and TO clauses)
  • FOR EACH VALUE IN ORDER
  • FOR EACH VALUE (in group context)
  • SORT RECORDS/RECORD KEYS
  • SORT VALUES
  • Pattern matcher (LIKE or LANGLIKE clause) range specifications

Note: Sorted file operations (with FILEORG = X'01') are not supported.

Pattern matching using the LANGLIKE operator

The SOUL operator LANGLIKE supports parsing and evaluation of patterns according to the tables provided with the LANGUSER and LANGFILE parameters.

The LANGLIKE syntax is the same as LIKE syntax. See the topic on value loops for more details.

  • The LIKE operator employs U.S. English for parsing the pattern and the value of LANGFILE for evaluating the pattern.
  • The LANGLIKE operator uses the value of LANGUSER for parsing the pattern and the value of LANGFILE for evaluating the pattern.

The parsing language, LANGUSER, is used for checking the syntax of the pattern and for determining the value of:

  • Special pattern escape character
  • Hexadecimal character
  • Alphabetic character

The evaluation language, LANGFILE, is used to match the pattern against the data. In particular, if a range of characters is defined in the pattern, then the collating sequence is determined by the evaluation language, LANGFILE.

Syntax

The format of the FIND statement used to perform pattern matching is:

FIND [ALL] RECORDS {FOR WHICH | WITH} fieldname IS [NOT] LANGLIKE 'pattern'

Where:

The LANGLIKE keyword indicates that pattern is the set of characters to match, using LANGUSER and LANGFILE as previously described.

The pattern argument must be enclosed in quotation marks. The characters that you can use in a pattern and the methods of optimizing a pattern retrieval are described in Record loops wiki topic.

SOUL $functions for language support

The $functions in the following table include language-specific processing capabilities.

$Functions for language-specific processing
$function Description
$Alpha Verifies that a string is composed of only characters that are valid in the specified or default language.
$Alphnum Verifies that a string is composed of only characters and digits 0 through 9, which are valid in the specified or default language.
$ChkPat Verifies the syntax of a pattern.
$LangSpc Returns a string containing the language-specific hexadecimal value of a special character on a particular terminal.
$LangSrt Transforms a string into a language-specific sequence value.
$LangUst Restores a transformed string back to its original value.
$LIKE Controls parsing and evaluation languages used in pattern matching.
$Lowcase Translates an uppercase case or mixed-case string into a lowercase string.
$Upcase Translates a lowercase or mixed-case string into an uppercase string.

Terminal interface requirements

Output validation on 3270 full-screen threads uses the list of displayable characters that is specified in the thread's language table, specified by LANGUSER or by the default language, US.

If no such list is supplied, then no output validation is performed, regardless of the setting of the FSTRMOPT parameter.

If there is a list of displayable characters, then output validation is performed when the FSTRMOPT parameter setting allows it; that is, when the X'01' bit is off.

The *UPPER and *LOWER commands, which set case translation, use the case translation rules specified in the thread's language table. If no case translation rules are specified, then no case translation is performed, regardless of the *UPPER or *LOWER command setting.

Using the JAPAN language table

The JAPAN language table is designed to handle Katakana terminal display and to provide upward compatibility with DBCS support in previous releases of Model 204. In particular, case translation and 3270 output validation are disabled.

Using DBCSENV for uppercase translation

When the DBCSENV parameter is set to a nonzero value, the LANGUSER parameter is automatically set to JAPAN. See the Model 204 DBCS Support Summary for the use and setting of this parameter.

Uppercase translation depends on the DBCSENV parameter. In the non-DBCS environment, when an *UPPER command is in effect, Model 204 converts data received from the user to uppercase for:

  • Full-screen editor commands
  • Screen input items not specified as mixed case
  • Line mode input (for example, command and $READ input)

Extended text lines for full-screen editor

Full-screen editor users in the Fujitsu environment can now input extended text lines of up to 255 display positions. If the storage requirement of such a line exceeds 255, the line is truncated cleanly. The screen is resent to the user with the truncated line highlighted, and an error message is displayed in the full-screen editor's message window.

Control characters

For a list of the control characters found in IBM computers and the sequence in which they are sorted, see Control characters and Model 204 language support.

Special characters

For a list of the special characters found in text, such as punctuation marks, diacritic (or accent) marks, currency symbols, arithmetic and mathematical marks, building blocks for screen forms, and Optical Character Recognition characters:

See the Unicode code charts or the Unicode Standard Worldwide Character Encoding, Version 1.0, Volume 1.

Latin Alphabet, Diacritics, Ligatures, and Numerals

For a list of the characters used to build words in U.S. English, French Canadian, and other written languages utilizing the Latin and extended Latin character set:

See the Unicode code charts or the Unicode Standard Worldwide Character Encoding, Version 1.0, Volume 1.

Language support topics

The Model 204 language support documentation consists of the pages listed below. This list is also available as a "See also" link from each of the pages.

Retrieved from "https://m204wiki.rocketsoftware.com/index.php?title=Model_204_language_support&oldid=95034"