From RWKatMIT-MC  Sun May 24 00:00:00 1981
From: RWKatMIT-MC (Robert W. Kerns)
Date: 24 May 1981, 00:00
Subject: H19
Message-ID: <mailman.597.1479821114.4695.its@nocrew.org>

    Moon at MIT-AI 05/24/81 01:37:31 Re: H19
Subject: H19
    To: rwk at MIT-MC
	kmp,bil at MIT-MC (Sent by BIL at MIT-MC) 05/23/81 21:56:03
	To: (BUG ITS) at MIT-MC
	Recently, all the H19's on the 8th floor have been dying on ^S^Q problems
	with insertline/deleteline. These used to work. The change happened maybe
	a week ago? Can it be fixed back or what's up?
	-kmp
    
    Bob, do you know anything about this?  I suppose ITS's idea of the
    padding got broken somehow?

No, Kent is just wrong about it having ever worked at 9600 baud.  There
is some bug in the changes I made for padding H19's with nulls, and I
haven't gotten around to debugging it yet.  In the meantime, use -%TOLID
at 9600 baud.  I suppose :TCTYP should know this.


From BIL at MIT-MC  Sat May 23 00:00:00 1981
From: BIL at MIT-MC (BIL at MIT-MC)
Date: 23 May 1981 00:00
Subject: No subject
Message-ID: <mailman.598.1479821114.4695.its@nocrew.org>

Recently, all the H19's on the 8th floor have been dying on ^S^Q problems
with insertline/deleteline. These used to work. The change happened maybe
a week ago? Can it be fixed back or what's up?
-kmp


From MOONatMIT-MC  Sat May 23 00:00:00 1981
From: MOONatMIT-MC (David A. Moon)
Date: 23 May 1981, 00:00
Subject: Chaos connections to Dover losing
Message-ID: <mailman.599.1479821114.4695.its@nocrew.org>

    Date: 23 May 1981 1255-EDT
    From: J. Noel Chiappa <JNC at MIT-XX>

    	Something about the latest change in the AI-IO-11 broke
    connections from XX to the Dover.
Actually, those work just fine.  But the DOVERSEND program has a private
Chaosnet server on MC, which I didn't know about it, that it uses to find
out the state of the MC dover spooler and of spruce, which hadn't been
converted and also failed to report back its errors properly.  It's fixed
now.

From JNCatMIT-XX  Sat May 23 00:00:00 1981
From: JNCatMIT-XX (J. Noel Chiappa)
Date: 23 May 1981, 00:00
Subject: Chaos connections to Dover losing
Message-ID: <mailman.600.1479821114.4695.its@nocrew.org>

	Something about the latest change in the AI-IO-11 broke
connections from XX to the Dover.
-------

From MOON at MIT-MC  Thu May 21 00:00:00 1981
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 21 May 1981 00:00
Subject: Bug fixed
Message-ID: <mailman.601.1479821114.4695.its@nocrew.org>

That bug where network servers show up as logged in and looping forever
trying to log in again is a bug in the LOGIN system call introduced by
RWK a few months back and fixed in the source (ITS 1218).

From MMcMatMIT-AI  Wed May 20 00:00:00 1981
From: MMcMatMIT-AI (Mike McMahon)
Date: 20 May 1981, 00:00
Subject: Lisp machine gets "file system fucked" trying to read directory from ML:
Message-ID: <mailman.602.1479821114.4695.its@nocrew.org>

    MOON at MIT-MC 05/20/81 17:17:41 Re:  Lisp machine gets "file system fucked" trying to read directory from ML:
Subject:  Lisp machine gets "file system fucked" trying to read directory from ML:
    There must also be a bug in the Lisp machine, that it dies so foully
    when it gets back an ISE0 error from a DIRECTORY operation (the real
    error is a CHNL NOT OPEN IOC error from the SIOT that is slurping in
    the MFD, but the error string reported by the file job says ISE0 for
    some reason, and has what the Lisp machine thinks is the wrong
    transaction ID.)
This failing SIOT symbolic call appears not to set the error code as
asked, so you still get ISE0, although it doesn't bomb out the file
system any more. 
    
    Date: 23 MAR 1981 0139-EST
    From: MMCM at MIT-AI (Mike McMahon)
    When you specify a non-existent directory to the DIRECTORY command,
    you don't get an error until interrupt time.  Probably it should
    fill the first buffer at process level before returning to the
    user.
This now properly gives an error via an asynch mark, however it would
still be better if it would happen sooner.



From EAKatMIT-MC  Wed May 20 00:00:00 1981
From: EAKatMIT-MC (Earl A. Killian)
Date: 20 May 1981, 00:00
Subject: [KREEN: Babyl Rave]
Message-ID: <mailman.603.1479821114.4695.its@nocrew.org>

My first guess is that Babyl is eliminating MIT-DM from the
header, except that MIT-DMS is what really occurs in the header,
and so a "S" is left.  This is the result of having DM be the
only ITS machine whose official arpanet host name is not
"MIT-" concatenated with what it returns as its machine name.
Sigh.  I supposed a special conditional is the only way to win.


From MOON at MIT-MC  Wed May 20 00:00:00 1981
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 20 May 1981 00:00
Subject: Lisp machine gets "file system fucked" trying to read directory from ML:
Message-ID: <mailman.604.1479821114.4695.its@nocrew.org>

This is caused by a bug in ITS, such that SIOT does not work properly
when reading a binary directory.  MLSLV notices the bug while most
other programs do not, since it tries to read past the end of the
directory.  The bug is fixed in the source (ITS 1216); as a byproduct
the operation will be much faster.  I guess I (or someone) should
install this system on ML soon.  (The Chaosnet is currently broken in
the source, but ML doesn't have a Chaosnet, and only hosts without a
Chaosnet cause the original symptom of the complaint from the Lisp
machine.)

There must also be a bug in the Lisp machine, that it dies so foully
when it gets back an ISE0 error from a DIRECTORY operation (the real
error is a CHNL NOT OPEN IOC error from the SIOT that is slurping in
the MFD, but the error string reported by the file job says ISE0 for
some reason, and has what the Lisp machine thinks is the wrong
transaction ID.)

From RWKatMIT-MC  Wed May 20 00:00:00 1981
From: RWKatMIT-MC (Robert W. Kerns)
Date: 20 May 1981, 00:00
Subject: No subject
Message-ID: <mailman.605.1479821114.4695.its@nocrew.org>

    Date: 19 MAY 1981 2044-EDT
    From: EAK at MIT-MC (Earl A. Killian)
    To: (BUG DDT) at MIT-MC
    
    Perhaps :REAP FOO should work even if FOO is on an unmounted pack?
    Does ITS provide the ability to do this (ie. open a directory
    entry)?

ITS dooesn't have a way to do this, although it does have bit 1.5
mean just the right thing in the case of links.  Maybe the right
thing is to make this bit work for non-links too?


From TAA  Tue May 19 00:00:00 1981
From: TAA (Timothy A. Anderson)
Date: 19 May 1981, 00:00
Subject: BUG => its
Message-ID: <[MIT-DMS].198181>

ITS 1214 seems to work much better with CFHPI+11 changed from
PUSH P,C ? HRLI C,2200 to HRLI C,2200 ? PUSH P,C.  The former
causes UCPRL to be called with just an address, rather than a
byte pointer, and crashes almost immediately.
	-taa


From KLOTZ at MIT-MC  Mon May 18 00:00:00 1981
From: KLOTZ at MIT-MC (KLOTZ at MIT-MC)
Date: 18 May 1981 00:00
Subject: No subject
Message-ID: <mailman.606.1479821114.4695.its@nocrew.org>

I just got a chnl not open error when trying to write a
file to the ai device from here.  I got some other error
before, which emacs was able to handle, but it cleared
the screen before I saw it.  Attempting to save it again
got the channel not open error.
It might have been directory full.


From MOON at MIT-MC  Sun May 17 00:00:00 1981
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 17 May 1981 00:00
Subject: No subject
Message-ID: <mailman.607.1479821114.4695.its@nocrew.org>

The AI: device is broken such that trying to write a file when
there is zero free space on any pack causes the slave simply to .logout,
causing an ioc error on the other end (with no error message, just
channel not open) and no dead slave job lying around.  Maybe this isn't
a new bug, I don't know.

From GSB at MIT-ML  Sun May 17 00:00:00 1981
From: GSB at MIT-ML (GSB at MIT-ML)
Date: 17 May 1981 00:00
Subject: record time
Message-ID: <mailman.608.1479821114.4695.its@nocrew.org>

MC's record time seems to be 7 months, 23 days, etc.

From MOON at MIT-MC  Sat May 16 00:00:00 1981
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 16 May 1981 00:00
Subject: No subject
Message-ID: <mailman.609.1479821114.4695.its@nocrew.org>

The smoke alarm and the temperature alarm behind MC just triggered,
neither of them for any discernible reason.  By the time I was able
to go and look at all the detectors, none of them had their light lit.
So if the building burns down later this morning, you can blame me.

From MOON at MIT-MC  Thu May 14 00:00:00 1981
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 14 May 1981 00:00
Subject: No subject
Message-ID: <mailman.610.1479821114.4695.its@nocrew.org>

        Date: 13 May 1981 23:25-EDT
        From: Earl A. Killian <EAK at MIT-MC>
        To: RWK at MIT-MC
        
        Isn't it supposed to say PACK NOT MOUNTED instead of undefined
        device?

    It does for SECOND:, because knowledge of that pack was wired in before
    the more general scheme was adopted.
Not true.  SECOND is treated the same as the other named packs.

I have fixed the job device handler SYS:ATSIGN DEVICE to return pack
not mounted instead of no such device when an OPEN on a known disk
pack name gets to it.

From RWKatMIT-MC  Thu May 14 00:00:00 1981
From: RWKatMIT-MC (Robert W. Kerns)
Date: 14 May 1981, 00:00
Subject: NO SUCH DEVICE
Message-ID: <mailman.611.1479821114.4695.its@nocrew.org>

Here's a good reason to know the names of all the disks even when not
online:

    COMSAT at MIT-AI 05/14/81 00:47:43 Re: Msg of Thursday, 14 May 1981 00:43-EDT
Subject: Msg of Thursday, 14 May 1981 00:43-EDT
    To: RWK at MIT-MC
    FAILED: (FILE [THIRD:NIS;*SYS MAIL]) at MIT-AI; Couldn't write message to file;
	    "THIRD:NIS;*SYS MAIL" - NO SUCH DEVICE
     Failed message follows:
    -------


From RWKatMIT-MC  Wed May 13 00:00:00 1981
From: RWKatMIT-MC (Robert W. Kerns)
Date: 13 May 1981, 00:00
Subject: No subject
Message-ID: <mailman.612.1479821114.4695.its@nocrew.org>

    Date: 13 May 1981 23:25-EDT
    From: Earl A. Killian <EAK at MIT-MC>
    To: RWK at MIT-MC
    
    Isn't it supposed to say PACK NOT MOUNTED instead of undefined
    device?

It does for SECOND:, because knowledge of that pack was wired in before
the more general scheme was adopted.  THIRD:, FOURTH:, VISION:, etc. are
known from the name stored in the TUT on the disk, so ITS doesn't know
anything about the pack at all if it's not mounted.  Maybe this info
wants to be included in the CONFIG file as well.


From RWKatMIT-MC  Wed May 13 00:00:00 1981
From: RWKatMIT-MC (Robert W. Kerns)
Date: 13 May 1981, 00:00
Subject: No subject
Message-ID: <mailman.613.1479821114.4695.its@nocrew.org>

    Date: 13 May 1981 17:37-EDT
    From: Charles Rich <RICH at MIT-AI>
    To: BUG-ITS at MIT-AI
    
    What happened to device THIRD:, it now says undefined device.
    Also I can't write to PK14: either now. (SECOND: still works).

If only you'd noticed the message when you logged in that the
disk drive was down....  I guess it would be a help if people
would also send a message to *AI when this happens, since it is
very easy to overlook SYSTEM MAIL when you log in.


From RICHatMIT-AI  Wed May 13 00:00:00 1981
From: RICHatMIT-AI (Charles Rich)
Date: 13 May 1981, 00:00
Subject: No subject
Message-ID: <mailman.614.1479821114.4695.its@nocrew.org>

What happened to device THIRD:, it now says undefined device.
Also I can't write to PK14: either now. (SECOND: still works).

From CBFatMIT-MC  Sun May 10 00:00:00 1981
From: CBFatMIT-MC (Charles Frankston)
Date: 10 May 1981, 00:00
Subject: [RGF: DM2500]
Message-ID: <mailman.615.1479821114.4695.its@nocrew.org>

    Date: 3 May 1981 00:12-EDT
    From: Frank J. Wancho <FJW at MIT-MC>
        RGF at MIT-MC

    Ok, I suppose the distinction is that since my DM3025A also responds
    to DM2500 codes and that I use :TCTYP DM SCROLL, everything works just
    fine for me.  But, when another tries to emulate a DM2500 and uses the
    same :TCTYP command (effectively), it doesn't scroll except when using
    CRTSTY???  -- I claim again that :TCTYP does it right and the
    documentation in KSC;DM2500 DOC must be either misleading or
    incomplete... or not properly implemented in RGF's emulation or some
    combination...

I explained the problem in detail.  The documentation in KSC;DM2500 DOC is
correct for a real Datamedia.  Your DM3025A does not work the same way.
You like the way it works better, great, tell your friend to make
his work that way.  I don't see what you expect us to do, go around the
country with a soldering iron fixing Datamedias?


From DCP at MIT-MC  Sun May 10 00:00:00 1981
From: DCP at MIT-MC (DCP at MIT-MC)
Date: 10 May 1981 00:00
Subject: No subject
Message-ID: <mailman.616.1479821114.4695.its@nocrew.org>

Is there a good reason why %PIATY (interrupt word 1, LH bit 4000)
is NOT documented in MC:.INFO.;ITS INTRUP. I think I understand
it well enough to document it, but I would prefer someone who
knows precisely what it does to document it. 

Also, what about all the other bits in the Left Half? Are they
real ntterupts, or just unused bits?


From GJC at MIT-MC  Sat May  9 00:00:00 1981
From: GJC at MIT-MC (GJC at MIT-MC)
Date: 09 May 1981 00:00
Subject: No subject
Message-ID: <mailman.617.1479821114.4695.its@nocrew.org>

I saw a GUMBY JOB.07 SYS with an MPV had been trying to read AR1:USERS2;ELDEFS
could be that his archive is messed up and he doesn't know it?



From RWK at MIT-MC  Fri May  8 00:00:00 1981
From: RWK at MIT-MC (RWK at MIT-MC)
Date: 08 May 1981 00:00
Subject: Recent problems with archives and EMACS libraries
Message-ID: <mailman.618.1479821114.4695.its@nocrew.org>

These were due to the wrong port being enabled on the ARM-10 (the port
for the DL10 wasn't on).  This has been rectified.

This affected mapping of pages from THIRD: and FOURTH: into memory.  Read-only
pages were not damaged, read/write pages were written back as zero.

*  If you had EMACS libraries that stopped working, they should work now.
*  If you had a program residing on THIRD: or FOURTH: that stopped working,
   it should work now.
*  If you had an archive that stopped working, it is now unusable.  You should
   send a request to FILE-RETRIEVE requesting that it be recovered from tape.
   (Be sure to include the filename!).

We are sorry for any inconvenience.


From KRONJatMIT-MC  Fri May  8 00:00:00 1981
From: KRONJatMIT-MC (David Eppstein)
Date: 8 May 1981, 00:00
Subject: No subject
Message-ID: <mailman.619.1479821114.4695.its@nocrew.org>

I have been getting a lot of "DEVICE FULL" errors lately when trying
to read files from archives.


From RLB at MIT-MC  Thu May  7 00:00:00 1981
From: RLB at MIT-MC (RLB at MIT-MC)
Date: 07 May 1981 00:00
Subject: No subject
Message-ID: <mailman.620.1479821114.4695.its@nocrew.org>

Supposing that the recent ARC device lossage had causes related to the
Emacs lossage KMP etc have noted, I copied DEVICE;DEVICE ARC to MC from AI.
Just before doing so, I $0L'd DEVICE;.FILE. (DIR) and after the copy I
$0Y'd it to DEVICE;.FILE? (DIR)
I don't want to risk trashing MY archives finding out whether the copy
fixed anything, though.


From MMCM at MIT-MC  Thu May  7 00:00:00 1981
From: MMCM at MIT-MC (MMCM at MIT-MC)
Date: 07 May 1981 00:00
Subject: more file lossage
Message-ID: <mailman.621.1479821114.4695.its@nocrew.org>

My EMACS init file, which has not changed in about a year, got broken today.
I renamed the old one to MMCM;MMCM BROKEN, which still gets a LIB error when
you try to load it, and copied over one from AI, which now loads successfully.
The two files are identical, at least when you compare them they are.


From LPH at MIT-MC  Thu May  7 00:00:00 1981
From: LPH at MIT-MC (LPH at MIT-MC)
Date: 07 May 1981 00:00
Subject: No subject
Message-ID: <mailman.622.1479821114.4695.its@nocrew.org>

the archive device is rather messed up.
i get all sorts of trash appearing in the wasted words and in the number of
blocks in files. some of my archives get UNRECOGNIZABLE file errors when
i try to list them; though i can use emacs to visit the archive itself,
the individual files can't be listed correctly at ddt...

From GJC at MIT-MC  Thu May  7 00:00:00 1981
From: GJC at MIT-MC (GJC at MIT-MC)
Date: 07 May 1981 00:00
Subject: No subject
Message-ID: <mailman.623.1479821115.4695.its@nocrew.org>

The archive devices on MC are going down in flames the
last few days, resulting in files being forever locked, etc.


From KMP at MIT-MC  Wed May  6 00:00:00 1981
From: KMP at MIT-MC (KMP at MIT-MC)
Date: 06 May 1981 00:00
Subject: No subject
Message-ID: <mailman.624.1479821115.4695.its@nocrew.org>

Today I noticed several unusual effects which affected Emacs, but which I 
attribute to ITS or hardware lossage.

A dumped Emacs which I had and for which no files it depended on had changed
suddenly stopped working.

Doing M-X Load LibraryVT52 loaded the SAFETY library for half the afternoon
in any version of Emacs. ECC and I both looked at this and were kinda confused.
:PRINT showed EMACS;VT52 :EJ was really not the SAFETY library, so something
was off.

Later I was going to show EB how M-X Load LibraryVT52 was losing, but it said
that the file was not in library format. This is wierd because it had still not
been altered (since March, 1980).

I just renamed EMACS;VT52 :EJ to EMACS;VT52 O:EJ and copied in 
EMACS;VT52 :EJ and suddenly my dumped Emacs is working again.
M-X Load LibraryVT52 is now working also. A binary comparison of these files
(I opened them in fixnum mode in lisp and did a word-by-word comparison) shows
that they are identical and doing M-X Load LibraryEMACS;VT52 O:EJ now wins.

I am wondering what kind of lossage could have caused this problem. Any
ideas? Maybe the directory was somehow inconsistent?

-kmp


From FJWatMIT-MC  Sun May  3 00:00:00 1981
From: FJWatMIT-MC (Frank J. Wancho)
Date: 3 May 1981, 00:00
Subject: [RGF: DM2500]
Message-ID: <mailman.625.1479821115.4695.its@nocrew.org>

Ok, I suppose the distinction is that since my DM3025A also responds
to DM2500 codes and that I use :TCTYP DM SCROLL, everything works just
fine for me.  But, when another tries to emulate a DM2500 and uses the
same :TCTYP command (effectively), it doesn't scroll except when using
CRTSTY???  -- I claim again that :TCTYP does it right and the
documentation in KSC;DM2500 DOC must be either misleading or
incomplete... or not properly implemented in RGF's emulation or some
combination...

--Frank


From CBF at MIT-MC  Sat May  2 00:00:00 1981
From: CBF at MIT-MC (CBF at MIT-MC)
Date: 02 May 1981 00:00
Subject: [RGF: DM2500]
Message-ID: <mailman.626.1479821115.4695.its@nocrew.org>

Unfortunately, a real Datamedia will very easily drop out of roll mode.
Exiting Insert/Delete mode (^X) will also exit roll mode.  On some
models apparently a Master Reset command (^_) will also exit roll mode.

In order to actually use Datamedia hardware scroll features it would be
necessary to always follow each of these commands with an enter roll mode.
This would probably work for TCTYP support.  The reason CRTSTY does not
use this method is because it allows the use of all 80 columns on the
terminal (if a terminal autowraps the way a Datamedia does, you cannot use
the last column with TCTYP support).  If the terminal were to operate in
roll mode all the time, but the ITS user had asked for wrap mode (the
default, as opposed to scroll mode), and were to output a character in the
last column of the last line, the terminal would auto-newline and scroll
irretrievably losing the top line of the screen before CRTSTY could do
anything to compensate.  In fact there would be no way CRTSTY could safely
put a character in that position, short of temporarily exiting roll mode.
I guess it seemed easier to implement scrolling with delete line.


From MOON at MIT-MC  Sat May  2 00:00:00 1981
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 02 May 1981 00:00
Subject: [RGF: DM2500]
Message-ID: <mailman.627.1479821115.4695.its@nocrew.org>

I forgot to say in my previous message that by default ITS will never scroll
but will always wrap around at the bottom of the screen.  If you would prefer
scrolling say :TCTYP SCROLL and then output from most programs will be scrolled.

From MOON at MIT-MC  Sat May  2 00:00:00 1981
From: MOON at MIT-MC (MOON at MIT-MC)
Date: 02 May 1981 00:00
Subject: [RGF: DM2500]
Message-ID: <mailman.628.1479821115.4695.its@nocrew.org>

ITS sends ^M ^J ^W when it wants to go to the next line, which should
scroll if given on the bottom line.  Real datamedias ignore the ^J in this
circumstance, but ITS sends it anyway for the benefit of some simulated
datamedias.  ^W is erase-to-end-of-line of course.

Maybe CRTSTY doesn't send the ^J?

ITS assumes that roll mode is on and that you have set the line length short
enough that the hopeless auto-nl misfeature does not get invoked.  The :tctyp
command does both of these I believe.  You should not implement auto-nl and
not implement lack of roll mode.  What you should do is handle ^M by going
to start of same line, ^J by going down a line and scrolling if that would take
you off the bottom of the screen, both of these unconditionally.  That will
work with ITS but perhaps not with some other programs such as CRTSTY and
WAITS that claim to know about datamedias.  It will also work with TECO
on Tenex and TOPS-20.

From RWKatMIT-MC  Fri May  1 00:00:00 1981
From: RWKatMIT-MC (Robert W. Kerns)
Date: 1 May 1981, 00:00
Subject: mail files
Message-ID: <mailman.629.1479821115.4695.its@nocrew.org>

    Date: 30 Apr 1981 2249-EDT
    From: ALA <METHODS-TOOLS at DEC-MARLBORO>
    To: bug-its at MIT-AI
    cc: richardson.alyson at KL2137
    Reply-to: dp at MIT-ML
    Subject: mail files
    Message-ID: <MS"5(1631)"11724421306.18.515.41914 at DEC-MARLBORO>
    
    My mail file on mit-ai (users0;ala mail) seems to be locked. Can
    someone look into this?
    
    Thanks.
    
	    Alyson
	    (ala at mit-ai)
       --------

This means one of two things.  One is that it may have already been
deleted, but not yet removed from the directory because someone is
reading it (such as RMAIL).  The other possibility, which isn't likely
in this case, is that the file is still being written, or is being
appended to.


From FJWatMIT-MC  Fri May  1 00:00:00 1981
From: FJWatMIT-MC (Frank J. Wancho)
Date: 1 May 1981, 00:00
Subject: [RGF: DM2500]
Message-ID: <mailman.630.1479821115.4695.its@nocrew.org>

Ron is using the documentation found in KSC;DM2500 DOC and GZ's DM2500
emulation code for use on a TRS-80 to emulate a DM2500 on his micro
and it seems that there is a difference in how a DM2500 is scrolled
using TCTYP vs CRTSTY.  (Now, I know there is, but my terminal
emulates a DM2500 too, and I don't use CRTSTY, and it scrolls alright
for me.)  Is there a difference between the description of a DM2500 in
that file and the ITS implementation as far as how scrolling is
handled?  The reason I ask is that I disagree with Ron and believe
that the way ITS does is right and CRTSTY does it awkwardly (nad takes
up an unnecessary job slot in the process.  --Frank
--------------------

Date: 05/01/81 01:34:12
From: RGF
Re:   DM2500

  Frank, I still have problems with the DM2500 when I'm not using
CRTSTY.  The only time I can get a screen scroll is when I'm in
CRTSTY, and it does a scroll by going to top line and issuing a
delete, then going back to bottom line.  Is it possible to have
the "natural" DM2500 (whatever *that* is) do this?
====================