COMMENT ⊗   VALID 00001 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂05-OCT-76  1540	JFR  	Compiler bug  
A very long string constant comment (say, 12 pages of text) gets
TOPBYTE out of range at STRNGC, can be continued, but dies soon afterward.

∂05-OCT-76  1542	JFR  	Runtime error handler bug    
Reply of "E" to runtime error handler calls COMPIL in a way which causes an
infinite loop in COMPIL on TOPS-10 systems.

[Should it start SOS in RPG mode instead?  How is file name and place supposed
to be communicated?]	[Maybe Hedrick "fixed" this.]

∂05-OCT-76  1546	JFR  	Untyped item or itemvar ought to be typed   
begin require 10 new!items;
string array itemvar array x[1:2];
preload!with "A"; string array y1[1:10];
x[1]←new(y1);
outstr(datum(x[1])[1]) end

∂03-Nov-76  2021	FTP:PHILIP KARLTON at CMU-10A	Run time errors when code is in the high segment  
Date:  3 Nov 1976 2316-EST
Sender: PK01 at CMU-10A
Subject: Run time errors when code is in the high segment
From: PHILIP KARLTON at CMU-10A
To: JFR at SU-AI
CC: BZM@CMU-10A
Message-ID: [CMU-10A] 85890 PHILIP KARLTON

John,

Bruce tells me that you may be amused by a problem I am having trying
to convert an existing program into a high segment version.  There are
many modules (some small, some medium size) in this thing, and SAIL
and LINK-10 do not complain about any of the code that I have
done.  (By the way, the program is our version of TENEX's MSG.)
The program has never failed with the code in the low segment, and
there is a heavy user community.

I think that something is going wrong in the string space allocator.
Different people get different run time errors depending upon what
the contents of their message files look like.  I looked at my error
in some detail in DDT and as near as I can make out, at one point,
when CAT is putting two strings together, it allows the new string
to overrun the contents of the string stack, totally screwing up
when the CAT returns.  It looks like it is asking itself if there
is enough room to put the two strings together and coming up with the
wrong answer.  The two strings that are being concatenated at the
time are
	1) a constant string ("0")
	2) a string which has been phonied up to point to an array
	with
		memory[location(STR)]←<some legitimate byte pointer>;
		memory[location(STR)-1]←<desired length>;
It could be that this is the problem, but it works just fine in the
low segment version.

I would like to know if you know of any thing that I should be
looking for in particular.  If you, or any of the heavy SAIL hackers,
are curious about poking around in a version with DDT, then after
getting logged in here at CMUA do
	.ru temp:rdh[n810pk01];rdmail[n810pk01]
which will fail in the way specified above.


Philip Karlton at CMU-10A

-------

∂03-Nov-76  2046	JFR  	Sail string problem
To:   pk01 at CMU-10A  
Sorry, but I am in thesis mode.  I suggest you get the source (in STRSER, on
[A7xxSA00] at CMUB or [S,AIL] at SUAI) and step through.
Your message will be added to the Sail mail file.

∂23-Nov-76  0312	JED  	more SAIL bugs
To:   MJC, JED, AIL    
I think I've found another bug in SAIL. The program in BUG2.SAI[1,JED]
blows up. As far as I can tell, it's syntactically and semantically correct.
I'd appreciate any comment on this, or an acknowledgement of this message.

[DRYROT TMPALL. l. 20, at end "setup"]

begin "bug2"

record_class EDGE (string foo; record_pointer (EDGE) bar);

record_pointer (EDGE) temp;

procedure SETUP;
begin "setup"
  record_pointer (EDGE) array ptr[1:10];
  temp ← (if ptr[1]=null_record then
    (ptr[1] ← new_record(EDGE)) else ptr[1]);
end "setup";

end "bug2";

∂23-Nov-76  1915	JFR  	profil   
RECURSIVE RECORD!POINTER(FOO) PROCEDUREs cause
PROFIL to bomb with a message "illegal type".
Works ok on RECORD!POINTER(FOO) PROCEDUREs.
Also works on RECORD!POINTER(FOO) RECURSIVE PROCEDUREs.

∂05-Dec-76  0205	JED  	SAIL bug 
The program in BUG3.SAI[1,JED] produces a strange reaction from SAIL - it
generates the message
   ATTEMPT TO MARK INVALID RECORD POINTER
The problem seems to involve record allocation -- the statement which
causes the problem works for several times, then bombs out. As far as
I can tell, the controlling factor seems to be the number of records
assocated.
  Thanks.

∂04-Jan-77  1449	JFR  	SAIL typo?    
To:   low at SUMEX-AIM 
TOTAL/10P/31L at INXSTF-2 has a  TRNN SBITS,INDXED  but INDXED is a left-half
bit.  Could this matter?

∂05-Jan-77  1310	FTP:NEVATIA at USC-ECL	SAIL   
Date:  5 JAN 1977 1302-PST
From: NEVATIA at USC-ECL
Subject: SAIL
To:   jfr at SAIL

There is a bug in ATAN2 routine for tenex sail (I have the 8-29-76
version from sumex). ATAN2(1.0,0.0) returns PI/4 rather than PI/2.
However Stanford version works correctly. Try ATAN2.SAI[1,RKN]
for a test. Should I gripe to someone at Sumex (whom?)?
Would appreciate your looking into it. Thanks.
Ram Nevatia (messages to rkn at sail).
[forwarded to daniels %sumex 1-5-77]
-------

∂23-Jan-77  1444	JFR  	Array with constant bounds gets allocated   
begin "test3"
procedure foo; begin
integer array c[1:4]; end;
end "test3"

∂24-Jan-77  0315	MJC  	BAIL
I keep getting ill mem refs by doing αS at the beginning and end of procedures.

∂26-Jan-77  1001	FTP:Agin at SRI-AI	F40 troubles    
Date: 26 Jan 1977 0956-PST
From: Agin at SRI-AI
Subject: F40 troubles
To:   EJG at SU-AI
cc:   JFR at SU-AI, AGIN

Thanks for your help earlier on fixing the F40 compiler to come up
to what SAIL expects of it for passing arguments by indirection.  
In spite of my earlier message that I wasn't going to pursue it
any further, I got the sources from Sweer@Sumex and fixed them to
agree with LCLMOD.DOC.  The new compiler passes on arguments OK,
but here's a new wrinkle.  The following subroutine:
	SUBROUTINE FTEST(A)
	DIMENSION A(10)
	DO 1 I=1,10
1	A(I)=0
	RETURN
	END
generates the following F40 code:
	MOVEI 15,1
	MOVEM 15,I
3M:	MOVE 2,15
	ADD 2,A			; Should be ADDI 2,@A
	SETZM -1(2)
	CAIGE 15,12
	AOJA 15,3M

Please let me know when a fix is found so I can fix our own compiler.
We have several users of SAIL/F40 who have been forced to add an extra
level of subroutine calling to get around this problem.  (Thanks for
your response on passing of indirect arguments--without that we would
be without that temporary fix.)


			--Jerry Agin
-------

∂02-Feb-77  1015	100  : HEDRICK@CMU-10A via NTS	SAIL
SOME USERS HERE HAVE SUGGESTED THAT THE SAIL COMPILER SHOULD COMPLAIN
IF THERE IS EXTRA GARBAGE AT THE END OF A PROGRAM.  IF THERE IS AN
EXTRA END IN A PROGRAM, IT DOESN'T COMPLAIN, SINCE EVERYTHING AFTER
THE END THAT TERMINATES THE PROGRAM IS IGNORED.  I HAVE RECOMMENDED
THAT USERS PUT BLOCK NAMES ON THE OUTER BEGIN-END, WHICH EFFECIVELY
SOLVES THIS PROBLEM, BUT I AGREE WITH THEM THAT IDEALLY SAIL SHOULD
NOT ALLOW GARBAGE AT THE END.

[JFR: ho hum]

INDEED, WHAT WOULD BE EVEN NICER IS IF SAIL WOULD REINITIALIZE
ITSELF AFTER THE TERMINATING END, SO THAT ONE COULD INCLUDE SEVERAL
PROGRAMS IN ONE FILE.  THIS WOULD ALLOW ONE TO PUT A LIBRARY IN
ONE SOURCE FILE, GENERATING SEVERAL MODULES AT ONCE.  CURRENTLY
ONE CAN ONLY GENERATE ONE MODULE PER FILE.  (THIS HAS CAUSED ONE
USER TO WRITE SOMETHING LIKE SCISS FOR SAIL PROGRAM LIBRARIES,
A LESS THAN IDEAL SOLUTION IN MY OPINION.)

[JFR: A bad idea.]

THANKS,
CHUCK HEDRICK
UNIVERSITY OF ILLINOIS
HEDRICK@CMU-10A OR CMU-10B OR ILL-NTS
(PREFERABLY CMU-10A IF IT IS UP)

Heavy Sail Users
(personal recollection of JFR, 2-18-77)

Catastrophe would strike these installations if Sail were not maintained:
	Stanford University Artificial Intelligence Laboratory
	Carnegie-Mellon University Computer Science Department
	SUMEX
	IMSSS
	University of Illinois Coordinated Science Laboratory
	National Institutes of Health
	Federal Judicial Center, Washington, D.C.
	Univeristy of Rochester Computer Science Department, Dept. of Medicine

Others heavily dependent on Sail
	SRI
	College of Medicine & Computer Science Dept., Rutgers University
	TYMSHARE, Inc.
	Stanford University LOTS
	USC-ECL, USC-ISI
	National Radio Astronomy Lab, New Mexico
	Rapidata

Non-trivial use
	XEROX-PARC
	University of Arizona
	Univeristy of Pittsburgh
	many other universities
∂AIL 16 February 1977$COPY-N-MAIL, c/o DECUS↓146 Main Street (PK3-1/E55)
↓Maynard, Mass. 01754$$Sail Maintenance$SAIL.MSG∞
.begin ref;
[1]  John Reiser (ed.), "SAIL", Stanford Artificial Intelligence Lab Memo AIM-289,
178 pages, $6.70/copy, August 1976.

[2]  Nancy W. Smith, "SAIL Tutorial", Stanford Artificial Intelligence Lab
Memo AIM-290, 54 pages, $3.30/copy, November 1976.

[3] Marvin Shapiro, "A Beginner's Guide to SAIL", National
Institutes of Health, Bethesda, Maryand, 134 pages,
no charge for single copies, July 1976.
.end

This note summarizes the state of the Sail programming language,
discusses future maintenance alternatives, and solicits feedback
from users.

SAIL is a dialect of ALGOL 60 that runs under all known operating systems
of DECsystems 10 and 20 (TOPS-10, TOPS-20, TENEX, ITS, and SALTS).
In addition to conventional Algol features, it has
internal representations of sets, lists, and record structures, as well as
macros and conditional compilation, coroutines, events, and backtracking.
In the last month, double precision reals have been added.
A new edition of the manual [1] and a tutorial [2]
can be ordered at the exhorbitant costs listed above from:
Patte Wood, Stanford Artificial Intelligence Lab., Stanford, California 94305.
Another tutorial aimed at reforming Fortran programmers (but containing
a number of bugs) is available free from NIH [3].

SAIL has been under development for about 10 years, but has now stabilized
(I think) and seems to have rather few troublesome bugs.  The last graduate
student who has been involved in its development is now about to receive his
Ph.D. and vanish, so the relatively free maintenance we have enjoyed for so
long is about to end.  Since we and a number of other facilities are heavily
dependent on Sail, we would like to find some way to maintain it.
The salient alternatives appear to be:
.begin preface 0; indent 4,10;nojust
(1) find another student who wishes to work on it,

(2) convince DEC that they should maintain it,

(3) find one or more government agencies that are willing to support maintenance
and hire someone here or elsewhere to do it,

(4) organize a consortium of users who are willing to pay enough to support
maintainence and find a software house that would like to maintain it as a
commercial venture,

(5) abandon maintenance and hope that the environment doesn't change too much.
.end continue
The trouble with (1) is that no one has appeared yet.  As for (2), DEC
seems to have immense inertial resistance to such ideas even when it is in
their own best interest, as I think this would be.  (3) is a possibility
but requires some effort to bring off.  (4) might work well if we could find
the right group and if there is enough support.  (5) is the default and might
work for awhile.

Since the compiler and related programs have been
distributed through DECUS for a number of years, we have
lost track of how many facilities use it.  At the end of this note is a
list of contacts at sites that we are aware of.
To assistin evaluating alternatives, I would app@IKGSCQJAQK¬eS]N↓Me←Z4∃C]s=]JAQ¬mS]N↓S]M←I[CiS=\AeK1CiKH↓i↑Ai!JAM←1Y←oS9NAck∃giS←9ft~∀9EKOS8AS]I∃]h@h0b`vAAeKMC
J@`w9←UkgP~∀Pb$@A	↑↓s←jA-]←nA=LAC]dAMCG%YSiS∃fAkg%]NA'¬SXA←QQKdAQQC\AQQ←gJ↓YSgi∃HAEK1←n}~(~∀Pd$@A	↑↓s←jAQQS]V↓s←kd↓←eOC9SuCi%←\Ao=kYHA	JAoS1YS]N↓i↑Aa¬r@Hb0```AAKdAs∃CdAM=dA'C%X~∃[¬S]iK9C]GJ|~∀
∀ fR@A⊃↑As←TAQCm∀AC]r↓←iQKHAgkO≥KgiS=]fA←8AQ←n↓i↑AQ¬]IYJ↓'β∪_↓[CS]QK]C]
J}~∀9K]HA
←]iS9kJ~∃AYKCg∀AgK]⊂AeKgA←]gKLAi↑A5JACh↓iQJA¬IIeKMfAS\↓iQJA1KiiKIQKCH↓←dAm%BAβeAC]Kh4∃i↑A1&A↓M*[β∩8~∀]g≥\~∀]%L@q
eSEX↓iQK\↓giCeP~∀\@↓gWS`lAGDAMCSXAMSiJA
←]iC
ifv~(\@A]=MSYX4∀\AK9HAKYMJAgi¬eh@~. every heading(,%3Sail Site Contacts);
. area sites lines 3 to bottom char 1 to 80 in 3  columns 1 apart;
. place sites;
. nojust crbreak; preface 0; indent 0,5;
. BEFORE PAGE ⊂ IF !HF THEN STANDARD TITLES ;; ⊃
. defont(ngr25); select ngr25;
. at null ⊂skip⊃;
. next page
. end
Jo Hanna
ARPA Research Center
Unit 1
Moffett Field, Calif. 94035
415 966-5744  MJH @SU-AI

James T. Mickol
Systems Programmer
Bentley College
Beaver and Forest Streets
Walthan, MA 02154
617 891-2000

Richard Wolfson
Bolt Beranek and Newman Inc.
50 Moulton Street
Cambridge, Mass. 02138

W. Colter
British Columbia Telephone Co.
600 West 7th Ave.
Vancouver, British Columbia
Canada V5Z 1B5

P.E. Brownswood
Senior Systems Analyst
British Columbia Telephone Co.
768 Seymour St.
Vancouver, British Columbia
Canada VV6B 3K9

Lee Erman
Computer Science Dept.
Carnegie-Mellon University
Pittsburgh, Pennsylvania 15213
412 621-2600, ext. 146;  Erman @CMU-10B

Ed Mulrean
Catholic University of America
620 Michigan Ave.
Washington, D.C. 20064

David J. Slater
Computer Science
Colgate University
Hamilton, NY 13346
315 824-4184

Erich Knobil
Cornell University
Laboratory of Nuclear Studies
Wilson Synchrotron
Ithaca, New York 14853
.skip 200
Sandy Libman, Ted Hess
Digital Equipment Corporation
200 Forest Street
Marlboro, MA 01752

Robert Scott Butler
Central Research Department
Experimental Station
E.I. duPont
Wilmington, Delaware 19898

Rick Fennell
Federal Judicial Center
Dolley Madison House
1520 H Street
Washington, DC 20005

Kevin Casey
Computing Center
Gallaudet College
7th and Florida Ave., N.W.
Washington, D.C. 20002

J. Ralph Bender
Assistant Director
Information Systems Division
Gederal Home Loan Bank Board
320 First St., N.W.
Washington, D.C. 20552

Gerald Johns
Computer Systems Lab
George Washington Univ.
724 So. Euclid
St. Louis, Missouri 63110

Brian Harvey
IRCAM
35, Bd. di Sebastopol
75001 Paris, France
	BH @SU-AI

John Wedell
M/S 198-136
Jet Propulsion Lab
4800 Oak Grove Drive
Pasadena, CA 91103

Solis James
Director, University Computing Center
Garland Hall
Johns Hopkins University
Baltimore, Maryland 21218
.skip 200
Winfried Smith
Lockheed
Sunnyvale, Calif.

Tom Knight
MIT Artificial Intelligence Lab
545 Technology Square
Cambridge, Mass. 03139
617 253-6765  TK @MIT-AI

Glenn Ricart
National Institutes of Health
Building 12A, Room 1039
Bethesda, Maryland 20014
	DGR @SU-AI

Lewis Lipkin
National Institutes of Health
Bldg. 36, Room 3009
Bethesda, Maryland 20014

Gary Knott
National Institutes of Health
Bldg. 12A, Room 3049
Bethesda, Maryland 20014

Bob Pariseau
National Radio Astronomy Observatory
P.O. Box O
Socorro, New Mexico 87801

Aaron Engel
C433
National Security Agency
Fort George G. Meade
Maryland

John H. Wolfe
Code 9304
Naval Personnel & Training Research Lab
San Diego, Calif. 92152

Mike Pedelty
Nova University
Ft. Lauderdale, Florida  33314

David Glaser
Computer Center
Pan American University
Edinburg, TX 78539
.skip 200
Norbert J. Kubilus
Rapidata
20 New Dutch Lane
Fairfield, New Jersey 07006

Robert Smith
Department of Computer Science
Rutgers University
New Brunswick, N. J. 
201 932-3626  RSMITH @RUTGERS-10

Carlyle Reeder
Scope Electronics
1860 Michael Faraday Drive
Reston, VA 22090

R.R. Rodriguez
Supervisor of Academic Computer Lab
Southwest Texas State U.
San Marcos, TX 78666

Gerald Agin
SRI
323 Ravenswood Avenue
Menlo Park, Calif. 94025

Les Earnest
Artificial Intelligence Lab.
Stanford University
Stanford, California 94305
415 497-4202  LES @SU-AI

Rainer Schultz
IMSSS
Ventura Hall
Stanford University
Stanford, California

Ralph Gorin
Low Overhead Timesharing System
Stanford University
Stanford, Calif. 94305
415 497-1360  REG @SU-AI

Tom Rindfleisch, Clark Wilcox
Sumex
Department of Genetics
Stanford University
Stanford, California 94305
415 497-5569  @SUMEX
.skip 200
A. W. Kundred, Jane Middlebrooks
The Brookings Institution
1775 Massachusetts Ave., N.W.
Washington, D.C. 20036

Bill Weiher, Gary Morganthaler
Tymshare, Inc.
Technical Division
10231 Bubb Road
Cupertino, Calif. 95014
408 446-6391, 6392

Barry C. Howard
National CTR Computer Center
Lawrence Livermore Laboratory
University of California
P.O. Box 808
Livermore, CA 94550
415 447-100

Dr. B. Neumann
Institut fur Informatik
Universitat Hamburg
Schluterstraβe 66-72
2 Hamburg 13
Germany

Tom Burtnett, Charles Hedrick
Coordinated Science Lab
University of Illinois
Champaign, Illinois 61801
217 333-2511

Bruce Dawson
Computer & Systems Bldg.
Belknap Campus
University of Louisville
Louisville, Kentucky 40208
502 588-6123

Hanan Samet
University of Maryland
College Park, Maryland
	HJS @SU-AI

Peter K. Chiu
Assistant Director for Systems and Operations
University of Mississippi
University, MS 38677
.skip 200
C.M. Reyburn
Department of Biology
Univeristy of Oregon
Eugene, OR 97403

Jerry Feldman, Jim Low
Computer Science Dept.
University of Rochester
Rochester, New York 14627
716 275-5671  LOW @SUMEX

Ram Nevatia
Image Processing Institute
University of Southern California
Los Angeles, Calif. 90007

Dale S. Russell
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, Calif. 90291
213 822-1511  Dale @ISIB

Ms. Patricia Caroom
Computation Center
University of Texas
Austin, Texas 78712
512 471-7242

T. Stallknecht
Department of Information Science
Victoria University of Wellington
Wellington, New Zealand

Lawrence Johnson
Western Electric
Dept. 7619
4513 Western Ave.
Chicago, IL 60532

Dan Swinehart, Bob Sproull
Xerox Corporation
3333 Coyote Hill Road
Palo Alto, California 94305
415 494-4424, 4417  @XEROX-MAXC
∂18-Feb-77  1253	FTP:GOLDBERG at RUTGERS-10	MEMORY construct in SAIL    
Date: 18 Feb 1977 (Friday) 1552-Est
From: GOLDBERG at RUTGERS-10
Subject: MEMORY construct in SAIL
To:   jfr at SU-AI, ail at SU-AI

Consider the following SAIL statement:

	MEMORY[1]←'10;

SAIL generates code something like:

	HRRZ	2,ONE
	MOVEI	3,10
	MOVEM	3,0(2)

when in fact all that is needed is:

	MOVEI	1,10

The fact that additional code using unneeded AC's
is generated makes life harder for people who want to use
the MEMORY array to manipulate contents of AC's, and it is also
not optimal.  That was the point of my previous 2
messages.

				Sincerely,
				Bob

[JFR -  Sail has never made any claims about generating optimal code.
Besides, if you want to fiddle the acs then you had better hav@∀ABAO=←H~∃	←n@QM)β%(¬π∨	
$]:~∀<bp[
∃DZnn@bfd\∪
) i∂∨→		%∞A¬hA%+Q∂%&4b`∪9)$A%fA'β%_~∃	¬iJt@DpA
Kλ@brn\@Q
e%ICrRbldn5gh~)
e←ZhA∂∨→⊃¬%∞↓ChA%U)∂%LZb`~)'kEU∃GhtA∃≥)$↓SfA'¬∪_~∃Q↑t@@↓CSXA¬hA'*5β∩~∀4∃)QJ↓'β∪_↓MSYJ↓∩←≡AIk]iS5KfAI<A]←h↓CYY←\As←j↓i↑AGIKCiJ↓BA]K\@AMS1J@A←8~∃ISMV@Ao%iP@A∧AOSm∃\Aae=iKGi%←\\@↓∪]gi∃CHXAMβ∪_A¬YoCsLAakiLAB@`↓S\Ai!J~∃aI←iKGQS←\A→SKYH↓←LAi!JAEY=GVASPAGeK¬iKfA	KM←e∀AI←S9NAiQ∀A≥)∃$@A+U≡\~∃QQSf@↓GCkg∃f@A)=!&Zb@Ai↑A¬ggk[∀AiQJ↓giC]⊃CeHAAe←iK
iS←\↓M←dAQQJA]∃oYr~)GeKCQKHAM%YJ\@↓⊃←oKYKdXA$Ao←k1HAYS-JAi↑↓GeKCQJAMS1KfAi!ChAI<A]←h↓QCmJ4∃iQJ↓giC]⊃CeHAAe←iK
iS←\8~∀~∃=]JAo¬rAi↑↓OKhA¬e←k]⊂AiQJ↓IKMS
SK]GdASfAQ↑AI↑↓C\A9)$@!i↑AGIKCiJ↓iQJ~)MSYJ$AM←Y1←oKH↓ErAB↓%≥β5
AoSQP@Ai!J@AI∃gSeK⊂@Aae=iKGi%←\\@A⊃←o∃mKdX4∃iQSL@A←]1r@Ao=eWfA%LAiQ∀AMSY∀AoCf↓GeKCQKHAS8A←]J≥fA←o8AISe∃Gi←ed\@A∪_~∃iQ∀AMSY∀AoCf↓GeKCQKHA←8AC]←QQKdA⊃SeKGQ←erAQQK\AQQJ@AI≥β≠∀@A++<@AoS1X~∃kMkCYYd@AMC%XXAY∃CmS]≤As←j↓S\Ai!JAMk9]rAg%ikCi%←\A←_AQCm%]NAGIKCiK⊂AB~∃→SYJAQQChAe←jAG¬]]←h↓%≥β5
XAgUaKeG∃IJXA=dAIK1KiJ\4∀~∃∩↓gkOO∃ghAi!ChA←9JA←L↓iQJA→←YY←]S]NA	JAI←9Jt~∀4∀b\∪!CmJA∧AOY←	CXAS9iKOKH@Cae=hB@Q=dAg←5JA←i!KdA]¬[JR~(∪oQS
PA∩@↓GC\@↓IKGY¬eJ@A∃qiKe9CX@A¬]H@AQQK\@↓gKh@↓i↑@A]QCiKYKd~∀%ae←i∃GiS←8A∩AY%WJ\@↓)QK\0AoQK9KmKd↓≥)HAEkS1IfAB↓EY←G,X~∀∪%hAGC8AgiCMPAiQ∀AmCYUJAS\↓iQJAISOQh5[←ghrAESQfA←LCae←PB~∀∪%]i↑AQQJAaI←iKGQS←\A→SKYH8@A)Q%fAgK∃[fAM¬SeYr↓gS[a1J~∀∪Q↑AS[AYK[K9hAC]⊂ASfA
←[aCQSEYJ↓oSiP↓←YHAAe←Oe¬[f\~(~∀d\%βIHA∧AM←kIiPA-¬→+
A%≥)∂∃$AaCIC[Ki∃dAi↑↓≥)HXAoSQP~∀∪∧AIKM¬kYhAYCYkJ↓←L@`8@A)Q∃\A∩A
C\AGIKCiJ↓BAMS1JAoSQP~∀∪¬]rAI∃gSeK⊂Aae←QKGiS=\AEr↓gCsS9NXAM=dAKq¬[aYJ0~∀~∀$∪≥)∃$QGQ¬\YMS1K]C[∀YKed0Nddd$v~∀~(∪)QSLAo←k1HAEJ↓YKgf↓ieSG-rAiQ¬\A[KQQ←H@D\XAC9HAo←UYHACY←SH~(∪ae←	YK[f↓oQK\↓mCeS=kfAaI←GKIUeKfA
QC]O∀AiQJ↓mCYk∀A←L~(∩Cae=hB\@↓∪hAC1g↑Ag∃K[fA→CSeYdAgS[AYJAi<AS[a1K[K]PAC]H4∀∪Sf↓G←[a¬iSEY∀AoSi A←YH↓ae←OIC[f\4∃7∃
HZ[G←9gSIKHAI←S9NAiQ%fAoQ∃\AgK≥[K]h↓O←Kf↓i↑A'¬∪'∞r9:~∀~(~∀f\%⊃CmJ↓≥)HAgGC8AiQJ↓gieS9NAG←9iCS]%]NAi!JAMS1K]C[∀~∀∪M=dAiQ∀Aae←QKGiS=\AK]
Y←gK⊂AS\AA←S]idAEeC
WKif0AJ]N8~∀~∀$∪≥)∃$QGQ¬\XE
=≡]
∨=6nnX\o:xdHd|DY∃edRv4∀~∀∪QQJAaI←iKGQS←\A→SKYH↓S\Ai!JA≥Q$AE1←GVA]←kYH↓EJAg∃hAi↑4∀∩NdHdAEK→←eJA⊃←S]N↓iQJA∃≥)$↓++≡\A)QSLAo←k1HAEJ↓QCeI∃d~∀∪Q↑AS[AYK[K9hAgS9GJAπY
∪_A¬]HAa=ggSE1rA←i!KefA]←kYH↓QCmJ4∀∪i↑↓W]←n↓CE←kPAiQJ↓]KnA
←]mK9iS←\0AEkh↓ShASLAiQJ↓[←gh4∀∪CaAKCYS9NAg←1kiS←8AMe←4AiQJ↓giC]⊃a←S]PA←LA≥K]Ke¬YSir8~∀∪)!SfAG!C]OJ↓o←kY⊂ACYg<AEJA
←[aCQSEYJ↓oSiP↓←YH@4∀∪ae=OeC[L\~∃7)
$Z[QQSfAMs]iC`ASfA	YKiG!Ke←kLvAK]=kOPAQ↑AGCUgJA←9JAi↑↓akWJ↓←mKd↓iQJ~)G←]MUgS←\↓oSiP↓)≥`AC]H↓(d`A⊃SeKGQ←erA9C[Kf↓gQ←k1HAg←5JAag∃kI↑~)G←[a¬iSES1SirA∃mKdA	JACiQK[ai∃H\@A!←oKm∃dXAS_A!∪ Qπ∨!dRAoS1XAYKPAs←j↓I↑Ai!Sf~∃%\ABA
←[[C9HAgiIS]NX↓iQK\↓∩AgkAa←gJ\\]:4∀~∃∩↓o←kY⊂AEJA!Caar↓i↑Ag∃JAC]dA←LAQQKgJ↓[←IS→SGCi%←]f\4∀~∀∩$∩∪'S9GKeK1rX~∀$∩∩∪¬=DA∂←1IEKe≤~∀~∀<db[
∃DZnn@bh`d∪
) i∂∨→		%∞A¬hA%+Q∂%&4b`∪	%MMKe∃]GJA	KioK∃\A¬β%_AC]⊂A'β∪0AKqaIKggS=]f@@@~∃	¬iJt@HbA
Kλ@brn\@Q≠←9ICrRbn`r5gh~)
e←ZhA∂∨→⊃¬%∞↓ChA%U)∂%LZb`~)'kEU∃GhtA⊃SMMKIK]GJ↓EKio∃K\A¬¬∪_AC9HA'β%_AKqAeKggαK?;LhRS=iα↓βπ'bβπQα≥)6ε$hP4*%εCπ[∃εs?S'≡+⊃βSFQβ←FK3∃α∀
&1β∂βCπK.sS3Eπ∪↔SW⊗sMβSF(4+∂␈∪K↔∂"β[π3.)β≠?∩βπ9β/CCK↔∨≠'?9π≠W∂!εM↓!k1q5UbiQ%1εsπ7↔gI↓5Eε{H4*%∩V∃1εK→βg␈)β∨'6)β'Q¬##∃β/CCK↔∨≠'?9αA5Yqk)q5QbiM%βO!β←'faβK↔'+K9↓h+?I∧2ε"N*q↓α?rβS#∃ε{S#↔∩β#π;"aβ'→πK?Uβ≡{∪∃β&C∃β3∂#S↔Iε+cCK/≠O'?rβ';Sxh+¬α≤
&1βπ∪?∨K∞i1αNJ1β←Nc1β↔63Wπ&)β'Qπ#=αR∃*∃84Ph*S#O→β'Mε	β7'v{IβC⊗{3↔jβπQβn{OQ1ε∪WQβε+K#ππ→βO?n)β7↔w#'?9ε{_4+O!βO#␈+3⊃β⊗)β7π&)β'9π##∃α∀
&1β&{∂W7.sSπSN{984Ph($$M≠';∂/∪↔3e`h($$L∪?	α>{3∪/∪≥1α↔+S∨↔↔→5E@hP4(=∪⊃6≠↔∩i]]↓β	AQPK	AA↓βQβ+GV{#;O}qβ['
αε6⊗ JNε&bβW≤∨s{Lah*S#*β≠?3f{←';:βCK??∪π5β⊗{7MbβS#?.;!βπ≡≠?K∪Ns≥βSzβA9↓KAβ?→π##∃α≤
&1βn;Wπ`h+'Qπ≠#?Wf!β←?⊗Y9↓αJ;5βπ"α2>R~↓!s+∞S?#;≡{9y%αi5β←␈+3⊃β∂βCK↔≡KπS∃ε	βK↔εcd4+N1β¬β6Kaβ'~β↔[↔∩β7π∪*p4(4V∪↔∨'r↓↓↓↓α↓βK↔∂+'K∃β	AAAεs↔]πO#↔7MXh)↓βNsS↔∨/⊃βπK⊗eβπ⊗fmES*ul4R↓β';&+∨↔IεKKπJβ'S↔o3πIβ&+7C[∂⊃l4)αβCK'w!!
∪}s∃β←O#!β∪.≠3πK∂#'?;~⊃%l4R↓βS↔oβ[πI¬yβ;↔:CπKπJIm↓↓αβ∂?7n+;Q↓π##'Mε∪?7~β←'SBβπ9↓∀JR⊗5¬~Bε∞*α⊗b"
*NR⊗ h(%↓α↓↓↓↓α↓↓↓↓α↓↓↓↓α↓↓↓↓α↓↓↓↓αβ7↔O≡∨∃1ε∪WQβO!β∂↔↔#π';gIβO#␈+3∪9?!l4)αβCK'w!!	↓αβS↔7π3πIβ∂≠O'∨v+⊃	$hS↔;⊂hP4(=∪⊃6≠↔∩i]]↓β⊃MI\LR~I↓J≠'3/→βπ;"βOSW61↓↓↓h*S=R↓↓α2-→↓↓↓h*NεLa:∩>]→2ε&ei1α⊗Eα>JQt">nad
&2ubβπ;⊃∧2&2⊗≥Za2εLbuβπ⊗)βS#*βCK'v≠'Cπ`h+';&KK↔∂"βπ∪∪⊗+OO↔~β≠?Iεkπ';&';'v9αOπNa9↓α&C↔K∃εK∃β6K'?/→β3'∨#';∨_h+π;"β↔7↔⊗;↔;∂Jβπ∂←+AβS∂β↔MβNqβS#*βK??jβ?→α$!U]9ααS#∃ε#'K↔∨#?K'/_4*∩≤Yjm)d
&2uε≠?;S∞K9↓E+↓B-β}1αOπNa7K↔fS↔⊃ε3'3↔~q↓αSF+K∃βO→βπ3≡x4+O}k∃↓#v{]βC/∪↔3eεC'OS␈∪'∂πbIβπ≡[WAβ}qβS#*αV∩Aπ;'S!πβπ∂-εcπ↔bαNfMph(4*fKOS'v;Mβ?2α2&:ZiEAβ∞s⊃αB,⊃βπK*βπ3Ozβ≠?Wv!β'9π##∃β⊗{?5β}1α∩⊃+984*&C∃βO␈+K∂↔~β≠?I∧b&:-k	A↓"≥JMj2Lr-:∩m↓%βπ⊗)β?9π##∃α,"Aβ←O#!βC∞≠,4+f↔1¬~fM1εK↔¬¬Z2:-dR~Juph(4)JiIa5;0&≠'f+MαJ,~&9:≤
%1α∀*∞>V"rNε%ε{9β∪O≠SK'↔+S'?rβSπC*βK↔≠/⊃βS<hP&BJ|b>≥:D"JnNM→2B∩
iβπ;"α2&	tB∩Jn≥JM2B%
u1β>C'∂!εK∃βv{Qβ?rβS#∃π#πC∀hP'π;"β←#'≡Aβ'9π#WK9π∪↔GWO∪∃β3N∪KπKN+MβSFQβ;zβ3?;>+Iβ↔FKOQ8hP&7πN∪∃β∪zβO?7/##';:βπ?/!β'Qr↓αS#∞s/Mβ&yα≡*jβ≠?IεK;≠=ph(4({↓a67∂⊃5]]α↓AMEHJ6*
α4+.;'84W∪↔∂?⊗!π∂3∂≠Mβ≠}y#';&+∨↔IπIoK↔≡{K⊃πε{';S/⊃#≠?zIβA%Xh+K↔≡{K⊃πε{';S/⊃#≠?zIβAEg↓Il4W↓F␈;/9πK↔≡{K⊃#6{=%lHKAJ␈v+]πK.≠?K⊃F3?=%Xh+≠?{SfoA
j⎇ElHH'≠?{SfoA∃j⎇IlhS≠?=WαoAFm{;↔]∂∪↔∂?⊗!#≠?zIl'≠}ykBoβ∩v␈;/9πK↔≡{K⊃#6{=%lhS≠?=WJoAFi;≠?=WJoAJkX4*∞|j6⊗:"αS#∃εs↔cQπ≠SπS.k↔;Qε#?↔Or;Qβ∂}kC'3*q↓απfaα%β>;Qβ&yβ∪=εKMβO>AβC'∪Ml4V3?=k¬[AFt>3?=k¬[AJuXh+↔;#X4(4PyEE6∂βI5]:↓↓IM#(&~RβR≡>2$∩⊗J≥εQαJ-"≡⊗J~iE@&'K;π7N→βπK⊗gMβNqαNεLa4*&S∃iβ	Iαππ⊃↓Ee;9↓"S.+O∪πJI↓AI#)6↔O h*≠K}iiα≡|b∩
⊗∀9βπQ¬∩VR≡-∩M5Eh*OW⊗S↔∂QRα∪g;∞k'
β∂∪Kπg~β'9α≤
&04U#=i↓αβOπ'bβπQα≥)6ε$hP4*≠␈⊃β[π⊗K?WMεCC3N≠πS'}sM1βO!β'Mε≠?;[.s'↔;"βS=β⊗)βπf)βS=ε#g;πnK∂π3gH4+↔Gβπ;⊃ε9αε∃∩εeβ'+K';:βS#∃ε≠?WK≡)β?→ε+c↔∂/#'?9ε{→β¬πβK?∨⊗5β←O##?W h+3↔∂3';≥π##∃β⊗c?∂-εK9β←FK∂!β&C∃βπ↔∪πeβ>Mβ∪.≠3πK.!βπ;"βK↔↔w#↔K'v99↓αJβ#π[(h+SKN+⊃α2,
Aβπ↔∪πgMbβWQπ##↔K*βπK∃πβK?f+7Mβ>KS!β≡C↔∂//∪?π⊗#';≥εk↔7?↔I04+/≠C↔∂N33eεK→βSF)βπK⊗eβ∨⊗{←Mβ6+KeβfK∨∃r↓αO↔6+Kπ1πβπ∂/∞;↔Mβ∂∪∃β≠f{πS'v84+π⊗{W;⊃π;#'∂BβCK?ε{KQβ&yβCK␈3'∪∃ε	β∪gv7'
εKKπJβπ'fKSeβNqαNεLa9↓αJβ#π[(h+SKN+⊃βO/3↔Kπbβ←'SBαNRJLr≥βπ↔∪πgMε;⊃β6{W;⊃π##πQπ##↔eε;↔;↔⊗33eε#?9∨ h+←?⊗Yβ←↔fa↓#∃v99βSF)βOS⊗K;≥6<→β∪?/≠9∨Qε[;?]ε?W"βS#∃πβ?';&+KMβ7∪?5β&C∀4+'K;π7N→βπK⊗eβ'w#=βO'∪';≥π≠Cπ∂*aβO=εKQβk∂βMβSF)βOS⊗K;∨MJp4(4U;?W3"β'Qβ⊗)βC?∨≠'3*βS=βπ∪?['&)β¬β>{K/'v9βCπ≡[π∨∃αC?Iβ
β∪↔O∨∪'CSN{84+}1β#?:βS=β↔+'3⊃ne CORRECTLY) for dynamic STRING arrays?  The SAIL
manual does not have enough information on how garbage collection is
done for me to see what the problem is in the existing packages.  I
believe that there is a general need for a dynamic string array package
among the SAIL user community, so the time to implement it
would be justified.

				Bob Goldberg

P.S.  See DYNARY.SAI[a710sa00] @ CMU-10A for an example of a
	nice package that, unfortunately, does not work for string arrays.

∂24-Apr-77  1725	JFR   via RTGT	future optimization 
in /w mode, kep track$in /w mode, keep track of the address of the last %ALSTO symbol to
avoid issuing multiple symbols for the same address.

∂12-May-77  0621	FTP: Ives at RADC-Multics	 Message Clarification  
From:  Ives at RADC-Multics
Date:  05/12/77 0919-edt
Subject:  Message Clarification
To:  SAIL at SAIL

Two messages cued to Ives at radc came through blanked out.
If they held any content please repeat.
They were sent from Network host SAIL (NETML.NetAdmin)
on 05/11/77 at 0417.0 edt and 0420.6 edt.