From Gumby at MIT-MC.ARPA  Mon Mar 31 12:02:00 1986
From: Gumby at MIT-MC.ARPA (David Vinayak Wallace)
Date: Mar 31 86 05:02 EST
Subject: disowned vs in background
In-Reply-To: <[AI.AI.MIT.EDU].22357.860329.CENT>
Message-ID: <860331050242.8.GUMBY@MOSCOW-CENTRE.AI.MIT.EDU>

    Date: Sat, 29 Mar 86 17:23:33 EST
    From: "Pandora B. Berman" <CENT at AI.AI.MIT.EDU>

	Date: Thu 27 Mar 86 06:47:55-EST
	From: "Mark Becker" <Cent.Mbeck%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
	I admit ignorance as well... when I see a "disowned" job on an ITS, its
	usually associated with some username somewhere.
			----------begin forwarded mail----------
	Date: Wed, 26 Mar 86 23:17:29 EST
	From: Richard Barth <BARTH at MC.LCS.MIT.EDU>

	Ignorant question for today...
	What's the difference between running a job in the background and
	disowning it?

    beyond my limited technical ability to describe. someone on this list should
    be able to help you more.

Roughly speaking, a disowned job has no superior nor controlling TTY,
(f'rinstance like COMSAT normally runs).  DDT lets you run jobs in
background, (e.g.  w/ or ) by running them without the TTY and
handling output differently.  Their superior is still DDT.  From ITS's
point of view the only difference between running a job in foreground or
in background is who owns the TTY.

For a more detailed description, do :UUO .DISOWN, .ATTY, etc.

david

PS: bug-its people: what do you think of using BUG-ITS for questions
    like this?  I think it's a good idea, but if it's going to cause the
    fixers of bugs to remove themselves on the grounds of traffic
    levels, then we should have yet another list.

From ALAN at AI.AI.MIT.EDU  Mon Mar 31 07:52:51 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Mar 31 86 00:52:51 EST
Subject: AI:CRASH;CRASH QLOSS
Message-ID: <[AI.AI.MIT.EDU].22618.860331.ALAN>

AI:CRASH;CRASH QLOSS contains a crash dump that I can't figure out.  I
don't, unfortunately, grok the interface between the main program level
disk code and the interrupt level.  It looked for all the world (to the
users) like what happens on MC when the system is hung trying to write
directories to the T-300's.  I can tell that the main program level code is
waiting for bits to arrive from interrupt level, but I don't understand why
interrupt level isn't coming through.

Of course, the fact that we have two disk drives for the first time on a KS
is something to be suspicious of...

From CENT at AI.AI.MIT.EDU  Sat Mar 29 23:23:33 1986
From: CENT at AI.AI.MIT.EDU (Pandora B. Berman)
Date: Mar 29 86 17:23:33 EST
Subject: disowned?
Message-ID: <[AI.AI.MIT.EDU].22357.860329.CENT>

    Date: Thu 27 Mar 86 06:47:55-EST
    From: "Mark Becker" <Cent.Mbeck%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU>
    To: Cent at MC.LCS.MIT.EDU
    cc: Cent.Mbeck%OZ.AI.MIT.EDU at XX.LCS.MIT.EDU, Barth at MC.LCS.MIT.EDU
    I admit ignorance as well... when I see a "disowned" job on an ITS, its
    usually associated with some username somewhere.
		    ----------begin forwarded mail----------
    Date: Wed, 26 Mar 86 23:17:29 EST
    From: Richard Barth <BARTH at MC.LCS.MIT.EDU>
    To: MBECK at MC.LCS.MIT.EDU
    Ignorant question for today...
    What's the difference between running a job in the background and
    disowning it?

beyond my limited technical ability to describe. someone on this list should
be able to help you more.

From ALAN at MC.LCS.MIT.EDU  Sat Mar 29 13:58:39 1986
From: ALAN at MC.LCS.MIT.EDU (Alan Bawden)
Date: Mar 29 86 07:58:39 EST
Subject: So why did I bother you?
In-Reply-To: Msg of Sat 29 Mar 86 05:40:15 EST from Alan Bawden <ALAN at AI.AI.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].865489.860329.ALAN>

    Date: Sat, 29 Mar 86 05:40:15 EST
    From: Alan Bawden <ALAN at AI.AI.MIT.EDU>
    Well I just noticed that right now all new files on AI are being placed
    on the secondary pack!

This turned out to be easy to fix.  If the pack on unit #0 had enough free
space, ITS never noticed that it was not a primary pack.  I fixed ITS to
find a primary pack the first time someone writes a file after a boot.

From ALAN at AI.AI.MIT.EDU  Sat Mar 29 11:40:15 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Mar 29 86 05:40:15 EST
Subject: No subject
Message-ID: <[AI.AI.MIT.EDU].22278.860329.ALAN>

When I booted AI Friday morning, I wanted to test that I had built a
working front-end filesystem and DSKDMP on the secondary pack.  Since both
the 8080 front end and DSKDMP assume they should boot from unit #0, I
switched the unit number plugs so that the secondary pack was on unit #0
and the primary pack was on unit #1.

Well I just noticed that right now all new files on AI are being placed on
the secondary pack!  Yesterday, with the units arranged the other way files
were being made on PK0: just like the should have.  Perhaps this is some
unforseen result of my decision to number the secondary pack #1?  (I should
have chosen #13 to be conventional, but couldn't think of any reason why I
couldn't choose any number I wanted.)  Barf.

From ALAN at MC.LCS.MIT.EDU  Sat Mar 29 06:53:03 1986
From: ALAN at MC.LCS.MIT.EDU (Alan Bawden)
Date: Mar 29 86 00:53:03 EST
Subject: crash;crash massbs:  I see no unit #1 here.
In-Reply-To: Msg of Fri 28 Mar 86 11:20:19 EST from Richard Mlynarik <MLY at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].865339.860329.ALAN>

    Date: Fri, 28 Mar 86 11:20:19 EST
    From: Richard Mlynarik <MLY at MC>
    pi level 2 bughalt

Apparently the controller told ITS that drive #1, which I believe is
powered off, was asking for attention.  (Perhaps it was wondering when DEC
was coming back with the part they need to fix it.)  When ITS obligingly
asked the controller to ask the drive what its status was, the controller
reported that it timed out on the drive.  I guess we write this one off to
hardware flakeiness.

From MLY at MC.LCS.MIT.EDU  Fri Mar 28 17:20:19 1986
From: MLY at MC.LCS.MIT.EDU (Richard Mlynarik)
Date: Mar 28 86 11:20:19 EST
Subject: crash;crash massbs
Message-ID: <[MC.LCS.MIT.EDU].864552.860328.MLY5>

pi level 2 bughalt

From DCP at SCRC-QUABBIN.ARPA  Fri Mar 28 15:00:00 1986
From: DCP at SCRC-QUABBIN.ARPA (David C. Plummer)
Date: Mar 28 86 09:00 EST
Subject: where do sources live?
In-Reply-To: <[MC.LCS.MIT.EDU].863911.860327.GUMBY>
Message-ID: <860328090041.1.DCP@FIREBIRD.SCRC.Symbolics.COM>

    Date: Thu, 27 Mar 86 17:25:42 EST
    From: David Vinayak Wallace <GUMBY at MC.LCS.MIT.EDU>

    Why not delete sources from MC to prevent forking?

Why not take the phones and phone books out of your office on the
grounds you have sets at home?


From DCP at SCRC-QUABBIN.ARPA  Fri Mar 28 15:00:00 1986
From: DCP at SCRC-QUABBIN.ARPA (David C. Plummer)
Date: Mar 28 86 09:00 EST
Subject: where do sources live?
In-Reply-To: <[MC.LCS.MIT.EDU].863911.860327.GUMBY>
Message-ID: <860328090041.1.DCP@FIREBIRD.SCRC.Symbolics.COM>

    Date: Thu, 27 Mar 86 17:25:42 EST
    From: David Vinayak Wallace <GUMBY at MC.LCS.MIT.EDU>

    Why not delete sources from MC to prevent forking?

Why not take the phones and phone books out of your office on the
grounds you have sets at home?


From ALAN at AI.AI.MIT.EDU  Fri Mar 28 15:02:47 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Mar 28 86 09:02:47 EST
Subject: A new ITS is born
Message-ID: <[AI.AI.MIT.EDU].22057.860328.ALAN>

MIT-MX came up for the first time this morning.  (You can supdup there
right now, but you won't find much when you get there...)  There are still
some problems with the technology for creating new ITS systems from
scratch, but it mostly works.  Hopefully after doing the next two (ML and
MD) things will be pretty smooth.

All kind of worms are crawling out of the woodwork because of various
programs that -know- that all ITS machines are named "AI", "MC", "ML", or
"DM".  It should take another days hacking to stomp them all...

From ALAN at MC.LCS.MIT.EDU  Fri Mar 28 15:01:33 1986
From: ALAN at MC.LCS.MIT.EDU (Alan Bawden)
Date: Mar 28 86 09:01:33 EST
Subject: where do sources live?
In-Reply-To: Msg of Thu 27 Mar 86 17:25:42 EST from David Vinayak Wallace <GUMBY at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].864470.860328.ALAN>

    Date: Thu, 27 Mar 86 17:25:42 EST
    From: David Vinayak Wallace <GUMBY at MC>
    Why not delete sources from MC to prevent forking?

Because I think in would be a good idea for them to get on the last full
dump of MC.

From GUMBY at MC.LCS.MIT.EDU  Thu Mar 27 23:25:42 1986
From: GUMBY at MC.LCS.MIT.EDU (David Vinayak Wallace)
Date: Mar 27 86 17:25:42 EST
Subject: where do sources live?
In-Reply-To: Msg of Thu 27 Mar 86 16:59:17 EST from Alan Bawden <ALAN at MC.LCS.MIT.EDU>
Message-ID: <[MC.LCS.MIT.EDU].863911.860327.GUMBY>

Why not delete sources from MC to prevent forking?

From ALAN at MC.LCS.MIT.EDU  Thu Mar 27 22:59:17 1986
From: ALAN at MC.LCS.MIT.EDU (Alan Bawden)
Date: Mar 27 86 16:59:17 EST
Subject: No subject
Message-ID: <[MC.LCS.MIT.EDU].863829.860327.ALAN>

Pinhead!  You modified MC:SYSNET;TELSER instead of AI:SYSNET;TELSER.
If people make pinheaded mistakes like this we will be up to our
necks in forked sources.

Everybody:  Remember that sources live on AI!  If you are in doubt,
look for a file named " MOVED TO AI " on the directory containing
the source in question on MC.  If this file exists, then all of
the sources on that directory now live on AI.  This has
been true of all SYS*** directories for a couple of days now.

From ALAN at AI.AI.MIT.EDU  Mon Mar 24 03:27:35 1986
From: ALAN at AI.AI.MIT.EDU (Alan Bawden)
Date: Mar 23 86 21:27:35 EST
Subject: Grand migration begins
Message-ID: <[AI.AI.MIT.EDU].20774.860323.ALAN>

OK this is it.  The migration of ITS system files from MC to AI is
beginning.  I have already moved a few directories and mailing lists and
having just moved Bug-ITS and Bug-DDT to AI, I thought I would test them by
informing you all of how this migration will work.  I expect to have most
of the SYS*** directories moved to AI by tomorrow.  If you have some
question about the status of a particular directory, look for a file on
that directory named " MOVED TO AI ".  If that file exists, then the file
you are looking for now lives on AI, edits on MC are likely to be lost.  If
that file doesn't exist, then MC still has the master copy.  In any case,
if I am logged in, be cautious about timing screws.

From AI.DUFFY at UTEXAS-20.UTEXAS  Sun Mar 23 16:06:00 1986
From: AI.DUFFY at UTEXAS-20.UTEXAS (Gavan Duffy)
Date: Mar 23 86 09:06 CST
Subject: LMSEND
Message-ID: <860323090604.3.GAVAN@ALAMO.UTEXAS>

It isn't on AI. Sigh.  I had to CHTN to Jimi Hendrix to QSEND.


From ALAN at MC.LCS.MIT.EDU  Mon Mar  3 08:12:36 1986
From: ALAN at MC.LCS.MIT.EDU (Alan Bawden)
Date: Mon,  3 Mar 86 02:12:36 EST
Subject: " mode in PEEK
Message-ID: <[MC.LCS.MIT.EDU].836305.860303.ALAN>

I added a new mode to PEEK for printing the contents of the system message
buffer.  (Type a doublequote to get it.)  This is especially useful for
looking at crash dumps.  While I was at it I added a few features to crash
dump mode itself.  For a good example try (on AI):
:PEEK <CRASH;IMP NXM
and after looking at the crash dump display, type " to see some more
interesting error messages.