Introduction
This chapter covers
the elements of a DES form
three different ways to create DES forms
how to create a menu system
how to compile forms into binary files called masks and store the masks in a shared memory cache.
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.
An example of a simple one-page form is shown in Figure 1
to illustrate some of the terminology.
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 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 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 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 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.)
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.
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
specifying a
minimum number of characters that the user must enter
(thus making it a required field)
designating a field as the
home field for the cursor
(that is, the field where the cursor goes when the user enters a
CTRL-t)
designating a field as the initial field
(that is, the field where the cursor is located when the
form is first displayed)
indicating whether the field accepts
input in upper or lower case, or both
specifying that a field is restricted.
(See Figure 5 or Appendix A for details.)
specifying when and if validation of the field should occur
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.
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.
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.
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.
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.
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:
It avoids the overhead of communicating bad data.
The code in
application services can be less complicated,
since assumptions about the validity of input data can be made.
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.
File names for form source files and object files
follow these conventions:
Forms created with an editor or with
pic_uform and compiled with mc:
Source files have a .m suffix, as in
form.m
Object files output by mc have a .M suffix, as in
form.M
Forms created with vuform:
The suffix is ignored on input files.
As part of vuform processing the form is compiled.
The output is an object file with
a .M suffix.
UFORM is the TUXEDO System/T form specification language.
It consists of statements of the following five types:
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:
attributes that equate to parameters from
basic and extended descriptor statements in UFORM are assigned
through pop-up windows in vuform.
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.
In deciding on the physical appearance of a form,
at least the following questions
must be answered:
How many pages does the form require?
On each page, what are the locations of the fields?
What are the dimensions of each field?
(How many columns wide, how many lines deep?)
If the field is a literal, what is the literal?
If the field is variable,
does its value come from the user or a program?
Should the field have attributes such as highlighting
or blinking?
In addition to considerations of the physical layout there are other
fundamental questions:
Is this a field in which some entry must be made; that is,
is it a required field?
Should the user input be validated?
If so, when should validation be done, and what constitutes
valid input?
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.
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.
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.
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.
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.
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.
Here are some hints on how to enter UFORM statements:
Lines beginning with an asterisk ( * ), such as
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.
NOTE: * The default if nothing is specified.
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.
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:
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.
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.
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.
The UFORM
MENU
and
FORMEXIT
statements have strong
similarities and a couple of differences.
The syntax for the two can be summarized as follows:
The options and suboptions for
MENU
and
FORMEXIT
statements
are identical.
Both types of specifications have these four options:
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.
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.
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.
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.
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.
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:
The mcdis command is used to disassemble .M files
produced by mc or by vuform .
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.
The recommended directory in which to store application masks is
directory
mask
below the message catalog directory for your language.
Here is an example:
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:
Note: Use of the Internationalization feature of TUXEDO System/T is
documented in the
References to Additional Material
The Elements of a Form
Fig. 1: The Elements of a Form
Variable Fields
Unprotected
Protected
Literal Fields
Status Line
Field Attributes
Validation Criteria
Immediate or Deferred Validation
Types of Validation
Syntactic Checking
Validation Functions
Advantage of Validating Data
Service Name
Form Names
UFORM Statements
Form Layout
Menu Systems
A List Menu
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
Fig. 3: A Ring Menu System
After a Form Is Compiled
Creating a Form
Creating Forms with an Editor
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"
*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.
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.
Using pic_uform
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
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"
Creating a Form with vuform
Creating a Menu System
MENU and FORMEXIT Statements
Type Argument
-------- --------------------------------------------------
FORMEXIT key1=option:suboption, key2=option:suboption ...
MENU value1=option:suboption, value2=option:suboption ...
Similarities Between MENU and FORMEXIT Statements
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
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
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
Use of the At-sign to Pass the Field Value as an Argument
Including the Statements in the UFORM Specification
Differences Between MENU and FORMEXIT Statements
After the Form Is Developed
Compiling Masks
mc [ -m ] [ -r rows ] [ -c cols ] files
The options have the following meanings:
Setting the MASKPATH Variable
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.
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
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.