home *** CD-ROM | disk | FTP | other *** search
/ Liren Large Software Subsidy 5 / 05.iso / a / a524 / 38.ddi / doc / release.doc
Encoding:
Text File  |  1991-03-04  |  5.7 KB  |  131 lines

  1. ...
  2. ... $Header: release.doc,v 1000700.1 90/02/28 18:59:02 atam Exp $ release.doc Copyr (c) 1989 Oracle
  3. ...
  4.  Relase Bulletin
  5.  Oracle*Terminal Version 1.0.7 (Production)
  6.  February 26, 1990
  7.  
  8.  This bulletin contains important information about the production release of
  9.  Oracle*Terminal.  It is recommended that you read it before attemting to use
  10.  this version.
  11.  
  12.  
  13.  Documentation
  14.  -------------
  15.  Complete documentation is available with the release.  All users are advised
  16.  to obtain the most current documentation.  The Version 1.0 documentation set
  17.  consists of:
  18.  
  19.  Oracle*Terminal User's Guide V1.0 (Production)        5206-V1.0
  20.  
  21.  
  22.  Converting from CRT
  23.  -------------------
  24.  To use an old CRT definition for a given device, which is stored in the
  25.  database, and create an Oracle*Terminal readable .R (RESource) file, the 
  26.  CRTTORES conversion utility needs to be run.  The key and attribute
  27.  mappings can be then be used with the current versions of SQL*Forms 3.0
  28.  and SQL*Menu 5.0.
  29.  
  30.  Syntax:  CRTTORES device_name username/password
  31.  
  32.  e.g.  :  CRTTORES VT100 scott/tiger
  33.  
  34.  The database with which Oracle*Terminal was linked, will (and must) be the
  35.  same database from which the CRT information will be read.
  36.  
  37.  The devicename passed to CRTTORES will become the name of the .R file created
  38.  (e.g. VT100.R). This file and devicename need to be explicitly specified at 
  39.  runtime by SQL*Forms and SQL*Menu by using the -c filename:devicename option.
  40.  
  41.  A flat file, CRTOUT.TMP contains a listing of the CRT information read from
  42.  the database, for the most recent conversion. This file is intended only to
  43.  provide a means to look at the raw CRT information which CRTTORES attempts 
  44.  to map into the .R format. In case there is information that did not seem to
  45.  be used in the .R file (specifically, this may be true of attribute
  46.  information, since CRT allowed more attribute escape sequences, and only 8
  47.  could be chosen for Device Attributes in the .R file), then this
  48.  file may prove to be a valuable reference. This file would also be useful for
  49.  debugging if problems occur during the conversion, but otherwise it is not 
  50.  required, and may be deleted.
  51.  
  52.  How Keys Are Mapped
  53.  -------------------
  54.  If you review the created .R file using Oracle*Terminal, you will notice that
  55.  some compromises were made and naming conventions were used in the conversion.
  56.  These are:    
  57.  
  58.  1. An old CRT key mapping consisted of: function code, escape sequence,
  59.     function name, and a comment. The .R file uses the function name as
  60.     the 'Product Key Name', and the comment as the 'Device Key Name', and the
  61.     escape sequence to be the 'Physical Terminal Sequence' for that particular
  62.     'Device Key Name'. CRTTORES finds the equivalent new 'Product Function
  63.     Code' for each old CRT function code where possible.
  64.  
  65.     e.g.    (old):  function code   : 35
  66.                     escape sequence : \e\e[C
  67.                     function name   : Scroll Right
  68.                     comment         : Escape ->
  69.  
  70.             (new):  Function Code             : 35    
  71.                     Product Key Name          : Scroll Right
  72.                     Device Key Name           : Escape_->     
  73.                     Physical Terminal Sequence: \e\e[C
  74.  
  75.     Note that an underscore replaces any spaces in the comment.
  76.  
  77.     If comment was originally left blank, the new Device Key Name will be
  78.     named '+unnamed?' where ? is a unique number for each unnamed key. The
  79.     plus sign implies this key will not appear on a showkeys screen. 
  80.  
  81.  2. The old CRT format supported having several escape sequences associated
  82.     with a given device key. The new .R format assigns names to device keys,
  83.     and therefore each escape sequence must have a unique name associated
  84.     with it.  Thus, in cases where more than one escape sequence existed for
  85.     a given device key, a suffix is appended to the end of the original name
  86.     in order to ensure uniqueness. This suffix is 'key?', where ? is a unique
  87.     number for each new suffix as needed.
  88.     
  89.     e.g.  (old):  comment          : R12
  90.                   escape sequence  : \e[C
  91.  
  92.                   comment          : R12
  93.                   escape sequence  : \e[219z
  94.  
  95.                   comment          : R12
  96.                   escape sequence  : \e[xxx
  97.  
  98.       (new):  Device Key Name            : R12
  99.                   Physical Terminal Sequence : \e[C
  100.                   
  101.                   Device Key Name         : R12key1
  102.                   Physical Terminal Sequence : \e[219z
  103.  
  104.                   Device Key Name         : R12key2
  105.                   Physical Terminal Sequence : \e[xxx
  106.  
  107.  3. There are several new keys in the new versions of SQL*Forms and SQL*BMenu
  108.     that did not exist in the old CRT definitions.
  109.  
  110.     In the new .R file, these new Product Keys are added, along with default
  111.     mappings. The process for assigning a mapping for these new keys is as
  112.     follows:
  113.  
  114.     (i)  The keys:  [Up], [Down], [Beginning of Line], and [End of Line] will
  115.      be mapped to ^P (ctrl-P), ^N, ^A, and ^E respectively IF these keys
  116.      have not already been used by the existing set of product keys.
  117.  
  118.      Similarly:  [Cut], [Copy], and [Paste] will be mapped to Esc *X, 
  119.      Esc *V, and Esc *C respectively.
  120.  
  121.    (ii)  If the mappings above are not possible, and for all other new keys,
  122.      the control sequences ^A, ^B, ^C, etc. are tried in order.  The new
  123.      key will be mapped to the first available of these control sequences.
  124.      If no control sequences are available, then Esc *A, Esc *B, Esc *C,
  125.      etc. are tried in order.  If all the control and escape sequences have
  126.      been used, the new Product key will be mapped to a dummy string,
  127.      namely:  '+unmapped:new key'.
  128.  
  129.     Changes to these defaults and assignments of unmapped keys can be made by
  130.     editing the .R file using Oracle*Terminal.
  131.