perm filename RHT.MSG[CMU,AIL] blob sn#129496 filedate 1974-11-13 generic text, type T, neo UTF8
∂12-NOV-74  0730		CMU,AIL @ CMU
 I have no argument with anything in your last msg.
 Technically, I think the proposed changes are good; and since you
 are much more knowledgable and familiar with this, I would certainly
 bow to your judgment anyway.
 I have not done the SETPRI stuff yet, and if you could get it done
 in the next couple of days, I would be most grateful to wait and
 snarf yours.  A bit in the SPROUT sounds just fine to me.
 Again, I certainly must go along with your perceptions about
 maintenance.  I think we will probably hold off on SAIL-8 for
 a while yet, mostly because we are in crisis mode now and I
 have no time.  (I assume that the changes for FIFO will be directly
 usable in SAIL-7 -- if not, we may be forced to go over sooner,
 I guess [but I hope not]).
 I would suggest trying to get me over the net before calling -- I will
 probably be unavailable for most of the day (Nils Nilsson is giving
 a talk later, etc.).  You can always do a PLEASE to the
 to the operator, or just do a SEND to some random A610 job.
 p.s.  must run now, but will check my mail later.

∂11-NOV-74  0729		network site CMU
***** FTP mail from [A610LE03] (ERMAN)
 Thanks for the quick response to my poke about scheduling processes.
 Random reactions:
 .We also thought of using events and doing our own scheduling,
 but were hoping
 for something a bit more efficient (and less indirect).
 .I would be somewhat frightened about going to an undocumented
 implementation of a much older, documented, and debugged facility.  This
 is especially true since there is no one, anywhere, that is responsible
 for and has the time to do the debugging.  It seems to me that unless
 you are able to commit whatever of you is necessary to respond to
 bug reports on such a new implementation and document the record stuff,
 that it would be very unfair to the rest of the SAIL world.  If you
 just put it up as an "experimental" system, with no guarantees, then
 we will be back in the same boat as before, caught between your system
 which we dare not use and the "X,AIL" system in which bugs never get
 ....I would strongly urge making some attempt to get some
 resources from somewhere committed to maintaining SAIL -- I know we
 would be willing to kick in some of our ARPA funding to help.
 The situation as it now exists is inefficient and unfair for all
 of us (especially including you people).  If you think it would help,
 we would be glad to make a poke at someone to voice this concern.
 Who is the right person there? McCarthy? (I doubt it.)  Binford?
 I will not do anything about this for now until I hear from you,
 so don't panic.
 thanx again for your help,
 P.S.  I guess we will just go change SETPRI for now; if you have any
 ramore random thoughts about these changes, please let me know.
∂10-NOV-74  1607		network site CMU
***** FTP mail from [A610LE03] (ERMAN)
 We are hot and heavy into using the PROCESS stuff.  One thing we
 notice is that sprouted processes get put on their respective
 priority lists in LIFO order.  We would really like it to be
 FIFO.  Is there some reasonable way we can impose our own
 (user) schedule in place of SAIL's (which would, obviously,
 give us even more flesibilty)?  I gather there is no facility
 akin to user CAUSE and INTERROGATE procedures.  Would you have
 a suggestion on a simple way to implement this?  If not, which
 piece of the run-times would you suggest we should change to
 get SAIL to do FIFO (i.e., putting on the queue or taking off)?
 thanx for any help you can offer,
 	Lee and Rick