Ryan & Vint Associates
514 E. 4th St.
Santa Ana, CA 92701
(714)835-3073
AM1000/L bugs and suggestions-
This list was started long after bugs were first encountered, so it's by no
means all the bugs I've run into. I have sent the list to AM.
1. DEL deletes from memory any module that is marked as permanent. EXIT
deletes any modules not marked as permanent. The memory locked flag is
reported by MAP (undocumented feature), but is effectively deleted by DEL or
the exit after DEL (if not also marked as permanent). This is contrary to
page 3-6 of AMOS/L MONITOR CALLS MANUAL. A temporary fix is to patch
location 26 from 077002 to 077020 and location 34 from 063430 to 063030.
This causes DEL, as well as other non-permanent modules, to be listed on
the terminal and deleted, but spares locked modules. A better fix requires
reassembly, or several jumps. While you're at it, how about defining a
F.LOK option switch for FETCH? Also, LOGOFF deletes all memory modules, but
I consider this a desirable feature. Quite probably, the optimal disposition
of locked memory modules is application dependent. A LOGOFF switch perhaps?
2. FILNAM monitor call doesn't return with Z bit cleared if no filename
was found. Also, the default extension is optional, which isn't mentioned
in the manual. If no extension is given, and if no file name is supplied,
FILNAM exits to AMOS.
3. COPY=xxx.LIT[1,4] from OPR: gives error message ?Attempt to copy file
to itself without PACK switch, or some such. Default lookups while in OPR:
find SYS: files also. Speaking of COPY, what is the /X switch - ie
COPY /X=dsk:filnam.ext[nn,nn] is valid, but does it predelete the file or
what? Anybody know? By the way, the /PACK option of copy is not available
on the 1000/L. Can't pack sequential files without transfering to and from
another device.
4. The DELMEM monitor call doesn't seem to do anything. The code on page
3-9 of the AMOS/L MONITOR CALLS MANUAL, copied exactly into a program,
doesn't delete anything until the program exits. As it was being used
to clean up memory between AMOS monitor calls, it just didn't work.
Later - found out if the actual module size instead of the dummy size
used in the example, DELMEM does work.
5. Wrote a program to repeat other AMOS commands, after expanding one
argument using DIR with wildcards. Works fine unless the program to be
run (the argument passed to the AMOS call) is a .DO file. The AMOS call
doesn't recognize command files, so DO.LIT must be explicitly invoked.
Then, when multiple AMOS calls are made invoking command files they are
stacked rather than executed imediately. When all calls have been made, the
last call is executed first, and the first is executed last. Sleeping
between calls doesn't help. This may be a problem, in that memory can run
out before all calls are made.
6. If something is printed (a CRLF, TTYL, or OUTL call) prior to an AMOS call
the calling program MUST be sure to wait until the typing is finished
before calling AMOS or the system crashes. There is no call to check on
whether or not typing is finished, so a SLEEP must be done which wastes time.
7. Can't seem to get DSIZE to work properly, but if I use the equivalent
code (LWORD nnnn) the program does work. Tried several variations without
success. How about an example of correct usage?
8. A number of programs are missing from the first release of AMOS for the
1000/L. Most will presumably be available as soon as converted, such as
EDIT, LISP, PDL, etc. Others must already have been converted but are
missing anyway. For example, TRMSER and FILSER are referenced in the monitor
calls as being supplied in text form, but aren't. It would be very
convienient if the sources to the .UNV files were supplied as well. I
examined TRM.UNV and prepared a tentative .HLV file giving mnemonic
definitions in the terminal definition block, locations and sizes. In some
cases the descriptions are only guesses, but they may still be of assistance
to someone, as they are to me.
9. VUE - SBLK TRUE doesn't seem to actually restrict searches to the selected
region. A minor inconvienence.
10. The documentation on expanded TAB functions doesn't mention that the
number of the function is used as a table offset in the terminal driver. If,
as the BASIC manual suggests, new features are added starting at 100 (64.),
then the driver should be modified both at the table itself and in the table
lookup routine. For example, see the listing of TEL925.M68 below, compared
to the parent source TABDEF.M68.
In addition, it is to the benefit of all AM users if standard expanded
TAB functions are assigned to the more common functions supported by most
popular current terminals. While the actual numbers are unimportant,
consistency is. Thus I should like to donate the driver I use for the
Televideo 925. I have added the expanded function definitions to HLP:TCRT.HLV
too - listing is included. Also including the driver I use for the 910.
11. Be careful using the new TASK manager to avoid using the :T or similar
commands. While they are valid in normal command files, they bomb TSKINI when
used in a "B xxxxx.INI" line during task setup. One very nice feature of the
new TASKer, used with CRT610/F, is the ability to type out VCRSTS.LST while
the certification is still in progress without affecting anything.
12. The :P (partial keyboard entry) mode is still available on the 1000/L as
it has been on the 100 and 100/T - and is still undocumented. How about a
couple of lines in a manual somewhere for the benefit of new AM users?
13. Some assembly language subroutines to BASIC work perfectly well when
called from a COMPILed program, and when pre-LOADed before calling from
BASIC, but crash the system (RUN light off, no other symptoms) when the
BASIC interpreter must load the subroutine before execution. They do
modify A4 and A5, and I suspect this may have something to do with it but I
haven't narrowed it down yet. FIX doesn't help, as the program always
works properly when the subroutine has been preloaded by FIX. Perhaps BASIC
isn't updating A4 to point past the module it loads it, so that temporary
storage allocated at (A4) by the subroutine is actually overlaid on the
BASIC subroutine?
14. The standard system library subroutine $GTARG requires A4 to be left as
BASIC used it as well as the registers in the documentation.
15. The AM-1000 manual (and the Integrated Systems Manual (section II) with
respect to the 100/L) describe the cable as connecting pins 5,6 & 8 at the
printer (TI810) to cumputer pin 6. Pin 5 is required on the 1000/L for a
TI810 printer cable. Appendix D of the AM-1000 manual, page D-5, figure D-1
is correct but the text isn't.
16. FIX disassembles "CMPW 0(A3)[D1]" correctly, but then shows an extra
instruction "MOVB D0,D4" where there is none in the source text.
Single stepping through the code skips this spurious instruction.
17. Effective addresses are not always computed correctly by FIX. For
example, VIEW ll(An)[Dm] shows the same EA, and memory is displayed from,
(An) alone.
18. Equates defined using .OFDEF are not included in the symbol table even
when the /E switch is used. On the other hand, some equates are used as
labels (which they aren't) while some labels don't appear at all. The labels
do appear as the destination in BR instructions, and are valid search
arguments, so they must actually be in the symbol table. In one instance I
noted that the 1st equate of the program is used in place of the 1st label
of the program - the 1st and second labels do not appear in FIX. Removing
the /E switch from LNKLIT or SYMLIT makes the labels appear properly in FIX.
19. FIX incorrectly disassembles "CMP Dn,<ea>" to "CMP <ea>,Dn", which is
not even a valid assembler directive. <ea> was nnn(An).
21. The BASIC function LEN no longer works the way it does under AMOS 4.6.
Previously, LEN appeared to return the number of bytes before the first 0
(or null) byte, or else the length of the mapped string variable, whichever
was shorter. You could overlay a string variable with a binary variable
(using "@"), and a subroutine could distinguish which form the data was in
- string or binary - by the difference in the length of the mapped string
variable returned by LEN. This permitted you to overlay a B,4 variable and
a string (or to overlay both the string and binary variable on the same
unformatted variable) and then distinguish, in a general purpose
subroutine, whether a date had been set in binary format (via =DATE) or was
in string format (MMDDYY) by using LEN. If string, the LEN is 6 and if
binary the length is 3.
In this release, LEN works differently. It appears (unfortunately)
smarter. The LEN of a mapped string variable overlaid with binary and
unformatted variables in interpreted according to the data type last used
to write to the variable. If it common storage area was last set to a
binary variable, LEN (of the overlaid STRING) returns the lenght of the
string formed from the conversion of the binary variable to ascii, not the
number of bytes in the binary variable. If the last storage was via an equate
to an unformatted variable, the full mapped length of the unformatted variable
is returned. These are the same results expected had the argument of LEN
been a binary and unformatted variable respectively, rather than the overlaid
string variable. The BASIC subroutines which worked in 4.6 no longer work.
22. Control S in VUE within a few lines of the top of the file place the
line on which the cursor had been at the top of the screen rather than the
center. This may be a feature, so that the operation is not redundant with
home. If so, it should be noted in the manual.
23. FIXTRM seems to make the assumption that TTYL @A2 updates A2 to point
to the terminating null byte of the string to be output. In order to
actually get a wait on a driver for the Televideo 925, I had to replace
CMPB 1(A2),#200 with 2$:CMPB (A2)+,#0 ; BNE 2$ ; CMPB (A2),#200.
I didn't use FIX to verify that TTYL didn't update A2, but the above code
strongly indicates it. By the way, the sleep time required for that
terminal to clear to spaces is about 050. (030. is too short).
24. There is a bug in COMPIL which only occurs when line numbers are not
used. When a string variable is initialized at compile time, the adjacent
(next) string variable is also affected. The length of the second string, as
passed to an assembly language subroutine, is incorrect.
25. When exiting VUE with a "Quit", the system terminal buffers are not
always reset properly. Anything else typed at AMOS level just rings the bell
to indicate buffer full. You must clear the buffer with a ^U or ^C. If you
attempt to examine the buffer with ^R, a large memory dump to the terminal
begins and the terminal will no longer respond to ^C. On a single user
system rebooting is then the only solution.
26. When VCRRES determines during reading the tape table of contents that
there isn't room for the restore on the specified disk, it aborts the
operation. It does not clean up directory entries it has alrady made
however. Thus a number (perhaps a large number) of incorrect directory
entries persist. DSKANA shows no errors (surprisingly). The files must be
hand erased. This poses no problem if the transfer was into a clean account,
but may if the account contains a mix of good and bad directory entries.
The error message occurs after the table of contents has been read, while it
is listing files on the terminal:
?Cannot allocate random file DSKn:filnam.ext - device full
?Job aborted
?No files restored
Deleting 'VCRTOC.IPF'
.
27. I recently ran across a bug while using the accounting system, but I'm
not sure of the location of the bug. When attempting to automatically spool
a print file, a parity error was reported and the system halted with a status
code 9. When I rebooted using a single job .INI file instead of the two job
plus tasker and spooler INI I had been using, the problem disappeared. On
my present system I am unable to duplicate the bug. The only difference
I am aware of between the systems is that this one has 4 logical drives
while the other has only 1. Terminal drivers, the accounting programs, the
spooler itself are all identical, as is the hardware. I did find that if the
system was booted by the firmware (as when power is turned on, or the reset
button is pressed) the XCALL SPOOL from accounting reported the parity error.
Files could still be copied to the printer, but the parity error remained
consistent. If the system was booted via MONTST (same AMOSL.INI - the number
of jobs was inconsequential) then the printer worked reliably. As usual, on
another 1000/L the printer worked reliably even with a hardware boot, so the
problem doesn't apply to all 1000/Ls. Consequently, I don't know if the fix
will apply generally or not.
- Update: AM now has a patch to AMOS which fixes the problem as of 11/19/82.
I haven't seen it yet.
- Ok, I put in the patch. No more parity errors. Now the system sometimes
(but not always) hangs up in the SPOOL subroutine. Booting the system via
MONGEN rather than the reset button permits the spool to work more often, but
is now no longer completely effective. The same system on different days
will exhibit different behavior, rangeing from always failing to never
failing on two different days. The only difference was that instead of
explicitly specifying 1 copy I took the default (parameter not passed).
On another system the same hangup was observed. Waited 3 minutes, and the
terminal was released and the print file was actually spooled. Happened
several times. Booting via MONTST decreased the number of places in the
software where the problem occured, but didn't entirely prevent it.
28. There is a bug in the subroutine SERCH. If you ask for a sequential
file search on a file which is empty (that is, has no current data, just
deleted or free records), and if you ask for the search to begin with block
-1 (an error itself), no error message is generated. Later WRITEs to the
file work for the 1st record, but the second WRITE causes an illegal record
number message even though the record number is within the file. I don't
know if SERCH messes up BASIC's file pointers because the file has no data
records initially or because the search begins with an illegal record number,
but I suspect the latter.
29. The BASIC '@' function now returns dynamic floating point array status
for subscripted arrays not defined in map statements (it was an error really).
Does this basic now support dynamic arrays?
30. Subroutine PRINT has an error when generating second (and presumably
subsequent) pages. The title argument must be an even number of bytes, or
else a random (?) byte is added into the output text. Specifically, when
posting to AROPEN, the title "SALES JOURNAL" on the second page is followed
by a control A. The TI810 printer ignores this code, but an IDS printer goes
into normal from compressed print after receipt of the ^A. A temporary fix
is to add an extra space in the string definition of the BASIC source code,
and make the map count even.
31. If there is insuficient memory during phase 3 of an assembly (the cross
reference file), the system can die. The RUN light goes off and that's it.
INI.VUE file contains GO M68 %/R. With a little more memory, an "?Address
error at nnnnnn" message can be generated. With even more memory, all goes
well.
32. VCRRES doesn't always report an error when it cannot restore a file.
Several time we have noticed that when multiple accounts on a disk are
updated from tape in a single pass (ie VCRRES/H DSK0:[]=ALL:[]) some of the
files show an incorrect hashmark after the copy. The hash matches neither
the old hash nor the one on tape. If accounts are copied one at a time into
a different account containing no files to begin with, all is well. The
tapes have 20 copies, and the disks copied from and to are of the same type
(1000/Ls). Certification of the tapes shows they are acceptable. The disks
were analyzed with DSKANA before the tapes were made, with no file errors.
The number of extra copies may be reduced to 0, and the resultant hashmarks
of the restored files are the same as with 20 copies. For any given VCRRES
command line and tape, the bad hashmarks are consistent (the same files have
bad hashes, and the bad hash is the same on each tape read). When only a
single file is being restored, and it is specified by full name, no error has
ever been observed. In all cases with error, wildcarding was used
(SCNWLD.SYS is in system memory and has the correct hashmark, 363-66-774-273)
to restore multiple accounts while logged into OPR:.
The VCRRES program has the correct hashmark (026-060-401-567), as does
VCR.DVR (506-147-246-122). The problem has occurred reliably on 3 systems,
all 1000/Ls. The monitors tried, both with 2 logical devices on a winchester
drive, include 1.0(46)-2 (hash=745-741-031-650) and 1.0A(46)-2 (hash=
045-570-115-766). Patches are up through SPN 41 in each monitor.
The symptoms seem to vary depending on which disk is being restored. We had
one account from DSK1 at the beginning of one tape, followed by the
remainder of DSK0 accounts and then the rest of the DSK1 accounts. If,
while in OPR, we restored the accounts using a command line in tape
sequence order, we got a bad restore. On the other hand, if we specified
which PPNs were to be restored explicitly and in numerically ascending
order, the restore worked properly. The same trick did NOT work for DSK0.
The project numbers had to be in order, but the programmer numbers could be
given out of order and the restore would still work. Making a new tape in
strictly ascending account order did not improve the situation for DSK0.
Examination of the restored files with DUMP shows that the bad files all
share a common feature - the last N bytes are nulls. The number N varied
according to the command line used and files selected, but was constant
across files in any given restore operation. On DSK0 only it was observed
that the first file restored was correct, and then all others were incorrect.
On DSK1 all files restored were incorrect when any file was incorrect, except
of course when the file was short or otherwise had nulls at the end of each
block of the file.
It appears that the use of the /H switch is necessary to generate the
problem. If multiple files are renamed and a /NOD restore is done, the
hashmarks are correct (even with 0 extra copies). Furthermore, it seems
necessary to have generated a mismatched hashmark for some file (any file,
anywhere on the disk) prior to the tape read - ie, a VCRRES/H where no
files on disk were found to have a conflicting hashmark with the tape
directory will restore properly).
The problem can be demonstrated by (1) making a tape, with hashmarks, of SYS:,
(2) renaming a file not needed for system operation, such as RUN.LIT to
RUN.SAV, (3) logging to OPR:, and (4) typing VCRRES/H DSK0:[]=DSK0:[]. The
restored RUN.LIT then has a different hashmark than RUN.SAV (and the last
part of each block in RUN.LIT is 0).
We are now using the following work-around for the problem. Begin the
restore operation by logging to OPR and using VCRRES/H DSK0:[]=DSK0:[]. When
prompted to hit play, type control C. This erases all files with hashmarks
that differ from the one saved on the tape directory. Then rerun the
operation using VCRRES/NOD DSK0:[]=DSK0:[]. The restored files have the
correct hashmark. This was a bad problem, as we depended on the /H switch
for updating of accounts containing both files we provide as a software
house as well as end user generated files which cannot be erased prior to
updating the software.
New problem with VCRRES. On one system, we noticed that a VCRRES/H selected
181 files to be restored. When a control-C was done, followed by a VCRRES/NOD
only 177 files were selected. The operation was repeated 3 times, and the
same numbers came up each time. Unfortunately, there wasn't time to pursue
the problem further at the customer's site where the problem occurred.
33. When a device becomes full during a posting sequence in AR (posting
sales), the original file is lost (SALES.DAT). The original files should be
preserved!
34. Task manager user's manual indicates PRIORITY statement within job
initialization file is maximum at 512 and minimum at 1. The reverse seems
to be true.