RESTRICT ALL INPUT FOR CERTAIN USERS TO UPPER CASE?
ITEM: RTA000038120
******************************************************************
******************************************************************
QUESTION:
Customer wants certain users to input only upper case data, as if Caps
Lock were on all the time for those users. Is there a way to make all
input for certain users upper case? If so, will it affect system
performance?
---------- ---------- ---------- --------- ---------- ----------
A: Character mapping techniques differ depending on the type of terminal
you are using. I assumed you are using aixterms under
the AIXWindows environment. If this assumption is incorrect, please
respond with the specific term type your customer is using.
This solution involves using the xmodmap command to map keys.
The steps are as follows:
1) 'cd' to /usr/lpp/X11/defaults/xmodmap/$LANG where $LANG is your
environment variable (En_US for United States English).
2) Copy the file 'keyboard' to 'keyboard.allcaps' using the 'cp'
command.
3) Edit the keyboard.allcaps file (e.g. 'vi keyboard.allcaps').
4) Change each lower case entry in the file to upper case.
For example, change
keycode 25 = q Q NoSymbol
to
keycode 25 = Q Q NoSymbol
5) Save and exit the file.
6) Copy the /usr/lpp/X11/defaults/xinitrc file to .xinitrc
in the home directory of each user whose keys need to be mapped
if this file does not already exits in the user's directory.
7) Add the line:
xmodmap /usr/lpp/X11/defaults/xmodmap/$LANG/keyboard.allcaps
to the .xinitrc file directly under the "Start X clients" box.
This is 137 lines down in the default xinitrc file. Make sure
it is inserted before any X clients.
When the user starts Xwindows, all keys will be mapped to upper case.
This solution will not negatively affect system performance.
If this does not provide a solution, please respond with the following
information.
1) What type of terminal are the users using?
(VT100, HFT, ...)
2) Must the text actually be translated to upper case, or could
it just appear to be upper case for user output purposes?
3) If you can provide any additional information about this
customer's requirements or configuration it will be helpful
in determining the best solution.
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
The customer will be using ASCII terminals and a single hft device.
Other brands of ASCII terminals may come into the picture later.
The text entered while in the application must actually be translated
to uppercase. But we clearly do not want to translate aix commands to
uppercase. So we need to be able to turn the translation on and off.
The system is a 250 with 8-port controller, up to 8 3151s and 2
printers, running the customer's COBOL application.
---------- ---------- ---------- --------- ---------- ----------
A: Keymapping can be done with the setmaps command on the 3151 and
with the chkeymap on the HFT. Both of these commands are documented
in Infoexplorer. I will discuss keymapping for each of these
types of terminals.
IBM 3151
--------
The setmaps command maps keys according to an input file which
you must create. The input file contains lines of the following
format:
\xHexCodeOfKeyToMap:\xHexCodeofKeyToMapTo
To map 'a' to 'A' you use:
\x61:\x41
These hex codes can be determined by the following procedure:
a) Enter: cat od -x
b) Press the desired key (e.g. a) or sequence of keys and right
after press ENTER.
c) Press Ctrl-D. The "od -x" command will display the key(s) in
hexadecimal. Ignore the value "0a", which represents the ENTER
key. Write down the hexadecimal equivalents for the key(s).
d) Repeat the above steps for any key or key sequences that you
want to know the hexadecimal number for.
As stated above, 'a' is 61 and 'A' is 41. Subsequent letters
follow sequentially.
The input file must reside in the /usr/lib/nls/termmap directory.
Create a file there with the codes to map the keys from
lower case to upper case. The file must end with the .in extension.
For example, create the file 'lowertoupper.in' in the termmap
directory which contains:
\x61:\x41
\x62:\x42
\x63:\x43
and so on ....
To make the new map available for the current terminal you must:
enter the following as a root user:
setmaps -r -l lowertoupper.in
setmaps -i lowertoupper
This will put the keymappings into effect. 'setmaps -c' will clear
any mappings, however if you map your key to upper case, you
will not be able to issue this command. I suggest you also
create an input file that maps keys to back to themselves. Create
a shell script whose name is in all caps to convert the mappings
back to their original state.
HFT
---
To map keys on the HFT, create a script file with a command in the
following format for each key you wish to map.
chkeymap -kKeyBoardPosion -sb -tc -dDecimalASCIICodeOfCharacter
To map 'a' to A, use:
chkeymap -k31 -sb -tc -d97
To find all KeyBoardPostion codes, look at the chkeymap article
in InfoExplorer and the Key Postion Codes and Scan Codes for
Keyboards article under the '-k' flag documentation section.
Selecting the 101-Key Keyboard button from the Key Position Codes ...
article will give you a graphic of the keyboard layout. For
the decimal codes 'a' starts at 97 and 'A' starts at 65. Subsequent
letter codes follow sequentially.
General note: be very careful when mapping keys. If you map
a key to upper case, it may not be available to issue a command
to reverse the action. A trick to issue any key even if its
key is mapped is to 1) hold down the left Alt key, 2) type the
decimal ASCII code for the key you want on the NUMERIC KEYPAD,
and 3) release the left Alt key. This should get you out of
trouble if you make a mistake. Also, I found that if you log
out of your 3151, the setmaps is not in effect when you relog in.
So logging out of the 3151 with the control-D key combination
can also get you out of trouble if you make any mistakes.
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
The key mapping sounds like it would functionally satisfy the
requirement. What effect will it have on performance? Is each key
stroke translated, or is a map altered so that no further translation
is needed?
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
We tried this and it worked well with no noticeable performance
degradation. BUT: it translates PFkey escape sequences to uppercase
and they no longer work correctly. The 3151s PFkey escape sequences
are .a, .b, ... and the result with remapping is .A, .B, ...
Other types of terminals work okay (e.g. Wyse 50) because their
PFkey escape sequences happen to be uppercase sequences.
Is there any way to avoid the PFkeys being translated?
---------- ---------- ---------- --------- ---------- ----------
A: Each of the three commands I discussed in my previous responses
simply alter a key interpretation facility already in use by the
system. Thus, other than the processing to map the keys, no
additional load is put on the system - key mapping has no effect
on the overall system performance.
---------- ---------- ---------- --------- ---------- ----------
QUESTION:
What about the PFkey question in my last append?
---------- ---------- ---------- --------- ---------- ----------
A: I have tested your question extensively and have not found any
perfect solution. The control codes for the PF keys contain
the control codes for the lower case alphabetic characters.
I have tried putting maps for the function keys in the setmaps
input file in many different formats and the system does not
respond as you would like.
The sequence that did work was the following:
\x1b\x61:\x1b\x61\x0a
This maps the PF1 key to itself. The problem with this technique
is that an extra carriage return is entered. This may be a sufficient
work-around depending on your application's requirements.
Another solution might be to map some of the other keys on the
3151 keyboard, those that don't use lower case letters in their
control sequences, to map to the PF sequences. This really depends
on how the customer uses the keyboard.
The bottom line is that this may be a limitation of the 3151.
You may wish to submit this need for better keymapping to development
by using the HONE REQUESTS facility.
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q651459 CPDCD
Additional search words:
CASE CERTAIN CPDCD FEB94 INPUT IX LPPS OZIBM OZNEW RESTRICT RISCO
RISCSYSTEM SECURE SOFTWARE SUPT UPPER USER USERS
WWQA: ITEM: RTA000038120 ITEM: RTA000038120
Dated: 01/1995 Category: RISCO
This HTML file was generated 99/06/24~12:43:14
Comments or suggestions?
Contact us