perm filename MSGLOG.MSG[S,AIL]7 blob sn#077597 filedate 1973-12-15 generic text, type T, neo UTF8
00100	COMMENT ⊗   VALID 00005 PAGES
00200	C REC  PAGE   DESCRIPTION
00300	C00001 00001
00400	C00002 00002	
00500	C00013 00003	∂15-MAY-73  0648		GEM,TVR
00600	C00032 00004	 
00700	C00052 00005	 -------
00800	C00053 ENDMK
00900	C⊗;
     

00100	
00200	I fixed up the file of this morning's message (but still have a listing
00300	in case you want to see it) but it still "DRYROTS".  The file is
00400	TRY.SAI[G,MJC].  Is there something special I should know about for-stmts?
00500						Mike Clancy
00600	
00700	17-NOV-72  1742		G,MJC
00800	A program which I wrote to try to learn a few things (namely SAIL and the
00900	Quam display routines) uncovered a "DRYROT" error.  The program is 
01000	TRY.SAI[G,MJC], and the error occurred in line 2600.  Any suggestions?
01100						Mike Clancy
01200	
01300	JAM again. Sorry, it doesn't go away with
01400	an "IF TRUE THEN", only with an "IF FOO THEN"
01500	
01600	22-NOV-72  2344		MA,JAM
01700	JAM here bringing to you yet another
01800	insidious SAIL bug. There is a program
01900	BUG.SAI[MA,JAM] which compiles the following
02000	code incorrectly (see page 6 of source file):
02100	
02200		BEGIN "FLTO"
02300		    REAL ARRAY Y[1:LN+GWIDTH];
02400		    *** LOTS OF STUFF ***
02500		END "FLTO";
02600		BEGIN "DPGT"
02700		    INTEGER ARRAY BUF[1:5500];
02800		    *** MORE STUFF ***
02900		END "DPGT";
03000	
03100	The following code appears:
03200	
03300	DPGT&DPGT.-6/	PUSHJ P,BEXIT
03400	DPGT&DPGT.-5/	PUSH P,3	; LOWER ARRAY BOUND???
03500	DPGT&DPGT.-4/	PUSH P,[=5500]	; THIS IS OK
03600	DPGT&DPGT.-3/	PUSH P,3	; IT SEEMS TO THINK AC3 CONTAINS A 1
03700	DPGT&DPGT.-2/	PUSHJ P,ARRMAK
03800	
03900	This, of course, gets a "UPPER BOUND<LOWER BOUND" error
04000	message, for constant bounds yet! Anyway, the problem
04100	goes away if you put an "IF TRUE THEN" in front of
04200	the BEGIN "DPGT". Is that enough?
04300	
04400	22-NOV-72  2341		MA,JAM
04500	Dear Ail,
04600	  CASE n OF (ITV, ITV, ... ITV) generates, in at least one case
04700	
04800		<case check>
04900		JRST	@TABLE(IDX)
05000		PUSH	P,ITV
05100		JRST	DONE
05200		...
05300		PUSH	P,ITV
05400		JRST	DONE
05500	TABLE:	.-...
05600		.-...
05700		...
05800		TABLE-2
05900	DONE:	POP	P,TBITS2
06000		MOVE	A,0			;!!!!!!!!!!!
06100		....
06200	 This is fairly recent (MOVE s/b MOVE A,TBITS2 or whatever).
06300	
06400	DCS
06500	
06600	20-NOV-72  0341		SLS,DCS
06700	I RAN INTO PROBLEMS WHEN USING THE SAIL DPB COMMAND.
06800	THE CODE GENERATED FOR THE INSTRUCTION
06900		DPB(A,POINT(11,BUFX[POINTER],10))
07000		SEEMED TO LOAD A INTO REGESTER 10 AND PROMPTLY DEPOSIT REG 11.
07100	THE PROGRAM IS TEST.SAI ON [1,EMC], AND THE OFFENDING LINE IS IN THE
07200	AIVCT1 PROCEDURE FOUND ON PAGE 4, I BELIEVE.
07300	19-NOV-72  0831		1,EMC
07400	HELP!
07500	DON'T PUT UP THE NEW SAIL.
07600	TWO DEMOS ON MONDAY.  THIS WOULD
07700	BE THE 4TH DEMO IN SUCCESSION IMMED
07800	AFTER A SAIL CHANGE.
07900	TOB
08000	07-DEC-72  1419		H,HJS
08100	K PINGLE FOUND A BUG HAVING TO DO WITH AN ILLEGIT. ARRAY NAME IN AN
08200	ARERR UUO FOR COMPLICATED EXPRS.  SERIOUS ENOUGH TO FIX.  SEE BUG #KR.
08300	DCS
08400	
08500	06-DEC-72  2219		SLS,DCS
08600	NASTY BUG IN SAIL SETBREAK(TABLE,STRDELIM,STRDELETE,SWITCHES);
08700	IF YOU DO A SETBREAK WITH CHARACTERS TO BE DELETED,
08800	THEN LATER IN THE PROGRAM YOU DO ANOTHER SETBREAK ON THE SAME TABLE NUMBER
08900	WITH NULL STRDELETE, IT CONTINUES TO USE THE OLD STRDELETE!!!!
09000	
09100	06-JAN-73  1737		1,REM
09200	Is my observation correct? I have a block full of
09300	CONTINUEs, and I find that the first one jumps to
09400	the second, the second jumps to the third, and so
09500	on to the last one!!???
09600	
09700	04-JAN-73  0959		MA,JAM
09800	The SAIL error: BEGIN AND END DO NOT MATCH
09900	could be more helpful in telling which are
10000	the BEGIN block names.
10100	
10200	19-DEC-72  1609		WRU,TOB
10300	JAM here. I have a SAIL program that I said ↑C - SAVE
10400	to. The dump copy is SAVBUG.DMP[MA,JAM]. If you RUN it,
10500	it generally says "ERROR IN JOB 26, PC EXCEEDS MEM BOUND
10600	AT USER 400013", indicating to me that the second segment
10700	isn't hooked up. If you GET it and START it, sometimes it
10800	works and sometimes not. This doesn't seem to happen if I
10900	SAVE the program before it is ever run for the first time.
11000	If I start it up, then stop it and save it, this often
11100	happens.
11200		Please delete the file SAVBUG.DMP[MA,JAM] when
11300	you are finished with it.
11400	
11500	18-DEC-72  1151		MA,JAM
11600	export version of sail should not have dump never bit on in
11700	rel files created. fancyy technique for writing over ddt doesn't seem
11800	to work with export.
11900	                  jim low
12000	
12100	16-DEC-72  1444		S,JRL
12200	THE 7-LINE PROGRAM BUG.SAI[1,REM] COMPILES INCORRECTLY BY SAIL.
12300	JNAM←CVSIX("[LXGP]"); COMPILES AS MOVSI NIC,0;MOVEM NIC,JNAM;
12400	
12500	14-JAN-73  1824		1,REM
12600	YOU OUGHT TO FIX SAIL SO YOU CAN SPECIFY ODD FILE NAMES, LIKE [-AP-].DMP
12700	IN AN ENTER.  PERHAPS, ADOPT THE COPY CONVENTION ABOUT ↓ TO SURROUND A
12800	QUOTED NAME.
12900	
13000	01-FEB-73  1236		TAP,REG
13100	There is a deeper bug but you can cure your immediate problem by parenthesizing
13200	the expression TK([A⊗O≡V]) in your macro IV. Syntactically the parens are
13300	required since a boolean expression inside a foreach associative context musht
13400	be parenthesized.
13500		jim
13600	
13700	06-FEB-73  1126		S,JRL
13800		IT USED TO BE THAT INCHWL WAS ONLY TERMINATED BY <CRLF> NOT
13900	BY <ALT> OR <LF> OR BARE <CR> OR ANY OTHER ACTIVATION CHARACTER.
14000	A FEW MONTHS AGO INCHWL BEGAN TO BE TERMINATED BY THE OTHER ACTIVATION
14100	CHARACTERS AS WELL.  THIS LASTED FOR ABOUT A MONTH, THEN RETURNED TO
14200	THE <CRLF> ONLY METHOD.  NOW TONITE I FIND THAT INCHWL IS AGAIN TERMINATED
14300	BY ANY ACTIVATION CHARACTERS.  WHY DOES IT KEEP CHANGING???
14400	
14500	06-FEB-73  0124		1,REM
14600	The next person to make a new compiler might have some KVL typos to contend
14700	with (Gen pg 51,52,53 and Hel pg 15) due to implementation of ACCESS.  The
14800	slow system prevents me from making a compiler myself today.
14900				-peace and love - KVL
15000	
15100	06-MAR-73  1430		1,KVL
15200	BOTH OLD AND NEW PUB USE SAISG5 VERSION; BUT THE NEW CORE IMAGE IS
15300	3K BIGGER THAN IT USED TO BE 7 WEEKS AGO.  ANY IDEA WHY?  I ONLY
15400	ADDED A LINE OR TWO OF CODE. (COMPARE PUB2.DMP AND PUB2.OLD
15500	ON [1,3]).
15600	--- LARRY TESLER
15700	
15800	05-MAR-73  1151		2,TES
15900	Russ: We need to fix the realin (intin) and any associated code
16000	
16100	to handle overflow conditions by having a JFCL immediately following
16200	any instruction which can cause an overflow.  In particular, realin
16300	with a large integer part followed by a large number of fraction part
16400	zerowill cause an overflow.
16500	
16600	
16700	
16800	14-MAR-73  2024		1,PDQ
16900	RUSS: I GOT A "DRYROT AT EFORM" MESSAGE WHEN TRYING TO COMPILE
17000	FILE AESTH.SAI[A,JEG]. DAN SAID IT WAS A COMPILER ERROR AND THAT
17100	YOU ARE THE PERSON TO SEE. SUGGESTIONS? THANKS. 
17200					   - JIM
17300	
17400	07-APR-73  1850		A,JEG
17500	 
17600	∂15-MAY-73  0329		2,TES
17700	 The new version of SAIL will not compile PUB.
17800	 See PPSAV.PUB[2,TES].  I tried twice.
17900	 Larry
18000	 
18100	 
18200	∂15-MAY-73  0202		SLS,DCS
18300	 Larry Tesler couldn't get PUB up with new segment, so I
18400	 managed to get one running with SAISG5.513, SSAVED it
18500	 and changed named of segment to SAISGN -- put it on the
18600	 system.  The old dmp is PUB.DMP[
18700	 (sorry) PUB.DMP[SLS,DCS] if you want to try again, else
18800	 please delete it.  Larry will probably follow advice and
18900	 put it up with the library, at least for a while, soon.
19000	 Dan
19100	 
19200	 
     

00100	∂15-MAY-73  0648		GEM,TVR
00200	 Thank you for the pleasure of reloading my program because of change to SAISG5!
00300	 
00400	∂04-JUN-73  1245		SLS,DCS AT TTY62 
00500	 Sorry -- wasn't careful enuf in my examination of the problem.  SGLIGN
00600	 is MISSING from HLBSA5, tho PRESENT in LIBSA5!!!!  What a strange
00700	 situation.  I refrained from inserting it, so you could study the
00800	 anomaly in situ if you wished.
00900	   Dan
01000	 
01100	∂04-JUN-73  1025		LDE,DCS
01200	 IS THERE ANY GOOD REASON THAT POW & FPOW ARE NOT MADE "HERE"??  SINCE THE
01300	 COMPILER CALLS THEM DIRECTLY, SOMETIMES, ANYTIME A NEW SEGMENT IS MADE, A
01400	 NEW COMPILER MUST ALSO NEEDS BE MADE.
01500	 		LEE ERMAN
01600	 
01700	∂03-JUN-73  1105		SLS,DCS
01800	 There are no HEAD syms on either library.  Weiss du das?
01900	 
02000	∂13-JUN-73  0204		1,MSW
02100	  HELLO I AM ONE OF JEENA'S COLLEAGUES. IHAVE A SMALLPROGRAM
02200	 ON MIR.SAI WHICH YOU MAY LIKE TO SEE. IT DOES A LOT OF WIERD
02300	 THINGS. TWO COMMENTS IN THE PROGRAM WILL POINT THE PROBLEMS.
02400	 THEY ARE SYSTEM BUGS OR THE DOCUMENTATION WE HAVE IS 
02500	 OUTDATED. I WOULD LIKE TO HEAR YOUR OPINION ON THIS.
02600	 MY NAME SHRIRAM.
02700	 MY FILE MIR.SAI ON [1,MSW]
02800	 THANX.BYE.
02900	∂19-JUL-73  1102		IML,BO AT TTY113 
03000	 SAIL BUG: USING PORTRAN PROCEDURE ATAN2, THE EXPRESSION
03100	 ATAN2(A-B,C-D) USES THE SAME TEMPORARY STORAGE LOCATION FOR
03200	 BOTH OF THE EXPRESSIONS IN THE CALL.
03300	 
03400	∂04-AUG-73  1526		1,LDE
03500	 Please see LEAP.SAI[1,LDE] ( a five line program) for what seems to be
03600	 a ridiculously basic Leap bug.
03700	 _
03800	∂3-AUG-73  0826		network site CMUA
03900	 An ENDC followed by an ELSEC gives a non-helpful error message of
04000	 ILL MEM REF.  (See BADCOM.SAI[1,LDE) for and example.)
04100	 		Lee Erman
04200	 
04300	∂20-AUG-73  1557		MA,JAM
04400	 Hi. JAM here. I think I have discovered a feature,
04500	 but it might well be considered a bug. Try to
04600	 compile SAIBUG.SAI[MA,JAM] and it will get an
04700	 error on page 8 that says "Not enough params supplied
04800	 to procedure". To save you some looking, the statement
04900	 is:
05000	 	P1←PITCH(NLEND(RG1));
05100	 P1 is a real, RG1 is an integer. PITCH is a macro defined
05200	 on page 4 as:
05300	 DEFINE PITCH(PK)="RGET(PK,1)";
05400	 RGET is defined in LPACK.HDR[MA,JAM] as an integer procedure
05500	 of two integer arguements.
05600	 NLEND is a macro defined on page 5 as:
05700	 DEFINE NLEND(R)="PGET(R,2,TRUE)";
05800	 PGET is defined in LPACK.HDR[MA,JAM] as an integer procedure
05900	 of two integer arguements and one boolean arguement.
06000	 	What seems to happen is that the terminal ",1" in
06100	 the expansion of PITCH seems to get lost. If I put in
06200	 REQUIRE "⊂⊃⊂⊃" DELIMITERS; above the call, it gets past that
06300	 point. As I say, this may be a feature, not a bug, but here
06400	 it is anyway.
06500	∂15-OCT-73  1032		network site MAXC
06600	 -------
06700	 Date: 15-OCT-73 1032
06800	 From: SPROULL at PARC-MAXC
06900	 Re:   Bug in INTMOD
07000	 - - - -
07100	 I belive that there is a bug in the export version of
07200	 INTMOD (interrupt handler) in NWORLD.  I was reading the code,
07300	 preparatory to doing some shit for NIH, and I found this
07400	 exciting mask that is commented "insure only legit bits"
07500	 Unless I am very much mistaken, the person that put together
07600	 that mask counted bits from the left beginning at 1, not 0,;;;
07700	 the result is that the mask is WRONG.  Consult page 3-2 of the
07800	 DEC Assembly Language Book, and behold!!!!
07900	 
08000	 Am I right??
08100	 -------
08200	 
08300	∂08-OCT-73  1322		MA,JAM
08400	 JAM again. With reference to my last note, it
08500	 would appear that the problem is not necessarily
08600	 SAIL's but instead the LOADER's problem. That is,
08700	 if I say EX PP/DUMP, it executes fine but the
08800	 dump file is garbaged. If I say LOA PP then
08900	 SAVE, the dump file is OK. OK? Maybe you ought
09000	 to pass this on to whomever 'fixed' the LOADER,
09100	 whoever that is.
09200	 
09300	∂08-OCT-73  1314		MA,JAM
09400	 Hi. JAM here with another SAIL bug. If I SAVE my
09500	 program with the indicated amount of core from the
09600	 LOADER, it gets "RELEASE&: INVALID CHANNEL NUMBER"
09700	 If I SAVE it in one more K than that, it works fine.
09800	 See for yourself. The failing version is BUG.DMP[MA,JAM],
09900	 the winning version is PP.DMP[MA,JAM]. Source file
10000	 is PP and is assembled alone. To run:
10100	 
10200	 RU BUG[MA,JAM]
10300	 Input file:	JJJ.SND[SND,JAM]
10400	 Output file:	FOO.TMP
10500	 Clock rate:	20000
10600	 Lower frequency bound:	50
10700	 Upper frequency bound:	300
10800	 Step in Ms:	5
10900	 stp = 100
11000	 Decay constant =   .9480775
11100	 Min. frequency resolution in Hz:	1
11200	 167 frequency points
11300	 
11400	 at this point, program will either immediately
11500	 fail or start computing ad infinitum. Happy
11600	 hunting. P.S., this is not unique to this program,
11700	 I have several others that exhibit this behavior.
11800	∂19-OCT-73  1450		2,MLM AT TTY110 
11900	 SAIL PEOPLE: Found a DRYROT.  I know what the mistake in the source file
12000	 is, but you might be interested in the compiler problem that causes this
12100	 DRYROT message.  Compile DRYROT.SAI[2,MLM] and you will get message.
12200	 You may copy, delete, etc. this file.
12300	∂21-OCT-73  2140		204,MLM AT TTY110 
12400	 SAIL PEOPLE: Have found another DRYROT; I know what's wrong but again
12500	 thought you might be interested.  Should I bother reporting these as
12600	 the Monitor manual suggests, or are they so common as not to bother?
12700	 All files on [2,MLM] produce DRYROT messages because of stupid mistakes
12800	 (in fact these are stupid programs altogether, the product of my rather
12900	 empirical method for learning SAIL; my apologies to your sensibilities)
13000	 and are yours to play with and delete.
13100	∂25-NOV-73  1426		network site CMU
13200	 ***** FTP mail from [A702SA00] (ERMAN)
13300	 SAIL SAILORS:
13400	 	Suggestions from CMU while you are freebing things:
13500	 
13600	 .Add .FAI extensions to source file names -- most installations do
13700	 not have FAIL as the default compiler but rather FOOTRAN.
13800	 
13900	 .Make sure all the runtimes that the compiler calls are
14000	 HEREd (e.g. POW and FPOW).  It seems silly to have to make
14100	 a new compiler just because some trivial change needs to
14200	 be made to the runtimes.
14300	 
14400	 .The DRYROT that "can't happen" in SYM at INCR3 can happen if
14500	 it is at the top of core and no more room to expand -- the
14600	 error msg should be made more informative thereof.
14700	 
14800	 .CVSIX hacks on [], -- I know why, but can this be handled
14900	 more cleanly.  (In the very least, the manual should state that.)
15000	 
15100	 .Error messages from the compiler should not use non-standard characters
15200	 (such as left single quote) and should translate them (including underbar)
15300	 to their standard ASCII equivalents.  The current state is particularly
15400	 messy on terminals that thing these characters are control characters
15500	 for them.
15600	 
15700	 .The ALLOC request doesn't accept lower case y.
15800	 
15900	 .A missing runtime is CVR -- convert to real.
16000	 Some helpful compile time functions would be:
16100	 CURLINE -- current line number of the source file,
16200	 CURFILE -- current source file name,
16300	 CURDATE -- date of the compilation,
16400	 CURTIME -- time of the compilation.
16500	 
16600	 .REQUIRE MESSAGE should accept a compile-time string expression.
16700	 
16800	 .Device I/O error message should print out the status bits of the channel.
16900	 
17000	 
17100	 For the following things, we already have them in our code under
17200	 a SACSW switch and SAC/NOSAC macros (they can be found in the appropriate
17300	 files on A701SA00/CMUB); if you don't stick them in
17400	 the general system, we will stick them in under our switch:
17500	 
17600	 .A facility for trapping to a user's procedure on certain events --
17700	 currently we have before and after a coreuuo and before and after
17800	 string garbage collection.  Obviously, it would be much nicer to
17900	 integrate these into the new stuff you guys have.
18000	 
18100	 .During a REENTER ALLOC, print out the current values when asking
18200	 for new one.
18300	 
18400	 .A here HERE location in the runtimes called DD.RET which contains
18500	 a  JRST @2,UUO0.  Likewise, a msg is printed out when ones gets to
18600	 DDT (by typing a D to the error msg handler) that one returns
18700	 by typing "DD.RET$G".
18800	 
18900	 .In the error UUO, type out a crlf before beginning the error msg.
19000	 (Besides making things generally neater, this is essential on the
19100	 ARDS if it is in vector mode.)
19200	 
19300	 .Remove that idiocy when string space is exhausted that automatically
19400	 restarts your program, thus making it impossible to rummage around
19500	 (with ddt) and find out where all the string space went.
19600	 (Of course, if the dynamic string space goes in, then this won't be
19700	 necessary.  Dynamic string space will make the facility to inform
19800	 the user of garbage collections and space expansions even more important.)
19900	 
20000	 .HERE on CORGET & friends.
20100	 
20200	 .If running 2 segments, prevent the lower one from expanding past
20300	 400000 -- only chao results.
20400	 
20500	 .In SIMIO, make explicit check for doing buffered I/O with no buffers -- the
20600	 DEC monitor is not as nice about error messages as yours.
20700	 
20800	 .By turning on a funny bit in the left half of the argument when doing
20900	 an OPEN, let him specify that nulls are not to be thrown away when
21000	 doing ASCII input.
21100	 
21200	 .Give error message in OPEN if invalid device name or device
21300	 unavailable only if he asked for error msgs (in the EOF variable).
21400	 For device unavailable, ask him if he wants to try again.
21500	 In any case, make the error continuable, with the EOF variable
21600	 set to TRUE..
21700	 
21800	 .In the OPEN, use the DEVCHR uuo to determine if the device is
21900	 a TTY, not just the name of the device (since one often does a
22000	 logical assignment.
22100	 
22200	 .GETSTS and SETSTS routines:
22300	 STAT←GETSTS(CHNL);		SETSTS(CHNL,BITS);
22400	 
22500	 .An input mode (called K) that converts lowercase alphapetics (a-z only)
22600	 into upper case.  (We also have a mode called F that converts to lower
22700	 case, but I don't think anyone has ever used it.)  Likewise, an integer
22800	 procedure called TTYUP(DOIT) that
22900	 sets conversion of TTYUUO's to do similar conversion on input:  if DOIT
23000	 is true, then doit, else don't.  It returns the old value of the state.
23100	 
23200	 .When coming into ARRYOUT and WORDOUT, set the EOF variable to false.
23300	 
23400	 
23500	 .A routine called INOUT(inchan,outchan,amount) that does direct
23600	 i/o between the channels, thus saving a movement of the data.  If
23700	 amount is negative, then go til hit EOF.  In all cases, set the EOF
23800	 variables as if one were doing arryins/arryouts. (e.g., errors.)
23900	 
24000	  
24100	∂25-NOV-73  1306		1,LDE
24200	 By the way, the correction to my network mailing address never got made on
24300	 the document that got distributed.  It says I'm at CMU-10A -- should be
24400	 CMU-10B.
24500	 		thanx,
24600	 			Lee
24700	 
24800	∂25-NOV-73  0956		1,LDE
24900	 I now have a tiny program that seems to poke the multiple string preload problem:
25000	 see PREBAD.SAI[1,LDE] get an illegal uuo.
25100	 	Lee
25200	 }
25300	∂25-NOV-73  1528		1,KVL
25400	 Everything seems to work properly in the new err stuff.  I've tested
25500	 the compiler version of logging, REQUIRE ERRMODES, <esc>I, and linkage
25600	 to user procedures.  The description of the new stuff is ERRORS.NEW[S,KVL].
25700	 There is a bug in the compiler which I don't think is mine.  The compiler
25800	 always emits a 0 at S.+7.  When this is changed to JFCL, everything runs
25900	 fine. Seems to be independent of what's in the source.  
26000	 
26100	 I probably won't be around for awhile. Give me a call if any bugs develope.
26200	 -Kurt
26300	∂26-NOV-73  1739		S,JRL
26400	 I found the difficulty with LES's program. He had a FORLC of the form
26500	 
26600	 	FORLC X = (A,B,C) DOC
26700	 		⊂ mummbblee   X mummmble ⊃ ENDC
26800	 
26900	 where X had previously been defined as a macro name. Hanan did not turn
27000	 off macro expansion as soon as the FORLC was scanned, but did turn it off
27100	 while scanning the FORLC body, Thus if the macro X had been defined
27200	 
27300	 	DEFINE X = ⊂FOO⊃;
27400	 
27500	 the FORLC was acting like:
27600	 
27700	 	FORLC FOO = (A,B,C) DOC
27800	 		⊂ mummbblee  X mummble ⊃ ENDC
27900	 
28000	 I have not changed the compiler, but have sent a note to Hanan telling him about
28100	 this problem.
28200	 
28300	 		jim
28400	 
28500	∂26-NOV-73  0854		1,PJ AT TTY125   0854
28600	 PRIMES.SAI[1,PJ] CAUSES IO TO UNASSIGNED CHANNEL AT USER 24001.
28700	 I WOULD BE INTERESTED IN YOUR COMMENTS AS TO WHY.
28800	∂27-NOV-73  1257		network site AI
28900	 
29000	 - - - - - - - - - - - -
29100	 
29200	 11/27/73  15:55:37
29300	 From:  PJ@MIT-AI
29400	 
29500	 - - - - - - - - - - - -
     

00100	 
00200	 WHAT IS JOBENB ALL ABOUT?
00300	∂27-NOV-73  1816		1,LDE
00400	 RUSS:
00500	 THIS IS MARK AT CMU. WE ARE HAVING A LITTLE PROBLEM
00600	 WITH FAIL.  AS I TOLD FW IT LOOKS LIKE A PUSHJ CORINI SHOULD BE DONE
00700	 AFTER THE RESET AT DOAT:.  THIS SEEMS TO LET OUR CCL DO ITS THING.
00800	 HOWEVER WHEN I ASSIGN DSK AS SYS THEN SAY COMP FILE.FAI I GET AN
00900	 ILLEGAL UUO AT PC 7414. THE WORD IS THE TEMPCOR CALLI.  WHEN LOOKING
01000	 AT THE INFO PASSED TO THE CALLI I FOUND A BUFLEN OF 170 WHICH
01100	 WITH THE JOBFF SEEMS TO EXCEED THE CORE THE JOB HAS ALLOCATED, IE.,
01200	 THE JOB HAS 12K WHEN ONE DOES A CORE COMMAND YET THE ADDRESS OF THE
01300	 LAST WORD OF THE BUFFER EXTENDS PAST THE 12K. 
01400	    ANOTHER FUNNY ITEM IS THAT WHEN ONE USES CCL FROM SYS THERE IS NO
01500	 ERROR AND COMPILATION COMPLETES FINE, YET IF IASSIGN DSK
01600	 AS SYS AND THEN RUN COMPIL FROM THERE I GET THE ILLEGAL UUO.
01700	    AM I JUST IGNORANT OF THE FACTS OF FAIL OR IS THIS A BUG?
01800	    COMMENTS WILL BE GREATLY APPRECIATED.
01900	 MARK [A610MM42] PDP-10/B
02000	∂28-NOV-73  0000		IMS,AIL
02100	 THIS IS RLS.  THE FIX IN SYM (FOR THE FORMFEED BUG)
02200	 IS WHAT I DID ALSO.  I WILL TRY TO CONFER ON
02300	 OUR BUGS WHEN WE MERGE.  ALSO I HAVE SOME FEATURE SUGGESTION.
02400	 			BOB SMITH
02500	 
02600	∂28-NOV-73  2232		network site CASE
02700	 -------
02800	 Date: 29-NOV-73 0128-EST
02900	 From: METZGER at CASE-10
03000	 Re:   SAIL ON [S,AIL]
03100	 - - - -
03200	 RUSS, IS THE SAIL ON [S,AIL] IN A STABLE STATE? I'D LIKE TO GET A
03300	 COUPLE OF THE BUG FIXES AND SINCE SO MANY FILES ARE AFFTECTED I THOUGHT
03400	 I'D FTP THE WHOLE WORKS IF THINGS ARE STABLE ENOUGH. WHOULD YOU BE
03500	 INTERESTED IN THE ROUTINES TO DO SOME STRING COMPARES? MANY PEOPLE
03600	 HERE FIND THE EQU ISN'T  ENOUGH SO WE WROTE THINGS TO DO
03700	 LSS("ABC","DEF"), GTR LEQ AND GEQ. WITHOUT SUCH ROUTINES IT'S A LOT
03800	 HARDER TO WRITE SORTING ALGORITMS. I FEEL THAT THE CURRENT MEANING TO
03900	 STRING A < STRING B DOESN'T HAVE MUCH USE AND THAT IT WOULD BE NICE
04000	 IF <,> ETC. WOULD USE THE WHOLE STRING WHEN DOING A COMPARE.
04100	 ALSO WOULD IT BE POSSIBLE TO TO PUT THE "END OF SAIL EXECUTION"
04200	 UNDER A CONDITIONAL ASSEMBLY SWITCH AS MANY PEOPLE HERE USE SAIL TO
04300	 WRITE SYSTEM TYPE PROGRAMS AND DON'T WANT SUCH MESSAGES. IN GENERAL
04400	 THEY DON'T WANT ANY SAIL MESSAGES (PARTICULARLY THE SAIL ERROR MESSAGES
04500	 THAT ASK THE USER TO CONTINE, EXIT OR WHAT EVER AS THESE TEND TO
04600	 CONFUSE NON-SAIL PROGRAMMERS, BUT THIS IS A MORE GLOBAL ISSUE OF THE
04700	 ERROR TRAPPING AND RECOVERY PROBLEM THAT KVL IS WORKING ON).
04800	 HOW IS THE TENEX SAIL GOING? I HAVEN'T BEEN ABLE TO CONTACT BOB SMITH
04900	 IN A WHILE. DID HE GET THE CONTRACT SETTLED YET? PROBABLY THE BEST WAY
05000	 TO ANSER THIS IS TO LOG IN HERE AND USE OUR SNDMSG (UNLESS YOUR MAIL
05100	 PROGRAM CAN SEND TO NET SITES EASILY). THE PASSWORD TO SAIL-TAYLOR IS
05200	 STILL THE SAME AS YOUR BOAT'S NAME.
05300	 			JOHN METZGER
05400	 			METZGER@CASE-10
05500	 -------
05600	∂30-NOV-73  1402		network site CASE
05700	 -------
05800	 Date: 30-NOV-73 1702-EST
05900	 From: METZGER at CASE-10
06000	 Re:   GOT YOUR MESSAGE
06100	 - - - -
06200	 THNKS FOR THE INFO. WILL TRY TO FTP NEW SOURCES WED OR THURS.
06300	 I'LL PUT THE STRING ROUTINES (LSS, GEQ ETC) ON <SAIL-TAYLOR>
06400	 SO YOU MAY LOOK AT THEM AT WHEN YOU GET TIME. FEEL FREE TO GRAB
06500	 ANY FILES YOU WANT FROM OUR SYSTEM (IF WE DON'T WANT SOMETHING
06600	 TO GET OUT WE HAVE IT PROTECTED, SO ANYTHING THAT'S UNPROTECTED IS
06700	 FAIR GAME). THE STRING ROUTINES ARE IN A FILE CALLED COMPAR.
06800	 AL ROSENFELD WILL BE AT NIC, PARC AND ISI ABOUT THE FIRST WEEK OF
06900	 JAN. AND WILL PROBABLY STOP AT SU-AI. I'M NOT SURE IF I'LL BE WITH HIM
07000	 AT THIS TIME. AS WORK IS PROGRESSING ON THE NEW LEAP SYSTEM WE'D LIKE
07100	 TO GET TOGETHER WITH YOU AND JIM LOW, TO FIND SOME OF THE REAL NASTY
07200	 PROBLEMS IN LEAP AND TO HAVE YOU HELP EXPLAIN HOW THE CODE GENERATORS
07300	 ARE ALL PUT TOGETHER. WILL YOU OR JIM BE WILLING TO DO THIS (FOR ABOUT
07400	 A WEEK SOMETIME IN JAN)? CONSULTING FEES MAY BE ARRANGED, I'LL HAVE TO
07500	 TALK TO PEOPLE HERE TO FIND YOU EXACTLY WHAT WOULD BE ACCEPTABLE.
07600	 THE BASIC PROBLEM IS CONVERTING ALL THE CODE GENERATORS TO BELIVE
07700	 ITEMS ARE 27 BITS WIDE INSTEAD OF JUST 18. ALSO DATUMS HAVE TO BE 
07800	 PAGED. WE HAVE IDEAS HOW TO DO THIS, JUST THAT THE INTERNALS
07900	 OF THE CODE GENERATORS IS NON TRIVAL, THE SMALLEST CHANGE SEEMS TO
08000	 CAUSE A GREAT DEAL OF HAVOC AND WOULD LIKE YOUR EXPERT HELP WITH
08100	 THIS STUFF. JIM CALVIN HAS JUST RECENTLY ASDDED SOME CODE TO TOTAL
08200	 AND FRIENDS TO GENERATE A MACHINE LANG. LISTING SIMILAR TO FORTRAN'S
08300	 M OPTION, ANYONE INTERESTED IN SUCH A THING. WE WANT IT TO HELP
08400	 WITH DEBUGGING NEW CODE GENERATORS. THANKS AGAIN. NO HURRY ON A RESPONSE
08500	 I WON'T BE BACK TILL NEXT TUESDAY.
08600	 					JOHN METZGER
08700	 					METZGER@CASE-10
08800	 -------
08900	
09000	∂30-NOV-73  0949		network site CMU
09100	 ***** FTP mail from [A700SA00] (SAIL)
09200	 Russ,
09300	 	Just to confuse you, I think we will bring up the new Sail
09400	 on A700SA00, and leave the old stuff on A702SA00.  In preparation
09500	 for this, I have moved SAIL.LOG to A700.
09600	 	Sorry, again.
09700	 			Lee
09800	 
09900	
10000	∂04-DEC-73  1011		1,DCS
10100	 Unfortunately, your fix will not work.  It will cause block name
10200	 mismatches, in fact, if you're not lucky -- and other things too.
10300	 
10400	 The problem is that unless you copy the zeroes accompanying the end
10500	 of identifiers down to new locations when you move the identifiers, what
10600	 is left after some new identifiers will be non-zero characters
10700	 from previous strings.  Since the scanner compares full words,
10800	    things will no longer match.  In addition, if the last string
10900	 is a complete identifier, unless topbyte lines up, there's no guarantee
11000	 that it will face a zeroed set of characters -- this sentence
11100	 doesn't make much sense.  
11200	 
11300	 Anyhow, best is for programs which set SGLIGN to assume that
11400	 topbyte will be aligned after GC.  If it should not be (should point
11500	 to first char after partial ID, for example), the program
11600	 should re-create TOPBYTE using SUBSTR, and the known partial
11700	 length and starting ID byte ponter.  I now recall special hair
11800	 in the GC to make sure TOPBYTE lined up just
11900	  past the last char of the last string moved.  It was
12000	 a true, losing kludge.  I will be happy to try to get SYM fixed
12100	 to do what I suggested above, but am not sure how soon I can do
12200	 it what with vball and no sleep and all.  You could help
12300	 by listing the STRNGC portion of GOGOL and all of SYM, I guess.
12400	 
12500	 Let me know if either you think I'm wrong, or there's something else.
12600	 Also call me at work to discuss this, etc. -- try several times,
12700	 since there's no paging.
12800	 Dan
12900	∂05-DEC-73  1130		1,PDQ AT TTY26   1130
13000	 HEY, ZERO DIVIDE BIT IS NOT GETTING CLEARED IN NEW
13100	 OVERFLOW CODE.  THE MOVSI 440100 AT TRIGIN+37 SHOULD BE
13200	 MOVSI 440140.
13300	∂06-DEC-73  0847		GUN,KKP AT TTY74   0847
13400	 The current global segment still has the bug in the PTY code.  We need
13500	 this fixed if I am going to get the hand/eye monitor running again.
13600	∂06-DEC-73  0954		1,DCS
13700	 Russ,
13800	  Subtle bug (which I actually encountered!):
13900	 
14000	   Consider, if you will,
14100	 	USERCON(UUO1,SAVERET,0);   and its corresponding
14200	 	USERCON(UUO1,SAVERET,1); !!
14300	   The effects are lovely and mysterious.  Try to predict
14400	    them without writing any programs.  This is one nice
14500	    mutation.
14600	 DCS
14700	 
14800	∂6-DEC-73  1914		network site CASE
14900	 -------
15000	 Date:  6-DEC-73 2034-EST
15100	 From: METZGER at CASE-10
15200	 Re:   ANNOUN
15300	 - - - -
15400	 GOT YOUR MESSAGE OK. WHY WAS IT SENT FROM BBN? I ASSUME THAT SINCE
15500	 IT CAME FROM BBN YOU KNOW THAT GOODWIN AND CREW HAVE FINISHED UP
15600	 THERE WORK ON BBN'S VERSION OF TENEX SAIL. NOT MUCH WAS DONE.
15700	 JUST UUO'S OUT OF COMILER AND RUNTIMES, AND NEW COMMAND SCANNER
15800	 THAT TAKES TENEX NAMES (AND FILE COMPLETION) ALSO TENEX FILE
15900	 NAMES IN REQURIES (REQUIRE <SAIL>NAME.EXT INSTEAD OF NAME.EXT[X,Y])
16000	 ALSO COMPAR.FAI (THE SAIL STRING THING TO DO LSS(A,B) ETC.) IS ON
16100	 <SAIL-TAYLOR> IF YOUR INTERESTED.		JPM
16200	 -------
16300	 
16400	∂6-DEC-73  2339		network site CASE
16500	 -------
16600	 Date:  7-DEC-73 0240-EST
16700	 From: METZGER at CASE-10
16800	 Re:   [X,AIL]
16900	 - - - -
17000	 I'D BE GLAD TO GIVE YOU ANY HELP YOU WOULD NEED ROM ME TO
17100	 SET UP X,AIL. IF NONE IS REQUIRED, THEN I'LL FTP THE FILES FROM
17200	 X,AIL EARLY MONDAY MORNING (UNLESS I HEAR FROM YOU THAT I SHOULD
17300	 WAIT) AND WILL TRY TO GET UP A STRAIGHT EXPO SYSTEM, THEN PUT IN
17400	 OUR PATCHES, WHICH FOR RIGHT NOW ARE:
17500	 REMOVE "END OF SAIL EXECUTION" MESSAGE
17600	 ADD OUR LOCAL RUNTIMES (CHANGES TO FOO2 AND ORDER ONE EXTRA FILE
17700	 	CALLED CASE10 WITH ALL THE CODE)
17800	 FIX MINOR EXPO BUGS LIKE LOADVR←←52 IN FILE SAIL (NOT UNDER STANSW
17900	 	OR NO EXPO)
18000	 FIX SCISS TO START FAIL IN INFERIOR FORK. (MINOR CHANGE)
18100	 DON'T HESITATE TO LET ME KNOW IF THERE IS ANY THING I CAN DO TO HELP.
18200	 				JPM
18300	 -------
18400	∂8-DEC-73  1535		network site MAXC
18500	 -------
18600	 Date:  8-DEC-73 1537
18700	 From: SPROULL at PARC-MAXC
18800	 Re:   The usual
18900	 - - - -
19000	 You'll never believe it, but there are no bugs in
19100	 the glorious interrupt handler (that is, i found an overflow
19200	 with a jfcl following it that did the right thing!).  So
19300	 I am farily confident that it is ok.  Furthermore, Gary Knott
19400	 will surely test EVERY possible combination of conditions before
19500	 he "accepts" the new system.
19600	 
19700	 I did discover one small thing.  We put in the entry DD.RET for
19800	 Lee Erman so that you could return from DDT after typing D to
19900	 an error message.  It is a HERE'd symbol, in the error handler
20000	 area.  However, I forgot to make in INTERNAL when putting out
20100	 a library (another minor change the the COMPIL macro for
20200	 SAILUP).
20300	 
20400	 My tapes, they spin slowly.
20500	 -------
20600	∂09-DEC-73  1635		S,LES
20700	 Dan,
20800	 Here is an elaborated version of SAVE_IT that gets around a couple of
20900	 problems.  In order to avoid having to give a Core argument to SSAV,
21000	 the left half of JOBSA is set to JOBREL.
21100	 						LES
21200	 
21300	 PROCEDURE SAVE_IT; BEGIN
21400	 COMMENT If you  are doing no  I/O, you may  call this procedure.   It
21500	 saves  the accumulators, sets up  a new starting  address, and exits.
21600	 If you then say "SSAV <file>" (or "SAVE ..." if you have  no segment)
21700	 then subquently  RUN <file>, it  will start  at the point  where this
21800	 procedure  was called,   thus preserving  all strings,   items, etc.,
21900	 that would  be  cleared in  a normal  start.   Note  that you  cannot
22000	 subsequently  give  ↑C and  start  the  program  again, since  SAIL's
22100	 storage allocation  would become  hopelessly  confused.   To  inhibit
22200	 this,  any such attempt draws an error message. ;
22300	 	SIMPLE PROCEDURE BOMB; BEGIN
22400	 		OUTSTR("
22500	 Sorry, you can't restart this program.  Please get a new copy.
22600	 ");
22700	 		CALL(0,"EXIT");
22800	 		END;
22900	 	START_CODE
23000	 	SAFE OWN INTEGER ARRAY SAVACS[0:'17];
23100	 	EXTERNAL INTEGER JOBSA,JOBREL;
23200	 	LABEL RESTART,RERESTART;
23300	 	MOVE JOBSA;
23400	 	HRRI RERESTART;
23500	 	PUSH '17,0;
23600	 	MOVEM '17,SAVACS['17];
23700	 	MOVEI '17,SAVACS[0];
23800	 	BLT '17,SAVACS['16];
23900	 	HRL JOBREL;
24000	 	HRRI RESTART;
24100	 	MOVEM JOBSA;
24200	 	CALLI 0,'12;
24300	 
24400	 RERESTART:  PUSHJ '17,BOMB;
24500	 RESTART:
24600	 	MOVSI '17,SAVACS[0];
24700	 	BLT '17,'17;
24800	 	POP '17,JOBSA;
24900	 	CALLI 0,0;
25000	 	END
25100	 	END "SAVE_IT";
25200	∂11-DEC-73  1814		network site MAXC
25300	 -------
25400	 Date: 11-DEC-73 1815
25500	 From: SPROULL at PARC-MAXC
25600	 Re:   Sproull in Washington
25700	 cc:   JRL at SU-AI, SWINEHART
25800	 - - - -
25900	 Throught the magic of the ntwork, I come forware to hassle you
26000	 in your peace.  Basically, I was able to read my tapes, and 
26100	 everything works.  However, I have found two bugs, one of
26200	 which is serious:
26300	 
26400	 1. (not serious( JRL>s bug fix PP to check for hiseg arrays
26500	 going 'before' the origina of the rel file fails to check
26600	 the OWN bit before entering the bug check.  There fore,
26700	 I reccommend something along the lines of
26800	          Tnn tbits,own
26900	           jrst .+6
27000	 in ARRAY, just at the beginning of the PP patch.
27100	 
27200	 2. (serious) God damn you Russ talyor, that piece of my
27300	 accumulator-saving code that you 'optimized' because you
27400	 couldn't keep your fucking fingers off the code, you broke.
27500	 When restoring ac's after the call on the error handler
27600	 proc, there is a HRLZI ff,d-15(p) that is wrong, it should
27700	 be HRLZI ff,dxxxxxx scratch that it is now hrlzi ff,15-d(p),
27800	 and should be hrlzi ff,d+1-15(p).   This really fucks
27900	 up the compiler whenever an error message is ussued,
28000	 clobbering PNT, TBITS, and the like.  You should be
28100	 ashamed.
28200	 
28300	 More news later, pehrhaps.  But for now, all is well.
28400	 MLAB runs (wihtout error handler yet), even in a HISEG
28500	 version!!!!  See ya.
28600	 
     

00100	 -------
00200	 
00300	∂11-DEC-73  1648		ACT,REG
00400	 THE CRETINOUS MANUAL LIES ABOUT THE COMPILER BEING SMART ENOUGH TO GENERATE
00500	 AN ASH FOR DIVISION BY A POWER OF 2! [24L]
00600	 AND WHATEVER ASSHOLE PROGRAMMED IT DIDN'T REALIZE THAT IDIV DOESN'T GIVE
00700	 THE SAME RESULT AS AN ASH. E.G.,  '777770000017 DIV '100000 = -7, NOT
00800	 THE -'10 I'D HAVE GOTTEN FROM AN ASH!
00900	∂12-DEC-73  0658		1,RFS
01000	 R
01100	 Russ -- I hate to pick nits, but the addition you made to LOG
01200	 to explain the fix for the bug in GOGOL is NOT correct. First,
01300	 the HRLZI has a (p) in it, second the From and To forms you gave
01400	 are not right:
01500	 	was:    HRLZI FF,15-d(P)
01600	 	s/b:	HRLZI FF,D+1-15(P)
01700	 Note that one of the most importnat parts of the fix is that
01800	 the old ac's are UP the stack (i.e. the thing should be -mumble(P),
01900	 not +mumble as it was).
02000	∂12-DEC-73  1626		network site MAXC
02100	 -------
02200	 Date: 12-DEC-73 1501
02300	 From: SPROULL at PARC-MAXC
02400	 Re:   Another bug
02500	 cc:   SWINEHART, JRL at SU-AI
02600	 - - - -
02700	 Here is your happy bug finder at work.
02800	 
02900	 The XX variables on page 9 of gogol have a problem (actually 2):
03000	 There is some stuff conditionally assembled with the LOW switch
03100	 near the end of the page; needless to say, this screws the XX
03200	 assignments for the high segments, because the low segment will
03300	 have three more cells in there for the LEAP initialization block.
03400	 Fix is to move the LOW stuff to the end of the page, after the last
03500	 XX.
03600	 
03700	 The other problem, which does not actually make a bug, but which is
03800	 wrong, is that the XX for APRACS (GOGOL/9) does not have its fourth
03900	 argument filled in; it shuld of course be 20.  Thought you all
04000	 might like to fix that.
04100	 
04200	 The first thing shouuld indeed bee fixed.
04300	 
04400	 That's all for now.
04500	 -------
04600	 
04700	 
04800	∂14-DEC-73  0003		ACT,REG
04900	 I SUGGEST THAT SAIL BE MODIFIED TO DO A DSKTIM UUO AND A RENAME ON THE
05000	 REL FILE AFTER DOING THE CLOSE TO GIVE THE REL FILE THE LATEST POSSIBLE
05100	 CREATION DATE.  THIS WILL HELP PREVENT RPG FROM DOING EXTRA COMPILATIONS.
05200	 
05300	∂13-DEC-73  2224		1,DCS
05400	 MACRO bug dix (discovered at CMU) (fix for dix) reported in mail to AIL.
05500	 Pls. don't remove it  without recording it in detail in one of 
05600	 the places where things like this belong (changes, etc.)
05700	 CC: rht;hjs;kvl;jrl
05800	 
05900	∂13-DEC-73  2222		1,RFS
06000	 Russ, please read bugs.rfs[1,rfs]
06100	 		rfs
06200	
06300	∂13-DEC-73  2223		1,DCS
06400	 Well, might as well try out the bug reporting method.
06500	 
06600	 The code at DEFCHK and beyond in sym has  been  the  most  consistent
06700	 source of bugs ever.  Now there is another bug.  It didn't used to be
06800	 that STRNGC (via SGCOL) could be called at RANSC1+3, by the nature of
06900	 tests  ahead  of time that assured enough REMCHRs. But now, there's a
07000	 test in RESTOR, coming out of macro actuals, to see if there's enough
07100	 room  for  the  rest  of  the macro, and that can cause GC to happen.
07200	 Anyhow, in the DEFCHK code there's a kludge  whereby  one  string  is
07300	 made  to  look  one  character  too long, to protect a pointer to the
07400	 succeeding byte.  It seems I do this a tad too  early,  because  what
07500	 happens is the STRNGC after RANSC1 happens, and TOPBYTE ends up being
07600	 kicked up one character, so that a null ends up in the macro  string,
07700	 then  some other things happen, and the null stays, but the character
07800	 following the null gets wiped out by the '177/0  thing,  or  someting
07900	 like  that.  Now, at SEEPRM and following, the one extra char. kludge
08000	 is ok, becuase it does protect a random pointer over  gc,  and  later
08100	 TOPBYTE  gets  restored from saved values anyhow.  I include all this
08200	 in hopes you will just ignore it  and  install  the  fix,  with  some
08300	 innocuous comment. It is actually easier by far to understand than to
08400	 explain. The fix goes:
08500	 
08600	 Delete the line, at DEFCHK+6 or so, which says:
08700	 	ADDI	C,1	;TO CARRY XTRA CHAR THROUGH FURTHER STEPS
08800	 
08900	 Replace the instructions at SEEPRM:
09000	   HRRM <-> SUBI <-> PUSH <-> PUSH <-> PUSH      with:
09100	 
09200	 SEEPRM:	PUSH	P,A		;Save bits,
09300	 	PUSH	P,B		;  character, and current total
09400	 	PUSH	P,C		;  macro body string count.
09500	 	ADDI	C,1		;Make PNAME look one longer to protect
09600	 	HRRM	C,PNAME		; end pointer over GC.
09700	 
09800	 finally, change 5 to 4 in COLNEC-1.
09900	 
10000	 I  have  not  made this change in any files anywhere. Thought I'd try
10100	 expo bug reporting scheme.  Oddly, this same fix was necessary for me
10200	 to  compile FILE, which I was asked to recompile here, just as I came
10300	 here last eve. to report bug. Truly surprised that  any  macros  have
10400	 worked recently (since at least last July).
10500	 
10600	 HJS  may  want  to  check  this  over  before  it  is installed.  But
10700	 something has to happen, and I hope this is it.
10800	 
10900	 Have fun. DCS
11000