Google
 

Trailing-Edge - PDP-10 Archives - SRI_NIC_PERM_SRC_3_19910112 - midas/midas.bugs
There are no other files named midas.bugs in the archive.
Date: 27 September 1983 13:44 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Mailing list on OZ...
To: Ian @ MIT-OZ
cc: INFO-MIDAS @ MIT-MC

Yes, merge it (you can just point to it if you want to keep an OZ-specific
group)...

Latest version of MIDAS (not back on MC yet) fixes the various
problems with building new MIDASes.  I am currently
scanning MIDAS BUGS (archive of bug-midas mail) to see if there
are any interesting things that are easy to add before installing
it.

Date: 27 Sep 1983  03:29 EDT (Tue)
Message-ID: <[MIT-OZ].IAN.27-Sep-83 03:29:17>
From: Ian Macky <Ian@MIT-OZ>
To:   Info-MIDAS@MIT-OZ
Subject: Mailing list on OZ...

There's this list here... maybe it should be merged?  It's mostly to do
with 20-only stuff, usually OZ-only, like new packages and junk.

MIDAS-USERS=Ian Jeh ZZZ Marty *SS:<ARCHIVE>MIDAS.ARCHIVE Gumby egk GZ-OZ GS

Date: 16 September 1983 01:29 EDT
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Adventures assembling MIDAS
To: KLH @ MIT-MC
cc: BUG-MIDAS @ MIT-MC
In-reply-to: Msg of 15 Sep 1983 04:20 EDT from Ken Harrenstien <KLH>

Since you mentioned INFO-MIDAS, and since there was no such mailing list on
MC, I hunted it down in the old AI:.MAIL.;NAMES > file kept on MC:KSC; and
created it on MC.  (Yes, I did check to see that it wasn't on OZ first.)
Info-MIDAS used to be archived in AI:MIDAS;INFO MINS, a file we no longer
have.

Date: 15 September 1983 04:20 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Adventures assembling MIDAS
To: MARTY @ MIT-OZ
cc: BUG-MIDAS @ MIT-MC, ALAN @ MIT-MC, Moon @ SCRC-TENEX

Yes, the proper method of putting together a T-20 MIDAS is not
well documented.  I am now fixing that, as well as making the
purification code really work (all it is useful for on T20
is catching bugs, however).  When done the new version will
be available as usual from the canonical MC:MIDAS; location
and announced to info-midas.

Date: 31 Aug 1983  21:48 EDT (Wed)
Message-ID: <[MIT-OZ].MARTY.31-Aug-83 21:48:44>
From: Martin David Connor <MARTY@MIT-OZ>
To:   Bug-Midas@MIT-MC
Cc:   Alan@MIT-MC, Moon@SCRC-TENEX
Subject: Adventures assembling MIDAS


A funny thing happened on my way to fixing a file server...

First I consed up a TWXBTS file from UNV:MONSYM.MAC
following the instructions in SS:<SYS.SUBSYS>TWXBTS.CONSING.
Then I tried to compile, with the CVTSW off.

    [PHOTO:  Recording initiated  Wed 31-Aug-83 9:16PM]
    
    TOPS-20 Command Processor 5(742)-2
    [COMAND]
    !i j
      Job 15, User MARTY, SS:<SYS.SUBSYS>, Account AI, TTY1
    !midas midas /t
    MIDAS
    TTY: .INSRTed, end input with ^Z
    CVTSW==0
    TNXSW==1
    ^Z
    SS:<SYS.SUBSYS>TWXBTS.MID.10
    1	 0.     6-054	
    Comma past the 3rd field of a word
    1	 0.     6-054	Undefined format
    2	 0.     6-056	
    Comma past the 3rd field of a word

	....

    2	 0.     6-056	Undefined format
    3	 0.     6-081	
    Comma past the 3rd field of a word
    3	 0.     6-081	Undefined format
    4	 0.     6-083	

	....

    SS:<SYS.SUBSYS>TSRTNS.MID.194
    422644	 0.    54-032	DEFSTR	Non-macro made macro
    in DEFINE Starting at 54-025
    Pure pages = 14
    ST = 13271
    SS:<SYS.SUBSYS>TWXBTS.MID.10
    EISYM1+1725	101255	 1.     6-056	
    Garbage in ASCIZ-style macro arg
    in DEFSTR Starting at 6-054
    EISYM1+1726	101256	 1.     6-056	%%FNLC	Undefined in LOC
    101256	 0.     6-056	Stray )
    101256	 0.     6-056	Undefined format
    101325	 1.     6-083	

	.....

    Garbage in ASCIZ-style macro arg
    in DEFSTR Starting at 6-081
    101326	 0.     6-083	Stray )
    101326	 0.     6-083	Undefined format
    101331	 1.     6-090	
    Garbage in ASCIZ-style macro arg
	.....

    ^C
    !;sigh.
    !pop
    
    [PHOTO:  Recording terminated  Wed 31-Aug-83 9:19PM]

My, my, someone call a priest.

Then I found the program CVT which I used to conse up a TNXDFS.MID
file:

    [PHOTO:  Recording initiated  Wed 31-Aug-83 9:20PM]
    
    TOPS-20 Command Processor 5(742)-2
    [COMAND]
    !i j
    Job 15, User MARTY, SS:<SYS.SUBSYS>, Account AI, TTY1
    !midas midas /t
    MIDAS
    TTY: .INSRTed, end input with ^Z
    CVTSW==1
    TNXSW==1
    ^Z
    Pure pages = 14
    ST = 13271
    22206 words initialization coding.
    MINPUR-MAXMAC = 7
    MIDAS
    Constants area inclusive
    From	To
    423146	426002
    76453	76532
    Run time = 1:07.57
    7094 Symbols including initial ones (70% used)
    
Well, it assembles, let's try purifying it.

    !v midas
    SS:<SYS.SUBSYS>
    MIDAS.CONSING.1;P777752    1 1173(7)    31-Aug-83 20:20:37 MARTY     
    .DIF.1;P777752           1 2284(7)    31-Aug-83 02:14:09 MARTY     
    .EXE.1;P777752          68 34699(36)  31-Aug-83 21:20:28 MARTY     
    .MID.433;P777752       127 64841(36)   5-Apr-83 18:16:05 IAN       
    .435;P777752        127 324202(7)  31-Aug-83 02:20:18 MARTY     
    
    Total of 324 pages in 5 files

    !get midas.exe.1
    !start purify
    ?Illegal instruction 256006,,0 at 417757
    ?Invalid access requested

Can't fool me, just barfed trying to do a SPACS call on a page that
wasn't yours.

    !continue
    Purified, now SAVE

Yes sir!

    !save midas
    MIDAS.EXE.2 Saved
    !v midas.exe
    
    SS:<SYS.SUBSYS>
    MIDAS.EXE.1;P777752       68 34699(36)  31-Aug-83 21:20:28 MARTY     
         .2;P777752           47 24064(36)  31-Aug-83 21:27:14 MARTY     
    
    Total of 115 pages in 2 files
    !get midas.exe.2
    !i mem
    
    46. pages, Entry vector loc 420074 len 254000
    
    Section 0	R, W, E,  Private
    0-3	 MIDAS.EXE.2  1-4   R, CW, E
    76-120	 MIDAS.EXE.2  5-27   R, CW, E
    400-426	 MIDAS.EXE.2  30-56   R, E

    !;looks good, but will it assemble?

    !midas ss:<sys.system>file
    FILE JOB FOR TOPS-20
    (OZ's munched on version)
    NETWRK.MID included in this assembly.
    FILE JOB FOR TOPS-20
    (OZ's munched on version)
    NETWRK.MID included in this assembly.
    END OF IMPURE=2770
    START OF PURE=3000
    END OF PURE=15570
    FIRST BUFFER LOC=22000
    Constants area inclusive
    From	To
    13740	15567
    Run time = 9.74
    5639 Symbols including initial ones (71% used)
    !;works fine.
    !pop
    
    [PHOTO:  Recording terminated  Wed 31-Aug-83 9:29PM]

Now, I said all that to say that for my money MACCNV (or the
instructions on how to use it) are broken, because the TWXBTS file that
it generates is not assemblable.

Perhaps someone would like to look into this.  CVT seems to do fine.
Maybe there is no need.


Date: 31 Aug 1983  02:52 EDT (Wed)
Message-ID: <[MIT-OZ].MARTY.31-Aug-83 02:52:18>
From: Martin David Connor <MARTY@MIT-OZ>
To:   David A. Moon <Moon@SCRC-TENEX>
Cc:   bug-file@MIT-OZ, BUG-LISPM@MIT-OZ, bug-midas@MIT-OZ,
      Ken Haase <KwH@MIT-OZ>, bug-system@MIT-OZ
Subject: Options needed on file write.
In-reply-to: Msg of 30 Aug 1983 15:09-EDT from David A. Moon <Moon at SCRC-TENEX>

    Date: Tuesday, 30 August 1983, 15:09-EDT
    From: David A. Moon <Moon at SCRC-TENEX>
    To:   Ken Haase <KwH>
    cc:   BUG-LISPM, bug-file, bug-midas
    Re:   Options needed on file write.
    Received: from SCRC-QUABBIN by SCRC-TENEX with CHAOS;
              Tue 30-Aug-83 15:15:01-EDT

        Date: Tuesday, 30 August 1983, 14:38-EDT
        From: Ken Haase <KwH@MIT-OZ>
        In Release 4.4, Experimental LMRLL 11.0, FEP 12,
	 site configuration 58, on Lisp Machine Janis Joplin:

        This should offer to run DIRED or CLEAN Directory.

        >>Error: File system bug on host MIT-OZ:
        Disk structure completely full (at 6021 inside FILE server)
        For OZ:PS:<KWH.RLL>RLL.LISP

    It would have if the Lisp machine had known that this error meant
    "disk structure completely full".  As you can see, it says "File
    system bug."  I've reported this at least once before: the bug is
    that MIDAS is broken on OZ; it assembles the wrong system error
    codes into the FILE server.  I don't remember now the exact error
    code that is wrong (or, more likely, undefined).  Someone at OZ
    should fix MIDAS and reassemble SS:<SYS.SYSTEM>FILE.MID and start
    the resulting binary at PURIFY, which will dump it into
     SYSTEM:CHAOS.FILE.

Fixed. The file server should now know all about IOX34 (Disk structure
completely full).

Fixing MIDAS was a pain.

The TWXBTS file on OZ seems to be missing some things.  I ended up
getting the TNXBTS file from XX, and SRCCOMing XX's version of MIDAS
with OZ's.  What we have now is a MIDAS that is basically a TENEX
version, but it seems to have everything defined properly.

Also, starting MIDAS PURIFY barfs it when it tries to set the page
access of a the core image (did I say CORE), but if CONTINUED it seems
to win.  There is a pure version now on PS:<SUBSYS>.

If anybody *really* knows how to assemble a TOPS-20 version of MIDAS
that uses TWXBTS, please spill your guts.  MACCNV sort of works, but
what it produced would not compile properly.


Received: from SCRC-QUABBIN by SCRC-TENEX with CHAOS; Tue 30-Aug-83 15:15:01-EDT
Date: Tuesday, 30 August 1983, 15:09-EDT
From: David A. Moon <Moon@SCRC-TENEX>
Subject: Options needed on file write.
To: Ken Haase <KwH@MIT-OZ>
Cc: BUG-LISPM@MIT-OZ, bug-file@MIT-OZ, bug-midas@MIT-OZ
In-reply-to: The message of 30 Aug 83 14:38-EDT from Ken Haase <KwH at OZ>

    Date: Tuesday, 30 August 1983, 14:38-EDT
    From: Ken Haase <KwH@MIT-OZ>
    In Release 4.4, Experimental LMRLL 11.0, FEP 12, site configuration 58, on Lisp Machine Janis Joplin:

    This should offer to run DIRED or CLEAN Directory.

    >>Error: File system bug on host MIT-OZ:
    Disk structure completely full (at 6021 inside FILE server)
    For OZ:PS:<KWH.RLL>RLL.LISP

It would have if the Lisp machine had known that this error meant "disk structure
completely full".  As you can see, it says "File system bug."  I've reported this
at least once before: the bug is that MIDAS is broken on OZ; it assembles the
wrong system error codes into the FILE server.  I don't remember now the exact
error code that is wrong (or, more likely, undefined).  Someone at OZ should
fix MIDAS and reassemble SS:<SYS.SYSTEM>FILE.MID and start the resulting binary
at PURIFY, which will dump it into SYSTEM:CHAOS.FILE.

Received: from SCRC-BEAGLE by SCRC-TENEX with CHAOS; Sun 31-Jul-83 21:03:14-EDT
Date: Sunday, 31 July 1983, 21:01-EDT
From: David A. Moon <Moon@SCRC-TENEX>
Subject: Re: disk full error should give space-making proceed options
To: bug-midas@MIT-OZ
Cc: JTW@MIT-MC, Zvona@MIT-OZ, bug-twenex@MIT-OZ, BUG-LISPM@MIT-OZ,
    bug-file@MIT-OZ
In-reply-to: The message of 31 Jul 83 19:44-EDT from David A. Moon <Moon at SCRC-TENEX>

IOX34 and IOX35 are undefined in Midas on OZ.  Hence the FILE server
installed there is misassembled.

Date: 2 June 1983 15:35 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
To: BUG-MIDAS @ MIT-MC

Just testing, ignore this message.

Date: 26 May 1983 17:55 EDT
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Building a new MIDAS for 20X
To: IAN @ MIT-OZ
cc: BUG-MIDAS @ MIT-MC

    Date: Thursday, May 26, 1983 3:27PM-EDT
    From: Ian Macky <IAN@MIT-OZ>

    After I've assembled one up, do I need to purify it?  PURIFY$G and it
    bombs out on a SPACS with illegal access requested.  Anyone know what's
    going on?  More details on request...

No, don't bother purifying it.  That stuff was for debugging but never
really got debugged.

Date: Thursday, May 26, 1983 3:27PM-EDT
From: Ian Macky <IAN@MIT-OZ>
Subject: Building a new MIDAS for 20X
To: Bug-MIDAS at MIT-OZ

After I've assembled one up, do I need to purify it?  PURIFY$G and it
bombs out on a SPACS with illegal access requested.  Anyone know what's
going on?  More details on request...

Date: Mon 2 May 83 15:38:33-PDT
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: non-zero sections
To: Ian%MIT-OZ@MIT-MC.ARPA, Marty%MIT-OZ@MIT-MC.ARPA,
    Bug-MIDAS%MIT-OZ@MIT-MC.ARPA, NCP.EGK@GSB-HOW
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)

     There is absolutely no way to get MIDAS to do a DECSAV with a
non-zero section, just as there is no way to get PSECTs out of MIDAS.
Your best bet is to do it the release-4 way; that is, have your code
all boot in section 0, then SMAP% itself up into section 1.  This isn't
too bad since very few programs require more than 256K for code; it's
generally data structures that get so big.

     MIDAS was a real nice assembler.  Too bad it's fallen so far behind
the times.  We've abandoned FAIL for much the same reasons0.
-------

Date: 2 May 1983  15:21 EDT (Mon)
From: Ian Macky <Ian@MIT-OZ>
To:   Bug-Midas@MIT-OZ
Subject: [NCP.EGK: How Does one ...]

Date: Mon 2 May 83 10:34:29-PDT
From: Edjik <NCP.EGK at GSB-HOW>
To:   Ian%oz%MC at SCORE, Marty%OZ%MC at SCORE
Re:   How Does one ...
Received: from GSB-HOW by SCORE with Pup; Mon 2 May 83 10:35:03-PDT

Get midas to do a DECSAV with a non zero section?

Date: 6 Apr 1983  16:30 EST (Wed)
From: Ian Macky <Ian@MIT-OZ>
To:   Ken Harrenstien <KLH@MIT-MC>
Cc:   BUG-MIDAS@MIT-MC
Subject: MIDAS 433
In-reply-to: Msg of 6 Apr 1983 16:16 EST from Ken Harrenstien <KLH at MIT-MC>

MACCNV is a Teco library that does MONSYM->TWXBTS in the current
buffer (and fails trying); Hmm, creation day of the original was
in '80 sometime, last mod by MT.  Hmmpf.

;UNGETting the current system Midas after the patch results in one
that's 4 pages longer; it works, tho.  I'll try it on that WATSON
program once I rearrange it again and let you know.

Date: Wed 6 Apr 83 13:43:55-PST
From: Mark Crispin <MRC@SU-SCORE.ARPA>
Subject: Re: MIDAS 433
To: KLH@MIT-MC.ARPA
cc: Ian@MIT-OZ.ARPA, BUG-MIDAS@MIT-MC.ARPA
Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041
Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence)
In-Reply-To: Your message of Wed 6 Apr 83 16:16:00-PST

I officially provided CVT to MIT years ago.  The dispute which
prevented its redistribution was resolved to everybody's satisfaction.
If you can't find it, grab MRC:<UTILITIES>CVT.MID.  CVT reads in the
SYS:MONSYM.UNV and SYS:MACSYM.UNV files and makes a TNXDFS from it.
This reads the UNVs, not the sources.
-------

Date: 6 April 1983 16:16 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: MIDAS 433
To: Ian @ MIT-OZ
cc: BUG-MIDAS @ MIT-MC

What is MACCNV?  Is it a frob to gobble MONSYM and output TWXBTS?
MRC had such a program, but didn't want it re-distributed; is this the
same one?

Don't bother explicitly purifying MIDAS on 20X, the TNX purify stuff
was basically for debugging.  Just patch it and dump it back with
;Unget.

Date: 5 Apr 1983  18:52 EST (Tue)
From: Ian Macky <Ian@MIT-OZ>
To:   Ken Harrenstien <KLH@MIT-MC>
Cc:   BUG-MIDAS@MIT-MC
Subject: MIDAS 433
In-reply-to: Msg of 5 Apr 1983 16:26 EST from Ken Harrenstien <KLH at MIT-MC>

Sigh.  I grabbed the latest source from AI, and the TXWBTS and TNXDFS
files needed to assemble it, but I can't get MACCNV to do anything
reasonable with out MONSYM...  the warning says to remove the INFDEF
FOR,< ... >'s, which I do, but then it dies (Search failed) along the
way... it dies if you leave them in, too.  Anyone know how to make
this work?  I can't patch the .EXE we have since FILDDT doesn't
believe it's a real .EXE file, and if I ;Yank it into an NDDT and then
;Unyank it out, and then try and purify it, MIDAS dies in an SPACS
trying to set access to a non-existant page...  this is pretty grim.

Date: 5 April 1983 16:26 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: MIDAS 433
To: IAN @ MIT-MC
cc: BUG-MIDAS @ MIT-MC

I think I fixed your problem.  You can either gobble MIDAS 433 from AI,
or patch MINUS+3 to a JFCL.  This shouldn't break anything that
previously worked, but stay alert just in case.
New MIDAS installed on *ITS:SYS;TS MIDAS.

Date: 5 April 1983 13:43 EST
From: Christopher C. Stacy <CSTACY @ MIT-MC>
To: BUG-MIDAS @ MIT-MC

Test

Date: 5 April 1983 13:38 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: WATSON bug
To: IAN @ MIT-MC
cc: BUG-MIDAS @ MIT-MC

Well after all that, how could I not look at the bug?  You seem
to have made a pragmatic fix in WATSON already, but I was able to
write a small test program that tickled it.  It's about what
I expected; MIDAS is being confused by seeing both [a,,b]
and [-a,,b] where a and b are not yet defined, and is doing
constants optimization which tries to produce only one unique
constantt whenever possible.  On pass 2 it discovers its
mistake and complains with a straight face.

The fix for now is to define those symbols ahead of the constants
reference.  It is a real MIDAS bug, though.  Will see if I can
grovel over the optimization code.


Date: Tue, 5 Apr 1983  04:45 EST
From: Leigh L. Klotz <KLOTZ@MIT-OZ>
To:   Edjik <NCP.EG%U-GSB-HOW@SU-SCORE>
Cc:   BUG-ITS@MIT-MC, BUG-MIDAS%OZ@MIT-MC, BUG-MIDAS@MIT-MC, BUG-OZ@MIT-MC,
      KLH@MIT-MC
Subject: Gross OZ lossage
In-reply-to: Msg of Mon 4 Apr 83 11:41:35-PST from Edjik <NCP.EGK at SU-GSB-HOW at SU-SCORE>

KLH knows more about midas than most people, including you.  Please keep
your nitbrained views to yourself.


Date: Tue, 5 Apr 1983  03:26 EST
From: PGS@MIT-OZ
To:   Edjik <NCP.EG%U-GSB-HOW@SU-SCORE>
Cc:   BUG-MIDAS@MIT-MC, KLH@MIT-MC
Subject: Gross OZ lossage
In-reply-to: Msg of Mon 4 Apr 83 11:41:35-PST from Edjik <NCP.EGK at SU-GSB-HOW at SU-SCORE>

    Date: Mon 4 Apr 83 11:41:35-PST
    From: Edjik <NCP.EGK at SU-GSB-HOW at SU-SCORE>

    Gosh, I wonder just how many people on the 6 mailing lists that KLH
    shotgunned his msg to really give a ff about where the MIDAS sources
    live.  Probably damn few.  Oz is the successor to AI.  Moving mailing
    lists and sources of system programs to it from AI seems natural to me.
    Since KLH got the msg Ian sent, he still is on the new offical list at
    oz, so why gripe?  His talk of "sacrilege" conjures up images of the
    inquisition.  Is KLH the defender of the ITS faith?  Probably KLH's main
    gripe is that he hates TOPS-20 and is pissed at having to goto a TOPS-20
    site to look at the sources.  If he uses it for TOPS-20 and 10X
    software, why does he need it on ITS?

    I hope the people in charge of the MIDAS mailing list and sources
    do the appropriate thing in response to KLH's flame, ie. ignore it.

    -- Edjik

KLH is the only person who maintains MIDAS these days.  Thus it is good to
keep the sources in a place where he finds it convenient to access them.  If
he wanted to keep them in his back pocket it would be fine by me and most
people here, so long as the rest of the world could get at them there.  It
seems to me completely bizarre and unpleasant of you to send a message like
this about something you have nothing to do with.


Date: 5 April 1983 01:43 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject:  Gross OZ lossage
To: MARTY @ MIT-OZ
cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, DCP @ MIT-MC,
    KLH @ MIT-MC
In-reply-to: Msg of 4 Apr 1983  23:19 EST (Mon) from Martin David Connor <MARTY at MIT-OZ>

What is all this flaming horseshit in my mailbox?!?!  Is there anyone who
will argue that it was correct that there were TWO BUG-MIDAS mailing lists?
No.  Have we fixed that?  Yes.  (Thank you Ian.)

Now is there somebody out there who can actually claim to be maintaining
MIDAS to a greater extent than KLH?  If so, then lets hear from them.  If
not, then everyone shut the hell up.


Date: 5 April 1983 00:57 EST
From: David C. Plummer <DCP @ MIT-MC>
Subject: Gross 8 inch spikes in various people's heads
To: MARTY @ MIT-OZ
cc: BUG-ITS @ MIT-MC, BUG-MIDAS @ MIT-MC, BUG-OZ @ MIT-MC, KLH @ MIT-MC,
    BUG-MIDAS @ MIT-OZ

And you, Mr. Conner, have as much to learn as I.

Reactionary is not bullshit.  Go read a history book someday and
notice how progress is often achieved by reactionaries and their
ideas.

As for the local history of OZ, there were several people willing
(and eager) to help in creating another ITS.  Moon was willing to
hack microcode and oversee changes needed to the system (e.g.,
for disk support) which I was willing to help with.  As I recall,
you were against the idea of ITS on OZ.  Several other people
attended the Wars of Futility where it was decided to run 20X.
These people warned about all the features that 20X was lacking
and many of the problems it had.  But the wars were futile; the
decision was out of our hands.

So now our only recourse is to sit back and be little brats about
the whole thing.  "Nah, nah, I told you so..."  I, for one, am
proud to be one of these brats.

    For god's sake bring up a machine because it is the Right Thing, not
    because you hate another machine so much.
Wrong.  Both are often true.  In fact, this is how TWENEX was
developed. The history told to me was that BBN disliked Bots-10 so
much they went off and wrote TENEX.  DEC started seeing the light
and bought it from them and made it work on a 20.
						Learn from the mistakes of
    another attempt, ...
If TWENEX only could.

    Plummer, ... until you learn to work FOR A GOAL instead of
    AGAINST AN ALTERNATIVE you will be counterproductive to the
    causes you Support.  
Goal: Help build better Lisp Machines.  I think I am working for
this goal.  Goal: help MIT when I have the time.  I think I do a
fair job here.  Goal: convince people they lost completely when
they decided to run TWENEX on OZ.  Perhaps this is a subconsious
goal.  How actively I work toward it is not clear.  I would hope
to think I keep such discussions among (ITS) friends except when
something blatant happens.  If you didn't blindly defend the
obvious problems, OZ would probably be a lot nicer.

    Penny, I already know I will regret sending this, because so many
    minds are already closed, but I had to try.  Forgive me.
Mine is closed just enough so that spikes cannot penetrate.  I
know who does the real TWENEX development at MIT, and they have
often responded to the requests of others for (ITS-like)
features.  I hope they also understand the spirit in which I
write these flames.

Marty, you earned your second spike.


Received: from GSB-HOW with Pup; Mon 4 Apr 83 11:42:17-PST
Date: Mon 4 Apr 83 11:41:35-PST
From: Edjik <NCP.EGK@SU-GSB-HOW at SU-SCORE>
Subject: Re: Gross OZ lossage
To: KLH@MIT-MC
cc: BUG-OZ@MIT-MC, BUG-ITS@MIT-MC, BUG-MIDAS@MIT-MC, BUG-MIDAS%OZ@MIT-MC
In-Reply-To: Your message of Mon 4 Apr 83 13:53:00-PST

Gosh, I wonder just how many people on the 6 mailing lists that KLH
shotgunned his msg to really give a ff about where the MIDAS sources
live.  Probably damn few.  Oz is the successor to AI.  Moving mailing
lists and sources of system programs to it from AI seems natural to me.
Since KLH got the msg Ian sent, he still is on the new offical list at
oz, so why gripe?  His talk of "sacrilege" conjures up images of the
inquisition.  Is KLH the defender of the ITS faith?  Probably KLH's main
gripe is that he hates TOPS-20 and is pissed at having to goto a TOPS-20
site to look at the sources.  If he uses it for TOPS-20 and 10X
software, why does he need it on ITS?

I hope the people in charge of the MIDAS mailing list and sources
do the appropriate thing in response to KLH's flame, ie. ignore it.

-- Edjik
-------

Date: 4 Apr 1983  15:31 EST (Mon)
From: Ian Macky <Ian@MIT-OZ>
To:   Ken Harrenstien <KLH@MIT-MC>
Cc:   BUG-ITS@MIT-MC, BUG-MAIL@MIT-MC, bug-mail@MIT-OZ, BUG-MIDAS@MIT-MC,
      BUG-OZ@MIT-MC
Subject: Gross OZ lossage
In-reply-to: Msg of 4 Apr 1983 13:53 EST from Ken Harrenstien <KLH at MIT-MC>

Hmm.  Since you obviously have strong feelings about this, and since
that mailing list was screwed up by their being two parallel versions
(one on OZ and one on AI), I have done as you asked (insisted) and
merged the two and put the now official list on MC, with appropriate
pointers all around.

Date: 4 April 1983 13:53 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Gross OZ lossage
To: BUG-MAIL @ MIT-MC, BUG-OZ @ MIT-MC, BUG-MIDAS @ MIT-MC,
    BUG-ITS @ MIT-MC, bug-midas @ MIT-OZ, bug-mail @ MIT-OZ

I just got a message at SRI-NIC which IAN sent to BUG-MIDAS at OZ.
This implies that OZ has a BUG-MIDAS mailing list, and furthermore
that this list is NOT the same as the official list on AI.

This reminds me of the BUG-ATSIGN lossage.

I consider myself one of those people who now and then maintain MIDAS.
For the list to be moved without notice is reprehensible.  For it to
not be on an ITS is sacrilege.  I must insist that either AI or MC
be the official home of MIDAS sources and mailing lists.  This
should probably apply to all ITS developed software.  Since I was the
person who did the TENEX/TOPS-20 conversion for MIDAS, and regularly
use it for 10X/20X software, you can hardly say my viewpoint is
wedged.


Date: 4 April 1983 13:53 EST
From: Ken Harrenstien <KLH @ MIT-MC>
Subject: Gross OZ lossage
To: BUG-MAIL @ MIT-MC, BUG-OZ @ MIT-MC, BUG-MIDAS @ MIT-MC,
    BUG-ITS @ MIT-MC, bug-midas @ MIT-OZ, bug-mail @ MIT-OZ

I just got a message at SRI-NIC which IAN sent to BUG-MIDAS at OZ.
This implies that OZ has a BUG-MIDAS mailing list, and furthermore
that this list is NOT the same as the official list on AI.

This reminds me of the BUG-ATSIGN lossage.

I consider myself one of those people who now and then maintain MIDAS.
For the list to be moved without notice is reprehensible.  For it to
not be on an ITS is sacrilege.  I must insist that either AI or MC
be the official home of MIDAS sources and mailing lists.  This
should probably apply to all ITS developed software.  Since I was the
person who did the TENEX/TOPS-20 conversion for MIDAS, and regularly
use it for 10X/20X software, you can hardly say my viewpoint is
wedged.


Date: 4 Apr 1983  12:28 EST (Mon)
From: Ian Macky <Ian%MIT-OZ@MIT-MC>
To:   Bug-Midas%MIT-OZ@MIT-MC


This table assembles fine as is:

CmdTab:	nCmnds,,nCmnds
	[Asciz "All"],,[AHelp,,All]
	[Asciz "Brief"],,[BHelp,,Brief]
	[CM%INV ? Asciz "Display"],,[-SHelp,,Show]
	[Asciz "Done"],,[DHelp,,Done]
	[Asciz "Edit"],,[EHelp,,EditIt]
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
	[CM%INV ? Asciz "Exit"],,[-SHelp,,Show]
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
	[Asciz "Fast"],,[FsHelp,,Fast]
	[Asciz "Help"],,[HHelp,,Help]
	[Asciz "Kill"],,[KHelp,,Kill]
	[Asciz "List"],,[LHelp,,Show]
	[Asciz "New"],,[NHelp,,New]
	[Asciz "Old"],,[OHelp,,Old]
	[Asciz "Quit"],,[QHelp,,Quit]
	[CM%INV ? Asciz "Show"],,[-SHelp,,Show]
	[Asciz "Slow"],,[SHelp,,Slow]
	[Asciz "Verbose"],,[VHelp,,Verby]
	[Asciz "Zero"],,[ZHelp,,Zero]
nCmnds==.-CmdTab-1

and changing the bounded line to 

	[CM%INV ? Asciz "Exit"],,foo

where foo was defined previously as

FOO:	-DHelp,,Done

works too, but if you do

	[CM%INV ? Asciz "Exit"],,[-DHelp,,Done]

then I get a "More constants on pass 2 than pass 1" after the CONSTANTS
op at the bottom of the program.  The program is [OZ]SUB:WATSON.MID


Date: 10 February 1983  06:39-EST (Thursday)
Sender: GUMBY @ MIT-OZ
From: David Vinayak Wallace <GUMBY @ MIT-MC>
To:   bug-midas @ MIT-OZ
Subject: .FASL

Files assembled under twenex with the .FASL pseudo-op end up with
filetype FAS. this is OK for tenex, but no good for me.


Date:  5 Feb 1983 0116-EST
From: EGK at MIT-OZ at MIT-MC (Edjik)
Subject: MIDAS does NOT put JSYS Names in Symbol Table
To: Bug-Midas at MIT-OZ at MIT-MC

This bug has been buggin' me for a long time.  Since most of the people
I've spoken to privately seem to not think this is a bug, I'm sending
this to the "official" bug list.

The bug:
	 MIDAS does NOT put JSYS Names in Symbol Table

The Symptom:

	When DDTing a program written in MIDAS, Jsi appear as:
		JSYS <some-symbol-that-has-the-same-value-as-the-jsys-number>

	instead of:
		PSOUT% or GTJFN% or etc.

The Cure:

	Make Midas put the JSYS names in the programs symbol table.  Note
	saying, "Use NDDT" is not a fix.  NDDT knows about jsys names.
	DDT knows only about whats in the symbol table.  Everyone
	has DDT.   Only a fortunate few have NDDT.  DDT is supported
	by DEC.  NDDT is NOT.  Not fixing Midas will only hasten
	its death.  Its too winning an assembler to castrate it by
	not saveing JSYS names!

Cheers,
-- Edjik
-------


Date: Tuesday, 21 December 1982  08:12-EST
Sender: KLOTZ at MIT-OZ
From: Leigh L. Klotz <KLOTZ at MIT-MC>
To:   Sam <fHsu at BBNG>
cc:   Bug-midas at MIT-OZ
Subject: ?NIB errors
In-reply-to: The message of 20 Dec 1982  23:19-EST () from Sam <fHsu at BBNG>

I just remembered that the problem with MTOPR was that MIDAS
in its current dump thinks that MTOPR is different from what
it is or something.  I think it needs to be redumped with the
V5 symbols read in.

Leigh.


Date: 15 Nov 1982 2041-EST
From: Sam Hsu <FHsu at BBNA>
Subject: System defs
To: Bug-Midas at MIT-MC
cc: CLamb at BBNA, Tappan at BBNA

is there a way in Midas to get the equivalent of Macro's
.SEARCH MONSYM,MACSYM and .REQUIRE MACREL? i'd like for it
to get the system symbols in monsym, and the macros from
macsym. is the way to do this .INSRT MONSYM.MID that was
generated using MACCNV or CVT.EXE?

that sounds right - i could use the SYSTEM.MID package?
how about the MACSYM stuff? how can i get access to those
macros defined in there?

any help would be appreciated.

sam
-------


Date: 26 Oct 1982 0214-EDT
From: Michael Travers <MT at MIT-OZ at MIT-MC>
Subject: Problem parsing twenex JCL
To: bug-midas at MIT-OZ at MIT-MC

If you invoke midas by saying "r sys:midas" to the EXEC, it will interpret
the "sys:midas" as the file to assemble.
-------


Date: Tuesday, 3 August 1982  04:34-EDT
Sender: GREN at MIT-OZ
From: GREN at MIT-MC
To: BUG-MIDAS at MIT-MC
CC: RMS at MIT-MC
Subject: MIDAS bug


The main program:
-------
20X==1

IFN 20X,[

.INSRT ME:FOO

];20X

BEGIN:	HALTF

	END BEGIN
-------
the file it inserts:
-------
IFNDEF $$SYMGET, $$SYMGET==0

	.BEGIN DIEGO

IFN $$SYMGET,[
;[
] ;END IFN $$SYMGET

	.END DIEGO
-------
and it loses horribly.

Why?  The open bracket in the conditionalized comment line is not seen as
a comment, but as a real open-bracket of some sort.  If I change the line
from

;[

to

;[]

then it wins.  *SIGH*

			--gren (after a long night)
-------

Date: 16 May 1982 04:19-EDT
From: Richard S. Hall <RSH at MIT-MC>
To: BUG-MIDAS at MIT-MC

Is there a way to suppress the listing of false conditionals in Midas
assembly listings? I like to produce listing files to see if my macros
are expanding properly, but if all the failing conditionals are listed
it produces a cluttered and extremely large file. Surely there must be
some way around this but I have been unable to find any information on
this (or much else about listing control) in the on-line doc.

				Thanks,
				Rick Hall



dcp,alan@MIT-MC (Sent by DCP@MIT-MC) 03/19/82 00:45:04 Re:   MIDAS outsmarting itself with undifined constants in literals
To: (BUG MIDAS) at MIT-MC

	title midas bug

	go:	move 1,[foobar/2,,0]	;these are uniquized to
					;the same thing on pass one 
		move 1,[-foobar,,0]	;but on pass 2...

	constants
	foobar:

	end go

gives the following dialog:

	midas bug
	midas bug
	GO+4		104	 0.     1-008	More constants on pass 2 than 1
	Constants area inclusive
	From	To
	102	102
	Run time = 0.13
	1378 Symbols including initial ones (50% used)


Date: 2 March 1982 02:03-EST
From: Ken Harrenstien <KLH at MIT-AI>
Subject: literals in =
To: GZ at MIT-MC
cc: BUG-MIDAS at MIT-AI

Sorry, that is how a two-pass assembler must work.  It cannot
assign the address for [...bar...] until it knows where it is
going to put the literal, which isn't until later.  Suggest
that you simply make a macro out of it, as in
	define foo
	[...bar...] termin

Or give it a real location, as in
	foo: ...bar...

Depending on your tastes.  MIDAS will merge all references
to literals of the same value, which is why the macro above is
still efficient.

GZ@MIT-MC 02/09/82 04:22:26 Re: literals in =
To: (BUG MIDAS) at MIT-MC
Doing something like foo=[... bar ...] where bar is not defined until later,
gives an error (on pass 1 only of course) of "Undefined in =".  This is
annoying, since it is obviously not an error (everything needed to define foo
is there on the first pass, and it does assemble correctly), and forces you to
start ignoring some error messages, a dangerous thing.


Date: 28 January 1982 14:14-EST
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject:  :info Midas
To: BUG-INFO at MIT-MC, BUG-MIDAS at MIT-MC

Ideally, of course, the Midas info should be fully formattted for use in
Info.  But as an interim step, it would be nice if section numbers in
headings were complete (e.g. B.3.b) so that string search will find
sections.

Date: 18 Jan 1982 2130-PST
From: KLH at SRI-NIC
Subject: minor bug
To: bug-midas at MIT-AI

TSRTNS 195 on SRI-NIC has the SKIPE T,CMPTR at CMD: changed
to SKIPLE T,CMPTR.  This fixes a bug wherein 10X JCL was ignoring
switches (/T in particular).  I will install on AI when there
is enough disk; just noting it here to avoid forgetfulness.
-------

Date: 17 Jan 1982 1247-PST
From: KLH at SRI-NIC
Subject: Re: .SCALAR doesn't define labels
To: RMS at MIT-AI
cc: bug-midas at MIT-AI
In-Reply-To: Your message of 16-Jan-82 1313-PST

The reason why a second declaration of .SCALAR FOO should be flagged
is the same as the reason why a second label definition should be
flagged; the hacker is probably doing something wrong.  It used to
be that FOO' was a convenient way to assign a location for FOO, and
allowing several occurrences of FOO' meant you didn't have to remember
whether you'd already given one (the little ' is hard to spot).  But
when using .SCALAR, I think most people (me for sure) think of
it as a better way of saying FOO: 0.  It's "better" because it is
a convenient way of lumping all variables into an impure section, and is
a built-in pseudo-op so that you don't have to worry about .insrt'ing
this or that library.
   The main thing is that I got screwed because I was working on a big
program and adding code here and there, "knowing" that if I goofed and
re-used a symbol for some variable, MIDAS would tell me.  It didn't, and
it took me a while to figure out why I was losing and why something kept
getting smashed.
   Either MIDAS should flag multiple .SCALARs, or the INFO doc should
have an explicit note about the way it behaves.  If the doc had said
something, I might still think it was the wrong thing to do, but
I won't be so annoyed and I won't have sent a bug-midas message.
-------

Date: 16 Jan 1982 0338-PST
From: KLH at SRI-NIC
Subject: .SCALAR doesn't define labels
To: bug-midas at MIT-AI

Is it deliberate that .SCALAR and the equivalent <var>'
construct don't define symbols as labels, but rather
as some form of parameter assignment?  The effect of
this is that saying .SCALAR FOO in one part of an
assembly, and .SCALAR FOO in a different part, will
give you NO error message, and who knows where the
references are going to point.
	This seems counter-intuitive and this behavior,
as far as I can see, is not described in MIDAS INFO.
Is there some problem with defining those symbols in such
a way that a second occurrence in the SAME pass will
print a multiply-defined warning message?
-------

KLH@MIT-AI 12/18/81 06:36:47
To: DCP at MIT-MC
CC: (BUG MIDAS) at MIT-MC
I don't think the GAPFLS$G is ever necessary...



DCP@MIT-MC 12/12/81 18:43:09
To: (BUG MIDAS) at MIT-MC
CC: DCP at MIT-MC
Finally,
	:rename ai:sys;ts omidas,ts oomidas
	:rename ai:sys;ts midas ,ts omidas
	:link   ai:sys;ts midas ,ts omidas
	:job midas
	:load midas;ts mid430
	gapflsG
	purifyG
	:install ai:sys;ts midas
	  --DM was down-- I will do be hand later.

I have not deleted any files, in case I did something wrong.  (It
is hard to tell, since there aren't any directions.) 


DCP@MIT-MC 12/12/81 04:05:00 Re:  .value --> .lose
To: (BUG MIDAS) at MIT-MC
I changed the two .VALUEs in TSYMGT to .LOSE %LSSYS as
threatened.  I tried to assemble it, but I now give up.
AI:MIDAS;MIDAS 430 is the version I created. MIDDIF 429430 is the
comparison, TS MID430 is the assembled version, and TS ERR is the
error file, which contains 
	MIDAS
	Pure pages = 13
	ST = 12335
	2076 words initialization coding.
			46000	 0.   197-062	Pure too low.
	MINPUR-MAXMAC = 777777777767
	MIDAS
			46000	 0.   197-062	Pure too low.
	Constants area inclusive
	From	To
	362162	364455
	37075	37134
	Run time = 2:05.76
	3635 Symbols including initial ones (36% used)

I have now idea if that is a an OK response, and I'm not awake
enough to decide if it is or isn't.  I'm not going to run it
either, for fear it will bash the current installed MIDAS when it
purifies itself, and I don't want to have to rename the current
good one and go through all that junk in case something does go
wrong.  It would be nice if there were more documentation on how
to assemble the damn assembler. (Some of us haven't been around
for n years and therefore don't know all these things.)



Date: 9 December 1981 16:34-EST
From: David C. Plummer <DCP at MIT-AI>
Subject:  Shouldn't this .LOSE instead of .VALUE
To: BUG-MIDAS at MIT-AI


The following is from the MIDAS assembler:

	TSYMGT:	MOVE AA,[MXICLR-MXIMAC,,MXICLR]
		.CALL INITSB	;GET MACTAB PAGES NNOT LOADED INTO.
		 .VALUE
	IFN PURESW,[
		MOVE AA,[MINBNK-MINMAC,,MINBNK]
		.CALL INITSB	;GET PAGES FOR BLANK CODE & SYMTAB.
		 .VALUE

INITSB is a CORBLK request.  My question: Why, if the CORBLK fails,
does this .VALUE instead of .LOSE 1000?  If CORBLK fails it is likely
due to system bloat, and it is probably restartable.  .VALUE does not
let it restart, while a .LOSE does.  If I hear no objections, I will
change this and install it in a couple days; so if there is a really
good reason why it should be .VALUE, please tell me now!

DCP@MIT-MC 09/15/81 22:25:12 Re:  HUH??
To: (BUG MIDAS) at MIT-MC
The program

	title foobar
	a=b
	b=2
	end

gives the error file

	foobar
			100	 0.     1-002	B	Undefined in =
	foobar
	Run time = 0.14
	1347 Symbols including initial ones (49% used)

The INFO documentation reads

	<symbol>=<expression>
		sets <symbol>'s value to <expression>'s.
		If there are undefined symbols in <expression> the
		assignment is not performed.
		This construct is illegal where a value is needed,
		but if it is the last thing in a grouping it does
		supply the value of the grouping.  Thus,
		FOO=<BAR=1> is legal, though FOO=BAR=1 is not.

Is this an error or a warning? (Notice the message is only for
pass 1; it seems to be happy on pass 2.) Is it a bug to print the
message on pass 1, or is it (in my opinion) a misfeature?  The
word assembler (the one who will convert MOVE A,B into a PDP-10
word) only complains on pass 2 that MOVE, A or B is undefined.
Why should this be different?


Date: 1 May 1981 03:33-EDT
From: Paul T. Friedl <PTF at MIT-AI>
To: BUG-MIDAS at MIT-AI

  Would it be possible for me to get a symbolic listing of a large MIDAS
program. I wish to use it as a model for my MIDAS programming.
			Thanks...
			Paul

Date: 2 February 1981  02:32-PST (Monday)
From: WANCHO at DARCOM-KA
To:   BUG-MIDAS at AI
Subject: MIDAS 428
cc:   WANCHO at DARCOM-KA

Well, you can half-cancel my previous MIDAS bootstrap request.  I
imported MIDAS.EXE.428 from XX and it seems to work.  However, for
future reference, I would like to know how to generate a new MIDAS for
this TENEX machine.  I now have the following:

MACROS.MID;39
SYSTEM.MID;13 (from XX - I used to have ;8)
TNXDFS.MID;6
TSRTNS.MID;194 (from AI - had ;192)
TWXBTS.MID;12 (from AI - had ;3)
XJSYS.MID;5

I tried regenerating a new MIDAS using the MIDAS from XX and the
source from AI.  All seemed to go well, except the generated version
was 64 disk pages instead of the 68 that the XX MIDAS has.  Also, when
trying to generate a new CRTSTY using the generated MIDAS, .ICIFT,
.ICILI, and .ICPOV show up as Undefined.  The MIDAS from XX doesn't
generate these Undefines.  Why?  What am I doing wrong, or better yet,
what should I do?  If you tell me that there is no Tenex dependencies
and I can go ahead and use the versions found on XX, I will quietly go
away.

Thanks,
Frank

Date: 1 February 1981  22:13-PST (Sunday)
From: WANCHO at DARCOM-KA
Subject: MIDAS 428
To:   BUG-MIDAS at AI
cc:   WANCHO at DARCOM-KA

Some time ago I tried to compile the latest CRTSTY and it bombed.  EAK
said that I would need the latest MIDAS (we have 416).  So I brought
over MIDAS 428 from AI and it bombed with:

   0   0.   1-003  .SYMTAB 1st arg too big
Error is fatal.

Anybody have any idea how to boot up to 428?

--Frank

Date: 13 January 1981 19:25-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject:  [LARSON: midas]
To: Scott at SRI-KL
cc: BUG-MIDAS at MIT-AI

Any ideas?  Yes, use ATSIGN.


Date: 13 Jan 1981 1044-PST
From: Scott J. Kramer <Scott at SRI-KL>
Subject: [LARSON: midas]
To: Bug-MIDAS at MIT-AI

It apparently doesn't like /C, am using the latest Twenex version here
(ie, same as on XX & EE).	-sjk
                ---------------
Date:  8 Jan 1981 2007-PST
From: LARSON
Subject: midas
To: Scott

  I cannot get it to make a cref listing for me.  Here is what I
said to it:
		midas
		temp_teco/T/C
		EMCSDV==1
		INFODV==1
		COMNDF==1
		^Z

Any ideas?
	Alan
-------
                ---------------
-------

Date: 10 Dec 1980 1556-PST
From: Scott J. Kramer <Scott at SRI-KL>
Subject: Re: MIDAS bug found and fixed
To: EBM at MIT-XX, taa at MIT-XX, pdl at MIT-XX, clr at MIT-XX,
    bug-twenex at MIT-XX, bug-midas at MIT-AI
In-Reply-To: Your message of 10-Dec-80 0953-PST

In case anyone's interested, the fixed MIDAS is now installed as <NEWSYS>MIDAS
at EECS.   -sjk
-------

Date: 10 Dec 1980 1253-EST
From: EBM at MIT-XX
Subject: MIDAS bug found and fixed
To: taa at MIT-XX, pdl at MIT-XX, clr at MIT-XX, bug-twenex at MIT-XX,
To: bug-midas at MIT-AI

MIDAS broke some time ago, when all the MONSYM symbols were added.
First, there were symbol table size problems, but JONL managed to get
around that.  The symptom that had been tripping me up was that a
particular MONSYM symbol, .TICCA, was no longer defined.  I have tracked
this down, and fixed it, and have installed the working MIDAS into
SUBSYS.  The previous version is in SUBSYS, too, in case there are other
bugs that nobody has found yet.  The problem was:

In TWXBTS, some symbols (.ICxxx, the interrupt channels) were to be done
in decimal instead of octal; this continued through the .TICxx codes,
and a little bit later, the radix was again set to octal.  It turns out
that setting the radix overall does not work for the second insertion of
initial symbols, because one line in the DEFSYM macro reads:
	SQUOZE 10,Z
where Z is the symbol being defined.  The radix change changes the 10
from 8. to 10., and manages to destory the values of the symbols.  By
some simple fixes to TWXBTS (by hand), I got around this difficulty.

Suggestion: either MIDAS or the TECO macro that converts MONSYM.MAC into
TWXBTS.MID be changed to recognize this difficulty.  I also noticed that
the TECO macro sometimes output ".RADIX10." instead of ".RADIX 10.", if
that tends to make any difference.

-------

Date: 17 NOV 1980 1459-EST
From: JONL at MIT-MC (Jon L White)
To: JIS at MIT-MC, SJK at MIT-MC
CC: (BUG MIDAS) at MIT-MC, CPR at MIT-MC, ebm at MIT-XX

Elliot Moss and I just reassembled MIDAS on XX, and noted a few
rather simple differences (.TICCA being defined properly, for 
instance).  Not sure what was wrong with the previous assembly,
but I've moved the .EXE to EE, and Moss is going to put up a new
copy on SPEECH.


Date: 4 November 1980 19:49-EST
From: Earl A. Killian <EAK at MIT-MC>
Subject:  Assembling TECO
To: JPERSHING at BBNA
cc: BUG-MIDAS at MIT-AI, DPACHURA at BBND

    Date: Tuesday, 4 November 1980  16:33-EST
    From: John A. Pershing Jr. <JPERSHING at BBNA>
    To:   Earl Killian <EAK>
    Re:   Assembling TECO

    Is MIDAS system-dependent, or is it possible to FTP the .EXE file?

MIDAS is so system-indepdendent that you can use the same .EXE
file on 10X, release 1, release 3, and release 4.

    Also, what would cause MIDAS to crap out due to symbol table full?  Dave
    Pachura is trying to boot EMACS up on the MIS machine, and can't seem to
    assemble either TECO or MIDAS (same error for both).  Is it perhaps
    loading two copies of the JSYS table (e.g. the vanilla symbols and the
    %-versions of the same)?  They are running release 3 (vanilla DEC).

A MIDAS .EXE file has all the appropriate system symbols built
into it at its own assembly time.  Thus, if the MIDAS.EXE on BBND
assembles TECO, then the same .EXE should assemble TECO
elsewhere.  I'm not sure what the problem is, then, unless that
MIDAS will no longer assemble TECO on BBND.  Note that the MIDAS
on BBND has more system symbols than on XX (being generated from
MONSYM.UNV), so it is possible it assembles on XX and not on D.


JONL@MIT-MC 10/31/80 05:05:40
To: (BUG MIDAS) at MIT-MC
On twenex versions, a command line like
FOO.EXE_FOO.MID
should cause the FOO.EXE version number to be the same as that of FOO.MID
or at the verrrrry least, there should be some way to specify this.


JONL@MIT-MC 10/24/80 12:34:35
To: (BUG MIDAS) at MIT-MC
    Date: 24 Oct 1980 0247-PDT
    From: Mark Crispin <Admin.MRC at SU-SCORE>
    Subject: SYMDSZ in MIDAS
    For the TNXSW version SYMDSZ should be set to 6003 not 4003.  You
    run out of symbols otherwise.
It actually has to be even higher; also increased the .SYMTA at
the beginning, when assembling for a Twenex system.  New sources
now on XX< and just about to be on AI.


Date: 24 Oct 1980 0247-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Postal-Address: 12155 Edgecliff Place; Los Altos Hills, CA 94022
Stanford-Phone: (415) 497-1407
Subject: SYMDSZ in MIDAS
To: Bug-MIDAS at MIT-AI

For the TNXSW version SYMDSZ should be set to 6003 not 4003.  You
run out of symbols otherwise.
-------

Date: 16 Sep 1980 1938-PDT
From: Scott J. Kramer <Scott at SRI-KL>
Subject: Re: .FASL op
To: KLH at MIT-AI
cc: BUG-MIDAS at MIT-AI
In-Reply-To: Your message of 16-Sep-80 1805-PDT

Only every MacLisp autoload depends on it being ".FASL".  I'll check
into the access problem, you should at least be in the right user
groups to get at any MIDAS code lying around.	   -sjk
-------

Date: 16 September 1980 21:05-EDT
From: Ken Harrenstien <KLH at MIT-AI>
Subject: .FASL op
To: Scott at SRI-KL
cc: BUG-MIDAS at MIT-AI

    Date:  3 Sep 1980 0319-PDT
    From: Scott J. Kramer <Scott at SRI-KL>

    Files produced on Twenex using this should have ".FASL" rather than ".FAS"
    as their extension.  Looks like a carryover from Tops-10/SAIL in its present
    state.	   -sjk
    -------

Why?  What software depends on looking for .FASL instead of .FAS?  All
the DEC software is certainly restricted to 3-letter extensions.

In any case, I no longer have the necessary access to maintain MIDAS
on SRI-KL.  Their (CR) attitudes really put a damper on any
enthusiasm I might have.

Date: Tuesday, 9 September 1980  20:26-EDT
Sender: EMACS at BBND
From: Earl Killian <EKILLIAN at BBNA>
To: BUG-MIDAS at MIT-AI
Subject: error in PURIFY$G

A little while ago I reported that PURIFYG loses executing the
SPACS JSYS.  I found the problem, but don't have time to fix it
now.  The problem is that the TNX routines double the page number
and no. of pages in order to convert from ITS-size pages.
However, when there are an odd number of TNX pages in the area
being operated on at PURID1, this loses because it will try to
hack the last non-existant page that it thinks it should be there
due to the doubling.

Date: 3 September 1980 10:45-EDT
From: Earl A. Killian <EAK at MIT-MC>
Subject:  decsav format files
To: JoSH at RUTGERS
cc: BUG-midas at MIT-AI

MIDAS has never produced sharable files.  I'm afraid you'll have
to go on doing GET/SAVE.


Date:  3 Sep 1980 0319-PDT
From: Scott J. Kramer <Scott at SRI-KL>
Subject: .FASL op
To: Bug-MIDAS at AI

Files produced on Twenex using this should have ".FASL" rather than ".FAS"
as their extension.  Looks like a carryover from Tops-10/SAIL in its present
state.	   -sjk
-------

Date:  3 Sep 1980 0300-EDT
From: JoSH <JoSH at RUTGERS>
Subject: decsav format files
To: bug-midas at MIT-AI

the .exe file midas produces on twenex doesn't seem to be 
sharable, causing one to have to GET and SAVE it, eg:
@midas
NOTPUR MIDAS.423
*foo
...
@foo
FOO>^C
@i me
...
0-100	Private	  R, W, E
@get foo
@save foo
@foo
FOO>^C
@i me
...
0-100	FOO.EXE.2   1-101  R, CW, E

I am under the impression that Midas used to save sharably,
though when I tried to check with an old version of Midas (419),
it blew up.
--JoSH
-------

Date: Wednesday, 27 August 1980  20:34-EDT
From: Earl Killian <EKILLIAN at BBNA>
To: BUG-MIDAS at MIT-AI

I just assembled MIDAS 424 on a 20X and when I said PURIFY$G, it
crapped out on a SPACS JSYS.  Without the PURIFY$G it seems to
run ok.

Date: 12 Aug 1980 0204-PDT
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: constants area printing
To: JoSH at RUTGERS
cc: Bug-MIDAS at MIT-AI

Actually, if MIDAS is invoked with a CCL start then there is no problem.
It's just that nobody has fixed MIDAS to work with CCL in release 3/4.
-------

Date: 12 August 1980 04:46-EDT
From: Ken Harrenstien <KLH at MIT-AI>
To: JoSH at RUTGERS
cc: BUG-MIDAS at MIT-AI

    Date: 31 Jul 1980 0048-EDT
    From: JoSH <JoSH at RUTGERS>

    is there any way to prevent midas' printing the constants areas when
    it finishes?  I mean the double column of addresses it dumps on the
    tty. I have lots of these (to keep references on the same page) so it
    spits a long list at me which is most annoying.  I would prefer still
    to see the rest of the stuff (ie run time etc).
    -------

No.  I sympathize, though; for certain programs like CRTSTY this is
pretty bad.  Rather than introduce a new pseudo, anyone object
to merely printing the (1) # of constants areas, and (2) total # of wds
used by these areas?  If a programmer really needed to know the
locations, a simple typeout macro would do it.

Date: 31 Jul 1980 0048-EDT
From: JoSH <JoSH at RUTGERS>
To: bug-midas at MIT-AI

is there any way to prevent midas' printing the constants areas when
it finishes?  I mean the double column of addresses it dumps on the
tty. I have lots of these (to keep references on the same page) so it
spits a long list at me which is most annoying.  I would prefer still
to see the rest of the stuff (ie run time etc).
-------

Date: 19 July 1980 2100-EDT
From: Joe.Newcomer at CMU-10A
Subject: MIDAS bug (?)
To:  (BUG MIDAS) at MIT-AI

Using MIDAS.419, I have the following experience compling the AT source:

r midas
at.639

which produces a TOPS-10 version of AT just fine, but doing:

r midas
at.639(t)
SITE==:CMU20FLG
^Z

to produce a TOPS-20/CMU version of AT, I don't get ANY .REL file, anywhere,
of any description.  In fact, the .REL file I found was a couple days old,
and I went thru several compile/link/try-it cycles before discovering that
I had bogus (TOPS-10) code on the TOPS-20 system.  What gives?  How can
I get a .REL file (I am going to do the obvious of putting the SITE definition in
the source, but that is not what people are going to want when the
source is returned)
				joe

Date: 19 Jul 1980 1612-PDT
From: Mark Crispin <MRC at SU-AI>
Subject: interesting bug    
To:   Bug-MIDAS at MIT-AI   

777777777777_-1 returns 177777777777
but A=777777777777 then A=A_-1 returns A=377777777777



Date: 10 JUL 1980 1817-EDT
From: KLH at MIT-AI (Ken Harrenstien)
Subject: MIDAS on a BOTS-10
To: BUDD at MIT-MC
CC: (BUG MIDAS) at MIT-AI

There are a couple of pseudo-ops like .DECTWO which set up
high/low segments.  To switch from one to the other after
this, just save your loc counter with e.g. %%FOO==. and
later you can switch back with a LOC %%FOO.  Lots of
programs separate themselves into a pure and impure segment this way,
by having two loc-counter symbols; macros make it easier.
The MIDAS source itself is one example.

If this isn't what you wanted to know, ask again.

BUDD@MIT-MC 07/10/80 01:33:01 Re: MIDAS on a BOTS-10
To: (BUG MIDAS) at MIT-MC
How does one control "context" switching between bagbiting DEC
dual segments?

I showed a MACRO (archaic DEC assembler) hacker ho to do GETTABs
with a .OP and *BOY* did his jaw drop!

-Phil Budne


Date:  3 JUL 1980 0235-EDT
From: RWK at MIT-MC (Robert W. Kerns)
Subject: LISP and DDT symbols
To: EB at MIT-MC, (BUG DDT) at MIT-MC, (BUG LISP) at MIT-MC
To: (BUG MIDAS) at MIT-MC

The problem is a LISP bug, which I analyzed and reported some time ago.  I
thought JONL fixed it, but perhaps my memory deceives me.


Date: 28 JUN 1980 1738-EDT
From: EB at MIT-AI (Edward Barton)
To: (BUG DDT) at MIT-AI, (BUG LISP) at MIT-AI, (BUG MIDAS) at MIT-AI

Consider the following file:
if1,.insrt lisp;.fasl defs
.fasl
foobar==1
.global foobar
fasend
If it is assembled with MIDAS and loaded into LISP with SYMBOLS set to T,
the error DDT BUG:  PLEASE DO :BUG DDT DESCRIBING CIRCUMSTANCES occurs.

Date: 15 Jun 1980 1822-EDT
From: EBM at MIT-XX
Subject: New MIDAS cons'ed
To: bug-midas at MIT-AI

In order to permit larger multi-line literals, I edited the MIDAS
source to increase the PDL size from 500. to 1500.  (The C compiler
uses large multi-line literals for its branch tables, which is why
I needed to do this.)  The new MIDAS, version 423, is installed on
NEWSYS on XX.  However I did not install it on ITS because when I
assembled it the resulting file was 3 blocks shorter than SYS;TS MIDAS,
so I thought something might be funny.  It would appear that version
422 was never installed.  Would the appropriate person either do
the right thing, or tell me what to do?  Thanks ---
-------

Date: 14 Jun 1980 1625-EDT
From: EBM at MIT-XX
Subject: Multi-line literals
To: bug-midas at MIT-AI

There is a rather low upper bound on the number of words in
a multi-line literal.  I have evidence that this limit is about
150 to 160 lines.  This is unfortunate because the C compiler
uses a construct like this for it switch statement branch tables:
	move	reg,[
		lab1
		lab2
		...
		labn
		]
where n can theoretically be fairly large, and quite reasonably
could be 256 or 512, for an opcode branch table.  (GZ managed to
exercise this problem doing just that.)  Is there any possibility
of this being changed, or at least having the upper bound increased
by a significant factor?  Thanks ---
-------

MOON@MIT-MC 05/16/80 22:29:26
To: (BUG MIDAS) at MIT-MC
The enclosed program assembles incorrectly; it was about the simplest case
I could find that did.  The bug is that the JRST is assembled before the
POP rather than after.  This broke the mailer; I will change Comsat to
rplace the ? with a carriage return, which assembles correctly.

	title test

	define foo (list)
	push 1,2
	bar!list
	pop 1,2
	termin

	define bar (list)
	termin

	test:	jumple 3,[foo (zot) ? jrst zoo ]
	zoo:	end


Date: 27 Mar 1980 1651-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
To: EKILLIAN at BBN-TENEXA, BUG-MIDAS at MIT-AI
In-Reply-To: Your message of 27-Mar-80 1555-PST

Earl -

Try increasing SYMDSZ to 6003.  I have found this necessary in
the version at SCORE.  Only sites that use a TNXDFS that was
made by CVT probably need to do this.

-- Mark --
-------

Date: Thursday, 27 March 1980  18:28-EST
From: Earl Killian <EKILLIAN at BBN-TENEXA>
To: BUG-MIDAS at MIT-AI

I tried assembling MIDAS 422 on BBND and found that when the
result was run, it complained of a symbol table overflow as soon
as a file was given to it.  I suspect that this is because of the
large no. of JSYS names and bits defined in release 4.  I'm not
sure what parameter should be bumped; will someone figure this
out, bump it, and then let me know.  Thanks.

Date: 26 MAR 1980 1427-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: more ideas about constants bug finding
To: RMS at MIT-AI
CC: (BUG MIDAS) at MIT-AI

Well, I wasn't actually thinking of matching up the values,
which is clearly impossible.
Rather the idea is to remember in some fashion what the constants
area size is for each time a constant is seen.  That is, you
would identify constants not by their value but by their
place in the sequence of constants seen.  If on pass 2 the
n'th constant causes an expansion of the constants area, but
on pass 1 the n'th constant didn't, that's an error, but it
might not be necessary to flag it if the constants area size
at that point is equal to or less than its value on pass 1;
pass2 collapse of literals that were distinct on pass1 might have
saved you.  This error would only happen once for each constants
area; it might even be postponed until the constants pseudo is
seen and MIDAS can tell for sure whether something will be screwed
(again, pass2 optimization after the first "error" might have
saved things).
  It could be made even simpler by just remembering the sequence
(possibly as a string of 1-bit bytes), although this may have more
danger of getting out of phase and would definitely only be
reported if a larger-on-pass2 error happens.
  One alternative (or supplemental) hack might be to let the CONSTA
pseudo take an argument specifying how many extra words to reserve on
pass 1 beyond those needed for the constants seen thus far.  Then on
pass 2 MIDAS would ignore the argument and just compare the size this
pass with the total size reserved on pass 1.  When it DOES barf, it
should say by how many words the reserved size was exceeded.  This
will allow certain obscure pass1-pass2 hacks to win which currently
lose.  The error message would in any case provide a little more information
to help track down the problem (or solve it with appropriate extra
allocation).  Of course if this feature was requested for a constants
area, the sequential-checking hack may not do what you want, but
could still provide useful information when the size IS exceeded.

One other thing.  If lots of constant areas are sprinkled around,
they reduce the scope of errors and even eliminate some (by
flushing optimization).  As it happens, the main objection to using
lots of constant areas is not the loss of optimization but the
verbosity of the printout!!  I think it would be reasonable to
simply say how many constants areas there were and how large the
total sizes are and what the size of the largest area is.
If a particular constants area is in error, the err message for it
would say where it is and how big it is, which is about the only
time you need to know this thing.

It would be interesting to have a pseudo to disable optimization
altogether and see how much storage was lost.  I don't think it
is such a significant factor nowadays as it used to be, except
for moby hacks like ITS.


RMS@MIT-AI 03/26/80 04:02:38
To: KLH at MIT-MC
Constants tables can't be saved from pass 1 because they are re-used
when a program contains more than one constants area.
Even if they were saved, it isn't clear how that could be used, since
the values of words in the constants are not the same on pass 2, and
can't even be matched up with the constant words they mapped into on
pass 1!  The pass 1 constants data does not supply enough information
to figure out, on pass 2, what the value would have been!
FOO*BAR on pass 1 becomes "0 and don't optimize me".  On pass 2 it
will be just a number.

  Date: 24 MAR 1980 1713-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: RLJFN
To: MRC at MIT-AI
CC: (BUG MIDAS) at MIT-AI

I suggest that the HALT following the RLJFN simply be replaced with a JFCL.

The temporary file kludge is there because at the time I was
writing the conversion code, it was a lot easier to keep things
straight if I emulated the ITS code fairly closely.  Now that
it is all pretty stable, the code could be modified to always  use
the target filenames, if anyone cares to do so.

Date: 24 Mar 1980 1213-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: Re:  MIDAS bug
To: MMCM at MIT-AI
cc: BUG-MIDAS at MIT-AI
In-Reply-To: Your message of 24-Mar-80 0737-PST

Well, Release 4 must have fixed the bug that RNAMF% didn't completely
flush the JFN, because you get an unassigned JFN error on that RLJFN%
now.  I saw that other code jumped there, but decided to ignore that
fact since that case seemed to be for errors in the assembly and you
weren't going to go much further with MIDAS anyway.

Why does MIDAS bother with that temporary file kludge on TOPS-20
anyway?  It has a purpose on ITS, but on TOPS-20 it just makes things
unnecessarily more complicated.
-------

Date: 24 March 1980 10:37-EST
From: Mike McMahon <MMCM at MIT-AI>
Subject:  MIDAS bug
To: Admin.MRC at SU-SCORE
cc: BUG-MIDAS at MIT-AI

    Date: 22 Mar 1980 0729-PST
    From: Mark Crispin <Admin.MRC at SU-SCORE>
    Subject: MIDAS bug
    Remove:
    	SYSCAL RLJFN,[A]
    	 HALT
    at OCLOS5.  I don't understand how this ever worked, since RNAMF% is
    defined to release the JFN in AC1.
It works because RNAMF does not completely flush the jfn, you can do an RLJFN
at least afterwards.  I did not just flush it since other code jumps there.

KLH@MIT-MC 03/24/80 02:52:17
To: RMS at MIT-MC
CC: MOON at MIT-MC, (BUG midas) at MIT-AI
Okay, so after several hours of lossage I found that the [0,,U3]
was getting mapped to the U3 in a SYSCAL FOO,[A ? U3 ? U4].
On the second pass this became [x,,U3] so didn7t collapse, and
caused a larger constants area.  Apparently, something in
the old NLISTS DID collapse on the second pass but not the first,
so that it all evened out, and never caused an error until
I unknowingly got rid of the literal in NLISTS which saved the world.
The big problem was mostly being completely misguided by
most debugging principles (eg look at changes, assuming
previous stuff was winning).

So... no MIDAS bug in the strict sense.  But somehow it seems
there ought to be some kind of help for the poor loser
who is trying to figure out WHERE the constants area actually
becomes bigger and starts losing.  If the constants tables
could retain their info from pass 1, it would be easy to
catch funnyness by flagging any places where a literal that
DID formerly collapse DOESN'T do so on the second pass.
If necessary, this could be invoked by a debugging pseudo at
the same time a .SYMTAB declares the constant area sizes.
This might be done as part of label-inside-constant feature,
and is plausible since the constants tables are all set
up for dynamic allocation.
  Or maybe a pseudo turning off optimization altogether, just
so that in such cases the program could still be forced to
assemble a working version, even if not the most compact.
  Maybe there are simpler hacks that would still help pinpoint
the problem better, but I'm done.  Constants lossage is really
a sort of unusual problem since the error is only caught
at a point far removed from the original location; most other
errors will barf instantly and you at least know where it is.
Even if you're not quite sure at the moment how to fix it, you
can ask someone else "why doesn't the code at FOO+5 win?" and
stand a good chance of being helped.  But nobody wants to
tangle with a constants problem for the good reason there's
no locality and few clues.


Date: 22 Mar 1980 0729-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: MIDAS bug
To: Bug-MIDAS at MIT-AI

Remove:
	SYSCAL RLJFN,[A]
	 HALT
at OCLOS5.  I don't understand how this ever worked, since RNAMF% is
defined to release the JFN in AC1.  You know, that SYSCAL macro just
makes the code infinitely harder to follow through in DDT (besides
losing nice things like ERJMP/ERCAL).  Also, can't there be a more
reasonable error handler than HALT?  At the very least, it could
output the last JSYS error.
-------

KLH@MIT-MC 02/20/80 22:49:18
To: (BUG MIDAS) at MIT-MC
This looks like a real bug.  For the insrt files KSC;OUT 105,
KSc;NUUOS 167, and KSC;MACROS 72, the two test files
KSC;TESTB 1 and KSC;TEST 15 respectively bomb and win.
The only difference between them is that the latter, which
wins, has a random macro definition that isn't referenced anywhere
by anything.  The lossage for TESTB is that it gets a "more constants
on pass 2 than pass 1" error, plus assorted other errors about
phase globality and the like.

Although this is for MIDAS 419 on MC, I verified that the bin
has the right patch making it equivalent to MIDAS 420, i.e.
it is zeroing ILNOPT at ASSEM2+1.  So this must be some
other problem.

I hve encountered this before, but each time it appeared as if
I "fixed" the problem in some way.  This is the most glaring
repeatable error I've encountered... I will keep these source
files around as long as possible, but they are volatile and
I don't know if the bug will disappear if I move them around.


FJW@MIT-MC 02/03/80 05:44:28
To: (BUG MIDAS) at MIT-MC
Exactly what must I do to bring up the latest MIDAS on a Tenex
machine?  Does it need to be purified?  I am now using what is
externally labelled MIDAS.SAV;413 and signs on as NOTPURE 416.  I
suspect that there is something to be gained by moving up to 420...

--Frank


Date: 17 DEC 1979 2059-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: Macro question
To: (BUG MIDAS) at MIT-AI

Once again I am wrestling with macros that never quite do what
I want.  I'd like to know what might break if the syntax
for "parenthesized macro calls" was modified so that the argument
scanning did NOT stop upon sighting a semicolon or EOL.
Currently a parenthesized call looks like this:
	FOO(a,b,c,		; call will stop scanning here
		d,e,f)		; these will be ignored.

The idea is to allow a parenthesized call to handle arguments on
following lines, up to the closing paren/bracket.  Comments would
be ignored unless part of an argument, and EOL would gobble up
all following whitespace so that indentation wasn't included in
the next argument.  
	I have entertained far wilder ideas, but ths particular
mod would be pretty simple.  It could be tried out by means of a
.mllit-style switch, unless someone knows for sure that it would
break a bunch of things.

Date: 31 AUG 1979 0045-EDT
From: KLH at MIT-AI (Ken Harrenstien)
To: SHADOW at MIT-AI
CC: (BUG MIDAS) at MIT-AI

    Date: 30 AUG 1979 1637-EDT
    From: SHADOW at MIT-AI (Richard Mark Weinapple)

    What's the maximum number of symbol blocks permissible (and
    what would be necessary to change that number?)

At the moment, 40 octal, with a nesting depth limit of 8.
There is no way to change that short of re-assembling a new
MIDAS.

GSB@MIT-ML 08/29/79 17:06:40
To: (BUG MIDAS) at MIT-ML
Why ain't ..SRND & ..RRND defined??  (..RJCL etc are.)


EAK@MIT-MC 08/17/79 21:57:27
To: (BUG MIDAS) at MIT-MC
I've suddenly run into a problem assembling CRTSTY: I get the error
more constants on pass 2 than pass 1.  For the life of me I can't
figure out what is wrong.  However, if I insert a CONSTANTS pseudo
at the proper place then it assembles without error.  That CONSTANTS
is in the source now, labelled "; debug" if you want to look at it.
The source is MC:SYSENG;CRTSTY >.  Oh, also, the error only happens
when I assemble it for Tops-20 with TINT==1, i.e.
:MIDAS SYSENG;CRTSTY >/T
CRTSTY ...
TTY: inserted...
TINT==1
^C
System? Tops-20

I'd appreciate it if someone could figure out why its getting this
error, as there is no reason to have that extra CONSTANTS in there.
Also, it's a lot faster to assemble on a 20X, since you don't have to
assemble the whole TWXBTS file in...

Date: 20 July 1979 02:04-EDT
From: Mike McMahon <MMCM at MIT-AI>
Subject:  .DECSAV ? NOSYMS
To: EKILLIAN at BBN-TENEXE
cc: BUG-MIDAS at MIT-AI, KLH at SRI-KL

    Date: Wednesday, 18 July 1979  21:27-EDT
    From: Earl Killian <EKILLIAN at BBN-TENEXE>
    Re:   .DECSAV ? NOSYMS

    .DECSAV and NOSYMS creates a file that GET complains is badly
    formatted.
fixed in the source (MIDAS;MIDAS 418).

Date: Wednesday, 18 July 1979  21:27-EDT
From: Earl Killian <EKILLIAN at BBN-TENEXE>
To: KLH at SRI-KL, BUG-MIDAS at MIT-AI
Subject: .DECSAV ? NOSYMS

.DECSAV and NOSYMS creates a file that GET complains is badly
formatted.

Date: 9 JUL 1979 0224-EDT
From: RMS at MIT-AI (Richard M. Stallman)
Sent-by: ___002 at MIT-AI
To: EBM at MIT-AI, (BUG MIDAS) at MIT-AI

INFO;MIDAS appears to contain documentation on MIDAS
command strings.  At least, the one on AI does.

Date:  8 Jul 1979 1650-EDT
From: EBM at MIT-XX
Subject: Midas documentation
To: bug-midas at MIT-AI

Documentation on the command line format seems to have gone away;
the info on file name defaulting, etc. is there, but nothing about
the fact that you type (e.g.)
	midas foo.bin_foo.mid (we)
or whatever.  This seems to be true on ITS and XX.
-------

Date:  5 Jul 1979 1727-PDT
From: Rubenstein at SUMEX-AIM
Subject: MIDAS 416 works here now...
To:   bug-midas at AI

I renamed .SYMTA to be .SYMTB and it seems to assemble (and run)
fine...

Stew
-------

Date:  5 Jul 1979 1223-PDT
From: Mitsw at SUMEX-AIM
To:   Rubenstein, Bug-MIDAS at MIT-AI

the problem with assembling midas on tenex is that TWXBTS tries to define .SYMTA,
since this is a pseudo-op, it apparently only generates 1 word (the squoze) in
the initial symbol table, so that all symbols after that, including
all pseudo-ops, are undefined.  i dont know why this only loses on tenex, but
the midas.sav in <MITSW> here was assembled from the sources also here
and seems to work alright.
-------

Date:  3 Jul 1979 0923-EDT
From: EBM at MIT-XX
Subject: MIdas 417 on XX
To: bug-midas at MIT-AI
Cc: jonl at MIT-XX, mmcm at MIT-XX

Under instructions from Jonl and MMcM, I reassembled Midas 417 over here.
I gather that I am supposed to assemble it with the T flag, and type in
TNXSW=1, which I did.  TSRTNS 192 seems to have problems with it; see
<SOURCES.UNSUPPORTED>MIDAS.ERR.1.  The output from the assembly I did, which
used MIDAS 417 and TSRTNS 191, is in <SOURCES.UNSUPPORTED>MIDAS.ERR.2.
The binary file, which appears to work directly (does not have to be loaded
then dumped), is <NEWSYS>MIDAS.EXE.417; the broken one from before is
<NEWSYS>NMIDAS.EXE.417.  The sources I used were all in <SOURCES.UNSUPPORTED>

Problems:  TNXDFS is inserted instead of TWXDFS
	Command line hacking is still not the best; the algorithm I think
will work the best is as follows:
	If there is RSCAN input, use it; otherwise read from the primary
input; if that fails too, THEN try the controlling terminal.  In cleaning
up RSCAN input, all prefixes of RUN should be checked for, as well as
"(program)", which may be printed by altmode completion of the r or run
command, and then the program name should be stripped, leaving a good
command line.  Conceivably, the PRARG feature might be used for passing
arguments, too, but I don't think anyone uses it now.  Note that the
program name part of the RSCAN buffer may not be "midas", since people
might create "pseudo-links" - small bootstrap programs that load another
larger program.  (We use these for CLU programs all the time.)
	I would be happy to talk with whoever is hacking the jcl interface
to explain this further, if it is confusing.  Thanks!   Eliot Moss
-------

Date:  2 Jul 1979 1536-EDT
From: EBM at MIT-XX
Subject: Problem w/midas 417
To: bug-midas at MIT-AI
Cc: jonl at MIT-XX, mmcm at MIT-XX

We encounter the following difficulty using Midas 417:
when run from exec, there is no problem; when run from our
text editor TED, it gets into an infinite loop.  We redirect
the primary input and output to/from files, so it does NOT
have the terminal; BUT it should act as if it does, because
we are presenting JCL in the file.  The infinite loop comes from
reading NUL: (apparently).  It looks like an explicit test is
made on whether Midas has the terminal, which is reasonable on
most systems, but not here.  Midas 416 did not have this problem.
I renamed <SUBSYS>MIDAS.EXE.417 to <NEWSYS>NMIDAS.EXE.417, to
get it out of the way.  (MIDAS -> NMIDAS because a lot of us search
<NEWSYS> first).  This should not be too hard to fix.
-------

Date: 2 July 1979 14:57-EDT
From: Mike McMahon <MMCM at MIT-AI>
Subject:  XX versions of MIDAS
To: JONL at MIT-MC
cc: BUG-MIDAS at MIT-AI

    Date: 06/30/79 13:56:54
    From: JONL at MIT-MC
    Re:   XX versions of MIDAS

    R MIDAS     and
    RUN MIDAS   
    as commands cause MIDAS to begin assembling itself.  However,
    MIDAS
    as a command wins.
this is a crock in TOPS-20 rescan which MIDAS doesnt bother to compensate for.
there is no good reason for having to say RUN MIDAS, it means you have SYS:
defined poorly.  there is no reason at all for saying R MIDAS.

JONL@MIT-MC 06/30/79 13:56:54 Re: XX versions of MIDAS
To: (BUG MIDAS) at MIT-MC
Rescan on TOPS-20 must be crooked - both
R MIDAS     and
RUN MIDAS   
as commands cause MIDAS to begin assembling itself.  However,
MIDAS
as a command wins.  Is this a loss in the TOPS-20 rescan, or a
bug in MIDAS?


Date: 15 JUN 1979 1255-EDT
From: JSOL at MIT-AI (Jonathan  A. Solomon)
To: INFO-MIDAS at MIT-AI

i have a current copy of midas.322 and i have a source
copy of midas.416 i cannot compile the new version with the
old version as i do not have one of the funny definition
packages for midas.322 (TSRTNS MIDAS) i wonder if you can tell
me where i can pick up the proper copy. i try to assemble
midas, and i get errors from the new (TSRTNS) file as
it is for midas.416 please respond as soon as you can.
thank you
			/jon solomon
			Stevens Inst. of Tech
			(respond to jsol@ml)

Date: 11 JUN 1979 2025-EDT
From: MMCM at MIT-AI (Mike McMahon)
Subject:  MIDAS
To: EBM at MIT-XX
CC: (BUG MIDAS) at MIT-AI

    Date: 11 Jun 1979 1218-EDT
    From: EBM at MIT-XX
    Re:   MIDAS

    <SUBSYS>MIDAS does not work, but <CLU>MIDAS does.
    An example of a failing file is <CLU.SUBSYS>SETRECLEN.MID.
    -------
please try <NEWSYS>MIDAS

Date: 11 Jun 1979 1429-PDT
From: Rubenstein at SUMEX-AIM
Subject: MIDAS 416
To:   bug-midas at AI

I have MIDAS 416 and TSRTNS 191, straight off ai:midas; -- the
binary and sources are <SOURCES>MIDAS.MID;416 and .SAV.  The
binary is patched to force fl20x to 0.

Stew
-------

Date:  9 Jun 1979 1414-PDT
From: Rubenstein at SUMEX-AIM
Subject: MIDAS 416
To:   bug-midas at AI

I can't seem to get it to run right here -- I got midas 412
working a while ago, and it will assemble 416 with no errors,
but when I run it (after making the ppatch to fool it into
thinking we're a TENEX instead of TOPS-20), it comes out
with all sorts of "Syllables not seperated" and "Comma past
the 3rd field" and other error messages with files that assemble
just fine under midas 412.  Can anyone make a guess as to
what's going on?

Stew
-------

JONL@MIT-MC 06/05/79 10:18:45
To: (BUG MIDAS) at MIT-MC
The .FASL option does not recogize vertical-bar as a symbol quoter,
while it does recognize slash as a character quoter.


Date: 30 MAY 1979 2229-EDT
From: MMCM at MIT-AI (Mike McMahon)
Subject:  Very straaaaaange bug
To: (BUG MIDAS) at MIT-AI, Rubenstein at SUMEX-AIM

try taking the newest MIDAS;TSRTNS, which should fix the problem.

Date: 30 May 1979 0028-PDT
From: Rubenstein at SUMEX-AIM
Subject: Addendum to last message
To:   bug-midas at AI

I was able to make it work by inserting a couple of CRLF's before
that line...  But still, gentlemen....

Stew
-------

Date: 30 May 1979 0026-PDT
From: Rubenstein at Sumex-AIM
Subject: Very straaaaaange bug
To:   bug-midas at AI

I tried to assemble <RUBENSTEIN>FIND.MID;74 and MIDAS said
"No end statement...  Last grouping: ( at 6-025..."
Well, the last word it saw of my file was the first word
on (file) page 10 -- that is, characters 50000-50004 .
This word contained ",(pm%", being part of the line
"	movsi	3,(pm%rd)" or somesuch.  Why did MIDAS think
this was the end of file?  There is nothing wrong with
the EOF pointers, or anything else, about this file.
Version 73, to which I had made trivial, unrelated changes
at a different place in the file, assembles fine.

Stew
-------

Date: Thursday, 24 May 1979  18:20-EDT
From: Earl Killian <EKILLIAN at BBN-TENEXE>
To: bug-midas at MIT-AI
Subject: .FVERS

It should be safe to have MIDAS use .FVERS instead of .FNAM2 now; how
about it?

Date: 19 MAY 1979 2206-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: EKILLIAN at MIT-AI, (BUG MIDAS) at MIT-AI


    Date: 19 May 1979 1626-EDT
    From: EKILLIAN at BBN-TENEXE (Earl A. Killian)

    If I type
    DEFINE FOO #(A,B)
    then A and B are made balanced but not evaluated.  If I type
    DEFINE FOO (#A,B)
    then A and B are evaluated, but not balanced.  How do I get
    both of these options at once?

That is meaningless.  You can't have two different ways of parsing
specified.

    The only reason I want the arguments balanced is so I can
    call the macro with the parenthesized call syntax:
    FOO(N,5)
    which doesn't work unless A and B are balanced.
    -------
I don't think this desire is unreasonable, but it can't be achieved in
any such simple fashion as marking the argument as "both balanced and
evaluated".  Evaluated args work by just reading in an expression,
evaluating it.  What must be done is to make this do something
reasonable when it comes across an extra unmatched closeparen.

Date: 19 May 1979 1626-EDT
From: EKILLIAN at BBN-TENEXE (Earl A. Killian)
Subject: DEFINE line bug
To:   bug-midas at MIT-AI

If I type
DEFINE FOO #(A,B)
then A and B are made balanced but not evaluated.  If I type
DEFINE FOO (#A,B)
then A and B are evaluated, but not balanced.  How do I get
both of these options at once?

The only reason I want the arguments balanced is so I can
call the macro with the parenthesized call syntax:
FOO(N,5)
which doesn't work unless A and B are balanced.
-------

Date: 19 MAY 1979 0207-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: (BUG MIDAS) at MIT-AI

I have changed TSRTNS so that .FVERS will "work" on
Bots-10 just as it does on ITS.

Date: 19 MAY 1979 0020-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: EAK at MIT-AI, (BUG MIDAS) at MIT-AI


    Date: Thursday, 17 May 1979  15:02-EDT
    From: Earl Killian <EKILLIAN at BBN-TENEXE>

    It'd be really nice to have a remainder operator in MIDAS.

Is that the kind of operator that runs Feline's Basement?

Date: Thursday, 17 May 1979  15:02-EDT
From: Earl Killian <EKILLIAN at BBN-TENEXE>
To: bug-midas at MIT-AI
Subject: feature

It'd be really nice to have a remainder operator in MIDAS.

Date: 11 May 1979 1517-EDT
From: EKILLIAN at BBN-TENEXE (Earl A. Killian)
Subject: .FVERS
To:   bug-midas at MIT-AI
cc:   bug-atsign at MIT-AI

What do .FVERS and .IFVERS do on Tops-10s?  It'd be nice if the @
program used .FVERS instead of .FNAM2, but I don't want to break
Tops-10 assemblies.
-------

Date: 9 May 1979 1937-PDT
From: Mark Crispin <MRC at SU-AI>
Subject: (forwarded mail)   
To:   Bug-MIDAS at MIT-AI   

 09-May-79  1606	Rubenstein at SUMEX-AIM 	LOADTB    
To:   MRC at SU-AI
Date:  9 May 1979 1607-PDT
From: Rubenstein at SUMEX-AIM
Subject: LOADTB
To:   mrc at SU-AI

I did some checking around;  LOADTB is only defined in Tenex's that
have a pie-slice scheduler, that is, Tenex 134.  We're still
running (something based on) Tenex 131.  There must be some other
way to tell...  Why don't you use the JOBDIR table instead?  I
think that was renamed in Tops-20.  Or SNAMES, which doesn't
exist on Tops-20.

Stew
-------



Date:  5 May 1979 0705-PDT
From: Crispin at SUMEX-AIM
Subject: MIDAS at SUMEX
To:   Rubenstein
cc:   Bug-MIDAS at AI

MIDAS bites the bag on SUMEX because SUMEX does not have the LOADTB
table defined.  MIDAS uses the presence of this table as an indication
that the system is Tenex and not Tops-20.  It seems to be the most
reliable way (two others, GETTAB and checking for KL-ness, bite the
bag in other ways elsewhere).

Why doesn't SUMEX have a LOADTB table?

I guess it is getting time for MIDAS to divorce the Tenex and Tops-20
versions.  I don't see why Tops-20 MIDAS should be held back for Tenex
primitive ways of doing things.  I am unhappy about MIDAS not using
ERJMP/ERCAL.
-------

Date: Monday, April 23, 1979 14:28:29
From: Stewart Rubenstein  <RUBENSTEIN at SUMEX-AIM>
Subject: MIDAS for tenex
To: KLH@AI
CC: BUG-MIDAS@AI

The same binary does not work.  For one thing, somebody does an
RSCAN, which is 20x only.  Secondly, when I try to assemble
something, I get a bunch of errors (I don't remember what they
were off hand, but the same source worked fine when assembled at
SRI).

Stew

-------

Date: 23 April 1979 11:16-EST
From: Ken Harrenstien <KLH at MIT-AI>
Subject: MIDAS for Tenex
To: RUBENSTEIN at SUMEX-AIM
cc: BUG-MIDAS at MIT-AI

It's not clear if anyone answered your question, so I guess I will.
You shouldn't have to assemble a new MIDAS or anything.  The
same binary should work on both 10X and 20X.  Are you sure
you weren't just shafted by the difference between 10X and 20X
sharable files (SAV & EXE)?  Without more details I have no more
suggestions.

Date: Wednesday, April 18, 1979 16:29:42
From: Stewart Rubenstein  <RUBENSTEIN at SUMEX-AIM>
Subject: MIDAS for Tenex
To: BUG-MIDAS@AI

How can I build a MIDAS for Tenex?  (as opposed to 20x -- I have
a .sav file snarfed from SRI-KL that doesn't work)

Stew

-------

Date: 10 Apr 1979 2045-EST
From: Mike McMahon <MMcM at MIT-XX>
To: EBM at MIT-XX
Cc: (BUG MIDAS) at MIT-AI, MTravers at MIT-XX

a confusion in "page" sizes has been fixed in <NEWSYS>MIDAS.EXE.416.
<EBM>BUG assembles ok now.
-------

Date: 10 APR 1979 2153-EST
From: MMCM at MIT-AI (Mike McMahon)
Subject:  previous report
To: (BUG MIDAS) at MIT-AI, EBM at MIT-XX

    Date: 10 Apr 1979 1442-EST
    From: EBM at MIT-XX
    To:   bug-midas
    Re:   previous report

    I am still waiting for some reply to my previous
    TOPS-20 bug report.  Is there anyone out there,
    or are my messages going into the infinite bit
    bucket ????
    -------
i dont know exactly what you expect to happen; everyone has more than enough to
do, and someone will look at it when they get a chance.

Date: 10 Apr 1979 1442-EST
From: EBM at MIT-XX
Subject: previous report
To: bug-midas at MIT-AI

I am still waiting for some reply to my previous
TOPS-20 bug report.  Is there anyone out there,
or are my messages going into the infinite bit
bucket ????
-------

Date:  7 Apr 1979 2155-EST
From: EBM at MIT-XX
Subject: Previous bug report
To: bug-midas at MIT-AI

I would appreciate some reply about the report I made a week ago.
-------

Date:  2 Apr 1979 1433-EST
From: EBM at MIT-XX
Subject: More on previous bug report
To: bug-midas at MIT-AI

The bug appears to be rather simple: Midas tries to read beyond the
last word of the file, and if that happens to put in onto a non-existent
page of the file, the illegal memory read error occurs.  This looks like
the traditional fencepost (+ or - 1) error.  Note: many XX files have
their size in bytes recorded, and Midas seems to do things in terms of
words.  Maybe this is OK (since not all text files get their byte size
and length in bytes recorded exactly right).
-------

Date:  2 Apr 1979 1003-EST
From: EBM at MIT-XX
Subject: Midas bug on XX
To: bug-midas at MIT-AI

I got an illegal memory read on the file <ebm>bug.mid;
it looks like twenex-style page mapping is not being hacked
quite right by Midas.  This has happened to other people
before, and it is repeatable, but rare (i.e., if I change the file a little
(by adding comments) the problem goes away).
-------

EAK@MIT-MC 03/30/79 18:57:19
To: (BUG MIDAS) at MIT-MC
Why the hell is BLOCK illegal inside <>, () or []
?

Date: 13 MAR 1979 0233-EST
From: EAK at MIT-MC (Earl A. Killian)
Subject:  monitor definitions
To: Admin.MRC at SU-SCORE
CC: (BUG MIDAS) at MIT-MC

Wouldn't it be better to change IDDT to have the monitor symbols
pre-defined?

Does anyone know if MARC's new IDDT does this already?

Date: 12 Mar 1979 2311-PST
From: Mark Crispin <Admin.MRC at SU-SCORE>
Subject: monitor definitions
To: Bug-MIDAS at MIT-AI

Oh when oh when is MIDAS going to generate the JSYS symbols in the
output file's symbol table?  This is a complete and total screw, since
DDT (on WAITS, Tops-10, Tops-20, and Tenex) simply does not know any
UUO or JSYS definitions.  I agree the symbol table is enormous, but at
least it can do what MACRO and FAIL do and generate the used symbols
into the output file.  Having to look up the number and type 104000,,n
is ridiculous!
-------

MOON5@MIT-MC 02/25/79 04:45:28
To: (BUG MIDAS) at MIT-MC
CC: MOON at MIT-MC
Is the error message obtained by assembling MC:MOON;MIDAS BUG really a win?
(Barfs at formfeed in ASCII string which is in a literal)


Date: 8 JAN 1979 2214-EST
From: MMCM at MIT-AI (Mike McMahon)
To: EKILLIAN at BBN-TENEXE
CC: (BUG MIDAS) at MIT-AI

    Date: Monday, 8 January 1979  16:23-EST
    From: Earl Killian <EKILLIAN at BBN-TENEXE>
    To:   Bug-MIDAS

    Has anyone investigated the funny behavoir I reported a while ago?
    I'd like to have an up-to-date MIDAS, but I can't MIDAS 412 to
    assemble and work.
i have tried all the latest files both at MIT-XX (20X) and SRI-KA (10X),
and produced things that will assemble themselves and other sample programs
correctly.  Are you sure one of your files isnt munged?


Date: Monday, 8 January 1979  16:23-EST
From: Earl Killian <EKILLIAN at BBN-TENEXE>
To: Bug-MIDAS at MIT-AI

Has anyone investigated the funny behavoir I reported a while ago?
I'd like to have an up-to-date MIDAS, but I can't MIDAS 412 to
assemble and work.

Date: Sunday, 31 December 1978  16:02-EST
From: Earl Killian <EKILLIAN at BBN-TENEXE>
To: Bug-Midas at MIT-AI
Subject: XJSYS lossage

I'm having all sorts of problems creating a new MIDAS.  First I tried
assembling a new version from MIDAS 412, TSRTNS 188, and XJSYS 5.  However
everytime I tried doing so with my MIDAS 409 I'd get tons of "Multiply
defined" errors on pass two.  So I assembled FTP'd the sources to XX and
assembled it with the MIDAS 411 there.  It worked ok and I brought it over to
BBNE.  To test it I tried to have it assemble itself.  The assembly went ok,
but the thing it produced doesn't work.  At SITINI it does a SYSCAL
CVHST,[FNBWP A].  FNBWP contains a reasonable byte pointer, but when the
CVHST JSYS is XCT'd AC 1 has 3440 in it (FNBWP=3443).  Since CVHST expects a
byte pointer in AC 1, it bombs out.

I'd appreciate it if someone could look into this and figure out what is
going on.  You probably don't want to send out this version on the EMACS
distribution tape, either.

Date: 18 DEC 1978 1118-EST
From: EAK at MIT-MC (Earl A. Killian)
Subject:  rel 3 midas
To: KLH at MIT-MC, MRC at MIT-MC
CC: (BUG MIDAS) at MIT-MC

The problem with using JRST 4,. after JSYSs is that the illegal instruction
error destroys the error which caused the failure return, making debugging
difficult.  What's wrong with a PUSHJ (or even a JSR) to a short routine?

Date: 18 DEC 1978 0623-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: rel 3 midas
To: MRC at MIT-AI
CC: (BUG MIDAS) at MIT-AI

I'm surprised that you are complaining about this.  I thought
you weren't going to do anything about improving MIDAS for
rel 3 unless the XX people relented, and didn't want others
to do so either.  I certainly can't do it without actually
using XX (since SRI-KL is still waiting until Xmas for more
rel 3 work) and while I do have an account there for that
purpose, it seems like a strange situation.

Have you actually been screwed by any of the jrst 4,'s?
Without looking at the source, I would imagine that most of them
are either in op-sys independent places or follow instructions
that "should never" fail, including internal checks rather than
just JSYS's.  I suppose there could be a place for never-fail
JSYS'S (which fail) to JSR to and hack ERSTR, but note that
many JSYS's will just fail with an illegal instruction interrupt
anyway, particularly on TENEX.

Date: 16 DEC 1978 0418-EST
From: MRC at MIT-AI (Mark Crispin)
Subject: Tops-20 MIDAS
To: (BUG MIDAS) at MIT-AI

MIDAS STILL does not have any code for release 3 CCL commands on Tops-20.
nnnMID.TMP files do NOT exist on releases after release 1.  It is a real
loss for the COMPILE/LOAD/EXECUTE commands not to work.  I can't believe
you released MIDAS in this state.  C'mon guys, the code necessary is only
a few lines.

Another problem is that MIDAS does JRST 4,'s on JSYS failures when it should
really do ERSTR hacking.  JRST 4, just prints an illegal instruction message,
as if you executed a 0 or something.

Date: 16 DEC 1978 0413-EST
From: RG at MIT-AI (Richard Greenblatt)
To: (BUG MRC) at MIT-AI, (BUG MIDAS) at MIT-AI

It obviously doesn't make a tinker's damn worth of difference what the hell
gets used for a nop in any program anywhere.  You have just wasted more computer
power sending out your stupid message than will ever be spent on slow nops.

Date: 16 DEC 1978 0408-EST
From: MRC at MIT-AI (Mark Crispin)
To: (BUG MIDAS) at MIT-AI

MIDAS (and other ITS software) should use "NOP" instead of JFCL, and
allow sites to define NOP.  JFCL is disgustingly slow on KL-10's, where
CAI (SAIL) or TRN (DEC) is the preferred no-op.  [DEC likes TRN 'cuz
TRNA is the fastest KI no-op; SAIL sticks to CAIA for KA's and hence
uses CAI.  Of course, on KL's TRN/TRNA and CAI/CAIA are the same].

Date: 14 DEC 1978 0420-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: multiply defined bug
To: (BUG MIDAS) at MIT-AI

Yeah, the sequence
	foo==1 ? foo==<bar==foo>+1
does the right thing, but
	foo==1 ? foo==<bar==:foo>+1
gives a multiply-defined error for FOO.

KLH@MIT-MC 12/14/78 00:20:28
To: (BUG MIDAS) at MIT-MC
I suspect there is some MIDAs bug with flags or smething that causes
foo==1
foo==<bar==:foo>+1
to get a "FOO multiply defined" error.


Date: 13 DEC 1978 2208-EST
From: MRC at MIT-AI (Mark Crispin)
To: EAK at MIT-AI, (BUG MIDAS) at MIT-AI

I GUESS HAVING A SWITCH WHICH DEFAULTS TO FLUSHING NULLS IS ALRIGHT,
BUT I WOULD LIKE TO PRESS FOR AN UNDERSTANDING ON THE PART OF ALL
CONCERNED THAT USING SIGNIFICANT NULLS IN A PROGRAM IS A VERY VERY
BAD IDEA WHICH MAKES EXPORTABILITY AND EDITABILITY OF THE FILE IN
QUESTION VIRTUALLY IMPOSSIBLE.

EAK@MIT-MC 12/13/78 21:01:07
To: KLH at MIT-MC
CC: (BUG MIDAS) at MIT-MC
What KLH is proposing seems reasonable to me.  I'd like to point out that,
while most of the times I've used nulls it's been for ASCIZ delimeters,
in one program I had one inside an ASCII string constant.

Date: 13 DEC 1978 2020-EST
From: KLH at MIT-AI (Ken Harrenstien)
To: (BUG MIDAS) at MIT-AI, EAK at MIT-AI

OK, I'm convinced there are problems associated with nulls
and that if someone writes a program source file that depends
on having some nulls in it, they ae apt to face lossage with
respect to some 20X software.  However it still seems
reasonable to me to have a switch-style frob so that
winners who want to win can do so and losers who want to
lose can also do so (pick your choice of viewpoints and
associate it with either the on or off state).  It should
default to flush on T10 and 20X.  This sort of adds the
feature that you can request nulls flushed when you're on ITS!

By the way I think it's untrue that a random ^C or ^Z will
halt file input.  This only happens when the "eof char" is
exactly at the end of the file where it was cleverly placed
by MIDAS.

Of course, the only use I've found for ^@ has been in macros
which do ASCIZ's of their arguments, and if MIDAS ever acquires
string variables, this and many other crocks will disappear anyway.
So maybe it's more worthwhile to spend time wrestling with that
idea, than on fighting about nulls.

Date: 13 Dec 1978 0015-PST
From: Mark Crispin <MRC at SU-AI>
To:   EAK at MIT-MC
CC:   BUG-MIDAS at MIT-AI  

12-Dec-78  1657	EAK at MIT-MC (Earl A. Killian) 	nulls  
You've indicated that TNX programs flush nulls, but if there
aren't any TNX programs that insert them without being told then noone will
be screwed.

MRC - ANY PA1050 PROGRAM WILL INSERT NULLS.  TREATING NULLS AS SIGNIFICANT,
AND WORSE, DEPENDING UPON THAT, IS SUCH A BAD IDEA IT SHOULD BE FLUSHED
IMMEDIATELY.



Date: 12 DEC 1978 1946-EST
From: EAK at MIT-MC (Earl A. Killian)
Subject:  nulls  
To: MRC at SU-AI
CC: (BUG MIDAS) at MIT-MC

I'd hardly call providing a pseudo-op or something to control nulls a
don't-give-a-damn-about-anybody-else attitude.  What's more, not ignoring
nulls can only screw people who use programs which add them un-asked for
(such as E).  You've indicated that TNX programs flush nulls, but if there
aren't any TNX programs that insert them without being told then noone will
be screwed.

Date: 12 Dec 1978 1413-PST
From: Mark Crispin <MRC at SU-AI>
Subject: nulls  
To:   EAK at MIT-MC
CC:   Bug-MIDAS at MIT-AI  

Foo!  This is the sort of don't-give-a-damn-about-anybody-else attitude
that DEC has been accused of.  Every version of TENEX TECO (yes, dear,
TENEX TECO) that I've ever had the misfortune to use flushes nulls.  Why
don't you have your PRIVATE copy of MIDAS not flush nulls without screwing
the rest of the world.

If you can't think of something better to use in CRTSTY, that's your own
fault.  I would think that CRTSTY is a program you might want to give out
to the outside world, however, which would mean NO NULLS.

I think I will change MIDAS to require control-meta-linefeed for the end
of file character in all versions, flushing these losing ^C and ^Z users.
They steal the capability to use beta or not-equals.  As for people without
bucky bit terminals, why should I care?  After all, we have this winning
null precedent here for not giving a damn who we screw.



Date: 12 DEC 1978 1141-EST
From: EAK at MIT-MC (Earl A. Killian)
Subject:  MIDAS on Tops-10
To: MRC at MIT-MC
CC: (BUG MIDAS) at MIT-MC

     I don't care what MIDAS does on Tops-10, but I do care about its
operation on TNX systems, which I use.  So it is not necessary to tell us how
badly Tops-10s and Stanford will lose since they need not be effected.

     Second, you mentioned ASCIZ would lose: I'd like to point out that ASCIZ
was exactly where CRTSTY was using nulls, as delimeters.  This is a perfect
use for them because nulls are the only characters which it doesn't make
sense to put in a ASCIZ string.

     Also, I don't see that null usage forces you to use EMACS (though on TNX
I have no idea what else you'd want to use).  TNX TECO seemed perfectly able
to deal with nulls in files in a little test I made.

     Finally, you claimed that all the same problems exist on Tops-20 because
they use Tops-10 software.  Well if they use all Tops-10 software they should
have no objection to using MIDAS under Tops-10 simulation.  Basically I don't
see why MIDAS has to always lower itself to the lowest common dominator of
the software world.  It is as silly as the Header-People who argued against
lower case because some people still used TTY 33s.  Also I fail to see why
you object to have null ignoring controlled by a psuedo-op or something, as
KLH objected.  That allows people that want to lose (or are forced to by
their software) to lose, and people that want to win to win.

Date: 12 DEC 1978 0331-EST
From: MMCM at MIT-AI (Mike McMahon)
Subject: Nulls
To: KLH at MIT-AI, MRC at MIT-AI
CC: RMS at MIT-AI, EAK at MIT-AI, (BUG MIDAS) at MIT-AI


    Date: 12 DEC 1978 0316-EST
    From: KLH at MIT-AI (Ken Harrenstien)

    Perhaps it could be made a pseudo-invocable option.  Or
    a MIDAS source assembly option.  I don't know bout T-10
    or WAITS, but I've never had any trouble with 20X files,
    in fact I've had less than with ITS owing to more
    consistent byte-size/EOF handling.  Just as a matter of
    curiousity I'd be interested in why WAITS and T-10 lose
    with nulls, since I really hv no experience with them.
TVEDIT puts in loads of nulls to fill out everything to page boundaries
and doesnt have a write-out mode that flushes them, but i doubt anybody'd
ever use it to edit a MIDAS program.

Date: 12 DEC 1978 0316-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: Nulls
To: MRC at MIT-AI
CC: RMS at MIT-AI, EAK at MIT-AI, (BUG MIDAS) at MIT-AI

Perhaps it could be made a pseudo-invocable option.  Or
a MIDAS source assembly option.  I don't know bout T-10
or WAITS, but I've never had any trouble with 20X files,
in fact I've had less than with ITS owing to more
consistent byte-size/EOF handling.  Just as a matter of
curiousity I'd be interested in why WAITS and T-10 lose
with nulls, since I really hv no experience with them.

Date: 11 Dec 1978 2134-PST
From: Mark Crispin <MRC at SU-AI>
Subject: nulls in input file
To:   Bug-MIDAS at MIT-AI, EAK at MIT-MC   

Please do not make MIDAS not flush nulls in the input file.  Changing that
would be a gross screw.



Date: 12 DEC 1978 0016-EST
From: KLH at MIT-AI (Ken Harrenstien)
To: (BUG MIDAS) at MIT-AI
CC: EAK at MIT-MC


Date: 8 DEC 1978 2134-EST
From: EAK at MIT-MC (Earl A. Killian)

Damn, TNX MIDAS seems to lose on nulls in the input file; I'm not sure, but
I think it ignored them.  This caused some grief when I tried to assemble
a TNX CRTSTY.

[KLH - I think it does ignore them.  DEC midas does at least.  It has
something to do with crufty SOS/EDIT line-numbers... not sure what
best solution is.]

Date: 5 DEC 1978 0525-EST
From: KLH at MIT-AI (Ken Harrenstien)
To: (BUG MIDAS) at MIT-AI

Found it!!  By sheer obscure coincidence (more or less) I ran
into some missing symbols frm a .DECSAV assembly which I
traced back to a missing tweak in BKSRT.  Those bum-an-instruction
hacks may make MIDAS faster/smaller, but they sure are a pain to
figure out.  Anyway, that was undoubtedly why MRC's block structure
assemblies blew up on LOTS; when the monitor attempted to
load the .EXE it was probably hitting EOF on the file before
it could satisfactorily load all the symbols that MIDAS claimed were
there.
  MIDAS;MIDAS 412 has the fix.  It is simple enough to be
easily patched (see MIDAS;MIDDIF 411412).

Date: 28 Nov 1978 0339-PST
From: Mark Crispin <MRC at SU-AI>
Subject: .MID
To:   EAK at MIT-MC, Bug-MIDAS at MIT-AI   

I object strongly to changing .MID for the reasons that KLH
mentioned.  It seems like a totally worthless change whose
only advantage would be somebody's idea of what is prettier,
and which has the disadvantage of several screws.  Why not
leave well enough alone?



Date: 28 Nov 1978 0122-PST
From: Klh at SRI-KL (Ken Harrenstien)
Subject: File consolidation
To:   bug-midas at AI

One thing that would be reasonable is combining TNXDFS and TWXBTS;
I suggest that the latter be incorporated into the former.  Presumably
one file will never be without the other.  This also makes it
easier to substitute a single TNXDFS file of one's own manufacture.
-------

Date: 28 NOV 1978 0332-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: JONL's suggestion
To: EAK at MIT-MC
CC: (BUG MIDAS) at MIT-AI, JONL at MIT-MC

I would counsel leaving the extension as .MID for several
reasons.  One is that it is already a documented extension
for MIDAS (documented by DEC even) and they keep their
extensions to 3 letters for the very simple reason that
there is so much T-10 software running on TNX in compatibility
mode.  If you feel like re-writing it all to let you win with
full TNX extensions, fine.  For example, as a first start
you have to convert ATSIGN, which could use it anyway and doesn't
have DEC copyright hassles attached.
Let us know when it's done...


EAK@MIT-MC 11/27/78 22:23:46 Re: JONL's suggestion
To: (BUG MIDAS) at MIT-MC
CC: JONL at MIT-MC
I'd gladly rename my MIDAS files to get a nicer extension like .MIDAS.


JONL@MIT-MC 11/27/78 22:13:05
To: (BUG MIDAS) at MIT-MC
Is it too late to have the default extension be
MIDAS for twenex and MID for TOPS-10?  In general, it
seems better to pick a name, and not shorten it on twenex,
but shorten it only by truncation for TOPS-10.


KLH@MIT-MC 11/24/78 08:02:29
To: RWK at MIT-MC
CC: (BUG MIDAS) at MIT-MC
Well, I tried assembling MC:SYSEN1;PWORD 1699 with
MIDAS 410 and it seemed to work fine, so either it was
a super random bug or someone fixed it already.


Date: 24 NOV 1978 0750-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: separate source files
To: MRC at MIT-AI
CC: (BUG MIDAS) at MIT-AI

Personally I prefer it kept separate, since this makes it
more manageable and easier to edit.  Furthermore its style
is different (lowercase comments) and most everything in
it concerns system dependent code, which I think is best
kept smewhat removed from the main, system-independent,
body of MIDAS itself.
Other programs may .insrt XJSYS.  That was its original intent
I believe.
In fact I'd rather see MIDAS more modularized than more
monolithic.  How would you like to have ITS > in one file?

Date: 24 NOV 1978 0059-EST
From: MRC at MIT-AI (Mark Crispin)
To: (BUG MIDAS) at MIT-AI

Say, why not flush this separate TSRTNS file?  It's enough of a pain
having these xxxDFS and xxxBTS files without making it any worse.  I
think XJSYS should be in the main MIDAS file too.

Date: 21 NOV 1978 1733-EST
From: KLH at MIT-AI (Ken Harrenstien)
To: (BUG MIDAS) at MIT-AI

Have fixed TNX run-off-end bug in source, TSRTNS 187.
Someone (RMS I guess) has fixed the listing-file rename bug.

Date: 21 Nov 1978 1417-PST
From: Klh at SRI-KL (Ken Harrenstien)
Subject: OUTUPD and OUTN1 and NED error on TNX
To:   bug-midas at AI

Well, the mysteriousity remains mysterious.  The file
AI:KLH;.BOMB > will work OK on ITS, but get a NED (No
END statement) error on TNX.  The reason it does this is
that the NED checking logic at NEDCHK tests the variable OUTN1
which is only bumped by the OUTUPD routine, which is only
called by output-format-selecting pseudos such as DECREL and
FASL.  DECSAV and SBLK in particular do NOT call it.  I
can't figure out what the hell any of it is supposed to mean,
especially since most of this NED-hacking stuff is conditionalized
by A1PSW (pass-1 auto-reassembly hack) which I doubt anything
has ever used for at least 10 years.

(incidentally don't be fooled by the fact that the source file
selects DECSAV format; MIDAS helpfully does an automatic DECREL
selection as part of the pass initialization)

Perhaps a good solution is to set A1PSW==0 for TNX midases.
-------

Date: 21 NOV 1978 1334-EST
From: KLH at MIT-AI (Ken Harrenstien)
To: (BUG MIDAS) at MIT-AI

I've found a simple fix for the TNX run-over-EOF bug,
but uncovered another one which I haven't yet figured
out.
  Fix is not yet in source.

Date: 21 NOV 1978 0306-EST
From: KLH at MIT-AI (Ken Harrenstien)
To: MOON at MIT-AI
CC: (BUG MIDAS) at MIT-AI


    Date: 20 NOV 1978 2238-EST
    From: MOON at MIT-AI (David A. Moon)

    Do :midas tty:
    .insrt nosuch file

    And watch it bite the bag

I tried this and it very reasonably told me no such file
existed, use what filename instead?

Date: 21 NOV 1978 0208-EST
From: KLH at MIT-AI (Ken Harrenstien)
Subject: /CREF
To: ekillian at BBN-TENEXE
CC: (BUG MIDAS) at MIT-AI

The CREF output file format is only understood by the ITS CREF program,
so it is not assembled into non-ITS MIDASes.  Tell him to use the
winning ATSIGN program.

Date: 20 NOV 1978 2238-EST
From: MOON at MIT-AI (David A. Moon)
To: (BUG MIDAS) at MIT-AI

Do :midas tty:
.insrt nosuch file

And watch it bite the bag

Date: 19 NOV 1978 0142-EST
From: MOON at MIT-AI (David A. Moon)
To: (BUG MIDAS) at MIT-AI

When a fatal error, no END statement, occurs in pass 2
when the /L option was used, it forgets to rename the _MIDAS LSTOUT file.

Date: 17 NOV 1978 1552-EST
From: KLH at MIT-AI (Ken Harrenstien)
To: RMS at MIT-AI
CC: (BUG MIDAS) at MIT-AI, DANG at MIT-AI, MMCM at MIT-AI

Sorry if it was a mis-understanding, but knowing that you are about
to distribute a tape, I want to be sure it's not a castrated midas on
the tape.  In the midas bugs file, the only message about block
structure not working is from MRC; previously I had said that I
made it follow the documented DEC format in LINKER manual.  
  I certainly hope that all you did was insert a flag check, rather than
removing the block-structure hiar for .decsav.  Anyway, I would
definitely be willing to make sure that it works, if MRC can furnish
his lossage example.  (as I recall it was utterly weird in that
the monitor GET JSYS was crapping out on attempt to load!  It is
probably a 20X v3 monitor difference, since I have had no trouble
with my block structured hacks on our v2.  This is why XX would
be useful.  I would like to ask Dan if that is not a sufficient reason.

Date: 16 NOV 1978 1754-EST
From: KLH at MIT-AI (Ken Harrenstien)
To: RMS at MIT-AI
CC: MRC at MIT-AI, (BUG MIDAS) at MIT-AI

Why is "block structure in .DECSAV assemblies illegal"????
I need that!!!!!!! It works for me!!!!! Nobody has yet given
me a reproducible example of lossage, so how can I debug it?
I spent a lot of time making it work.

I will not test the new MIDAS until that is restored.

Date: 15 Nov 1978 1523-EST
Sender: EKILLIAN at BBN-TENEXE
Subject: /C
From: Earl A. Killian <EKillian at BBN-TENEXE>
To: Bug-MIDAS at MIT-AI
Message-ID: <[BBN-TENEXE]15-Nov-78 15:23:32.EKILLIAN>

Is the /C supposed to generate a CREF?  One user here tried to get a CREF
from MIDAS and couldn't.

Date: 12 NOV 1978 1622-EST
From: KLH at MIT-AI (Ken Harrenstien)
To: rwk at MIT-MC
CC: (BUG MIDAS) at MIT-AI

If no one has looked at your problem yet, can you please save PWORD 1699 and 1700
(or a srccom of latter) on AI:MIDAS; along with any insrted files, so that
I or someone else can reproduce the lossage later.  Thanks.  It does sound
like an obscure bug.

RWK@MIT-MC 11/10/78 21:45:32
To: (BUG MIDAS) at MIT-MC
The BINPRT info gets all filenames including device as zero, when the input
is from the TTY:
Also, it should clobber DSK: to MC: or ML:, so one can tell what machine
a program was assembled on.


RWK@MIT-MC 11/10/78 21:41:01 Re: Obscure bug in .SYMTAB allocations?
To: (BUG MIDAS) at MIT-MC
:MIDAS SYSEN1;PWORD 1699
Answer "No" to the question.
On pass 2 at label PURIFY+3 it tries to expand my SYSCAL macro completely
wrong, ends up complaining that CORBLK is undefined (that's supposed to go into
the sixbit /arg1/)
and tries to put the second argument inside a ASCIZ (there is no ASCIZ in the
SYSCAL macro).  It works right on pass 1, and in SYSCAL's before and after.
Didling the .SYMTAB parameters as in PWORD 1700 fixes this.


Date: 27 OCT 1978 2317-EDT
From: RMS at MIT-AI (Richard M. Stallman)
To: (BUG MIDAS) at MIT-AI

The who-line display loses
when .INSRT is done.  It shows the page number in the .insrt'ed file correctly
but with the filename of the main file.

Date: 16 OCT 1978 1949-EDT
From: MMCM at MIT-AI (Mike McMahon)
Subject: RUN MIDAS
To: KLH at MIT-AI
CC: RMS at MIT-AI, (BUG MIDAS) at MIT-AI, EAK at MIT-AI


    Date: 15 OCT 1978 0759-EDT
    From: KLH at MIT-AI (Ken Harrenstien)

    Well, there are all these ways of invoking it like [@]<NEW>MIDAS
    and [@]midas.EXE.500  (with recognition) and so forth, which
    the current algorithm (flush until space seen) handles adequately
    and I'd like to keep that capability.  Perhaps MMCM has a
    suggestion.  Perhaps the EXEC can be modified so that it clobbers
    the RSCAN string to act just like ITS JCL, making sure thre is a
    space at the start of the string (as normally there will be anyway).
whenever the command is started with a filename, the rscan
line seen by the program will contain just the FN1 of the
resulting file, so both of these cases would look just like
MIDAS.  there is of course the problem with NMIDAS or
OMIDAS.  this means perhaps checking for R or RUN as the
first token and flushing the command line in only those
cases.  the RSCAN parser maybe can share some code with the
TOPS-10 one, which is probably already hacking RUN MIDAS;FOO
or whatever. 

Date: 15 OCT 1978 0759-EDT
From: KLH at MIT-AI (Ken Harrenstien)
Subject: RUN MIDAS
To: RMS at MIT-AI
CC: (BUG MIDAS) at MIT-AI, MMCM at MIT-AI, EAK at MIT-AI


    RMS@MIT-AI 10/13/78 23:18:13 Re: RUN MIDAS
    To: KLH at MIT-AI
    I think that at least MIDAS should not do JCL rescanning
    if it can't recognize the command that ran it as being
    of a type that it understands.  Simplest would be that
    anything other than "MIDAS " as the beginning of the command
    would cause it to ignore the "command string".
    This might slightly inconvenience someone but at least
    it prevents anyone from being really screwed.

Well, there are all these ways of invoking it like [@]<NEW>MIDAS
and [@]midas.EXE.500  (with recognition) and so forth, which
the current algorithm (flush until space seen) handles adequately
and I'd like to keep that capability.  Perhaps MMCM has a
suggestion.  Perhaps the EXEC can be modified so that it clobbers
the RSCAN string to act just like ITS JCL, making sure thre is a
space at the start of the string (as normally there will be anyway).

Date: 12 OCT 1978 1822-EDT
From: GLS at MIT-MC (Guy L. Steele, Jr.)
To: JLK at MIT-MC, (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC
CC: BEE at MIT-MC

    Why does this crock persist that (when using .FASL)
    .ENTRY FOO SUBR 0001
    means a subr of no arguments (i.e. it is always one more than what it
    should be)?  Is there a reason for this?
The answer is that the number 0001 is the "internal format"
value of the ARGS property.  Niceness might have dictated
a better interface, but it suffices.  People write 0001
instead of 1 to remind themselves that a crock is happening.


Date: 12 OCT 1978 1634-EDT
From: JONL at MIT-MC (Jon L White)
Subject: .FASL format ".ENTRY FOO SUBR 0001"
To: JLK at MIT-MC
CC: (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC

I think that occurs due to the ease of modifying MIDAS, when RG first
put in the .FASL option.


Date: 12 OCT 1978 1632-EDT
From: JLK at MIT-MC (John L. Kulp)
To: (BUG LISP) at MIT-MC, (BUG MIDAS) at MIT-MC
CC: BEE at MIT-MC

Why does this crock persist that (when using .FASL)
.ENTRY FOO SUBR 0001
means a subr of no arguments (i.e. it is always one more than what it
should be)?  Is there a reason for this?


Date: 11 OCT 1978 2030-EDT
From: MRC at MIT-AI (Mark Crispin)
To: KLH at MIT-AI, (BUG MIDAS) at MIT-AI

Why would ANYBODY want to use the RUN command when the obvious right
thing that everybody does is DEFINE SYS: DSK:,SYS: ???

Date: 11 OCT 1978 1255-EDT
From: KLH at MIT-AI (Ken Harrenstien)
To: (BUG MIDAS) at MIT-AI


    RMS@MIT-AI 10/11/78 02:46:36
    To: KLH at MIT-AI
    Another bug in Twenex MIDAS is that if it is run with
    @RUN MIDAS
    then it decides to assemble MIDAS.

I'd consider this more of an EXEC screw, since MIDAS has no good
way of knowing all the subtleties of EXEC command line syntax,
and the goddam EXEC is simply passing on the whole last-line-input
to the RSCAN buffer.  I have trouble believing DEC's cretinism 
sometimes.  Anyway, poor MIDAS is throwing away the first word in
the belief it is a "MIDAS" (from [@]MIDAS FOO_BAR), and then
takes the rest of the line as it would ITS JCL, which explains 
its action for [@]RUN MIDAS.
  If you use RUN a lot, I guess you could kludge the RSCAN reading
routine.

Date: 10 OCT 1978 2326-EDT
From: KLH at MIT-AI (Ken Harrenstien)
To: (BUG MIDAS) at MIT-AI

There is a bug in the TNX version such that in certain circumstances
the char reader can somehow manage to skip over the EOF character,
and it either continues to read merrily into nothingness (or zaps
the read BP to a random location, I don't know which) and spews
out an amazing variety of error messages in response.  I suspect
the same bug may exist in the ITS version also but manages to
get caught after only one or two garbage characters.
I'll have to look into it sometime.

EAK@MIT-MC 09/29/78 19:30:34
To: (BUG MIDAS) at MIT-MC
MIDAS should put the filenames of all .INSRT'd files into the binary
information block.  If I remember correctly its all setup to take
variable length information so there should be no problem there.
Sometimes the version no.s of some packages are more important than
the main file so this info is needed.

RWK@MIT-MC 09/29/78 17:49:59
To: (BUG MIDAS) at MIT-MC
How about fixing the BININF info saved in BIN files to say AI: or ML: etc.
instead of DSK: ??


MOON@MIT-MC 09/28/78 21:38:19
To: (BUG MIDAS) at MIT-MC
CC: EAK at MIT-MC
    EAK@MIT-MC 09/28/78 18:37:24
    To: (BUG TECO) at MIT-MC, (BUG MIDAS) at MIT-MC
    CC: MOON at MIT-MC, RWK at MIT-MC
    I've figured out why TECO wasn't assembling correctly these days.
    The problem is that I assembled it on MC, a KL.  TECO wants to
    increment various byte pointers so it does:
    .AOP IBP,0,XX
    which on a KA leaves an incremented byte pointer in .AVAL2.  On a
    KL, however, an IBP with a nonzero AC is the ADJBP instruction!
    Thus it was doing the wrong thing.  One solution would be to
    use
    .AOP IBP,1,XX
    and if .AVAL2 is not equal to XX then use it, otherwise use .AVAL1.
Probably it would be better if Midas used AC 0 for assembly-time
instructions, or let the user specify.

I always knew someone would be shafted by the crockish way DEC
put in ADJBP, but I never suspected it would happen in this fashion.

EAK@MIT-MC 09/28/78 18:37:24
To: (BUG TECO) at MIT-MC, (BUG MIDAS) at MIT-MC
CC: MOON at MIT-MC, RWK at MIT-MC
I've figured out why TECO wasn't assembling correctly these days.
The problem is that I assembled it on MC, a KL.  TECO wants to
increment various byte pointers so it does:
.AOP IBP,0,XX
which on a KA leaves an incremented byte pointer in .AVAL2.  On a
KL, however, an IBP with a nonzero AC is the ADJBP instruction!
Thus it was doing the wrong thing.  One solution would be to
use
.AOP IBP,1,XX
and if .AVAL2 is not equal to XX then use it, otherwise use .AVAL1.


RWK@MIT-MC 09/24/78 19:39:16 Re: re-written file lossage
To: (BUG MIDAS) at MIT-MC
The lossage isn't rare with large files...I've had it happen 3 times to
me today alone.  If a file is large enough to take a few minutes, it's
very tempting to make more changes while waiting.  I'd find it very
helpful if some kind soul were to fix it.

On an unrelated question....what must I do to define new .BREAK 12, symbols
to MIDAS?  Will purifying it under the new DDT work, or do I have to put
it into a table in the source?  Is there anything special I have to know
to create an ITS MIDAS?  Are the current sources runable?  Are there volunteers
to do it for me?


Date: 24 SEP 1978 1930-EDT
From: KLH at MIT-AI (Ken Harrenstien)
To: RWK at MIT-MC
CC: (BUG MIDAS) at MIT-AI


    RWK@MIT-MC 09/24/78 16:09:06
    To: (BUG MIDAS) at MIT-MC
    On ITS, where it is possible to win, MIDAS shouldn't close and
    re-open the file between the two passes, but should just position back
    to the beginning, so if you've written a > file with a minor change
    in between passes you don't have to start MIDAS all over again.
    Maybe on other sites the file is closed at EOF, so it may not be possible
    to win elsewhere, but that's no reason to lose here....

This might be accomplished for the main file, and perhaps on TNX for
all files, but in general you can't win this way, because .INSRT
files are equally vulnerable to this (exceedingly rare) lossage
and ITS simply can't save anything like a JFN.  I've thought about
doing this for TNX just as a means of improving efficiency (with
large PMAP buffers, moderately-sized files would only be read once!) but
gave it up.

RWK@MIT-MC 09/24/78 16:09:06
To: (BUG MIDAS) at MIT-MC
On ITS, where it is possible to win, MIDAS shouldn't close and
re-open the file between the two passes, but should just position back
to the beginning, so if you've written a > file with a minor change
in between passes you don't have to start MIDAS all over again.
Maybe on other sites the file is closed at EOF, so it may not be possible
to win elsewhere, but that's no reason to lose here....


Date: 22 Sep 1978 1410-PDT
From: Mark Crispin <MRC at SU-AI>
Subject: Command line scanning   
To:   Bug-MIDAS at MIT-AI   

Tops-20 MIDAS seems to slurp command lines when run manually in the same
losing way as Tenex MIDAS does.  How about making it use RDTTY and/or
GTJFN hackery so display stuff (and maybe recognition) will win?



Date: 20 SEP 1978 0924-EDT
From: KLH at MIT-AI (Ken Harrenstien)
Subject: Bug I reported yesterday
To: MOON at MIT-MC
CC: (BUG MIDAS) at MIT-AI


    MOON@MIT-MC 09/19/78 23:01:59 Re: Bug I reported yesterday
    To: (BUG MIDAS) at MIT-MC
    MC:MIDAS;TSRTNS 181 fixes this bug, I believe.  Could someone who knows
    how to assemble, purify, install, and so forth Midas do so?  Or else
    patch OINIT+13 from TLNN to TLNE.  I must say, these TSRTNS are a
    complete and utter pile of shit. 

I moved the file to AI, which is where the master copies are (I never
even knew a MIDAS directory existed on MC, although I won't mind
keeping masters there instead), and assembled & etc'd into AI:MIDAS;TS MIDAS
which can simply be copied into SYS;TS MIDAS if it works for you.
BTW, if you want to know, just assemble MIDAS (no hair is ever necessary unless
you're cross-assembling), and start at PURIFY$G which valrets a
pdump.
	Sigh, I don't claim TSRTNS is wonderful but think it
stinks a lot less than the previous hackery.  If you tell me why it
loses maybe the next effort will be better.

MOON@MIT-MC 09/19/78 23:01:59 Re: Bug I reported yesterday
To: (BUG MIDAS) at MIT-MC
MC:MIDAS;TSRTNS 181 fixes this bug, I believe.  Could someone who knows
how to assemble, purify, install, and so forth Midas do so?  Or else
patch OINIT+13 from TLNN to TLNE.  I must say, these TSRTNS are a
complete and utter pile of shit. 

MOON5@MIT-ML 09/19/78 03:29:40
To: (BUG MIDAS) at MIT-ML
THE CURRENT VERSION OF MIDAS PUNCHES COMPLETE GARBAGE IF RIM10
IS USED.  THE BUG HAS BEEN PRESENT SINCE AT LEAST 8/22/78.
PLEASE FIX THIS AS sOON AS POSSIBLE.

EAK@MIT-AI 09/03/78 16:10:29
To: (BUG MIDAS) at MIT-AI
Why does MIDAS print out "SBLK Encountered", "RIM Encountered", or
"RIM10 Encountered"?  And why is there both .SBLK and SBLK?  What
is the difference?

Date: 31 Aug 1978 1231-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: Tops-20 EXE file format  
To:   Bug-MIDAS at MIT-AI   

MIDAS's .DECSAV feature loses on programs which use block structure.
If this is a permanent restriction, it should cause an error to use
block structure and documented as such.



Date: 31 Aug 1978 1135-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: MIDAS requires too many files 
To:   Bug-MIDAS at MIT-AI   

Fix:  Replace the .INSRT XJSYS with the contents of XJSYS.MID.  Consider
merging TSRTNS back into MIDAS main file.



Date: 31 Aug 1978 1133-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: Tops-20 MIDAS bug   
To:   Bug-MIDAS at MIT-AI   

MIDAS attempts to execute a CVHST JSYS, because Tops-20 always has a
LHOSTN table.
Fix:
In TSRTNS (179), page 43,line 10, before:
	JUMPE B,SITIN3			; Jump if none, not on net
insert:
	JUMPL A,SITIN3			; Tops-20 release 3 always has LHOSTN
This makes TSRTNS 180.

[End]



RMS@MIT-AI 08/31/78 01:23:07
To: (BUG MIDAS) at MIT-AI
I have put a new TWXBTS > on AI:SYS;
It was made from MIDAS;MONSYM > by using Convert MONSYM
and then deleting some things (jsys defs) and adding the first and
last pages.
Please check it over.

KLH@MIT-AI 08/28/78 23:14:41
To: (BUG MIDAS) at MIT-AI
Make that TSRTNS 179, I added a check to pull the site-name out
of the CVHST call if possible; if not on the net it will
give up and get it from SYSVER as before.  Apparently there
are places that put a lot of shit in SYSVER, BBN-A/B/C/D/E for one.

Date: 28 AUG 1978 1843-EDT
From: KLH at MIT-AI (Ken Harrenstien)
Subject: .SITE
To: EKILLIAN at BBN-TENEXE
CC: (BUG MIDAS) at MIT-AI

Sigh, this was an outright bug on my part (gave wrong AC to GETAB call).
Fixed that and also added a little check so that you get only
the site name, rather than the whole cruft like "SRI-KL,
 Tops-20 monitor 101-B V1234 EXEC314159 etc etc".
Snarf a new MIDAS;TSRTNS >.
As for changing the format of .SITE I dunno.  I certainly won't have the
time this week or next to think about it.

KLH@MIT-AI 08/28/78 17:40:31
To: EAK at MIT-AI
CC: (BUG MIDAS) at MIT-AI

    EAK@MIT-AI 08/27/78 14:58:11
    To: (BUG MIDAS) at MIT-AI
    I assembled a 10X version of TECO on ITS and all went well.  However it
    called the output file TECO BIN; wouldn't TECO SAV or TECO EXE have been
    better?

The latest version of MIDAS (which is not yet installed on ITS) will
do this.

Date: 28 Aug 1978 1113-EDT
From: EKILLIAN at BBN-TENEXE (Earl A. Killian)
Subject: .SITE
To:   Bug-MIDAS at MIT-AI

Why does .SITE return
"__X__X__X__X__X"
on my 10X?  Thats very random.

Also, how about changing the way .SITE works.  It shouldn't take an
argument, it should just return the whole thing like SIXBIT does.
You could use .NTHWRD to be like .SITE n.  Also you could then do
.SITE and get the whole thing.
Thus, .SITE would be identical to SIXBIT/SITE-NAME/.  If you used it
in an expression the value would be truncated to one word, just like
SIXBIT.  If you used it to generate storage words then it would take
as many as necessary, like SIXBIT and ASCII.  Finally if you wanted
the effect of .SITE n then you could trivially get it with .NTHWRD.

Sorry if this is a bit rambling.
-------

EAK@MIT-AI 08/27/78 14:58:11
To: (BUG MIDAS) at MIT-AI
I assembled a 10X version of TECO on ITS and all went well.  However it
called the output file TECO BIN; wouldn't TECO SAV or TECO EXE have been
better?

KLH@MIT-AI 08/21/78 12:13:41
To: (BUG MIDAS) at MIT-AI
CC: MMCM at MIT-AI
MIDAS 409, TSRTNS 176 fix BLOCK -n and FOO;T_BAR
respectively.  Not tested or installed yet.
Diffs in MIDDIF 408409 and TSRDIF 172176.

KLH@MIT-AI 08/20/78 03:20:23
To: MMCM at MIT-AI
CC: (BUG MIDAS) at MIT-AI

    MMCM@MIT-AI 08/18/78 20:22:38
    To: KLH at MIT-AI
    ;T in the command line does not make the output file temporary.

How about that, you're right.  Guess I'll look and see why.
I assume the foo_bar construct in the JCL is what you wanted, though?

KLH@MIT-AI 08/18/78 18:27:05
To: MMCM at MIT-AI
CC: (BUG MIDAS) at MIT-AI
Anything wrong with something like
[@]MIDAS foo;t_bar
i.e. just specify another FN1 in the command line, and if you
want "temporary" in the true sense just add ";t".
I don't think the source code should specify where its output should go,
even as a default.
Creating a separate symbols-only file would be a more reasonable idea,
but you'll still be GET'ing and SSAVE'ing the bin file, so I don't
know if that would gain you anything.

MMCM@MIT-AI 08/18/78 16:49:05
To: KLH at MIT-AI, (BUG MIDAS) at MIT-AI
"." IS THE ONLY CHARACTER WITH OTHER SYNTACTIC INTERPRETATIONS THAT IS
LEGAL WITHIN THE <>'S OF A DIRECTORY NAME, YES, WHICH IS WHY I JUST
PUT IT IN TO USE THE EXISTING ROUTINES.
IT WOULD BE NICE IF .SBLK AND .DECSAV HAD A WAY TO SPECIFY THE FN1 OF
THE .EXE OR BIN FILE, SINCE E.G. I DONT WANT TO WRITE A TECO.EXE, BUT
RATHER SOME TEMPORARY FILE THAT WILL THEN GENERATE THE REAL (SHAREABLE)
TECO.EXE.

KLH@MIT-AI 08/18/78 06:09:38
To: MMCM at MIT-AI, (BUG MIDAS) at MIT-AI
I have put in the appropriate output-fn2 defaultings for SBLK, etc;
DECSAV on ITS will hae FN2 of SAV; SBLK on non-ITS will hae FN2 of SBK.

I am willing to make BLOCK -n generate an error if nobody objects.

Mike, did you hack the <foo.bar> directory-name parsing thing?
Random things like that should be mentioned in a message; it makes it
easier to figure things out, especially when some code doesn't work
and it's not clear who put it in.  Is "." the only strange character
that might be encountered?

Date: 17 AUG 1978 1829-EDT
From: KLH at MIT-AI (Ken Harrenstien)
Subject: feature
To: EKILLIAN at BBN-TENEXE
CC: (BUG MIDAS) at MIT-AI

We have mumbled in the past about system independent ways of
asking for filename components, such as having .FVERS MAIN,
give you version # of main input file, or some more general
pseudo.  As I recall this trailed off in the hope that a
"string" data type would evolve, with which one could truly win.
	I'm not sure if preserving the version # is reasonable.
What would you do if a .SAV.nn file already existed - replace
it or use next higher number?  What if .SAV.nn didn't exist, but
.SAV.nn+m did?  Just checking for such cases is a pain.  Myself
I rarely need such info; 20X provides directory listings sorted
by creation date if you like, which is somtimes more useful.
Having a version # available to the program via pseudo would
help, of course.

Date: 17 Aug 1978 1652-EDT
From: EKILLIAN at BBN-TENEXE (Earl A. Killian)
Subject: feature
To:   Bug-Midas at MIT-AI

It would be nice if MIDAS had something akin to TECO's FS IF VERSION, i.e.
something which would be the version no. of the source file.  On ITS it
would be the FN2 converted to a numeric no.  On TNX it would be the file's
version no.

Right now most programs that assemble on TNX and want their version no.
ask for it (and TECO has to be called TECO.nnn instead of TECO.MID so
that it will be able to get it).  This would eliminate the need to ask.

RMS, what does FS IF VERSION return for non-numeric FN2's on ITS?  Should
MIDAS do the same thing?

Finally, it might be nice if MIDAS's command line hackery defaulted the
output filename to FOO.SAV.nnn where nnn is the version no. of the input
filename.  It would save renaming FOO.SAV.1 to FOO.SAV.nnn after the
assembly.
-------

MMCM@MIT-AI 08/12/78 07:58:39
To: (BUG MIDAS) at MIT-AI
i think the clu problem should be fixed now.

MRC@MIT-AI 08/10/78 16:24:51
To: KLH at MIT-AI, MMCM at MIT-AI
CC: (BUG MIDAS) at MIT-AI

    KLH@MIT-AI 08/10/78 12:10:19

    You can't expect us to debug anything on MIT-XX if you won't let
    us log into the machine.

RIGHT!!!

KLH@MIT-AI 08/10/78 12:16:06
To: MMCM at MIT-AI
CC: (BUG MIDAS) at MIT-AI
    .sblk should not generate files with the extension EXE on 20X, but rather something
    like SBLK

Uh huh.  I seem to recall there was a 3 letter extension for it listed
in a 10X manual once, but I can't find it again; probably .SBK will
do.

KLH@MIT-AI 08/10/78 12:10:19
To: MMCM at MIT-AI
CC: (BUG MIDAS) at MIT-AI, rra at MIT-DMS

    MMCM@MIT-AI 08/10/78 05:27:21
    To: KLH at MIT-AI
    CLU is exercising a 20X only bug in the new midas that causes phase errors.
    i have the files here since mit-xx isnt on the net very often, they are
    CBUF > -> CBUF.MID
    ALPHA > -> CLU:ALPHA.MID
    OMEGA > -> CLU:OMEGA.MID
    PASS1 > -> <CLU>PASS1.MID
    TYPES > -> <CLU>TYPES.MID
    COMMON > -> <CLU>COMMON.MID
    JSYS SYSDEF -> <CLU>JSYS.SYSDEF
    or some such mapping, if you want to try shipping them there to test it.  there are
    infintely hairy macros involved and lots of faking out the constants area.  it assembles
    fine under ITS.  RRA might have some more ideas of what exaclty is going wrong.

You can't expect us to debug anything on MIT-XX if you won't let
us log into the machine; otherwise you'll have to give more information
and settle for very slow debugging.
   What version of MIDAS was losing?  There was one TNX specific bug
that existed for a while which is now fixed, but I can think of
one or two other ways in which the 20X version could assemble
differently.

MMCM@MIT-AI 08/10/78 04:52:27
To: (BUG MIDAS) at MIT-AI
.sblk should not generate files with the extension EXE on 20X, but rather something
like SBLK

MMCM@MIT-AI 08/08/78 04:16:33
To: (BUG MIDAS) at MIT-AI
i am not sure that just moving . is the right thing for the BLOCK pseudo to do;
specifically a negative argument should perhaps cause an error.  This is what
FAIL does.  (MACRO only checks for this error condition on pass 2 for no reason
that i can figure!)
the case where this arises is BLOCK 1000-<.-MUMBLE>  where you've got too much
code after MUMBLE.

KLH@MIT-AI 08/08/78 03:56:53
To: (BUG MIDAS) at MIT-AI
OK, MIDAS 408 and TSRTNS 172 appear to work fine on SRI-KL.
A srccom of differences from 405 and 171 is combined in
MIDAS;MIDDIF 405408 (skipping 406).  I judged it better
to smash the .OSMIDAS symbol value before spreading
the symbols rather than making it an "internal symbol",
so as to avoid breaking programs that do .OSMIDAS==SIXBIT/FOO/.
Sigh.


RMS@MIT-AI 08/05/78 18:27:27
To: KLH at MIT-AI, MRC at MIT-AI
I don't agree that, in processing a MACRO universal file,
not understanding macros would be a significant disadvantage.
So what if there are macros in MONSYM?  Those macros are not
present in DECBTS or TWXBTS, so the lack of them can't be too bad,
and won't make things any worse than they are now.
If we make MIDAS able to read and write MACRO universal files
(actually we can do without writing), ordinary numeric symbols only,
that will make things a lot more convenient for us.  It could be
smart enough to detect conflicts between symbols in the universal
file and predefined MIDAS symbols, and prefer the latter.  Then there
would be no trouble with .SYMTAB.  Since some losing sites delete the
universal files supplied by DEC, we can just supply copies of them
with MIDAS.

Alternatively, I think we should use a TECO macro to convert a MACRO
file into a MIDAS one.  Making MIDAS understand the mBn construct
would not eliminate the need for this, since we would still have
to put in the calls to DEFSYM.  It would make the TECO macro simpler,
but we would still need to perform a conversion.  So we might as
well put it all in the TECO macro and not change MIDAS.  I will
write the macro now.

Of course, reading universal files is only for the future.
Right now the problem has to be fixed some other way, so you might
as well just do so the way you plan to, without further discussion.

If we decide we really want to provide some macros as well as
symbols, we can always have a .INSRT file which defines the macros
and then gobbles the DEC universal file for the other symbols.
KLH@MIT-AI 08/05/78 05:48:56 Re: Universal files
To: RMS at MIT-AI, MRC at MIT-AI
CC: (FILE [MIDAS;MIDAS BUGS]) at MIT-AI
I've thought about this too, but there ae a number of problems
which would need solving.
	First, as far as understanding DEC's universal file format,
FAIL doesn't and MIDAS would have a lot of problems doing so,
because the symbol table structure is so different.  Also it
turns out to be fairly important that macros be preserved, since
DEC defines some which are used a lot in user programs (prime
example is .FLDDB which sets up args for the COMND JSYS).
Granted it would be an amazingly impressive hack, if anyone bothered.
	So it would be better for MIDAS to have its own format
not only for speed but for macro-saving capability as well.  But
here again there are problems because we can't just run MIDAS
over the DEC MONSYM source file; it uses various macros and
lots of nBm value constructs and the like.  This is why MRC
consed up the equivalent for MIDAS by hand (!!).  Naturally this
is not what we want to do either.

	My suggestion here would be to concentrae on the immediate
problem (getting symbol definitions into MIDAS) and worry about
universal file capability later, by making it easier to snarf
DEC symbol definition files into MIDAS-readable format; the more automatic
this can be made, the less hassle we'll have.  Basically I have
two suggestions:
	(1) define a pseudo which enables MIDAS to read nBm values,
	and likewise to stop recognizing them.
	(2) write and document a TECO macro which will make the
	minor changes necessry to MONSYM.MAC; this will need
	to be changed only when the MACRO macros are
	substantially modified.  This teco macro will also
	insert DEFSYM's in the appropriate places.

Then we .insrt the file twice into MIDAS, once for the definitions
and once for the symbols alone, not bothering to evaluate them
the second time but just using the scheme of storing the value as
defined on the first .insrt.  This avoids the pain of trying to
change the monsym.mac format so that DEFSYM can pluck out the value alone,
making it much easier to write this teco macro.

Reading nBm values will of course break existing programs, which is
why we will make it a normally-off switch and let the source
code turn it on and off.  I haven't thought of a reasonable name
for the pseudo(s) but that shouldn't take long.
This will also make it a lot easier to snarf and convert TNX routines
by the way, not that I'm in love with the stupid syntax.


RMS@MIT-AI 08/04/78 20:42:21
To: MRC at MIT-AI, KLH at MIT-AI
Looking at the comparison of MIDAS with FAIL and MACRO,
it seems to me that FAIL and MACRO win in that the way
to specify which symbols to use is independent of whether
you are assembling on the same system of a different one.
But they lose in that only the symbols you use
are defined in DDT.  Clearly, they should all be in DDT.

So, unless people can fix DDT (unlikely), MIDAS should put
all of the system symbols in the binary, for best results.

However, since any user can request this for himself by
doing the .insrt, we need not put this in MIDAS.  We should
just change the documentation to point out that this is possible.

The other possible advantage of FAIL and MACRO is that universal
files are at least potentially much faster than .insrt files,
especially .insrt files which are being parsed by DEFSYM.
So maybe we should make MIDAS able to read and write universal
files.  It would read them by looking at them and putting the
data in the regular symbol table.  Of course, macros wouldn't
have to be made to work, and macros in universal files written
by MACRO almost certainly wouldn't work, but that doesn't matter
as long as they are ignored reasonably.

Then users would write in MIDAS just as they write in FAIL or MACRO,
except that the symbols would go in the user symbol table, which is
even better (of course, there could be an option saying whether to
.KILL the symbols being gobbled).  An additional advantage would
be that we would not have to maintain any more defs files.
We could just copy DEC's defs files.
  
MRC@MIT-AI 08/04/78 19:00:44
To: RMS at MIT-AI, KLH at MIT-AI
FAIL and MACRO only put into the symbol table those system symbols and
bits which the program actually used.  UUO's which are opcodes are
included always since DDT knows about them, but it doesn't know about
extended things.  In other words, JSYS, CALLI, and OPEN are known, but
OUTSTR or SOUT or EXIT aren't known unless the program does one, which
is quite a screw.  I suspect it is DEC trying to bum a K or two.  Sigh.

FAIL and Stanford DDT should know better, but they don't.
 Date:  4 Aug 1978 1946-PDT
From: Klh at SRI-KL (Ken Harrenstien)
Subject: ( Forwarded Mail )
To:   [midas;midas bugs] at AI

Mail from SU-AI rcvd at 4-Aug-78 1939-PDT
Date: 4 Aug 1978 1938-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: universal files in MIDAS
To:   RMS at MIT-AI, KLH at SRI-KL    

[just a side note, MIDAS compiles TWXBTS faster than MACRO searches (reads
a universal file) MONSYM!!!]

Well, reading a universal file sounds like a win, although I would prefer
that it would be done intelligently.  In particular, DEC cretinously
introduced a symbol called .SYMTAB into MONSYM.  Its purpose in life isn't
terribly justifiable, and in fact it should NOT be used on Tenex at all, so
I flushed it when I made TWXBTS.  Another problem is that I would prefer not
to have to say .SEARCH MONSYM in my programs; SYS:MONSYM.UNV should always
be read in (and, I guess, dumped out) in the Twenex version (in Tenex, you
read <SUBSYS>STENEX.UNV instead).  I think it is safe to assume that this
file would be present.

What to do about the DEC systems is a bit harder.  The true right thing to
do at SAIL is to get them from the monitor.  Look at the CALLIT UUO writeup
on page 113 of the UUO manual, and low core location 272 on page 260 (in
Appendix 3).  FAIL knows about the UUO's and gets the CALLI's only, but it
is possible using CALLIT to get all the UUO's with appropriate heuristics.
An alternative way is to do a CALLIT on any symbol which would be otherwise
undefined; this of course means a system call has to be done for every UUO
(or undefined symbol) in the program.  Actually no matter what you do it is
almost too horrible to comtemplate, depending on where your values are.

On Bottoms-10, you would try to snarf UNV:UUOSYM.UNV.  If that fails, try
UNV:C.UNV.  If that fails, try device SYS: instead of UNV:.

As for the cases where you can't get at the file, well, on Tenex and Twenex
I think it is safe to assume the file would exist.  Bottoms-10 is another
story (unfortunately); some cretinous business systems actually have deleted
the files (to my unending chagrin).  A safe alternative is to continue the
basic DFS files (both DECBTS and TWXBTS are out of date by now), to at least
provide in a bare MIDAS what MACRO provides.  If we go the universal file
route, I do have a universal file for ITS on DECSYS;SITS MAC and SITS UNV--
DFTP uses it, although no ITS bits are included in it.

An alternative approach is to continue as we have done, except that we will
attempt to get up to date copies of UUOSYM and MONSYM from DEC to update our
files.  That may end up as the best way.

One last note before I end this over-long message; in any case, MIDAS should
dump out its symbol table in the system-dependant crud since there is no
hope of fixing DDT.

-- m


-------

KLH@MIT-AI 08/04/78 18:40:17 Re: symbols
To: MRC at MIT-AI, RMS at MIT-AI
CC: (BUG MIDAS) at MIT-AI
Let me see if I can get things straight.  This is only a
first pass, is incomplete with respect to comparisons with FAIL/MACRO,
and has no conclusions.  Comments welcome.

Case IA: User program to run on assembly system.

	This is the majority of cases; for example, assembling
	FOO on ITS to run on ITS, or BAR on 20X to run on 20X.
	The MIDAS philosophy seems to be that no system symbols
	should have to be .insrt'd, and they shouldn't be written
	out in the program's symbols.
	FAIL and MACRO, on the other hand, make use of UNIVERSAL
	files (extension .FUN and .UNV respectively) which are
	explicitly requested by the user program with a SEARCH pseudo.
	Hence the "SEARCH MONSYM" you see for Macro programs.  Read
	up on these in MACRO or FAIL documentation.  Any symbols
	which are used by the program are written out in its symbol
	table; unreferenced ones are not.

Case IB: User program to run at another system. (Cross-assembly)

	MIDAS requires the user program to .insrt one of
	the standard sets of symbol definitions, depending on
	what system one is assembling for.  These symbols are
	included in the outputted symbol table for the program,
	unless .KILL'd.
	For FAIL and MACRO one just SEARCH's the appropriate
	universal files instead of the normal MONSYM or MACSYM.
	Essentially this is no different from case IA.

Case IIA: MIDAS to run on assembly system.

	The basic difference between MIDAS and a random user program
	is that during the assembly the symbols which are to be pre-defined
	must be assembled into the initial symbol table.  This
	is why DEFSYM exists, so that one can deposit symbol names and
	values into the storage area reserved for initial symbols.

	Since by definition in case IA MIDAS has all of the
	system symbols pre-defined, one could get away with just knowing the
	symbol names, and letting the assembling MIDAS furnish the
	values.  This will work unless some new symbols have
	been added or some values have changed.  Thus it is
	still necessary for DEFSYM to pull out the value, and if
	the MIDAS being assembled uss one of the new symbols, it is
	also necessary to define them at start of assembly, just as for
	a cross-assembly.

Case IIB: MIDAS to run on another system. (cross-assembly)

	Clearly it is necessary to both .insrt the symbols as
	a means of defining them (so that the code will assemble properly)
	and to put them in the initial symtab area of the assembled
	MIDAS.  In this case, it is reasonable for the DEFSYM macro
	to let the assembling MIDAS furnish the value (since the symbol has
	been defined by the first .insrt).

KLH@MIT-AI 08/04/78 00:56:25
To: (BUG MIDAS) at MIT-AI
A while ago I started up a MIDAS on AI to assemble a tenex version,
to get an error file output etc; the result is MIDAS;MIDAS BIN
(and ERR).  There is one assembly error shown in ERR.  I imagine
it can be fixed in TWXBTS.  However, the other problem is that
if you use the resulting midas (on a tnx of course) to assemble
a program, all jsys's have turned into 104 (instead of 104000,,x)
I thin ecause the IRPS hangs up before the bit-shift operand
is seen (tnxdfs file).  Is there any form of IRP that will
properly isolate the value?  I have never had anything to do
with the way initial symbols are defined so I much prefer to
let the author(s) of the code in question have at it.

MRC@MIT-AI 08/03/78 19:57:49
To: (BUG MIDAS) at MIT-AI
CC: EAK at MIT-AI
I certainly did not do any of those losing changes to MIDAS' DEFSYMM.
KLH, please fix it back (and flush that losing expression in the beginning too
while you're at it.

KLH@MIT-AI 08/03/78 18:04:44
To: (BUG MIDAS) at MIT-AI
CC: EAK at MIT-AI
All right, who clobbered the DEFSYM macro?  That screwed up assembling
TNX version.  Unless there is a good reason I'll just change it back.
Also why were the older sources flushed?  Fortunately I retained a
MIDAS 402 on SRI-KL to compare 405 with; did someone's EMACS macro automatically
flush older versions or smething?  (This screwed Moon too when
he tried to find an old MIDAS).  

Date: 2 Aug 1978 2301-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: RG's $. idea  
To:   Bug-MIDAS at MIT-AI, RG at MIT-AI    

I agree completely.  FAIL has this feature in relocatable assemblies and
wins just fine with it, and I would think absolute assemblies would be
easier since on pass 2 MIDAS should know where the storage word is going
to be(?).
By the way, is it still true that -<relocatable value> loses with DEC's
LINK?  A program of mine needs to compute the number of bytes accumulated
in a buffer from the byte pointer and does a MOVEI AC,-START(PNTR) to get
the number of words to start off with.  I ended up making the program an
absolute assembly since it's a Twenex program (so relocatability doesn't
matter!) and it turned out I wanted to do LOCs to start on different pages,
but it would be nice to know if the restriction is still necessary.  Or is
it a MIDAS loss?



RG@MIT-AI 08/03/78 01:07:44
To: (BUG MIDAS) at MIT-AI
   IT WOULD BE NICE IF $. INSIDE CONSTANTS WORKED IN AN ABSOLUTE ASSEMBLY.
IE IT SHOULD GIVE YOU THE LOCATION IN THE CONSTANTS AREA WHERE THE CURRENT
STORAGE WORD WILL BE PUT.

KLH@MIT-AI 08/02/78 18:08:58 Re: .OSMIDAS => TENEX/TWENEX
To: (BUG MIDAS) at MIT-AI
CC: eak at MIT-MC

    EAK@MIT-AI 08/01/78 21:58:11 Re: MIDAS
    To: KLH at MIT-AI
    How about changing MIDAS's .OSMIDAS to return either SIXBIT/TENEX/ or
    SIXBIT/TWENEX/.  I find the current scheme where they're undifferentiated
    pretty bothersome.

I would agree with this; 10X and 20X ARE different systems no matter how
much we would like programs to remain runnable on both.  There is probably more
difference between 10X and 20X than between CMU and DEC.
The only question is whether TENEX and TWENEX are the names we want to
use.  I can't think of anything better, though.

MOON@MIT-AI 07/31/78 09:22:51 Re: Yet more about how I am getting shafted by new Midas
To: (BUG MIDAS) at MIT-AI
I don't think putting this "debugging info" lossage after the symbol table
will help.  How about putting it after the second starting address, or flushing
it entirely, or not starting it with an aobjn pointer, or putting it in the
complete crud at the front of the file before the JRST 1.  Or at least document it.

MOON@MIT-AI 07/31/78 09:17:19 Re: Previous bug
To: (BUG MIDAS) at MIT-AI
Aha, I found some documentation about a "debugging info block"
in INFO; MIDAS ARCHIV, which didn't say anything about its format.
I'm pretty sure this is what is screwing me.  Please fix Midas to
put this after the symbol table, instead of before, so that it will
not confuse NTSDDT and DSKDMP.

MOON5@MIT-MC 07/31/78 09:11:31
To: (BUG MIDAS) at MIT-MC
SOMEONE CHANGED THE FORMAT OF MIDAS OUTPUT WITHOUT
ANNOUNCING IT, AND WITHOUT CREATING ANY DOCUMENTATION,
AND WITHOUT LEAVING THE OLD VERSION AROUND SO I COULD
SRCCOM IT.  IT IS NO LONGER POSSIBLE TO ASSEMBLE ITS
AND HAVE IT WORK.  PLEASE CHANGE IT BACK OR DOCUMENT
THE CHANGE POST HASTE.

KLH@MIT-AI 07/27/78 10:44:43 Re: Another TNX MIDAS
To: (BUG MIDAS) at MIT-AI
CC: EAK at MIT-AI, DANG at MIT-AI
I've updated MIDAS (to 402) to reflect my current understanding
of DEC symbol-table formats; this only influences people who
debug .DECSAV-produced block structured programs, and to the
best of my knowledge (as per DEC LINK loader reference manual)
the MIDAS-produced format is in exact conformance.
  I also fixed a bug in the new ITS code for outputting a debug-info
block (user,date,filenames); it would have clobbered stuff if
actually invoked.

Date: 24 Jul 1978 2303-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: nBm construction in MACRO and FAIL
To:   KLH at MIT-AI, Bug-MIDAS at MIT-AI   

I don't think that it is worthwhile to do this.  No matter how it is done,
I don't believe it can be done in a way which will avoid all the screw
cases.

When I converted MONSYM to TWXBTS, it was the result of many gruesome hours
of thankless effort.  My difficulty was excerbated by my communications link:
an ADM-3A via the NYU-ELF via CRTSTY (cretins all) to EMACS, all at 300 baud.
Converting from version 1 to version 2 was done by making a SRCCOM of the
two MONSYMs, then MANUALLY typing in the new entries (with, as you may have
noted, the GETAB mnemonics commented out since DEC wisely called one of them
.SYMTAB!!!!).

I would like to see a version 3 version of TWXBTS, but I sure as hell don't
intend to do it this time.

--m



Date: 24 Jul 1978 2252-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: additional instructions in MIDAS  
To:   MMcM at MIT-AI, Bug-MIDAS at MIT-AI  

Not everybody has castrated their microcode, and in this day and age KA's
are just about obsolete; it's enough that MIDAS will still run on them.
I in fact have accounts on uncastrated KL's which are soon going to get
the multiple-field capability.  I haven't yet had the need for a core
image greater than 256K, but the extended instructions are winners:
CMPSE is an especial winner in this respect.

Even though it is hopeless to get the world to convert from MACRO to
MIDAS, there is no reason why we should give them any reason to use
MACRO other than "DEC supports MACRO" (titter, giggle, chuckle, guffaw...).



Date: 24 JUL 1978 1947-EDT
From: MMCM at MIT-AI (Mike McMahon)
To: (BUG MIDAS) at MIT-AI, EKILLIAN at BBN-TENEXE


    Date: 23 Jul 1978 2011-EDT
    From: EKILLIAN at BBN-TENEXE (Earl A. Killian)
    To:   Bug-TECO at MIT-AI

    Assembling TECO 656 with MIDAS 400 gets an error because TECO uses "EDIT"
    as an instruction label.  Either TECO should use another name or a
    IF1 EXPUNGE EDIT should be added at the beginning.
    -------
i really dont see why all the kl EXTENDed instrs should be included at all.

KLH@MIT-AI 07/23/78 02:26:37
To: (BUG MIDAS) at MIT-AI
By the way, just for the record, the # of symbols that gets printed
out at end of assembly is a lie.  For example during assembly of an
ITS verson of MIDAS, the # syms as returned by A.SYMC was 3558 upon
calling PSYMS to punch out the symbols, and 4787 afterwards; apparently
the symbol table compaction/sorting done for SBLK and DECSAV formats
leaves some cruft around.  I noticed this when the # syms reported
for various programs suddenly jumped when I began assembling with
DECSAV format.
  It's not a crucial bug but can easily be fixed sometime.
It would probably be nice also to print out the # o symbols actually
punched out; for absolute assemblies this is trivial, for relocatable
ones slightly harder I think.


EAK@MIT-MC 07/18/78 22:35:48 Re:  MIDAS .SAV output
To: KLH at MIT-MC
Perhaps instead of having lots of pseudos like .DECSAV you want
one pseudo that takes an argument saying which format to use?


KLH@MIT-AI 07/18/78 20:20:22 Re: PDUMP, DMP files etc
To: RMS at MIT-AI, MRC at MIT-AI, eak at MIT-MC
CC: KLH at MIT-AI
Of course, if anyone really wanted MIDAS to produce PDUMP or
sharable 10X/20X files it won't be too hard.  All that is
necessary is a page mapped into an inferior process which
you then deposit into, changing the mapping as necessary,
and finally wrapping it up with a PDUMP (or SAVE) call, making it
unnecessary to know very much about sharable file format.  EAK
has suggested that it could evven be purified with suitable macros
before PDUMPing.
  I wonder if this would be any faster than current output scheme,
probably insignificant. Can think of a nmber of more useful things to
do anyway.
   I doubt if producing a DMP file for SAIL will ever be reasonable,
likewise SHR fils for T10, because you can't have an inferior address
space to deposit into (unless you do strange things with random
access writes to a file).
  The .DECSAV format writes out to .SAV on T10 and 10X, .EXE on 20X,
and should be runnable on all - but not sharable of course.  In
this respect it is just like ITS where you have to e.g. do a PURIFY$G
and then :PDUMP it back out.  One other thing about it is that it
eliminates the space taken up by intermediate .REL files, which isn't
trivial for large programs and tight quotas (grumble grumble).
   Incidentally does anyone happen to know why it turns out that
ITS and DEC symbol table formats are so different - apart from the
fact that DEC right-justifies its SQUOZE, the structuring of symbols
for blocks is almost exactly the reverse of ITS's (I think).  There
are also a couple f minor inconsistencies with respect to program names
and block names.  I wonder where this all started.
  
RMS@MIT-AI 07/17/78 22:55:23
To: KLH at MIT-AI
I am surprised that you are working on .DECSAV.
I do not think it should be the default.
I certainly don't think that the meaning of
any of the mode-selecting pseudos should depend
on the system you are using.  It is just as easy
for people to say .DECREL as it is to say RELOCATABLE.
   
Date: 17 Jul 1978 1956-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: MIDAS SAV stuff    
To:   KLH at MIT-AI, RMS at MIT-AI, MMCM at MIT-AI
To:   DANG at MIT-DMS, HIC at MIT-MC, EAK at MIT-MC

 ...
Absolute assemblies should select .DECSAV; relocatable ones should
select .DECREL.
 ...
-------
    
RMS@MIT-AI 07/17/78 23:05:39
To: KLH at MIT-AI
By the way, there are several things in my RMAIL file from
you and other people about MIDAS, if you are in the mood to
hack it.  One thing that might be doable would be labels
inside literals, by making them save up some sort of reminder
to define the symbol later when the location of the literal is
chosen.  Because it can legitimately happen that literals
which are distinct on pass1 collapse on pass 2, it would be
necessary to detect on pass 2 that the literal contained
a label, and advance the location counter if necessary to
make the label match up with its pass 1 value.  If you had
to decrement the location counter, that would be an error,:
since that shouldn't ever be necessary, and if it were necessary
it could cause lossage as things are now.
The symbol "." will probably still have to refer to the
location outside the literal.
   Date: 22 JUL 1978 0536-EDT
From: KLH at MIT-AI (Ken Harrenstien)
Subject: Sorry but...
To: TAPPAN at BBN-TENEXA
CC: (BUG MIDAS) at MIT-AI

    if you examine the info file on midas, on the third page of
    the menu item "Invoke", is a chauvanistic, uncalled for,
    and as it happens untrue, attack on the t(w)enex
    GTJFN scheme.

No, it's true that Twenex cannot provide this defaulting if you
try to GTJFN the filename from the terminal directly.  Remember
all of these specs are on a single line and you don't have
the default for the output until after you've read the input filespec!
I didn't write that documentation, but I did write the TNX code.

Date: 19 Jul 1978 2018-EDT
From: TAPPAN at BBN-TENEXA (dan tappan)
Subject: a slight idea
To:   klh at AI
cc:   bug-midas at AI

 -- Messages from file: [BBN-TENEXA]<TAPPAN>MAIL.TXT.1
		 -- Wednesday, July 19, 1978 13:35:14 --

Mail from MIT-MC rcvd at 19-Jul-78 0414-EDT
KLH@MIT-AI 07/19/78 04:14:20
To: TRAPR at MIT-MC
CC: (BUG MIDAS) at MIT-AI

    TRAPR@MIT-MC 07/18/78 23:28:26
    To: (BUG MIDAS) at MIT-MC
    just a note to whoever wrote the info file, twenex can default
    whatever you like (assuming you write the program right)

I am reasonably sure that none of us understands in the slightest what
you are talking about... at least I don't.


___________

if you examine the info file on midas, on the third page of
the menu item "Invoke", is a chauvanistic, uncalled for,
and as it happens untrue, attack on the t(w)enex
GTJFN scheme. this really isn't something that belongs
in a self-respecting documentation file.
(in sending this as a bug i've been assuming that
documentation is written by someone who knows something
about the program, i.e. a maintainer. if in actuality
there's someone out there writing documentation
with no such connection then i apologize for bothering
you with it)

dan
-------

KLH@MIT-AI 07/19/78 04:14:20
To: TRAPR at MIT-MC
CC: (BUG MIDAS) at MIT-AI

    TRAPR@MIT-MC 07/18/78 23:28:26
    To: (BUG MIDAS) at MIT-MC
    just a note to whoever wrote the info file, twenex can default
    whatever you like (assuming you write the program right)

I am reasonably sure that none of us understands in the slightest what
you are talking about... at least I don't.

TRAPR@MIT-MC 07/18/78 23:28:26
To: (BUG MIDAS) at MIT-MC
just a note to whoever wrote the info file, twenex can default
whatever you like (assuming you write the program right)


----------------------------------------------------------------
Messages about MIDAS bugs from RMS' mail.

EAK@MIT-MC 07/10/78 23:14:42
To: (BUG MIDAS) at MIT-MC
Why does IFNDEF 0 succeed?  I would think that no.s would always be
"defined".  This was a screw when I used it in a macro which did
something like:
	.TTYMAC F
	  IFNDEF F,[ ... ]
	  FLAG==F
	TERMIN
etc.


Date: 16 Aug 1977 0505-PDT
From: MRC at SU-AI (Mark Crispin)
Subject: Bug MIDAS
To:   RMS at MIT-AI    

MIDAS treats grave accent (`) as question mark, ie, it says new word.  I
accidently typed ` when I meant ' and got no message, and in general was
screwed.

-------

DATE: 3 APR 1977 1121-EST
FROM: AS at MIT-DMS
SUBJECT: FEATURE MIDAS
ACTION-TO: (FEATURE MIDAS) at MIT-DMS
MESSAGE-ID: <[MIT-DMS].49455>

I would like a way to make IRP not strip off [] brackets
around elements of a list.  Is there an easy way to do
this?  Perhaps, one should be able to write

	IRP [D],,[1,[2,3],4]

where the [D] guides the scan, as for real macro dummy
arguments, so that D gets bound to "1", "[2,3]", and "4".


Moon@MIT-AI (DLW) 08/04/76 17:28:37
To: BUG-MIDAS at MIT-AI
I'm not sure if this is a bug, but I think it used to work.
IRPW fails to consider tabs preceding semicolon as part of the comment,
and IRP FOO,,[<tab>] IRPs once, with FOO bound to just tab.  So the effect
is that a line containing just an indented comment, being picked up
by a whole-line type macro and decommentified by IRPW, appears to
contain something and screws up the macro which is expecting to
IRP over symbols.



MOON@MIT-AI 03/28/76 17:46:36 Re: Feature MIDAS
To: RMS at MIT-AI
How about IRPM:  IRPM dummies:calls considers dummies a list of macro
dummies of various syntaxes and repeatedly scans calls for their values.

Need 2 more macro dummy syntaxes:  SYLLABLE and SINGLE CHARACTER.
SYLLABLE should re-read its terminator.