Trailing-Edge - PDP-10 Archives - BB-5543E-BB_1979 - documentation/bas2.doc
There are no other files named bas2.doc in the archive.

BASIC.DOC -- Changes from V1C(211) to V2(252)
May 1979

COPYRIGHT (C) 1977, 1979 BY



BAS2.DOC                                                          Page 2

BASIC.DOC -- Changes from V1C(211) to V2(252)
May 1979

   1.0  SUMMARY...............................................  3
   2.0  EXTERNAL CHANGES......................................  3
      2.1  INPUT, INPUT LINE, And LINPUT......................  3
      2.2  Performance Improvements...........................  4
      2.3  COMMON.............................................  4
      2.4  BASIC Initialization...............................  6
      2.5  Command Files......................................  7
         2.5.1  DO Command....................................  7
                Commands......................................  8
         2.5.3  The STATUS Command............................  8
      2.6  Compile And Run Time Reporting.....................  8
      2.7  BASIC System Version Validity Checking.............  9
      2.8  CHAINing From EXE File To EXE File.................  9
      2.9  The RUN Command....................................  9
      2.10  Memory Management Improvements....................  9
      2.11  The VAL% Function.................................  10
      2.12  New Error And Warning Messages....................  10
         2.12.1  New Command Errors...........................  10
         2.12.2  New Compiler Errors And Warnings.............  10
         2.12.3  New Run Time Errors And Warnings.............  10
   3.0  KNOWN BUGS AND DEFICIENCIES...........................  11
      3.1  BASIC Software Bugs................................  11
      3.2  BASIC Restrictions.................................  11
      3.3  Operating System Deficiencies......................  12
      3.4  BASIC Documentation Errors.........................  12
         3.4.1  Undocumented Functions........................  12
         3.4.2  CTRLC And RCTRLC..............................  13
         3.4.3  SLEEP.........................................  13
         3.4.4  ISAM files....................................  13
         3.4.5  Null Data Items...............................  14
   4.0  INSTALLATION INSTRUCTIONS.............................  15
      4.1  Files Included On This Tape........................  15
      4.2  Installation.......................................  15
      4.3  Creating A BASIC Initialization Command File.......  15
   5.0  INTERNAL CHANGES......................................  16
   6.0  SUGGESTIONS...........................................  18
      6.1  Output To Files....................................  18
      6.2  VAL% And VAL.......................................  18
      6.3  Array References...................................  18
BAS2.DOC                                                          Page 3

BASIC.DOC -- Changes from V1C(211) to V2(252)
May 1979


     BASIC-PLUS-2/20  is  a  powerful  implementation   of   the   BASIC
programming  language for the DECSYSTEM-20.  This release of the product
is a development release which includes  performance  improvements,  the
COMMON statement with "blank" COMMON preserved across a CHAIN statement,
and several other new functional enhancements.

     BASIC-PLUS-2/20 runs on a  KL-20  processor  under  release  3A  or
higher  of  the TOPS-20 monitor.  It supercedes all previous versions of
the   BASIC   language   on   the   DECSYSTEM-20.    During   execution,
BASIC-PLUS-2/20 requires the BASIC run-time system, BASOTS.EXE, which is
included on this tape.

     The external changes to BASIC-PLUS-2/20 version 2 are described  in
this  document  in  section  2.0  (BAS2.DOC).   The  presently published
documentation includes the BASIC-PLUS-2 Language Reference Manual (order
number  AA-0153A-TK)  and the BASIC-PLUS-2/20 User's Guide (order number
AA-0152A-TM).  This DOC file together  with  the  current  documentation
will  be  adequate  for  most  users  to  make  use of the new version 2
facilities.  There is a new BASIC-PLUS-2/20 manual for  TOPS-20  planned
for release this summer.


     The   sections   below   describe   the   enhancements   made    to
BASIC-PLUS-2/20  version  2.   The  BASIC-PLUS-2  documentation  will be
updated to reflect these changes.  For now, the  sections  below  should
describe  the  features  well  enough  for users to write programs using


     Due to several bugs in the product, these  statements  had  several
incorrect  side  effects  when  an  INPUT  request  from  a  file  found
insufficient data in a record to satisfy the request.  Versions prior to
version  2 would issue an error message but would automatically continue
reading the next and succeeding records  until  the  INPUT  request  was
satisfied.   This meant that what was probably a fatal user error, would
not correctly stop the program.

     Version 2 has corrected this by causing an INPUT request which  has
insufficient  data  items  in  the  current  file  record  to generate a
trapable fatal error.  The  only  exception  to  this  is  for  terminal
devices for which the user is reprompted for the missing items.  This is
provided for convenience since with a terminal device the user  has  the
opportunity to correctly input the missing items, where from a file, the
BAS2.DOC                                                          Page 4

items would be incorrectly read from the next data record.

2.2  Performance Improvements

     Version 2 of BASIC has several major performance  improvements.   A
collection  of  customer  applications were obtained as requested at the
Spring 1978 DECUS.  The  applications  were  analzyed,  and  performance
improvements were made in the following areas:

     1.  The PRINT package - Output to files  are  now  buffered  across
         PRINT statements doing fewer SOUT JSYS's.

     2.  FOR Loops now generate more efficient code when the  beginning,
         ending, and / or increment expressions are actually a constant.

     3.  Array references to an array element which has been dimensioned
         and is not in a MAP buffer or in COMMON will be 40% faster.

     4.  The string package has been improved.

     5.  There is a new function VAL% (see section  2.11)  which  is  10
         times faster than VAL.

The applications averaged a 32% percent run time performance improvement
overall  due  to  the  above  enhancements.   It  is expected that other
programs should see a similar improvement.

For some suggestions on writing faster programs, refer to section 6.0.


     The COMMON statement has the following forms:

             COM  { (name) }  variable-list
          COMMON  { (name) }  variable-list

     The COMMON statement allows the user to declare a data area  called
a  COMMON  area,  and  the  declaration  of  the variables which will be
allocated in this area.  These variables will retain their values across
a  CALL  statement,  and may be referenced in any SUB program which also
contains a COMMON statement declaring this COMMON area.   The  names  of
the variables and arrays do not need to be the same for each declaration
of the COMMON area in a particular SUB.  However, the data types of  the
variables,  and  the  type  and  dimensions  of  the  arrays  must match
positionally in each  declaration.   If  they  do  not  match  properly,
variables  will  overlay  one  another  in a fashion such that undesired
equivalencing will occur.  Version 2 of  BASIC-PLUS-2  will  not  detect
this  and  no  warning will result.  Some future version of the compiler
may issue a warning if this occurs.  The example below  shows  a  proper
BAS2.DOC                                                          Page 5

use of a COMMON area called XYZ which has three elements.

          00010 COMMON (XYZ) A,B,C
          00020 A = 1 \ B = 2 \ C = 3
          00030 CALL P
          00040 END
          00050 !
          00060 SUB P
          00070 COMMON (XYZ) X,Y,Z
          00080 PRINT X; Y; Z
          00090 SUBEND
           1  2  3

     All declarations for one COMMON area must  appear  together.   This
means  that  if several COMMON statements are used to declare one COMMON
area, then they must appear together  with  no  intervening  MAP  buffer
declarations,  a declaration for another COMMON area, or any other BASIC
statement.  For example:

     LEGAL                         ILLEGAL
     -----                         -------

     10 COMMON (FOO) A,B           10 COMMON (FOO) A,B
     20 COMMON (FOO) C             20 COMMON (BAR) Z$
     30 COMMON (BAR) Z$            30 COMMON (FOO) C

In the above example, the declaration of the COMMON  area  FOO  contains
three elements;  A, B, and C.  This declaration is equivalent to:

          00010 COMMON (FOO) A,B,C

     The variables in a COMMON area retain their  values  until  an  END
statement is executed in the MAIN program.  If a COMMON declaration does
not include a name then it is  referred  to  as  "blank"  COMMON.   This
COMMON  area,  if  declared prior to all other COMMON statements and MAP
statements, will retain all values  across  the  execution  of  a  CHAIN
statement.   If  the  above rule isn't followed, the user will receive a
warning from the compiler indicating that the "blank" COMMON  area  will
not  be  preserved.   The blank COMMON area defined by the program being
chained to must be the same size as the blank COMMON area in the program
which  contained  the CHAIN statement and must also be declared prior to
all other MAP and COMMON area declarations.  If it is  not,  or  if  the
program  being CHAINed to does not have a "blank" COMMON area, a warning
message will result at run time but execution will continue  as  always,
with all MAP and COMMON areas being initialized.

     The major advantage to the "blank" COMMON facility is  that  larger
applications can be developed and segmented into pieces which CHAIN from
one another.  In the past in  order  to  pass  data  between  two  BASIC
programs, one would have to write data to a file, perform the CHAIN, and
the program CHAINed to would read the data from the file  and  continue.
This  procedure  is very costly.  The "blank" COMMON area will allow the
BAS2.DOC                                                          Page 6

data to be passed with no overhead.

     For  COMMON  areas  between  MAIN  and  SUB   programs   subsequent
declarations of a COMMON area may be smaller than the first declaration,
but must not be any larger than the first declaration.  For example:

     MAIN PROGRAM                  SUBPROGRAM
     ---- -------                  ----------

     10 COMMON (FOO) A,B,C         100 COMMON (FOO) A1,B1,C1
     20 COMMON (FOO) D$,E$(100)    200 COMMON (FOO) D1$

Also note as stated before, the  names  of  the  corresponding  variable
names need not be the same.

     If an array is to be defined in a COMMON statement, its  dimensions
must  be  specified as in an array declaration in a DIMENSION statement,
and it may not also appear in a DIMENSION statement in that SUB or  MAIN

     String variables are fixed in  length.   The  length  of  a  string
variable  may  be  specified  in  the same manner as they are in the MAP
statement.  For example:

          00010 COMMON LINE.REC$=80%, MY.ARRAY$(5%)=10%, XX$

In the above  example,  LINE.REC$  would  have  a  fixed  length  of  80
characters,  each  element  of MY.ARRAY$ would have a fixed length of 10
characters.  If no string length is specified for a string  variable  in
COMMON,  it assumes a default length of 16 characters.  Therefore in the
above example the variable XX$ has a length of 16 characters.

     String variables in COMMON are just like string  variables  in  MAP
buffers  in  that  they are fixed in length and are always padded on the
right with blanks.

     Variables which  are  in  COMMON  must  be  declared  in  a  COMMON
statement before the first reference to that variable.

2.4  BASIC Initialization

     BASIC has several commands  which  allow  various  features  to  be
enabled or disabled, such as QUIET CHECK, which would disable the syntax
checking facility of BASIC.  Currently there is no way  for  the  system
manager  to  set  the default for these status switches.  A new facility
has been added for version 2 which allows the system manager to  set  up
the defaults for these status commands and much more.

     The system manager can create a file called BASIC.INI which must be
placed on the SYS:  area along with BASIC.EXE and BASOTS.EXE.  This file
can contain any BASIC command or immediate mode  statement  which  could
otherwise be typed to BASIC at command level.  Each time BASIC is run by
a user, the commands from this file are processed by BASIC until the end
of  the  file  is  reached or a command or run time error occurs.  BASIC
BAS2.DOC                                                          Page 7

then releases the command file and types READY.

     The prime motivation for this is that many installations have  many
users  running BASIC, which can degrade the system performance.  One way
of making BASIC put less of a load  on  the  system,  and  increase  the
interactive speed of BASIC while users enter programs, is to disable the
syntax checking faciltiy built into BASIC.  The  "QUIET  CHECK"  command
does  just  this.  Thus the system manager could create a BASIC.INI file
which contains this command, and  all  users  would  have  the  facility
turned off as the default.

     Any users who really want to have the facility, can enable  it  for
themselves by giving the command "VERBOSE CHECK".  The default for BASIC
currently is "VERBOSE CHECK".

     If no BASIC.INI file is found on device SYS:   then  BASIC  behaves
exactly as it did in previous versions of the product.

2.5  Command Files

2.5.1  DO Command - 

     Version 2 has implemented a  command  file  facility  which  allows
users  to instruct BASIC to accept commands from a file, instead of from
the users terminal.  The new command to do this is the  DO  command  and
has the following format:

          DO {  <file-specification>  }

The file specification is optional  after  the  command.   If  it's  not
specified BASIC will prompt the user.  For example:

          Command file name--PAYROLL.CMD

If no file type is specified, BASIC will assume a default of .CMD.

     Currently, a command file may contain any command or immediate mode
statement  which could otherwise be typed by the user from the terminal,
except the DO command  itself.   Therefore  command  files  may  not  be
nested.  This restriction may be removed some time in the future.

     If any error occurs while processing a command from a command file,
the command file is closed and released, the line which caused the error
is echoed to the user's terminal, the error reported, and  the  user  is
returned  to  READY  with  BASIC  accepting  commands  from  the  user's
BAS2.DOC                                                          Page 8


     The commands read from the command file can be echoed on the user's
terminal if the user gives the command VERBOSE COMMAND.  As each line is
read from the a command file, it will be echoed on the  user's  terminal
along  with  a  prompt  if  the command normally would have prompted the
user.  The default setting for this is QUIET COMMAND.

2.5.3  The STATUS Command - 

     The status command can be used to determine the current setting  of
the COMMAND switch.  For example:

          VERBOSE WARN
          MODE NODEF *

2.6  Compile And Run Time Reporting

     BASIC will now report compile time and  run  time  separatly.   The
number  reported  previously  as "RUNTIME" was actually the compile time
plus the run time.
For example:

          00010 FOR I% = 0% TO 9%
          00020   PRINT I%;
          00030 NEXT I%
          00040 PRINT
          00050 END
          Monday, January 1, 1979 16:45:00
           0  1  2  3  4  5  6  7  8  9
          Compile time: .043 secs
          Run time: .066 secs           Elapsed time: 00:00:01
The compile time is reported whenever "VERBOSE HEADER" is enabled and  a
compile  is done.  This means that the DEBUG and BUILD commands will now
report compile time and elapsed time as well.  Due to the new  behaviour
of  the  RUN  command (see section 2.9), the RUN command will not always
BAS2.DOC                                                          Page 9

report compile time since a compilation may not always be done.

2.7  BASIC System Version Validity Checking

     Version 2 of BASIC now will verify that the version of the compiler
and  OTS  (BASIC.EXE  and  BASOTS.EXE respectively) are in fact both the
same  version.   This  will  eliminate  the  possibility  of  the   user
inadvertantly  using  an  old  BASOTS.EXE with the new compiler, or vice
versa.  The user will receive a warning message, but BASIC will continue
and try to work.

     Also, if a precompiled program is run, (an EXE file), and it is not
compatible  with  this  version of the OTS, then the user will receive a
warning diagnostic which instructs the user to rebuild the program.  EXE
files  built  with  version  1A  or  1  of BASIC will cause this warning
because the data types of the LEN and FIX functions have been changed by
version 1B to return an integer and a real value respectively.  Refer to
section 2.1 in the 1B DOC file for more information.   EXE  files  built
with  version  1B or 1C will work correctly with version 2, and need not
be rebuilt.

2.8  CHAINing From EXE File To EXE File

     When BASIC CHAINs from a BASIC EXE file to another BASIC EXE  file,
and  the  program  was  run  from the EXEC and not from within the BASIC
environment, then BASOTS will change the name of program for  the  users
job to be the first six characters of the program name being CHAINed to.

2.9  The RUN Command

     The RUN command in versions prior to version 2 would always compile
the  current  program  before beginning execution.  Version 2 will first
determine if the program has changed.  If not, and if the compiled  code
is  still  valid,  it  will  begin  execution of the program immediately
without doing the unnecessary (and expensive) compile.  This may  reduce
the  system  load  in  an  environment  where users were often rerunning
programs not realizing that this involved recompilation.

2.10  Memory Management Improvements

     The free storage manager used by both the BASIC  compiler  and  the
user  program  during execution has been made more efficient by handling
stack expansion and contraction as needed.  This will allow  for  larger
programs  to  be  compiled,  and  user programs to be larger with larger
arrays possible.  The estimated increase in usable space is about 30%.
BAS2.DOC                                                         Page 10

2.11  The VAL% Function

     This function is the same  as  the  VAL  function  except  that  it
returns  an  integer value instead of a real value, and accepts a string
representing an integer number as an argument.  The function is 10 times
faster than the VAL function and so it is much better to use VAL% if the
program is dealing with integer quantities.

     Also additional precision is possible with integers and so VAL% can
be used instead of VAL, to make use of this additional precision.

2.12  New Error And Warning Messages

     The following sections describe new error messages and warnings the
user  may receive relating to the new version 2 facilites.  All existing
error messages have been converted to upper and lower case characters as

2.12.1  New Command Errors - 

? DO command illegal from within a command file

2.12.2  New Compiler Errors And Warnings - 

? Multi-statement COMMON area declaration out of order

? COMMON or MAP area previously declared in line nnnnn

? <variable-name> has been previously referenced or declared

? COMMON area declared in line nnnnn longer than specified in line nnnnn

% "Blank" COMMON area will not be preserved across a CHAIN

2.12.3  New Run Time Errors And Warnings - 

These warnings may occur at run time but are non-trappable:

% Old BASIC not compatible with this BASOTS, must use current BASIC

% EXE file not compatible with this BASOTS, program must be rebuilt

% Incompatible version of BASOTS being used, must use current version

% "Blank" COMMON area not preserved across CHAIN due to size inconsistency
BAS2.DOC                                                                 Page 11


     This section is divided into four subsections.  The  first  section
describes  the  current set of known bugs which have not yet been fixed.
The second describes known  deficiencies  in  BASIC  which  will  remain
restrictions  for  this  release.   The third section describes problems
known with TOPS-20 release 3A which affect BASIC.  The fourth  clarifies
and corrects the current documentation.

3.1  BASIC Software Bugs

     There are no unresolved known bugs at the  time  of  this  release.
The  version  2  product does however have several DDT patches which are
recommended.  These patches and the  problems  they  fix  are  described
thoroughly in the beware file BAS2.BWR contained on this tape.

3.2  BASIC Restrictions

     1.  It is not possible to continue a  BASIC  program  after  typing
         control-C  (^C).   Due  to  the  design  of  BASIC-PLUS-2, this
         behavior cannot be implemented without a major rewriting of the
         compiler.  It is not planned to implement it in the foreseeable

     2.  MAP buffers larger than 256K are not detected and will  produce
         unpredictable results.

     3.  If a record file is created on disk, and is subsequently opened
         from a BASIC program with a smaller record size, BASIC will not
         detect the error until the first operation is attempted on  the
         file.  An error will be generated at that time.

     4.  STREAM files by definition are a sequence of ASCII  characters.
         For  this  reason  it  is  not  possible to specify a MAP which
         contains numeric fields.  Currently BASIC will not  detect  the
         condition as an error, and erroneous data will result.

     5.  When an element of a virtual array which is on  a  non-existent
         page is referenced, that page is created.  This will cause

                   ?  433 Illegal memory read

         if the user has only read access to the file.

     6.  MAP statements must not appear on the same line  as  any  other
         MAP or COMMON statement.  The compiler will not flag this as an
         error but the results of using the MAP will be unpredictable.
BAS2.DOC                                                                 Page 12

3.3  Operating System Deficiencies

     1.  There are several problems with the FLIN JSYS which BASIC  uses
         to  read  all  floating  point  numbers and convert them into a
         machine representation.

         1.  The letter "D" will be accepted as a substitute for "E"  in
             the  exponent  field  of  a  floating point number.  On the
             other hand however the lower case letter "e"  will  not  be

         2.  "Nines Disease":  A single bit of  precision  is  sometimes
             lost when floating point numbers are read.  For example the
             number .55 will be represented internally as .549999  .   .

         3.  Numbers  whose  magnitude  is  greater  than  the   largest
             floating  point  number  representable in the hardware, but
             less than 10^64 will not give any error and will result  in
             the  largest  representable  floating  point  number.   For
             numbers larger than 10^64, FLIN and  therefore  BASIC  will
             give  an  error,  and  result in the largest floating point

     2.  If the terminal page  length  is  set  to  0  and  TERMINAL  NO
         INDICATE  is  set, any program which outputs a form feed to the
         terminal will cause the monitor to loop, sending  linefeeds  to
         the  user's  terminal.   This  will  be  fixed  in release 4 of

     3.  The vertical tab character  (VT)  does  not  act  as  a  record
         terminator  for record input using a GET when the input is from
         the terminal.  This will be fixed in release 4 of TOPS-20.

3.4  BASIC Documentation Errors

3.4.1  Undocumented Functions - 

     The following  functions  are  not  completely  documented  in  the
CURRENT manuals.

     1.  POS Function - The POS function has two forms:

         1.  POS(  string1,  string2,  expression  )  -  This  form   is
             documented on page 7-12 of the Language Reference Manual.

         2.  POS%(  file-expression  )  -  This  function  takes  as  an
             argument  the  channel  number  of  an open terminal format
             file, (0 for the terminal), and returns the  current  print
BAS2.DOC                                                                 Page 13


     2.  MAR% ( file-expression ) - Returns the current MARGIN width  of
         the specified terminal format file.

     3.  VPS%( file-expression ) - Returns the  current  vertical  print
         position  (current line count) of the specified terminal format

     4.  PPS%( file-expression ) - Returns the current page count of the
         specified terminal format file.

     5.  USR$ - Returns string of connected structure and directory.

     6.  LINO ( line-number ) - Expects a real (as opposed  to  integer)
         line number as an argument.  Returns that number (i.e.  LINO(3)
         returns 3%).  The advantage of using LINO instead of the actual
         number is that LINO is recognized by the resequencing operator,
         which changes the argument  to  its  corresponding  resequenced
         line  number.   This  allows the user to take full advantage of
         the ERL function.

3.4.2  CTRLC And RCTRLC - 

     The CTRLC  and  RCTRLC  functions  are  documented  backwards.   An
appropriate description of them is as follows:

CTRLC - Enable control-^C trap.  Typing ^C causes a branch to the  error
handler.  Stays in effect until a RCTRLC is executed.

RCTRLC - Disable control-^C trap.  Typing ^C returns the user  to  READY
mode.  This is the initial default.

3.4.3  SLEEP - 

     The Language Manual indicates on  page  5-13  that  a  job  may  be
awakened  from the SLEEP state by typing a line terminator.  This is not

3.4.4  ISAM files - 

     You cannot specify an array name or an array item (e.g.  A$(1))  as
a  primary  or  alternate  ISAM  key in an OPEN statement.  The language
manual does not mention this restricton.

     This restriction can be circumvented by specifying an alternate map
which contains a string scalar variable which overlays the array element
which is to be the key.  For example:
BAS2.DOC                                                                 Page 14

        10 MAP (XYZ) A$(10)=5
        20 MAP (XYZ) DUMMY1$=5, KEY$=5, DUMMY8$(8)=5

where A$(1) is to be the key.  KEY$ is the same as A$(1) and thus can be
used to specify the key in an OPEN statement.

3.4.5  Null Data Items - 

     If a null  data  item  is  encountered  when  a  numeric  value  is
expected, then no assignment will be made to the variable, and the input
will continue with the next item in the input list.  A null data item is
indicated  as  shown in the following example by from 0 to any number of
spaces or tabs, followed by a comma.

     00010      A,B,C = 1234
     00020      INPUT A,B,C
     00030      END

If this program is run, and the user types 3,,5 where the  second  input
value  is  null, no assignment will occur for variable B.  Therefore the
values of A, B, and C after the INPUT will be 3, 1234, 5 respectively.

     Note however if the null  data  item  is  found  when  expecting  a
string,  then  this  null  data item is actually the null string and the
assignment will be made to the string variable.  For example:

     00010      A$,B$,C$ = 'INITIAL'
     00020      INPUT A$,B$,C$
     00030      END

When this program is run, and the user types:

     ?  FOO,,BAR

the value of A$, B$, and C$ will be "FOO", "" (null string),  and  "BAR"

     The description of  "null  data  items"  above  is  to  provide  an
explanation of BASIC's current behavior, so that some confusion might be
avoided.  It has not been determined whether or  not  this  behavior  is
correct  or  not, and, if not, how it will change in some future version
of BASIC-PLUS-2/20.
BAS2.DOC                                                                 Page 15


4.1  Files Included On This Tape

     This tape contains two savesets which contain the following sets of


     o  BAS2.BWR        - The beware file
     o  BAS2.DOC        - This file


     o  BASIC.EXE       - The BASIC-PLUS-2/20 compiler
     o  BASOTS.EXE      - The BASIC-PLUS-2/20 run-time system

4.2  Installation

     There is a beware file containing several recommended  DDT  patches
to the product.  These are described in full in the beware file BAS2.BWR
and it should be carefully read before the BASIC product is installed.

     The .EXE files should be placed on <SUBSYS>.  BASIC will  look  for
its  run-time  system  BASOTS.EXE  on logical device SYS:, so you should
make sure  that  your  installation  has  <SUBSYS>  in  its  system-wide
definition of SYS:.

     It is recommended that  the  system  manager  make  this  DOC  file
available to all BASIC users and that they read this file.

4.3  Creating A BASIC Initialization Command File

     Version 2 of BASIC has implemented a new facility which allows  the
system  manager  to  create  a file which can contain BASIC commands and
immediate mode statements which will be processed each time a user  runs
BASIC.   The  file  must  be  called BASIC.INI and placed on device SYS:
along with BASIC.EXE and BASOTS.EXE.  Refer  also  to  section  2.2  for
additional information.

     If BASIC.INI does not exist, then  BASIC  will  behave  exactly  as
previous  versions  of  BASIC have.  This faciltiy is therefore optional
and need only be used if the system manager wishes BASIC to do something
special upon starting up.

     An example of a possible use for this  command  file  would  be  to
change  the  default  for  the  syntax  checking  feature of BASIC to be
disabled since this can cause BASIC to put a heavy load on the system if
there  are  many  BASIC users.  This can be done by creating a BASIC.INI
file which contains the command "QUIET CHECK".  If any user then  wishes
to  use  the  syntax checking feature, the user would issue the "VERBOSE
CHECK" command which would enable syntax checking just for him/her.
BAS2.DOC                                                                 Page 16


Edit                     Description
----                     -----------

212 - 214 Reserved.

215       Implemented COMMON with "blank" COMMON area preserved across a
          CHAIN statement.

216       Implemented compile time reporting separately  from  run  time

217       Implemented command files and the DO command,  and  the  BASIC
          initialization mechanism.

220       Implemented OTS, EXE file, compiler version validity checking.

221       If a CHAIN is done from an EXE file to another  EXE  file  and
          not from within the BASIC environment, then do a SETNM JSYS to
          change the program name.

222       Improve the PRINT package speed.

223       Expresssions  containing  unary  operators  are   not   always
          correctly evaluated.  For example:

                    12/-3*2 would yield -2 instead of -8

224       The command file facilty should have a QUIET and VERBOSE  mode
          which  in  VERBOSE  mode  would  echo  all commands as they're

225       None.  The READ statement would generate an extra call to  the
          OTS  READ routine if an array element was the last item on the
          I/O list.

226       Some MACRO routines are allocating too much stack storage.

227       Improve the PRINT package speed.

230       If a READ statement is called from within a  function  and  an
          array element is in the I/O list, then an internal error and /
          or incorrect results will occur.

231       If QUIET HEADER is the status while a compile or run is  done,
          and then VERBOSE HEADER is given