Conference iosg::all-in-1_v30

    Well, there's a display only field (KBD_WP_MAP) on the OA$KEYBOARDS
    form, which was presumably intended to hold the name of the WPS-PLUS
    version of the files, since it's the same size as the ALL-IN-1 version
    on the previous line.
    
    The initialisation script OA$LIB:OA$KEYBOARD_PREPOP.SCP, which
    populates OA$KEYBOARDS.DAT always blanks out that field.
    
    The *WPS*.A1KMT files seem to be similar in format to the *A1*
    equivalents, although their contents are not the same.
    
    There is some code which reads the field out of OA$KEYBOARDS at image
    initialisation time, and saves it in a global symbol.
    
    There is some code in the editor initialisation, whic looks at the
    symbol, and uses it to open a file which it then reads and, for each
    line, calls @OA$LIB:KOTERMTAB to define /JOB logicals to tell WPS-PLUS
    how to do the key mapping. Only this code is never executed, since the
    file name is always blank. And anyway, the code is looking for a file
    with records which start with "KB_" or "OUTPUT_".
    
    So no, I don't know why they are there either!!
    
    Cheers,
    
    Graham
    
    	

    They're there because that mechanism (defining /JOB logicals) was the
    way that WPS-PLUS was going to get its keyboard mapping information (in
    the BEV).
    
    However, it was changed. I don't know how they actually do get their
    mapping info - perhaps you'd have to ask in the WPS-PLUS conference.
    
    D.

    Um, that still doesn't tell us what they might be used for, since
    they're not in the right format for the /JOB logical definition. They
    look more like an alternative version of the ALL-IN-1 keyboatd mapping
    files, but in the case of the one I looked at, with a lot more
    information in.
    
    Graham

    Hello,
    
    all I could remember was that there was a good reason to leave outr the
    A1KMT files in the translated version. To learn the details again, I
    asked the real experts. Next two replies are excerpts of mails from
    Georges Plattner and Andr� Plamondon about the issue. I hope that 
    clarifies a bit.
    	Stefan

    
    
    Bonjour,
    
    	The KBD_*WPS*.A1KMT was not used by ALL-IN-1/WPSPLUS.
    
    	The plan was to integrate all keyboard mapping in a commun
    	mechanisme OA$KEYBOARD.DAT file. (Some of you may remember the
    	memo from Christine Landels about keyboard setup in Amethyste)
    
    	Unfortunely, they did not really integrate them in one mechanisme.
    	The file KOTERMTAB still the mechanisme for WPSPLUS Keyboard setup.
    
    	So, these file are not mandatory...some country (as the France)
    	did them and included in Amethyste...of course they Still there 
    	in Zircon.
    
    	Whem we decided (in Frankfurt) to standardize the C components for
    	all 13 countries. We reduce the number of file at the minimun 
    	(delete these files from the C and many others files). 
    
    	Many country provide in the past a lot of empty *.A1KMT, they was
    	replaced by one EMPTY.A1KMT file. This effort was done to reduce 
    	the maintance cost.
    
    
    
    						Andre Plamondon
    
    
    	The KOTERMTAB provide by BEV is not fully correct for countries,
    	in the futur the KOTERMTAB must be part of the C component.

This is Georges Plattner, Switzerland, speaking:
    -------------------------------------------------------------------------
    

	FRENCH_WPS_LK201_*.A1KMT

 
These files are no longer in the C-Component, it's true.
1) they are not used to setup WPS-PLUS mapping. WPS-PLUS mapping is done by 
help of WPKEYBOARD.COM (which in turn calls KOTERMTAB.com) which defines the 
appropriate KOA$... logicals. WPKEYBOARD has to be run before invoking 
ALL-IN-1.
For more details how to setup keyboards see oa$data_share:A1_KB_SETUP.TEMPLATE

2) Before eliminating the *_WPS_*.A1KMT files we also tested if they have any 
effect on WPS or EDT. This is not the case. WPS and EDT have to be setup by 
help of EDTCUSTOM.EDT and WPSCUSTOM.EDT respectively if any other mapping than 
the default one in oallv.bli is requested.

To our knowledge the *_WPS_*.A1KMT files are no longer needed.



NOTE 
The keyboard setup for WPS-PLUS never worked as it was designed with the 
additional field in OA$KEYBOARDS because of some defines executed from calls in 
subprocesses. May be that a solution could be find easily. It would be great if 
this could be fixed. So the keyboard setup could be handeled with one single 
keyboard parameter instead of two.
More about this subject -> Consult Richard Bauer or Christine Landless


    
For KOTERMTAB there are two remaining problems:
 - for installations using the US language kit in combination with the French 
   C-Component
   A KOTERMTAB from any other language has to be provided.
 - from a engineering point of view a solution has to be found to have the 
   correct KOTERMTAB in all kits
It is nice to have a KOTERMTAB covering all keyboards supported by any country.

 
May be that reading the keywords SUBPROCESS and DEFINE somebody of IOSG is 
reminiscent of the difficulties encountered in relation to that problem and 
*_WPS_*.A1KMT
    

This is Andr� Plamondon, Canada, speaking:
    ----------------------------------------------------------------------
    
    
	I was there whem in Amethyste they introduce the new keyboard
	mapping. IOSG (Christine Landels) never fully integrate the 
	WPS Keyboard mapping (I believe they find problem to work with
	the WPSPLUS group) in the ALL-IN-1 mapping. Christine wrote 
	a famous memo about how to define keyboard with ALL-IN-1 V2.3.

	Most of the contry were confused and created KBD*WPS*.A1KMT
	BUT ALL-IN-1/WPSPLUS DOES NOT USED THEM. We never built these 
	keyboard mapping in Canada (France did for V2.3). 

	In Zircon (I did France and Canada C component) nothing was
	fixed we just keep the C as is.

	With DIAMOND still the same.

	THE KBD*WPS*.A1KMT are not require for DIAMOND, the KOTERMTAD
	do the job of setting the keyboard of WPSPLUS.

    
    	KOTERMTAB.COM

    	    
	    During the last days before FCS we replace the KOTERMTAB from the
	    C (were he should be) in the B because we had installation 
	    problem and no enought time to fix them.


	    The fix was to add the KOTERMTAB in the C with a 32000 version
	    number. In the working directory this file will be instead
            of the B kotermtab.