Data Entry Forms

Introduction

This chapter covers

References to Additional Material

The complete syntax for the UFORM form specification language is in Appendix A. Tutorials on the use of vuform(1), the visual screen editor and on menu systems are contained in Chapter 3.

The Elements of a Form

An example of a simple one-page form is shown in Figure 1 to illustrate some of the terminology.

Fig. 1: The Elements of a Form

In TUXEDO System/T, a form has one or more pages containing two types of fields: variables and literals. Portions of the page not occupied by either a literal field or a variable field are simply undefined. When the form is used for data entry, you're allowed to move the cursor only to unprotected variable fields.

Variable Fields

Variable fields are areas where data is input and/or displayed. They can be either unprotected or protected, and can have many attributes assigned to them. (There is more about attributes below, and further on in the chapter when we discuss the UFORM statements.)

Unprotected

Unprotected variable fields are those where data can be entered by the person completing the form. An unprotected field can also be used to display output.

Protected

Protected variable fields are those fields of a form that can contain variable data that cannot be changed by the user. The data in a protected field can be changed by the program that handles the form, or by the service that processes the request.

Literal Fields

Literal fields are areas of the form that are static once the form has been created. (They can be changed only by editing and re-compiling the form.) Display attributes, such as bold or reverse video, can be assigned to them just as attributes are assigned to variable fields. On most forms, a literal appears next to an unprotected field as a label or a prompt to suggest to the user what should be entered in the field. Literal fields are also used with protected fields to expand on the information displayed in the protected field. For example, if "Page __" appeared on a form, Page could be a literal; the __ would almost certainly be a protected field where the page number is displayed. (You will see later that the UFORM language has another way of specifying page numbers on a form.)

Status Line

Most forms have one line called the status line. It may be convenient to think of this as a system field, but some of the messages that are displayed there are under the control of the programmer who develops the form. By default in TUXEDO System/T the status line is the bottom line (line 24) of each page of the form. It is used for warnings, error messages or other information directed to the user.

Field Attributes

The specification of a field includes control of its display attributes. This refers to the way the field appears on the terminal. Depending on the capability of the terminal you can highlight a field, show it in reverse video, or otherwise specify its characteristics.

For variable fields, attributes also include

Validation Criteria

Another important behind-the-scenes aspect of a form, is the specification of what constitutes valid input for an unprotected field. This lets you catch errors during the data entry process and remind the user what input is acceptable.

Immediate or Deferred Validation

Not all unprotected fields need to be validated, but for fields that do you have a choice of when the validation is done; validation can take place when the user moves the cursor to another field, or it can be deferred until the entire form is complete. You can also specify globally that field validation is to be deferred until the form is complete, and select certain fields to be validated as soon as the data is entered.

Types of Validation

The TUXEDO System/T form specification language, UFORM, has a powerful assortment of tools for checking the data as it is entered into the form.

Syntactic Checking

You can specify that a field must be alphabetic, or numeric, or alphanumeric (that is, no special characters). You can say that it must match a given literal string or a regular expression. Numeric fields can be further limited to be only integers; all numeric fields can be validated as being within a specified range.

Validation Functions

For fields that need more than syntactic checking, UFORM provides the means for the form handler program, mio, to call in application-specific C functions to validate the data.

Advantage of Validating Data

All the data validation, of course, takes place before the service request is passed to an application service for processing. The alternative to using UFORM on-the-spot validation tools is to pass the data along to be validated within the application service.

Validating the data before the form is sent to the service has these advantages:

Service Name

A required part of a TUXEDO System/T form that need not appear on the screen is the name of the service to which the data is sent for processing. The service name must be included at some point before the form is sent on for processing. It provides the connection between DES client programs and services in System/T.

Form Names

File names for form source files and object files follow these conventions:

UFORM Statements

UFORM is the TUXEDO System/T form specification language. It consists of statements of the following five types:

#SERVICE
tells the system what service is used to process the data entered on this form. It is a required statement, and there can be only one per form.

#FORM
is used to define global default values for fields, to name certain application-written validation functions, to give the line number of the status line, and to start a global transaction in the client process. It is an optional statement, and there can be only one per form.

#PAGE
is used the same way as the #FORM statement, but applies only to one page of the form. If the form exceeds one page, the #PAGE statement is used to mark the beginning of a new page. For a one-page form, the #PAGE statement is optional.

Basic Descriptor
statements carry seven different pieces of information for each field of the form. This information tells what type of field it is, where it is located, how large it is, etc. One basic descriptor statement per field is required.

Extended Descriptor
statements are used to define additional properties of variable fields, such as default values, validation routines, exit choices, error or help messages, and in a menu system, what the next form is. Extended descriptor statements are always optional but vastly expand the usefulness of the form. If present, they immediately follow the basic descriptor statement for the field to which they apply.

UFORM statements describe the physical layout of a form plus all its associated attributes. When UFORM statements are compiled they constitute instructions to mio on how to handle the form. Whether you create your UFORM specifications with ed or vi, work with pic_uform or vuform, you ultimately produce a file of UFORM specifications. When you work with vuform you may be unaware of the UFORM statements for two reasons:

  1. attributes that equate to parameters from basic and extended descriptor statements in UFORM are assigned through pop-up windows in vuform.

  2. files coming out of vuform are already compiled into an executable file.

It is an interesting exercise to run an output file from vuform through the de-compiler, mcdis. You will see the UFORM statements displayed on your terminal. Appendix A contains the complete syntax of the UFORM language, with references to the analogous fields in vuform windows. The material in this chapter is just a sample, to help you get started.

Form Layout

In deciding on the physical appearance of a form, at least the following questions must be answered:

In addition to considerations of the physical layout there are other fundamental questions:

Menu Systems

Beyond the question of the requirements of an individual form is the broader question of the entire set of forms needed by an application. Is there a hierarchical relationship among the forms that suggests a menu system that offers the user a variety of selections from which to choose? UFORM provides two statements that implement such systems. They are the MENU statement and the FORMEXIT statement. Each of these two statements can be used with a individual form to specify what happens when the user enters a leave key. They can also be used to call up other forms, thus tying together a whole set of forms. See the section called ``Tying Forms Together in a Menu System'' later in this chapter for a description of how to do that.

A List Menu

The traditional list menu presents a selection of items and gives the user one field in which to enter the number or name of a selection from the list. In effect, the form says, ``Here is a list of things you can ask for. Indicate the one you want in this field.''

The UFORM MENU statement that supports this form would specify the next action based on what the user enters. It could be written to accept 1, D or d to mean the Deposit function, 2, W or w to mean Withdrawal, etc. Figure 2 shows an example. Presumably, each of the six choices might call in a different form for further data entry.

Fig. 2: A List Menu

                       TUXEDO (R) System, Release 6.1
                             Banking Application
                               1.  Deposit
                               2.  Withdrawal
                               3.  Transfer
                               4.  Balance Inquiry
                               5.  Open Account
                               6.  Close Account
                         Enter Choice, then CTRL-v: __

A Ring Menu

A ring menu is one that offers several selections through which the user can tab. Tabbing from the last field in the list brings the cursor back to the first field, which explains how this style came to be known as a ``ring'' menu. Each choice in the ring has a field that can be used as an exit point. For each exit point there can be a FORMEXIT statement. The thing that makes a ring menu so flexible is that the FORMEXIT statement associated with each exit point, like a MENU statement, can specify several destination points. Thus, the action taken on leaving the form can be controlled both by the exit field and the leave key that was pressed. The following figure illustrates this idea.

Fig. 3: A Ring Menu System

After a Form Is Compiled

Once a form has been compiled it can be handled by mio. mio is the client handler program that fetches a form requested by a user, gathers the data from the form into an FML buffer and sends it to a server for processing.

Creating a Form

This section identifies the different methods by which forms can be created in the TUXEDO System/T software. After outlining the different methods the section concentrates on a tutorial on vuform.

As noted, the TUXEDO System/T package offers three ways to create data entry forms:

  • by using any UNIX editor to create a file of UFORM statements. The UFORM statements are then compiled into a binary file referred to as a mask. The mask compiler, mc, is used for this purpose.

  • by using an editor (probably a visual editor, like vi) to draw a picture of a form, then processing the picture with pic_uform to convert it into skeletal UFORM statements. The output of pic_uform must then be edited further to produce the finished specification. The file is then compiled as above.

  • by using vuform to combine the drawing, editing and compiling into one interactive operation.

    The choice of which method to use is a matter of personal preference. Some people prefer the shorthand notation that is characteristic of the UFORM specification language, and choose to key in the UFORM statements directly. Others consider it tedious work to figure out the row and column locations of fields, and prefer using either pic_uform or vuform because those utilities calculate field locations according to your layout. vuform has the additional advantage of help messages to remind you of the details of the specification language, and provides the Attribute Mode that lets you specify field attributes on a pop-up form. We recommend you try out all three methods, and decide which works best for you.

    Creating Forms with an Editor

    This is the most direct way of producing a set of UFORM specifications. The difficult part of it is working out the location of fields using row and column numbers, and you don't get to see what the form looks like until you have compiled it.

    We will be using the OPEN form from bankapp as an example throughout this chapter. Figure 4 shows the UFORM statements for the OPEN form.

    Fig. 4: UFORM Statements for the OPEN Form

    #SERVICE NAME=OPEN_ACCT
    #FORM FLAGS=Umrv TRANMODE=TRAN TRANTIME=60
    #PAGE STATUSLINE=24   FLAGS=Pmrv
    *row	COL	MIN	LINES	WIDTH	FLAGS		VALUE
    *---	---	---	-----	-----	-----		-----
      1	 C	-	1	- 	L "TUXEDO (R) \
    						      System, Release 6.1"
      2	 C	-	1	- 	L 		"Banking Application"
      3	 C	-	1	- 	L 		"Open Account"
      6	 16	-	1	-	L		"Last Name:"
      6	 36	0	1	20	UmN7IHrv	LAST_NAME
        HELP="Enter last name"
        ERR="Last name must be letters, with hyphens or spaces"
        VAL=RE:"([A-Za-z-' ])*"
        FORMEXIT F0=FC:HELP,F11=S:OPEN_ACCT
      7	 16	-	1	-	L		"First Name:"
      7	 36	0	1	20	UmN7rv		FIRST_NAME
        HELP="Enter first name"
        ERR="First name must be letters, with hyphens or spaces"
        VAL=RE:"([A-Za-z- ])*"
        FORMEXIT F0=FC:HELP,F11=S:OPEN_ACCT
      8	 16	-	1	-	L		"Middle Initial:"
      8	 36	0	1	1	UmN7rv		MID_INIT
        HELP="Enter middle initial"
        ERR="Middle initial must be letters, with hyphens or spaces"
        VAL=RE:"[A-Za-z ]"
        FORMEXIT F0=FC:HELP,F11=S:OPEN_ACCT
     10	 16	-	1	-	L		"Mailing Address:"
     10	 36	0	2	30	UmN7rv		ADDRESS
        HELP="Enter complete mailing address: # street city state zip"
        FORMEXIT F0=FC:HELP,F11=S:OPEN_ACCT
     13	 16	-	1	-	L		"Telephone Number:"
     13	 36	0	1	12	UmN7rv		PHONE
        VAL=RE:"[2-9][0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9][0-9]"
        HELP="Enter telephone number where you can best be reached"
        ERR="Telephone number must be in form nnn-nnn-nnnn"
        FORMEXIT F0=FC:HELP,F11=S:OPEN_ACCT
     15	 16	-	1	-	L		"Account Type:"
     15	 36	0	1	1	UuN7rv		ACCT_TYPE
        VAL=RE:"[CScs]"
        HELP="Enter account type (use CTRL-w to view defaults)"
        ERR="Account type must be 'S' for savings or 'C' for checking"
        DFLT=STRING:"C" "S"
        FORMEXIT F0=FC:HELP,F11=S:OPEN_ACCT
     15	 40	-	1	-	L		"C=checking, S=savings"
     16	 16	-	1	-	L		"Desired Branch Id:"
     16	 36	0	1	2	UmN7rv		BRANCH_ID
        VAL=IR:[1-99]
        HELP="Enter numeric id of home branch for account"
        ERR="Branch id must be integer from 1 to 99"
        FORMEXIT F0=FC:HELP,F11=S:OPEN_ACCT
     16	 40	-	1	-	L		"(See Branch Codes Below)"
     17	 16	-	1	-	L		"Initial Balance:"
     17	 36	0	1	7	UmN7rv		SAMT
        VAL=NR:[0.01-99999.99]
        HELP="Enter amount of initial deposit"
        ERR="Initial deposit must be between $0.01 and $99999.99"
        FORMEXIT F0=FC:HELP,F11=S:OPEN_ACCT
     19	  C	-	1	- L "Hit CTRL-v to complete transaction"
     20	  C	-	1	- L "or ESC 0 for mio keystroke help"
     22	  3	-	1	-	L		"1 San Francisco"
     23	  3	-	1	-	L		"2 Los Angeles"
     22	 21	-	1	-	L		"3 Dallas"
     23	 21	-	1	-	L		"4 Chicago"
     22	 35	-	1	-	L		"5 St. Louis"
     23	 35	-	1	-	L		"6 Atlanta"
     22	 50	-	1	-	L		"7 Miami"
     23	 50	-	1	-	L		"8 Philadelphia"
     22	 67	-	1	-	L		" 9 New York"
     23	 67	-	1	-	L		"10 Boston"
    

    Here are some hints on how to enter UFORM statements:

    • Lines beginning with an asterisk ( * ), such as

      
      *row  COL...
      
      in Figure 4 above, are comment lines. They are ignored by the form compiler, but as you can see from the figure, they can be used to provide column headings.
    • UFORM parameters are positionally significant and are separated by white space (that is, tabs or blanks).

    • If a parameter is not furnished, a dash must be entered to preserve the positional relationship.

    • The size of a literal field is determined by the string supplied for the VALUE parameter.

    • The VALUE for a literal field is the literal string; it must be enclosed in quotation marks.

    • The VALUE for a variable field is its FML field name.

    • MIN means the minimum number of characters that must be entered in this field. Specifying a MIN parameter for an unprotected variable field makes it a required field. MIN has no meaning for a protected variable field or a literal.

    • The FLAGS parameter is used to assign attributes to a field. The range of FLAGS values and their defaults are shown in Figure 5. They are explained in detail in Appendix A.

    Fig. 5: UFORM Attribute Flag Values

    ATTRIBUTE FLAG EXPLANATION
    TYPE L literal field
    U unprotected field
    P protected field
    CASE u all data converted to upper case
    l all data converted to lower case
    m* data not converted (mixed case)
    DISPLAY FEATURES S secret field, never displayed
    N* display field.
    0* normal mode (A_NORMAL)
    1 standout mode (A_STANDOUT)
    2 inverse video (A_REVERSE)
    3 bold (A_BOLD)
    4 dim (A_DIM)
    5 blink (A_BLINK)
    6 --------- (A_INVIS)
    7 underline (A_UNDERLINE)
    8 --------- (A_PROTECT)
    9 --------- (A_ALTCHARSET)
    INITIAL I initial cursor position
    HOME H the home field. The mio home field function key, CTRL-t, moves the cursor to this field.
    RESTRICTED R The cursor can be moved to this field, but keyboard input is not accepted. The field may be modified only with the display default function key. This option has no effect on a protected field.
    r or unspecified* If unprotected, the field is unrestricted. All keyboard input is accepted. This option has no effect on a protected field.
    FIELD-BY-FIELD VALIDATION V If a validation function is specified, the field is validated as the cursor leaves the field. Applies only to an unprotected field.
    v or unspecified* Validation, if specified, is performed at exit from the form. Applies only to an unprotected field.

    NOTE: * The default if nothing is specified.

    Using pic_uform

    pic_uform is a utility that takes some of the drudgery out of entering UFORM statements. Its use is best described by an example. If you key into a file a picture of the form shown in Figure 6, and use the file as input to pic_uform, you end up with the output file of skeletal UFORM statements shown in Figure 6.

    Fig. 6: The OPEN Form as Input to pic_uform

                          TUXEDO (R) System, Release 6.1
                                 Banking Application
                                     Open Account
                   Last Name:          +___________________
                   First Name:         +___________________
                   Middle Initial:     +
                   Mailing Address:    _____________________________
                                       +_____________________________
                   Telephone Number:   +___________
                   Account Type:       +   C=checking, S=savings
                   Desired Branch Id:  +_  (See Branch Codes Below)
                   Initial Balance:    +______
                          Hit CTRL-v to complete transaction
                           or ESC 0 for mio keystroke help
      1 San Francisco   3 Dallas      5 St. Louis    7 Miami           9 New York
      2 Los Angeles     4 Chicago     6 Atlanta      8 Philadelphia   10 Boston
    

    The plus sign in Figure 6 is pic_uform default syntax for the start of a variable field and is the value of lastchar as described on the pic_uform(1) manual page. If a field entry requires additional lines, as does the Mailing Address: field, the lastchar character marks the beginning of the last line only of a multi-line field, and the beginning of all the other lines is marked by the firstchar character. The default firstchar character is the equal sign, but since the equal sign is being used as a literal in one of the fields (S=savings), the firstchar value has been changed to the ampersand sign (). This is done by specifying the new value on the pic_uform command line as the argument to the -f option. Refer to the pic_uform(1) manual page for complete details.

    Using the file in Figure 6 as input, the following command produces the output file shown in Figure 7:

    
    pic_uform -f"&"  < open > open.m
    

    Fig. 7: The OPEN Form Translated by pic_uform

    
    #SERVICE NAME=NULL
    #FORM STATUSLINE=24 FLAGS="-"
    #PAGE FLAGS="-" STATUSLINE=24
    *row	COL	MIN	LINES	WIDTH	FLAGS	VALUE
    1	18	0	1	44	L \
        "TUXEDO (R) System, Release 6.1"
    +1	30	0	1	19	L	"Banking Application"
    +1	34	0	1	12	L	"Open Account"
    +3	16	0	1	10	L	"Last Name:"
    -	36	0	1	20	U
    +1	16	0	1	11	L	"First Name:"
    -	36	0	1	20	U
    +1	16	0	1	15	L	"Middle Initial:"
    -	36	0	1	1	U
    +2	16	0	1	16	L	"Mailing Address:"
    -	36	0	2	30	U
    +3	16	0	1	17	L	"Telephone Number:"
    -	36	0	1	12	U
    +2	16	0	1	13	L	"Account Type:"
    -	36	0	1	1	U
    -	40	0	1	21	L	"C=checking, S=savings"
    +1	16	0	1	18	L	"Desired Branch Id:"
    -	36	0	1	2	U
    -	40	0	1	24	L	"(See Branch Codes Below)"
    +1	16	0	1	16	L	"Initial Balance:"
    -	36	0	1	7	U
    +2	23	0	1	34	L	"Hit CTRL-v to complete transaction"
    +1	24	0	1	31	L	"or ESC 0 for mio keystroke help"
    +2	3	0	1	75	L \
    "1 San Francisco   3 Dallas      5 St. Louis    7 Miami           9 New York"
    +1	3	0	1	73	L \
    "2 Los Angeles     4 Chicago     6 Atlanta      8 Philadelphia   10 Boston"
    

    Note that in the previous example the value fields for the first and last two rows of the form have the newline suppressed and are continued on the next line. pic_uform does not do this for you. This was done to have the figure fit on the page. However, the syntax of suppressing the newline is correct and may be used when editing a form.

    You have to edit the pic_uform output file to add

    • the service name to the NAME parameter of the #SERVICE statement

    • the transaction parameters of the #FORM statement (transaction parameters are further discussed in the vuform tutorial that follows and in Appendix A)

    • the FML names for the variable fields

    • any UFORM extended descriptor statements that are needed

    However, pic_uform allows you to lay the form out visually instead of having to figure out the row and column numbers for the fields.

    Creating a Form with vuform

    vuform is a full-screen editor with the look and feel of vi that can be used to lay out a form, complete the detailed UFORM specifications and compile the form all in one session. Chapter 3 contains a tutorial on its use.

    Creating a Menu System

    The discussion of specifying menu systems is divided into two parts:

    • a description of TUXEDO System/T MENU and FORMEXIT extended descriptor statements. That immediately follows this brief introduction.

    • a tutorial that shows the steps to follow in developing a menu system. The tutorial is contained in Chapter 3.

    MENU and FORMEXIT Statements

    The UFORM MENU and FORMEXIT statements have strong similarities and a couple of differences. The syntax for the two can be summarized as follows:

    
    Type      Argument
    --------  --------------------------------------------------
    FORMEXIT  key1=option:suboption, key2=option:suboption ...
    MENU      value1=option:suboption, value2=option:suboption ...
    

    Similarities Between MENU and FORMEXIT Statements

    The options and suboptions for MENU and FORMEXIT statements are identical. Both types of specifications have these four options:

    1.
    A - Action Suboptions specify any of a number of form management actions similar to those available through mio keystrokes
    
    Suboption       Explanation
    -------------  ----------------------------------------
    A               Abort current form
    C               Clear form buffer, redisplay defaults
    E               Exit mio
    N               Go to next page
    P               Go to previous page
    PF              Print form
    R               Redraw screen
    S               Escape to shell
    T               Go to the top level form
    
    2.
    C - Command A temporary exit from the form to invoke a shell command. The shell command is specified as a suboption.
    3.
    F - Form Change to the form named in the suboption; the F option has three variations
    
    Option Suboption    Explanation
    ------- ----------  ------------------------------------
      F     Form name  Switch to form at same hierarchy level
      FC    Form name  Bring up form as child of current form
      FT    Form name  Bring up form as child of initial form
    
    4.
    S - Service Send the contents of the form to the service named in the suboption; the S option has three variations similar to the F option
    
    Option  Suboption    Explanation
    ------- ----------  -----------------------------------------
      S    Service name   Send to service
      SC   Service name   Send to service, display response in a
                          form brought up as child of current form
      ST   Service name   Send to service, display response in a
                          form brought up as child of initial form
    

    Use of the Asterisk to Match Any Input

    Both types of menu-implementing statements support the use of the asterisk ( * ) to match any key or value input by the user. Arguments are evaluated left to right; evaluation ends as soon as a match is found. The most common use for the *, therefore, is as the last entry following a list of acceptable values, where it should generate an error message.

    Use of the At-sign to Pass the Field Value as an Argument

    Both types of statements support the use of the at-sign (@) with the C, F and S options to substitute the value entered in the associated field as a suboption.

    Including the Statements in the UFORM Specification

    Both are UFORM extended descriptor statements. In a form specification created with an editor or through pic_uform a MENU or FORMEXIT statement immediately follows the field with which it is associated. If the form is created with vuform, they are specified on Page 3 of the Variable Field Parameters pop-up form.

    Differences Between MENU and FORMEXIT Statements

    The two statements are different in that

    • MENU statements look for a match between the value entered in the menu field and a list of literal values specified in the statement. The MENU statement does not evaluate the leave key.

    • FORMEXIT statements look for a match between the leave key used to exit the form and a list of leave key values specified in the statement. The FORMEXIT statement does not evaluate the value of the field.

    A form can have both MENU and FORMEXIT statements. One restriction: the same field cannot be both a MENU field and a FORMEXIT field. Another restriction: there can be only one MENU statement in a form.

    After the Form Is Developed

    Once you have developed forms, and possibly written MENU or FORMEXIT statements to tie forms together into a menu system, you are almost ready to test them out. This section takes you through the final steps.

    Compiling Masks

    After UFORM statements have been edited, they are compiled into a binary format used by mio. vuform incorporates the compile step, but when you choose an alternate method, the mc command is used for compiling. The syntax of the mc command is:

    
    mc [ -m ] [ -r rows ] [ -c cols ] files
    
    The options have the following meanings:

    -m
    suppresses the use of the m4(1) preprocessor. This eliminates error messages that would result from the use of m4 macro names in the form.

    -r rows
    specifies the number of rows on the terminal that uses the mask. The default is 24 rows.

    -c cols
    specifies the number of columns on the terminal that uses the mask. The default is 80 columns.

    files
    names the UFORM source files to be processed. Input file names must have a .m suffix. mc uses input file names for output files, but changes the suffix to .M.

    The mcdis command is used to disassemble .M files produced by mc or by vuform .

    Setting the MASKPATH Variable

    Compiled forms (masks) are stored as files in the UNIX file system. So mio can find them, the directory name(s) are listed in the environment variable MASKPATH, and MASKPATH is exported. The format for the name list in MASKPATH is like that used for the UNIX variable, PATH; that is, a colon-separated list of pathnames. It is unlike PATH in that substitution fields of the form %character can be used for directory names in the path list. For applications accessed by users using several different languages, System/T allows application developers to produce multiple versions of masks, which are stored in language-related directories. The specific mask that is accessed is controlled by the substitution fields. The following table shows valid substitution fields.

    MASKPATH Substitution Fields
    %L The current locale from the LANG variable.
    %% A single % character.
    (The following substitutables are valid, but their use is not fully implemented in the current release.)
    %l The language element from the current LC_MESSAGES locale.
    %t The territory element from the current LC_MESSAGES locale.
    %c The codeset element from the current LC_MESSAGES locale.

    The recommended directory in which to store application masks is directory mask below the message catalog directory for your language. Here is an example:

    
    MASKPATH=:${TUXDIR}/locale/%L/mask:${TUXDIR}/locale/%L/bankmasks
    
    This means that mio will retrieve masks according to the setting of the LANG variable. These environment variables should be set in the ENVFILE for your machine by the System/T administrator.

    Loading the Mask Cache

    So that frequently-used forms can be available quickly in a production environment they can be loaded into a shared memory cache. The loadfiles command is used to do this.

    Here is an example:

    
    loadfiles -k${MSKIPCKEY} OPEN.M
    
    where MSKIPCKEY is a variable that contains the IPC key of the shared memory cache for masks. The value for the IPC key may not be the same as the IPC key specified for the bulletin board shared memory or for the TUXEDO System/D shared memory; in a word, it must be unique. This environment variable should be set and exported by mio users when masks have been stored in a mask cache. This feature should only be used by application where all users use the same locale.

    Note: Use of the Internationalization feature of TUXEDO System/T is documented in the TUXEDO OEM Guide.