| Title: | *OLD* ALL-IN-1 (tm) Support Conference |
| Notice: | Closed - See Note 4331.l to move to IOSG::ALL-IN-1 |
| Moderator: | IOSG::PYE |
| Created: | Thu Jan 30 1992 |
| Last Modified: | Tue Jan 23 1996 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4343 |
| Total number of notes: | 18308 |
Hi,
ALL-IN-1 v2.4 (could not look to see if any patches installed, but
I cannot reproduce with/without patches on our system!)
A user changed his Keyboard Mapping field in SWC to
BRITISH_LK201-AA, which was originally blank. The Language field is set to
British. Since the user has done this, every time they type GOLD H in the
word processor, the process hangs. I have seen this problem before and
found it can be solved in one of two ways;
1) Setting $keyboard_1="USA_LK201"
$keyboard_2="USA_VT100"
2) Delete username.pst and run ALL-IN-1 again.
Unfortunately, this does not work in the customer's case. After
changing the users keyboard mapping , he found that $keyboard_1 was set to
WPSPLUS_201_BE KEYBOARD B
When he sets $keyboard_1="USA_LK201", it resolves the problem
while the user is in that ALL-IN-1 session, but as soon as they exit and
return to ALL-IN-1, they get the old problem back.
I am going to dial-in, so that I can get some more clues on the
problem, but I wondered if anyone else has seen this before??
Thanks
Julie
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 167.1 | OA$KEYBOARDS maps different data set? | CESARE::EIJS | All in 1 Piece | Wed Mar 04 1992 17:33 | 27 |
Hi Julie,
Is this a multi-lingual system, meaning is British seconf language?
The value of the symbol looks to me that OA$KEYBOARDS is mapping a
OA$DATA_SHARE:OA$KEYBOARDS.DAT of a different format. I'm not too good
at patches, and I don't know if one of the K60* ones handled these.
If not, you can do the following:
In case of a multi-lingual environment, check if OA$KEYBOARDS FRM
BRITISH (CM key) has the same layout/field order/etc as OA$KEYBOARDS
FRM <other language>. If not, adjust the form.
In case of a single language system, you probably best of creating a
new data set and fill it with the keyboard entries:
$ ALLIN1/USER=MANAGER
<DUMP OA$KEYBOARDS
<CREATE OA$KEYBOARDS
<DO OA$KEYBOARD_PREPOP.SCP
EXIT
HTH,
Simon
| |||||
| 167.2 | KERNEL::OTHENJ | Tue Mar 10 1992 16:41 | 10 | ||
Hello,
I have finally managed to dial-in; the customer had a
oa$keyboards.dat dated 23-sep-1989 (bit old for 2.4!!!), which had a
fxied record length of 160 byte records, whereas our version has 192
byte records, which seems to explain why the value of oa$keyboards_1 is
so strange. The customer is <create oa$keyboards which should correct
the problem, so thanks for the pointer.
Julie
| |||||