TOPS-10 6.03
Arthur Krewat
I have had some success finally, getting a 6.03
SYSTEM.EXE running. I was able to boot it from SYS:SYS603.EXE
on a 7.03 pack, and it actually starts up, runs and works as
well as I expected it to. SYSTAT runs, but LOGIN dies with
an illegal UUO, which again, I expected.
On to bigger and better things, I'm going to make
up a system pack from the 6.03 tapes on trailing-edge,
and pray :)
aak
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>Hello all,
>
> I have had some success finally, getting a 6.03
>SYSTEM.EXE running. I was able to boot it from SYS:SYS603.EXE
>on a 7.03 pack, and it actually starts up, runs and works as
>well as I expected it to. SYSTAT runs, but LOGIN dies with
>an illegal UUO, which again, I expected.
Just out of curiousity, which UUO? All of my accounting stuff
was in the 7-series but not the 6-series. FILDAE wouldn't work
either...I don't think... because of the FILOP. UUO.
/BAH
>
> On to bigger and better things, I'm going to make
>up a system pack from the 6.03 tapes on trailing-edge,
>and pray :)
>
>aak
Subtract a hundred and four for e-mail.
Arthur Krewat
>
> In article <3B24FA9C...@bartek.dontspamme.net>,
> Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
> >Hello all,
> >
> > I have had some success finally, getting a 6.03
> >SYSTEM.EXE running. I was able to boot it from SYS:SYS603.EXE
> >on a 7.03 pack, and it actually starts up, runs and works as
> >well as I expected it to. SYSTAT runs, but LOGIN dies with
> >an illegal UUO, which again, I expected.
>
> Just out of curiousity, which UUO? All of my accounting stuff
> was in the 7-series but not the 6-series. FILDAE wouldn't work
> either...I don't think... because of the FILOP. UUO.
After booting SYS603, I got this from LOGIN:
.LOGIN
Job 1 Installation Monitor CTY
?
?Illegal UUO at user PC 000604
I rebooted into 7.03 and checked login.exe:
.get sys:login
Job setup
.ddt
VMDDT
604/ 0
605/ 0
606/ 0
607/ 0
610/ 0
611/ 0
Something is weird. But, I have to try building a real 6.03 pack
before I do anything else. I was able to INITIA and get logged
into 1,2 and could do this:
.I
Installation Monitor 08:55:05 CTY system 4544
Connected to Node CENTRA(0) Line # 11
.LOGIN 1,2
.R OPSER
[OPRPAF Processing auto command file]
?OPRALF LOOKUP failure 0
*^C
.^C
.SYS
Status of Installation Monitor at 8:55:15 on 12-Jun-101
Not Running
1 Jobs in use out of 15. 1 logged in, 0 detached.
Job Who Line# What Size(P) State Run Time
1 [OPR] CTY SYSTAT 17+SPY RN 0
Swapping space used = 0/2000 = 0%
Virt. Core used = 17/2000 = 1%
1897P Core left
Active swapping ratio = 17/1914 = .00
Average job size =17/1 = 17.0P+0/1 = .00P Total=17/1 = 17.0P
No busy devices
1 disk DDBs
System File Structures:
Name Free Mount
DSKB 232030 2
Total Free 232030
aak
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>jmfb...@aol.com wrote:
>>
>> In article <3B24FA9C...@bartek.dontspamme.net>,
>> Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>> >Hello all,
>> >
>> > I have had some success finally, getting a 6.03
>> >SYSTEM.EXE running. I was able to boot it from SYS:SYS603.EXE
>> >on a 7.03 pack, and it actually starts up, runs and works as
>> >well as I expected it to. SYSTAT runs, but LOGIN dies with
>> >an illegal UUO, which again, I expected.
>>
>> Just out of curiousity, which UUO? All of my accounting stuff
>> was in the 7-series but not the 6-series. FILDAE wouldn't work
>> either...I don't think... because of the FILOP. UUO.
>
>After booting SYS603, I got this from LOGIN:
>
>Job 1 Installation Monitor CTY
>
>?
>?Illegal UUO at user PC 000604
See if you can say
E 000604
>
>I rebooted into 7.03 and checked login.exe:
>
>..get sys:login
>Job setup
>
>..ddt
Nope. This won't work. Let me think. I've written two suggestions
already on how to debug LOGIN but realized they wouldn't work.
I can't recall how I did debug LOGIN.
But, what you want to do is put a LOGIN on SYS: that has
breakpoint before the UUO gets executed. That way, you'll
hit the breakpoint when you're logging in. Note that you
do have to have the system come up without all of those
other jobs trying to login (as you have indeed done if your
SYSTAT was correct). I don't think LOGIN has a lowseg to it
but I'd have to look at a listing to be sure.
<snip SYSTAT>
/BAH
Arthur Krewat
Not if I'm not logged in :) Although I could
do it after INITIA. But then, I get the please
KJOB or DETACH.
> >..ddt
>
> Nope. This won't work. Let me think. I've written two suggestions
> already on how to debug LOGIN but realized they wouldn't work.
>
> I can't recall how I did debug LOGIN.
<snip>
Like I said, I'll build a 6.03 pack with the correct version of
the CUSPS and stuff.
The only problem is after doing all this work, I'll have to retro-fit
the KS10 stuff back into the sources for the 6.03 monitor - yuck.
But doable...
aak
Arthur Krewat
I have gotten TOPS-10 6.03 to boot and run, and now got
into a tough spot. I can't login, and INITIA won't
start with a regular GO command, although it did do it
once and only once. From the CTY, I did LOGIN 1,2 and
got a PPN expired - after that, I get the normal response
to the wrong password (Invalid entry). I'll have to go
back through my install procedure and remember to setup
the 1,2 account correctly.
Anyway, since the second tape of the 6.03 CUSPS is not
in the trailing-edge archives, I have had to use some
7.03 utilities like TECO and SETSRC.
Every thing runs, the only problem seems to be parity
with the DZ11 driver - I can SEND TTY0 from the console
and I get typical bad-parity output, but no response to
a carriage return (no suprise, the parity is probably
wrong). Using a line-feed, I get the typical garbled
output of wrong parity.
Oh well - it all seems to work this way, the only
problem I would like to tackle is putting the KS10
stuff back into the 6.03 monitor, since it seems to
be missing from the 603A on trailing-edge.
One appeal to the masses: DOES ANYONE HAVE TOPS-10
6.03 complete CUSP tapes, or better yet, the KS10
capable 6.03 TOPS-10 monitor sources????????
Anyone from ADP out there ? :)
aak
Henry Miller
"Arthur Krewat" <kre...@bartek.dontspamme.net> wrote in message
news:3B26A144...@bartek.dontspamme.net...
Well, my mother-in-law used to work for ADP; she could
probably get you payroll/tax information, but no TOPS sources.
Just to be clear, are you looking for 6.03 or 6.03A ?
> aak
-HWM
Arthur Krewat
>
> Arthur,
>
> "Arthur Krewat" <kre...@bartek.dontspamme.net> wrote in message
> news:3B26A144...@bartek.dontspamme.net...
> >
> > I have gotten TOPS-10 6.03 to boot and run
> >
> >
>
> Well, my mother-in-law used to work for ADP; she could
> probably get you payroll/tax information, but no TOPS sources.
Ouch... and for whom ? :)
> Just to be clear, are you looking for 6.03 or 6.03A ?
For the longest time, and I was the one hacking the monitor for the
site consisting of 5 KS10's running 6.03, I thought it was plain 6.03.
I found an installation monitor for 6.03A living as SYS000.EXE
in an old system backup, AFTER the logical end-of-tape on a 1/2"
personal backup I had...
Now, I am convinced it was 6.03A, since I have checked some other
backups I had made, and they plainly state 6.03A.
It's been fun... again, ANYONE HAVE 6.03A for KS10? ? ? huh, please?
Don't ask why, I'm just nostalgic... if I could, I'd love to run
TOPS10 5.06 on a KA10 again ... I once got a view of it through a
window...
aak
Arthur Krewat
>
> <snip lots of crap about TOPS-10 6.03>
>
> Every thing runs, the only problem seems to be parity
> with the DZ11 driver - I can SEND TTY0 from the console
> and I get typical bad-parity output, but no response to
> a carriage return (no suprise, the parity is probably
> wrong). Using a line-feed, I get the typical garbled
> output of wrong parity.
Anding each character written to the DZ11 (in dz0_wr) with 0x7f
solved this problem totally. Input is fine... weird how fixing
the output solved the above.
Is it a good idea to just blatently strip the MSB ? Is there ever
a case where it would be needed in ANY PDP-10 monitor?
Frank da Cruz, anything Kermit couldn't handle? (of course not, I
know, I just want to make sure, and to stir the pot a little).
aak
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>
>I have gotten TOPS-10 6.03 to boot and run, and now got
>into a tough spot. I can't login, and INITIA won't
>start with a regular GO command, although it did do it
>once and only once. From the CTY, I did LOGIN 1,2 and
>got a PPN expired -
If it's really 6.03, I think you've getting bit by an
emulator bug....unless you're trying to use a 7.03 ACCT.SYS
with a 6.03 LOGIN.
> after that, I get the normal response
>to the wrong password (Invalid entry). I'll have to go
>back through my install procedure and remember to setup
>the 1,2 account correctly.
What password are you using? I think we used to ship it
with ONETWO.
>
>Anyway, since the second tape of the 6.03 CUSPS is not
>in the trailing-edge archives, I have had to use some
>7.03 utilities like TECO and SETSRC.
Honey, with 6.03, you are going to have to get about 23 CUSP
tapes. We didn't get our distribution act together until
sometime after (I think) 6.03A.
<snip>
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
<snip>
>Don't ask why, I'm just nostalgic... if I could, I'd love to run
>TOPS10 5.06 on a KA10 again ...
No, no, no. You don't want 5.06. 5.07A was much better running
piece of software.
Henry Miller
<jmfb...@aol.com> wrote in message news:9g7ged$6na$3...@bob.news.rcn.net...
> In article <3B26A144...@bartek.dontspamme.net>,
> Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
> >
> >I have gotten TOPS-10 6.03 to boot and run, and now got
> >into a tough spot. I can't login, and INITIA won't
> >start with a regular GO command, although it did do it
> >once and only once. From the CTY, I did LOGIN 1,2 and
> >got a PPN expired -
>
> If it's really 6.03, I think you've getting bit by an
> emulator bug....unless you're trying to use a 7.03 ACCT.SYS
> with a 6.03 LOGIN.
>
> > after that, I get the normal response
> >to the wrong password (Invalid entry). I'll have to go
> >back through my install procedure and remember to setup
> >the 1,2 account correctly.
>
> What password are you using? I think we used to ship it
> with ONETWO.
>
Weren't BACKUP and FAILSA also old default passwords?
> >
> >Anyway, since the second tape of the 6.03 CUSPS is not
> >in the trailing-edge archives, I have had to use some
> >7.03 utilities like TECO and SETSRC.
>
> Honey, with 6.03, you are going to have to get about 23 CUSP
> tapes. We didn't get our distribution act together until
> sometime after (I think) 6.03A.
>
You start with the most recent ones and work backwards. We used
to save alot of time that way. Worked on VMS, too.
> <snip>
>
> /BAH
>
> Subtract a hundred and four for e-mail.
-HWM
Henry Miller
> Henry Miller wrote:
> >
> > Arthur,
> >
> > "Arthur Krewat" <kre...@bartek.dontspamme.net> wrote in message
> > news:3B26A144...@bartek.dontspamme.net...
> > >
> > > I have gotten TOPS-10 6.03 to boot and run
> > >
> > > Anyone from ADP out there ? :)
> > >
> >
> > Well, my mother-in-law used to work for ADP; she could
> > probably get you payroll/tax information, but no TOPS sources.
>
> Ouch... and for whom ? :)
>
> > Just to be clear, are you looking for 6.03 or 6.03A ?
>
> For the longest time, and I was the one hacking the monitor for the
> site consisting of 5 KS10's running 6.03, I thought it was plain 6.03.
>
> I found an installation monitor for 6.03A living as SYS000.EXE
> in an old system backup, AFTER the logical end-of-tape on a 1/2"
> personal backup I had...
>
> Now, I am convinced it was 6.03A, since I have checked some other
> backups I had made, and they plainly state 6.03A.
>
At a glance, it would be really difficult to tell 6.03 from 6.03A. But,
I
remember in part some of the pain we had to go through to get TOPS10
running on a 2020 in the field, and I recall clearly that the first release
that
we got, indeed that there was, was 6.03A.
As I recall now, the KS boot tape had the usual microcode, bootable
system, etc. BUT, after all of that, there was another BACKUP saveset
that had the modified modules plus KSSER.MAC, and whatever new files
were needed for KS10 support.
And, if you didn't have all of the system support files and cusps
readily
available, or knew how to fake it, you were SOOL. Oh, you could get the
system up eventually, but it was a slow process.
Also, I just remembered that in some context when booting the system
from tape, you had to use: "/TM02". I don't recall if it was in TOPS10 or
in the KS bootstrap.
> It's been fun... again, ANYONE HAVE 6.03A for KS10? ? ? huh, please?
>
Somebody, somewhere, has got to have a copy of the boot tape.
> Don't ask why, I'm just nostalgic... if I could, I'd love to run
> TOPS10 5.06 on a KA10 again ... I once got a view of it through a
> window...
>
5.06? Oh, why? Why not at least 6.01?
> aak
-HWM
jmfb...@aol.com
"Henry Miller" <henry....@worldnet.att.net> wrote:
>
><jmfb...@aol.com> wrote in message news:9g7ged$6na$3...@bob.news.rcn.net...
>> In article <3B26A144...@bartek.dontspamme.net>,
>> Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>> >
>> >I have gotten TOPS-10 6.03 to boot and run, and now got
>> >into a tough spot. I can't login, and INITIA won't
>> >start with a regular GO command, although it did do it
>> >once and only once. From the CTY, I did LOGIN 1,2 and
>> >got a PPN expired -
>>
>> If it's really 6.03, I think you've getting bit by an
>> emulator bug....unless you're trying to use a 7.03 ACCT.SYS
>> with a 6.03 LOGIN.
>>
>> > after that, I get the normal response
>> >to the wrong password (Invalid entry). I'll have to go
>> >back through my install procedure and remember to setup
>> >the 1,2 account correctly.
>>
>> What password are you using? I think we used to ship it
>> with ONETWO.
>>
>
> Weren't BACKUP and FAILSA also old default passwords?
Not BACKUP. FAILSA might have been one before Level D days.
>
>> >
>> >Anyway, since the second tape of the 6.03 CUSPS is not
>> >in the trailing-edge archives, I have had to use some
>> >7.03 utilities like TECO and SETSRC.
>>
>> Honey, with 6.03, you are going to have to get about 23 CUSP
>> tapes. We didn't get our distribution act together until
>> sometime after (I think) 6.03A.
>>
>
> You start with the most recent ones and work backwards. We used
>to save alot of time that way. Worked on VMS, too.
Uh-huh. That won't work. Think about all the lovely editions
of SCAN and WILD that we had before we generated one, and only
one, CUSP tape. If he misses one tape, he's screwed.
Your method will work but that assumes all editions are available.
jmfb...@aol.com
That was the LIR tape, wasn't it?
>
> And, if you didn't have all of the system support files and cusps
>readily
>available, or knew how to fake it, you were SOOL. Oh, you could get the
>system up eventually, but it was a slow process.
That was the definition of an LIR. These people seem to be
getting too used to this plug'n'play stuff. ;-)
<snip>
>> Don't ask why, I'm just nostalgic... if I could, I'd love to run
>> TOPS10 5.06 on a KA10 again ... I once got a view of it through a
>> window...
>>
>
> 5.06? Oh, why? Why not at least 6.01?
Apparently, at some point in time, we managed to really fuck it
up. Jim wrote a replace for KA floating point and we shipped that
as KASER.MAC but didn't keep the real one around.
Arthur Krewat
>
> As I recall now, the KS boot tape had the usual microcode, bootable
> system, etc. BUT, after all of that, there was another BACKUP saveset
> that had the modified modules plus KSSER.MAC, and whatever new files
> were needed for KS10 support.
Good news, at least there is still hope that somewhere a KS-capable
6.03A monitor source lives.
> Also, I just remembered that in some context when booting the system
> from tape, you had to use: "/TM02". I don't recall if it was in TOPS10 or
> in the KS bootstrap.
Boot from magtape, the bootstrapper comes up with a prompt, and you
type "/tm02" to load SYSTEM.EXE from the next tape file.
> > Don't ask why, I'm just nostalgic... if I could, I'd love to run
> > TOPS10 5.06 on a KA10 again ... I once got a view of it through a
> > window...
> >
>
> 5.06? Oh, why? Why not at least 6.01?
Just plain nostalgia. I used 5.06 on a KA10 for around a year before
the site "upgraded" to eventually 5 KS10's running 6.03A. This was
in 9th-10th grade.
I eventually went on to work at the site as a consultant on the KS10's.
aak
Arthur Krewat
>
> >I have gotten TOPS-10 6.03 to boot and run, and now got
> >into a tough spot. I can't login, and INITIA won't
> >start with a regular GO command, although it did do it
> >once and only once. From the CTY, I did LOGIN 1,2 and
> >got a PPN expired -
>
> If it's really 6.03, I think you've getting bit by an
> emulator bug....unless you're trying to use a 7.03 ACCT.SYS
> with a 6.03 LOGIN.
Nope, got past the problem, but now I can't login as 1,2
from TTY0:
.LOG 1,2
JOB 2 Installation Monitor TTY0
?LGNMNL May not LOGIN remote
And, I do not remember anything about the "PRIV WORD" that
REACT wants. Setting it to 777777,,777777 didn't do jack.
I also setup another account, 565,11 and still the same
"May not LOGIN remote".
> > after that, I get the normal response
> >to the wrong password (Invalid entry). I'll have to go
> >back through my install procedure and remember to setup
> >the 1,2 account correctly.
>
> What password are you using? I think we used to ship it
> with ONETWO.
Didn't try that. I already set it to something else.
> >Anyway, since the second tape of the 6.03 CUSPS is not
> >in the trailing-edge archives, I have had to use some
> >7.03 utilities like TECO and SETSRC.
>
> Honey, with 6.03, you are going to have to get about 23 CUSP
> tapes. We didn't get our distribution act together until
> sometime after (I think) 6.03A.
The monitor tape and the 1 of 2 CUSP tape hold almost everything,
except for certain necessities like SETSRC and TECO. It even
has MIC already in SYS:
I even have an old copy of TECO from 6.03A with one or two small
site hacks, so if I was a purist, I could always use that :)
aak
Arthur Krewat
>
> Nope, got past the problem, but now I can't login as 1,2
> from TTY0:
>
> .LOG 1,2
> JOB 2 Installation Monitor TTY0
> ?LGNMNL May not LOGIN remote
>
> And, I do not remember anything about the "PRIV WORD" that
> REACT wants. Setting it to 777777,,777777 didn't do jack.
> I also setup another account, 565,11 and still the same
> "May not LOGIN remote".
I was able to resolve this by answering the following question
in REACT after doing an "I 1,2"
LOGIN (TYPE TTY TYPES): REMOTE LOCAL
aak
Douglas H. Quebbeman
> Now, I am convinced it was 6.03A, since I have checked some other
> backups I had made, and they plainly state 6.03A.
>
> It's been fun... again, ANYONE HAVE 6.03A for KS10? ? ? huh, please?
>
> Don't ask why, I'm just nostalgic... if I could, I'd love to run
> TOPS10 5.06 on a KA10 again ... I once got a view of it through a
> window...
This was the version of TOPS-10 they were running most of the
time I was at IU... but we were running on a KL-10, upgraded
from a KI-10.
Are there really any differences? Other than bugs not fixed,
etc.?
-dq
Arthur Krewat
Between 5.06 and 6.03? Some, like virtual memory hooks, I think.
Also, I don't think 5.06 had SFD's (sub file-directories, like
[10,7,703MON]
aak
Al Kossow
>> Are there really any differences? Other than bugs not fixed,
>> etc.?
>
> Between 5.06 and 6.03? Some, like virtual memory hooks, I think.
> Also, I don't think 5.06 had SFD's (sub file-directories, like
> [10,7,703MON]
>
From: bu...@csa.bu.edu (Phil Budne)
Newsgroups: alt.sys.pdp10
Subject: stuff [was photos of TOPOS-10 teams]
Date: 10 Oct 2000 06:33:33 GMT
TOPS-10 Evolution
1964-66 1.4-1.9 PDP-6 Support, DECtape only, 27 jobs (UFA, 1 bit per job)
1967 2.18 KA support, disk support, shuffler
1968 3.27 swapping, 36 jobs (using JFFO)
1969 4.50 dual segments
4.72 CCL, 63 jobs
1970 5.01 TOPS-10, Disk Service rewrite (Phase I)
1971 5.02 MPB (batch), RTTRP (real time), Disk Service rewrite (phase II)
1972 5.03 1055 multiprocessor (dual KA)
5.04 KI support
1973 5.05 1077 support (dual KI)
5.06 SFDs (subdirectories)
1974 5.07/6.01
KL support, VM, IPCF (interprocess communication)
1975 6.02 1088 support (dual KL), class shced, RP04/6
ENQ/DEQ (resource locking), Galaxy I (spooling)
1977/78 6.03/A 1091 (MOS memory, RH20), ANF (PDP-10 comm network)
FILDAE (file access daemon)
1979 7.00 SMP (limited)
1980/82 7.01/A SMP (full), logical names, Galaxy 4.1
1984 7.02 DECnet-10 Phase III
Arthur Krewat
>
> >>
> >> Are there really any differences? Other than bugs not fixed,
> >> etc.?
> >
> > Between 5.06 and 6.03? Some, like virtual memory hooks, I think.
> > Also, I don't think 5.06 had SFD's (sub file-directories, like
> > [10,7,703MON]
<snip>
> 5.06 SFDs (subdirectories)
Interesting - I never knew it supported SFD's.
aak
John Sauter
version of TOPS-10 I worked with was RCC 2.4L, which
Robert Clements brought with him when he delivered
our PDP-6. I gather it wasn't generally distributed.
I worked with Bill Weir, the creator of CCL, the
language that formed the base for MS-DOS
and all of its descendants today. Bill wrote the
application, Dick Gruen (a DEC employee) modified the
compilers, and I hacked the monitor so the application
could read the line that invoked it. This was the
origin of the DIRECTORY command, among many others.
While a consultant at DEC I coded the original version
of IPCSER.
Lots of good memories here.
John Sauter (J_Sa...@Empire.Net)
TOPS-10 Evolution
1964-66 1.4-1.9 PDP-6 Support, DECtape only, 27 jobs
(UFA, 1 bit per job)
1967 2.18 KA support, disk support, shuffler
1968 3.27 swapping, 36 jobs (using JFFO)
1969 4.50 dual segments
4.72 CCL, 63 jobs
1970 5.01 TOPS-10, Disk Service rewrite (Phase I)
1971 5.02 MPB (batch), RTTRP (real time),
Disk Service rewrite (phase II)
1972 5.03 1055 multiprocessor (dual KA)
5.04 KI support
1973 5.05 1077 support (dual KI)
5.06 SFDs (subdirectories)
1974 5.07/6.01 KL support, VM,
IPCF (interprocess communication)
1975 6.02 1088 support (dual KL), class scheduling,
RP04/6, ENQ/DEQ (resource locking),
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>jmfb...@aol.com wrote:
>>
>> >?
>> >?Illegal UUO at user PC 000604
>>
>> See if you can say
>>
>> E 000604
>
>Not if I'm not logged in :) Although I could
>do it after INITIA. But then, I get the please
>KJOB or DETACH.
>
>> >..ddt
>>
>> Nope. This won't work. Let me think. I've written two suggestions
>> already on how to debug LOGIN but realized they wouldn't work.
>>
>> I can't recall how I did debug LOGIN.
>
><snip>
>
>Like I said, I'll build a 6.03 pack with the correct version of
>the CUSPS and stuff.
And I'm telling you that you're going to have nothing but problems.
There really wasn't a "correct" _single_ version of each CUSP
in those days. We had a mess.
>
>The only problem is after doing all this work, I'll have to retro-fit
>the KS10 stuff back into the sources for the 6.03 monitor - yuck.
>But doable...
But before you do that, you need to find out if you are wrestling
with an emulator bug. None of this work is going to be productive
if you're tripping on a bug not in TOPS-10.
I don't know your expertise. I would build a LOGIN with DDT and
set a breakpoint. Trial and error will get a breakpoint
before the illegal UUO. Then just $X through the code or
take a look at the job's data.
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>jmfb...@aol.com wrote:
>>
>> >I have gotten TOPS-10 6.03 to boot and run, and now got
>> >into a tough spot. I can't login, and INITIA won't
>> >start with a regular GO command, although it did do it
>> >once and only once. From the CTY, I did LOGIN 1,2 and
>> >got a PPN expired -
>>
>> If it's really 6.03, I think you've getting bit by an
>> emulator bug....unless you're trying to use a 7.03 ACCT.SYS
>> with a 6.03 LOGIN.
>
>Nope, got past the problem, but now I can't login as 1,2
>from TTY0:
>
>JOB 2 Installation Monitor TTY0
>?LGNMNL May not LOGIN remote
>
>And, I do not remember anything about the "PRIV WORD" that
>REACT wants. Setting it to 777777,,777777 didn't do jack.
That's documented in the REACT spec. Those specs (Notebook 13?)
are very useful. I don't remember anybody mentioning them
as fodder for the scanner.
>I also setup another account, 565,11 and still the same
>"May not LOGIN remote".
<snip>
You're not going to be able to do jack if your terminal
characteristics are viewed as remote. Those pesky students
made us tighten security w.r.t. remote terminals [grinning
emoticon looking around the readers and noticing how many
got started as a pesky student].
>> >Anyway, since the second tape of the 6.03 CUSPS is not
>> >in the trailing-edge archives, I have had to use some
>> >7.03 utilities like TECO and SETSRC.
>>
>> Honey, with 6.03, you are going to have to get about 23 CUSP
>> tapes. We didn't get our distribution act together until
>> sometime after (I think) 6.03A.
>
>The monitor tape and the 1 of 2 CUSP tape hold almost everything,
>except for certain necessities like SETSRC and TECO. It even
>has MIC already in SYS:
Sigh! I think I'm talking in ASCII English. Can somebody help
me try to explain our mess?
One of the side effects of getting our distribution act together
was the creation of a Tools tape and a Customer Supported Tape
so that we could ship stuff like MIC, Tulip, etc. When that
happened we never shipped another CUSP Update tape. Then the
idiots invented Autopatch and we ended up back to square one.
I finally fixed it so we didn't have to Autopatch the CUSPs
either, but, by then it was too late to have any shipping
advantages. My goal was to eliminate the BLISS monstrosity.
>
>I even have an old copy of TECO from 6.03A with one or two small
>site hacks, so if I was a purist, I could always use that :)
There were very few edits to TECO after Chuck McComas finished
with it. :-)
Arthur Krewat
>
> >I also setup another account, 565,11 and still the same
> >"May not LOGIN remote".
> <snip>
>
> You're not going to be able to do jack if your terminal
> characteristics are viewed as remote. Those pesky students
> made us tighten security w.r.t. remote terminals [grinning
> emoticon looking around the readers and noticing how many
> got started as a pesky student].
I posted yesterday that I resolved the login issue, and 6.03A
is working perfectly for me now. I can login, do anything, and
most of the CUSPS (that I remember) are there. I had to copy
SETSRC and TECO from the 7.03 distribution.
I was one of the pesky students that circumvented everything
that site did to tighten security, even after they ripped LOGIN
and REACT out and rewrote them themselves. That's why I was
offered a job at 17 to be a consultant for them!
Anyway, 6.03A is running fine for me, it's been up over 36 hours
now, and running fine.
I have yet to encounter any bugs in simh, although there may be
some lurking around somewhere.
aak
Arthur Krewat
>
> In article <3B263C19...@bartek.dontspamme.net>,
> Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
> >jmfb...@aol.com wrote:
> >>
> >> >?
> >> >?Illegal UUO at user PC 000604
> >>
>
> set a breakpoint. Trial and error will get a breakpoint
> before the illegal UUO. Then just $X through the code or
> take a look at the job's data.
>
Fair to middlin'. Using the 6.03 LOGIN.EXE, I do not have any
problems and everything works fine now.
I used to hack the monitor for security changes and bugs way
back when I was 17. Fun stuff ... playing with EDDT.REL and
the monitor to find the reason for a KAF stopcode was fun!
It turned out to be an endless loop when you have max core
and try to SSA a .EXE. The probem with our site was my boss
had setup the systems with 0 (yes 0!) virtual core limit, so
you could never map in the EXE directory when doing the SSA.
This caused a loop in SAVE somewhere, because one of the
labels had been mistyped (example: JRST SAVE5, instead of JRST SAVE6).
The fix was to adjust the core limits so you could have at
least ONE virtual page, or to edit the monitor and fix it.
I did, and even typed up an SPR but never turned it in.
What I still remember is slowly being reindexed and cached :)
aak
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>jmfb...@aol.com wrote:
>>
>> In article <3B263C19...@bartek.dontspamme.net>,
>> Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>> >jmfb...@aol.com wrote:
>> >>
>> >> >?
>> >> >?Illegal UUO at user PC 000604
>> >>
>>
>> I don't know your expertise. I would build a LOGIN with DDT and
>> set a breakpoint. Trial and error will get a breakpoint
>> before the illegal UUO. Then just $X through the code or
>> take a look at the job's data.
>>
>
>Fair to middlin'. Using the 6.03 LOGIN.EXE, I do not have any
>problems and everything works fine now.
>
>I used to hack the monitor for security changes and bugs way
>back when I was 17. Fun stuff ... playing with EDDT.REL and
>the monitor to find the reason for a KAF stopcode was fun!
The problem that I can't seem to write about is that there
are different debugging techniques depending on what you're
debugging. Debugging the monitor required a different
approach than debugging a CUSP that had to run 'not logged
in'. Debugging a CUSP such as DIRECT was different than
debugging a COBOL program.
The activities in getting a system set up for debugging
were not straight forward and got real complicated if
you had to work from the CTY.
Douglas H. Quebbeman
The verion? Or that TOPS-10 supoprt SFD's at all?
-dq
Arthur Krewat
No, I knew about SFD's as of 6.03, but never knew the older
5.06 (I used it on a KA10) did.
aak
Arthur Krewat
>
> The problem that I can't seem to write about is that there
> are different debugging techniques depending on what you're
> debugging. Debugging the monitor required a different
> approach than debugging a CUSP that had to run 'not logged
> in'. Debugging a CUSP such as DIRECT was different than
> debugging a COBOL program.
Yes. The only one above that I never had to do was a "not logged
in" CUSP. And yes, I even took a COBOL class once :)
> The activities in getting a system set up for debugging
> were not straight forward and got real complicated if
> you had to work from the CTY.
Hey, that was the FUN part! I seem to remember getting EDDT
into the monitor was pretty straightforward. Am I correct
in recalling that I had to build a monitor with EDDT.REL
linked in?
aak
Jim Thomas
aak> Hey, that was the FUN part! I seem to remember getting EDDT
aak> into the monitor was pretty straightforward. Am I correct
aak> in recalling that I had to build a monitor with EDDT.REL
aak> linked in?
You mean you built a monitor without it ?-)
Nothead
Jim Thomas
/BAH> In article <3B263C19...@bartek.dontspamme.net>,
/BAH> Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>> Like I said, I'll build a 6.03 pack with the correct version of
>> the CUSPS and stuff.
/BAH> And I'm telling you that you're going to have nothing but problems.
/BAH> There really wasn't a "correct" _single_ version of each CUSP
/BAH> in those days. We had a mess.
Barb, I'd like to offer up the opinion that it wasn't as bad as you're
saying :-) You were trying to get a full source tape with build
instructions that would match the executables on the tape.
I'd say that things are much worse now. Once DIRECT (e.g.) was built, it
was complete no matter what versions of SCAN/WILD were used to build it -
no sharable libraries like now.
There was a CUSP tape. It had executables. Even given PIP.EXE from a 5.07
tape, DIRECT.EXE from a 6.01 tape, DDT.REL from a 5.05 tape, and
MACRO.EXE/LINK.EXE from a 6.02 tape, I'd expect to be able to work on
6.03. BUT of course at the point of needing to rebuild LOGIN.EXE with DDT
loaded when not being able to log in, anyone would be toast without some
external help.
Nothead
Jim Thomas
/BAH> There were very few edits to TECO after Chuck McComas finished
/BAH> with it. :-)
Inside DEC, but outside we were a bit more interested in improving it :-)
Nothead
Arthur Krewat
I had hacked it to be more friendly with video terminals, especially
RUBOUT'ing back around the end-of-line, but it was specific to an ADDS.
And, I no longer have that source... :(
aak
Arthur Krewat
>
> There was a CUSP tape. It had executables. Even given PIP.EXE from a 5.07
> tape, DIRECT.EXE from a 6.01 tape, DDT.REL from a 5.05 tape, and
> MACRO.EXE/LINK.EXE from a 6.02 tape, I'd expect to be able to work on
> 6.03.
I have a running 6.03 system, with enough to run well. I had to copy
SETSRC and TECO from 7.03, but they work fine. The only thing I've
found missing is FOROTS.HGH, but hey, who the hell would run a CUSP
written in FORTRAN anyway? :)
I managed to get MACRO, LINK and TECO running, and I have the sources
to the monitor, albeit without the KS10-specific stuff. Ideally, I would
be able to MONGEN it at least, but the target may be a KL10 :)
> BUT of course at the point of needing to rebuild LOGIN.EXE with DDT
> loaded when not being able to log in, anyone would be toast without some
> external help.
Besides hacking LOGIN to allow you to at least TRY to login while already
logged in, I can think of NO WAY to debug (DDT) LOGIN without being logged in.
Although EDDT comes to mind and doing it from the CTY ... hmm...
As long as you had a spare system to do this with during the day,
hey, no problem. Otherwise you run the risk of sleep deprivation,
that lovely state I used to enjoy ...
aak
jmfb...@aol.com
Yea. That surprised me, too. Did anybody out there run a
monitor without EDDT? I can't conceive of anyone doing that.
People have given up job slots if they needed room before
giving up EDDT.
There's a reason JMF liked his line "Have EDDT, Will Travel".
jmfb...@aol.com
<grin> I didn't use TECO after Bob introduced me to (and now I'm
to screw this name up because my brain just spazzed) VTECO.
Henry W. Miller
<jmfb...@aol.com> wrote in message news:9gcpnm$ch7$3...@bob.news.rcn.net...
> In article <wwn17an...@atlas.cfht.hawaii.edu>,
> Jim Thomas <tho...@atlas.cfht.hawaii.edu> wrote:
> >>>>>> "aak" == Arthur Krewat <kre...@bartek.dontspamme.net> writes:
> >
> > aak> Hey, that was the FUN part! I seem to remember getting EDDT
> > aak> into the monitor was pretty straightforward. Am I correct
> > aak> in recalling that I had to build a monitor with EDDT.REL
> > aak> linked in?
> >
> >You mean you built a monitor without it ?-)
> >
>
> Yea. That surprised me, too. Did anybody out there run a
> monitor without EDDT? I can't conceive of anyone doing that.
> People have given up job slots if they needed room before
> giving up EDDT.
>
Only for a production system that was already short on resources.
I'd keep a "debug" version around as well.
> There's a reason JMF liked his line "Have EDDT, Will Travel".
>
"DDT - don't build a system without it". (People used to complain
that my executables were so large. Well, they had the symbol tables
linked in, possibly DDT as well.
> /BAH
>
> Subtract a hundred and four for e-mail.
-HWM
Henry W. Miller
<jmfb...@aol.com> wrote in message news:9gcptl$ch7$4...@bob.news.rcn.net...
DTECO? or VTTECO? (maybe there weren't no such latter beast...)
> /BAH
>
> Subtract a hundred and four for e-mail.
-HWM
jmfb...@aol.com
DTECO..damn...there goes my brain again. It's the one that
I shipped on one of the unsupported tapes...the Tools tape I think.
jmfb...@aol.com
Jim Thomas <tho...@atlas.cfht.hawaii.edu> wrote:
>>>>>> "/BAH" == jmfbahciv <jmfb...@aol.com> writes:
>
> /BAH> In article <3B263C19...@bartek.dontspamme.net>,
> /BAH> Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
> >> Like I said, I'll build a 6.03 pack with the correct version of
> >> the CUSPS and stuff.
>
> /BAH> And I'm telling you that you're going to have nothing but problems.
> /BAH> There really wasn't a "correct" _single_ version of each CUSP
> /BAH> in those days. We had a mess.
>
>Barb, I'd like to offer up the opinion that it wasn't as bad as you're
>saying :-)
It was.
>You were trying to get a full source tape with build
>instructions that would match the executables on the tape.
That was the problem. Nothing matched. There was a CUSP
tape plus 22 update tapes. If Conklin fixed a DIRECT bug
that required a later edit level of SCAN, his solution was
to ship a new SCAN with that DIRECT on an update tape without
testing the SCAN edit with all the other CUSPs that used
SCAN. Things got so bollixed that his solution to the
bolluxing was to create SCN7B.REL and have DIRECT search
that. So the developer or maintainer who had to answer
an SPR, or worse yet, try to do some developement really
didn't have a set of sources to start with. I remember
lots of programmers wondering around asking which MAC
file was the real SCAN. WILD had the same problems.
And then somebody, not to be named here, in the Language
group decided to ship SCAN on their tapes. And their pick
of sources to work from had no semblance in the field.
Nope. It was more of mess than you thought. There was
even a scenario (which I can't recall at the moment)
that guaranteed no installation from scratch could be done.
The only reason customers ended up with a system was because
their cold start installation was done in Marlboro when
manufacturing did their checkout. Manufacturing left their
checkout system on the customers' disks.
>
>I'd say that things are much worse now. Once DIRECT (e.g.) was built, it
>was complete no matter what versions of SCAN/WILD were used to build it -
>no sharable libraries like now.
But DIRECT wouldn't necessarily work with the SCAN that got shipped
on a language tape or a later CUSP update tape.
>
>There was a CUSP tape. It had executables. Even given PIP.EXE from a
5.07
>tape, DIRECT.EXE from a 6.01 tape, DDT.REL from a 5.05 tape, and
>MACRO.EXE/LINK.EXE from a 6.02 tape, I'd expect to be able to work on
>6.03.
Not if they had to do a cold start installation.
>BUT of course at the point of needing to rebuild LOGIN.EXE with DDT
>loaded when not being able to log in, anyone would be toast without some
>external help.
Oh, I'm not talking about that. I was addressing his idea
of getting the 6.nn cusp tape (note the singular?). There
were no Cusp tape. There were essentially 23 cusp tapes
with no installation instructions.
Henry W. Miller
<jmfb...@aol.com> wrote in message news:9gd17h$ga4$1...@bob.news.rcn.net...
And now you know the rest of the story.
> /BAH
>
> Subtract a hundred and four for e-mail.
-HWM
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>Jim Thomas wrote:
>>
>> There was a CUSP tape. It had executables. Even given PIP.EXE from a
5.07
>> tape, DIRECT.EXE from a 6.01 tape, DDT.REL from a 5.05 tape, and
>> MACRO.EXE/LINK.EXE from a 6.02 tape, I'd expect to be able to work on
>> 6.03.
>
>I have a running 6.03 system, with enough to run well. I had to copy
>SETSRC and TECO from 7.03, but they work fine. The only thing I've
>found missing is FOROTS.HGH, but hey, who the hell would run a CUSP
>written in FORTRAN anyway? :)
We did. Look on the Tools tape and in the USAGE directory.
Your FORTOS.HGH won't work either. I suggest you change your
emotional attachment to 5.07.
>
>I managed to get MACRO, LINK
Be very careful with this one (LINK).
> ...and TECO running, and I have the sources
>to the monitor, albeit without the KS10-specific stuff. Ideally, I would
>be able to MONGEN it at least, but the target may be a KL10 :)
>
>> BUT of course at the point of needing to rebuild LOGIN.EXE with DDT
>> loaded when not being able to log in, anyone would be toast without some
>> external help.
>
>Besides hacking LOGIN to allow you to at least TRY to login while already
>logged in, I can think of NO WAY to debug (DDT) LOGIN without being logged
in.
>
Of course that's the way to debug LOGIN. Did you read what I wrote?
You build LOGIN and save it with DDT and symbols and set a breakpoint.
Then, on the CTY which is not REMOTE, you login. You'll hit a break
point. Remember the monitor is treating that job as if it sorta
was logged in which is why you have to be on the CTY and LOCAL
to fool around with it. You also need to be able to attach
to detached jobs without invoking LOGIN code.
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
<snip>
>Besides hacking LOGIN to allow you to at least TRY to login while already
>logged in, I can think of NO WAY to debug (DDT) LOGIN without being logged
in.
>
>Although EDDT comes to mind and doing it from the CTY ... hmm...
<snip>
I forgot to say that this is the hard way of debugging LOGIN.
I'm sorry, I think I need a real system in order to write
an accurate recipe for debugging LOGIN, DAEMON, and GALAXY
components.
Arthur Krewat
>
> > aak> Hey, that was the FUN part! I seem to remember getting EDDT
> > aak> into the monitor was pretty straightforward. Am I correct
> > aak> in recalling that I had to build a monitor with EDDT.REL
> > aak> linked in?
> >
> >You mean you built a monitor without it ?-)
> >
>
> Yea. That surprised me, too. Did anybody out there run a
> monitor without EDDT? I can't conceive of anyone doing that.
> People have given up job slots if they needed room before
> giving up EDDT.
>
> There's a reason JMF liked his line "Have EDDT, Will Travel".
We constantly ran without it - with 40+ students logged into
a poor KS10, we needed all the memory we could get ... I know,
it wasn't much, but my boss liked to hunt for unnecessary bits...
aak
Arthur Krewat
>
> >I have a running 6.03 system, with enough to run well. I had to copy
> >SETSRC and TECO from 7.03, but they work fine. The only thing I've
> >found missing is FOROTS.HGH, but hey, who the hell would run a CUSP
> >written in FORTRAN anyway? :)
>
> We did. Look on the Tools tape and in the USAGE directory.
>
> Your FORTOS.HGH won't work either. I suggest you change your
> emotional attachment to 5.07.
Eh? Go back to 5.07 from 6.03? Can't - it won't run on a KS10...
> >
> >I managed to get MACRO, LINK
>
> Be very careful with this one (LINK).
It's the one that come on the monitor tape or at least the first
CUSP tape on trailing-edge.
> >Besides hacking LOGIN to allow you to at least TRY to login while already
> >logged in, I can think of NO WAY to debug (DDT) LOGIN without being logged
> in.
>
> Of course that's the way to debug LOGIN. Did you read what I wrote?
> You build LOGIN and save it with DDT and symbols and set a breakpoint.
>
> Then, on the CTY which is not REMOTE, you login. You'll hit a break
> point. Remember the monitor is treating that job as if it sorta
> was logged in which is why you have to be on the CTY and LOCAL
> to fool around with it. You also need to be able to attach
> to detached jobs without invoking LOGIN code.
Ahh... hadn't thought of that. Good ole [2,5]. Would you believe I
was able to ^C out of HELP on 7.01 (after trying for 20 minutes)
and got left logged into 2,5?
aak
Jim Thomas
/BAH> Of course that's the way to debug LOGIN. Did you read what I wrote?
/BAH> You build LOGIN and save it with DDT and symbols and set a breakpoint.
My point was that one can't do that if one can't log in!
Nothead
jmfb...@aol.com
<gasp> Blasphemy! :-)))
Sheesh! I can't imagine a KS with 40 kids on it. It's too bad
you didn't have a tri-SMP. A couple hundred kids investigating
cracks in the softwar all at once. The site that had a 5-CPU
system had a 500 job monitor.
jmfb...@aol.com
Arthur Krewat <kre...@bartek.dontspamme.net> wrote:
>jmfb...@aol.com wrote:
>>
>> >I have a running 6.03 system, with enough to run well. I had to copy
>> >SETSRC and TECO from 7.03, but they work fine. The only thing I've
>> >found missing is FOROTS.HGH, but hey, who the hell would run a CUSP
>> >written in FORTRAN anyway? :)
>>
>> We did. Look on the Tools tape and in the USAGE directory.
>>
>> Your FORTOS.HGH won't work either. I suggest you change your
>> emotional attachment to 5.07.
>
>Eh? Go back to 5.07 from 6.03? Can't - it won't run on a KS10...
No, no, no. I was talking about the comment of trying to run
5.06 again.
>
>> >
>> >I managed to get MACRO, LINK
>>
>> Be very careful with this one (LINK).
>
>It's the one that come on the monitor tape or at least the first
>CUSP tape on trailing-edge.
Right. Just be very careful. That's LINK V5 or before. Mixing
that with any LINK V6 will give nothing but headaches and messes.
>
>> >Besides hacking LOGIN to allow you to at least TRY to login while
already
>> >logged in, I can think of NO WAY to debug (DDT) LOGIN without being
logged
>> in.
>>
>> Of course that's the way to debug LOGIN. Did you read what I wrote?
>> You build LOGIN and save it with DDT and symbols and set a breakpoint.
>>
>> Then, on the CTY which is not REMOTE, you login. You'll hit a break
>> point. Remember the monitor is treating that job as if it sorta
>> was logged in which is why you have to be on the CTY and LOCAL
>> to fool around with it. You also need to be able to attach
>> to detached jobs without invoking LOGIN code.
>
>Ahh... hadn't thought of that. Good ole [2,5]. Would you believe I
>was able to ^C out of HELP on 7.01 (after trying for 20 minutes)
>and got left logged into 2,5?
>
>aak
Subtract a hundred and four for e-mail.
jmfb...@aol.com
<grin> I was trying to not confuse him with facts.
TOPS-10 had so many CATCH-22s that CDO named a node after
it in our shop. I'd give up a left ball to learn about
the process that gave us MACRO-10.
Jim Thomas
/BAH> TOPS-10 had so many CATCH-22s that CDO named a node after
/BAH> it in our shop.
.SET HOSTESS TWINKY
/BAH> I'd give up a left ball to learn about
/BAH> the process that gave us MACRO-10.
My guess is that it started with MAP on an IBM 709x. I don't remember
enough about MAP by this time :-( but when I came up with that I thought
there were enough similarities to justify the idea. IMHO
Nothead
John Sauter
contemporary with MAP and FAP on the IBM 7090. I
suspect MACRO was the ancestor of MACRO-6, which was
the direct predecessor of MACRO-10.
John Sauter (J_Sa...@Empire.Net)
jmfb...@aol.com
Jim Thomas <tho...@atlas.cfht.hawaii.edu> wrote:
>>>>>> "/BAH" == jmfbahciv <jmfb...@aol.com> writes:
>
> /BAH> TOPS-10 had so many CATCH-22s that CDO named a node after
> /BAH> it in our shop.
>
>
> /BAH> I'd give up a left ball to learn about
> /BAH> the process that gave us MACRO-10.
>
>My guess is that it started with MAP on an IBM 709x. I don't remember
>enough about MAP by this time :-( but when I came up with that I thought
>there were enough similarities to justify the idea. IMHO
That's not quite what I meant. An ancestral tree is a start
to what I want to know. How did the very first program get
started on that system. Somebody had to diddle it in and have
the tools to modify it to diddle the new one in. MACRO-10
is written in MACRO-10. Once upon a time, there really was
the first cold start.
Joe Smith
>
> jmfb...@aol.com wrote:
> > Yea. That surprised me, too. Did anybody out there run a
> > monitor without EDDT? I can't conceive of anyone doing that.
> > People have given up job slots if they needed room before
> > giving up EDDT.
> >
> > There's a reason JMF liked his line "Have EDDT, Will Travel".
>
> We constantly ran without it - with 40+ students logged into
> a poor KS10, we needed all the memory we could get ... I know,
> it wasn't much, but my boss liked to hunt for unnecessary bits...
What are you guys talking about? EDDT did not use up any memory at all!
When you got to "Startup-option: GO", if no DDT break points were set,
then EDDT and the symbol table were both thrown away. The core they
had been using was made available to user jobs.
Monitors were always built with EDDT, but rarely ran with EDDT intact.
-Joe
--
Joe....@inwap.com See http://www.inwap.com/ for details
Arthur Krewat
>
> > We constantly ran without it - with 40+ students logged into
> > a poor KS10, we needed all the memory we could get ... I know,
> > it wasn't much, but my boss liked to hunt for unnecessary bits...
>
> What are you guys talking about? EDDT did not use up any memory at all!
>
> When you got to "Startup-option: GO", if no DDT break points were set,
> then EDDT and the symbol table were both thrown away. The core they
> had been using was made available to user jobs.
>
> Monitors were always built with EDDT, but rarely ran with EDDT intact.
I'm sorry... I didn't know this - is this in ALL versions of TOPS-10?
aak
jmfb...@aol.com
Joe Smith <Joe....@inwap.com> wrote:
>Arthur Krewat wrote:
>>
>> jmfb...@aol.com wrote:
>> > Yea. That surprised me, too. Did anybody out there run a
>> > monitor without EDDT? I can't conceive of anyone doing that.
>> > People have given up job slots if they needed room before
>> > giving up EDDT.
>> >
>> > There's a reason JMF liked his line "Have EDDT, Will Travel".
>>
>> We constantly ran without it - with 40+ students logged into
>> a poor KS10, we needed all the memory we could get ... I know,
>> it wasn't much, but my boss liked to hunt for unnecessary bits...
>
>What are you guys talking about? EDDT did not use up any memory at all!
>
>When you got to "Startup-option: GO", if no DDT break points were set,
This can't be true.
>then EDDT and the symbol table were both thrown away. The core they
>had been using was made available to user jobs.
We always had patches in the monitors we ran in-house but no
breakpoints. However, we could always type ^D to pause a
running monitor. So the check couldn't have been breakpoints
to throw away EDDT. It must have been something else.
>
>Monitors were always built with EDDT, but rarely ran with EDDT intact.
Not in our shop but then that's the curse of being a development
shop with only one set of hardware.
jmfb...@aol.com
If chunks of memory were thrown away, then it was JMF who wrote
that code and, if true, would be a function of any -10 monitor.
I don't think Joe is 100% correct (if no breakpoints
set, throw away EDDT) for the reason I gave in another post.
Joe Smith
>In article <wwn17an...@atlas.cfht.hawaii.edu>,
> Jim Thomas <tho...@atlas.cfht.hawaii.edu> wrote:
>>>>>>> "aak" == Arthur Krewat <kre...@bartek.dontspamme.net> writes:
>>
>> aak> Hey, that was the FUN part! I seem to remember getting EDDT
>> aak> into the monitor was pretty straightforward. Am I correct
>> aak> in recalling that I had to build a monitor with EDDT.REL
>> aak> linked in?
>>
>>You mean you built a monitor without it ?-)
>>
>
>Yea. That surprised me, too. Did anybody out there run a
>monitor without EDDT? I can't conceive of anyone doing that.
>People have given up job slots if they needed room before
>giving up EDDT.
Huh? EDDT did not take up any room at all.
If there were no DDT breakpoints set, EDDT committed suicide, leaving
more physical memory for user jobs. Only if you had breakpoints set
did EDDT use up memory.
-Joe
--
See http://www.inwap.com/ for PDP-10 and "ReBoot" pages.