Google
 

Trailing-Edge - PDP-10 Archives - decuslib10-10 - 43,50516/basic.bwr
There are no other files named basic.bwr in the archive.


			BASIC V1 beware file.

	The following is a summary of known deficiencies/problems in
BASIC V1 and associated system software, together with some useful
miscellaneous information and operating recommendations.


1) MACRO V53(1025) gets "? Ill mem. ref." while assembling BASDDT.MAC.
Use MACRO V52(551), which works fine.


2) In the 6.03A monitor with VMSER running on a KI there are two known
problems with GETSEGs. These will be encountered when a user with no
virtual privileges runs a BASIC program so large that, together with
BASCOM it exactly fits in CORMAX core. When it GETSEGs BASXCT, which is
3P larger than BASCOM:

Either	(a) if BASXCT is a dormant segment (usual case) the GETSEG will
be performed and the user will be allowed to exceed CORMAX. If more core
is needed for execution, the CORE UUO fails and the "? Out of room"
message will be given. There may be circumstances under which BASIC can
use a CORE UUO to reduce core to a value still greater than CORMAX,
in which case it will probably fail and HALT.

Or	(b) if BASXCT is not a dormant segment, the GETSEG will fail,
as it should, but the monitor will not return the correct error code
to the segment controller. The user will therefore receive the
"? Segment control error" message instead of the correct "? Out of
room".

	It is not known what happens in the above two cases on other
processors, under other monitors, or when the user has virtual
privileges.


3) Occasional problems have been noted with the QUEUE command under
the 6.03A monitor. The source of these problems may be the monitor or
the distribution version of QUEUER used (dated 24-Sep-75 !). The
normal symptom is that BASIC hangs in RN SW state; typing ^C twice
causes correct completion of the command.


4) Random number sequences generated by BASIC differ between the KA
and KI processors. This is due to the AOBJN at RNDB+5 in BASXCT. Since
this is original DEC code, sparsely commented and characterised by the
remark "Its algorithm is unknown", it is not certain which is correct.
Despite the fact that the code almost certainly dates from the PDP-6,
some limited tests of randomness and the apparent intention of the code
suggest that the KI may be right.


5) Despite considerable work, it is still possible to force BASIC into
monitor mode by judicious use of ^C and REPEAT ! Success depends on
what BASIC is doing and on system load. Users not wishing to do this
should be told to type ^C exactly twice and be patient, this appears
always to work.

6) Installations with former versions of BASIC (V17H(143)-1, internal
version BASX11, and earlier) will find that old BASIC .SAV files that
should exit with an error message will exit with an "? Illegal UUO"
message instead. The simplest fix is to persuade users to resave under
V1. If this is for any reason impossible, BASERR V17H(143)-1 should be
retained on SYS: under the name BASR11 and octal location l523 of the
old .SAV files should be changed from SIXBIT /BASERR/ to /BASR11/.


7) ALT MODE (or ESC or PREFIX) does not act as a break character in
BASIC teletype input (e.g. in terminating an argumentless GENERATE
command). Use <ALT MODE> <CR>.


8) There are several error messages from BASIC that may indicate system
errors. The "? System error" message occurs on a variety of fatal I/O
conditions, e.g. disk parity errors. The "? System error - please
contact computer center" message is given when a pushdown list overflow
or illegal memory reference occurs. When readily reproducible, this can
indicate an internal error in BASIC and should be reported as such, but
experience has shown that increases in the frequency of non-reproducible
occurrences of this message often presage hardware failure. The
message "? Segment control error", except in the circumstances described
under 2(b) above, indicates either hardware error in reading a segment,
monitor error, or faulty installation (e.g. incorrect name(s) of .EXE
file(s)).


9) System managers should note that careless use of ON ERROR GOTO can
easily result in programs containing infinite loops that users may be
tempted to blame on BASIC. Example:

	10 F%=1% \ INPUT "FILE: "_F$ \ GOSUB 100
	.
	.
	100 ON ERROR GOTO 130
	110 OPEN F$ FOR INPUT AS FILE #F%
	120 ON ERROR GOTO \ RETURN
	130 PRINT "FILE ";F$;" NOT FOUND" \ RESUME 10
	.
	.



			End of BASIC V1 beware file.