On Saturday, June 17, 2023 at 6:56:27 PM UTC-7, Rich Alderson wrote:
> gah4 <ga...@u.washington.edu> writes:

(snip)

> > I was trying to be a little generic, as every system is different, but
> > mostly the generating of the new kernel.

> It's called the monitor.

I was trying to be generic, and that seems to be the usual generic
term. OS/360 calls it the nucleus. But that doesn't include much
non-resident parts.

As well as I know it, OS/360 is the first with "operating system"
in its name, though it might be that some earlier should also count.

> > For many, at least for those years, that was selecting the available
> > I/O devices, and assembling in the code for them.

> True, but it's more complicated than that. I'll explain why below, but first
> some history.
> For many years, each customer's initial monitor was assembled BY DEC, because
> the records of exactly how many of each kind of device installed on each system
> resided in the customer database in Marlboro. That's the PDP-6 and PDP-10
> era.
(snip)

> Also, please note that the PDP-6 and PDP-10 monitors from DEC, as well as ITS
> and WAITS, include a command processor. (TOPS-20, which originated as TENEX
> from BBN, instead provided a user mode command processor called the EXEC.)
> In DEC parlance, the monitor IS NOT "the operating system". Instead, user mode
> programs like the batch processor, the spoolers, and interprocess communication
> modules, were referred to as the operating system.

I think that is usual for everything except MS-DOS.

But okay, for OS/360 there is the resident nucleus, and then some
non-resident parts, especially for SVCs. Non-resident SVC (supervisor call)
routines are in 2K byte pieces, copied into a special buffer when
needed. So, not user mode, but also not nucleus.

As S/360 and PDP-10 were about the same time, and when memory
was still pretty expensive, lots of tricks were needed to fit everything
into available memory.

> > For Unix, there is somewhere a big struct array with one element
> > for each I/O device. There is a generic kernel with all the usual
> > devices, which one can run, and then generate a more specific
> > version. And one can add in new I/O devices, and compile
> > them into the kernel.

> The PDP-6/-10 monitors equivalent of that struct array was the written
> description of the system, and either a run of MONGEN or an editing session on
> STG.MAC.

(snip)
>> But you can also do it all manually.

> Manually is precisely how it was done on PDP-10 monitors.

Can it still be done manually?

(snip, I wrote)

> > I presume that there is still assembler source to generate TOPS-10
> > and TOPS-20, if one wants to do that. I am not sure what ran on
> > the PDP-6.

> There is, but those sources assume that you have a working system to run the
> assembler and linker. These days, PDP-10 hardware is so fast that rather than
> futz around with STG, TOPS-20 is built from scratch. (No one, for small values
> of "no one", builds Tops-10 these days.)
OK, so back to the original question. Is enough WAITS source around
to generate one from source?

> That's fairly close.
> Now for the things which make WAITS different from most other PDP-6/-10
> monitors:
> 1. There are no privileged instructions, in the sense than any user program
> can execute I/O instructions; they are treated as monitor calls, just like
> opcodes 040-077 in Tops-10 and ITS, or opcode 104 ("JSYS") in TENEX/TOPS-20.
So emulated like VM/370?

There are some fun parts of OS/360, which VM/370 has to know about,
like self-modifying channel programs.

> 2. WAITS was intended for experimentation in the design of operating systems,
> so all of the nifty devices attached to the systems as various times were
> programmed IN USER MODE, because there were no privileged instructions.
I am not completely sure by now, but I think that was also a reason
for creating VM/370. Well, CP/67 before that.

> 3. NB: There were privileged OPERATIONS of certain monitor calls, but they
> were only made slightly more difficult to use, in that a password would be
> added to the otherwise perfectly ordinary user mode call. This is referred
> to as GODMODE in the WAITS UUO manual.

gah4 wrote:
> Can it still be done manually?
> Is enough WAITS source around to generate one from source?

Yes. I have manually assembled a WAITS monitor from ~1974 sources.

gah4 <gah4@u.washington.edu> writes:
>On Saturday, June 17, 2023 at 12:18:40=E2=80=AFAM UTC-7, Johnny Billquist w=
>rote:
>
>(snip, I wrote)
>> >>> Just wondering, how was this supposed to be done? Are the original=20
>> >>> sysgen files lost now, so the only way is to restore an already=20
>> >>> generated and running system?=20
>
>(snip)
>
>> I wonder if you are expecting too much. I sortof understand it as there=
>=20
>> is no such thing as a sysgen, and never was.=20
>=20
>I was trying to be a little generic, as every system is different, but
>mostly the generating of the new kernel.
>
>For many, at least for those years, that was selecting the available
>I/O devices, and assembling in the code for them.
>
>For Unix, there is somewhere a big struct array with one element
>for each I/O device. There is a generic kernel with all the usual
>devices, which one can run, and then generate a more specific
>version. And one can add in new I/O devices, and compile
>them into the kernel.=20
>
>> You basically just had a running system. Yes, you could change sources=20
>> and recompile the kernel, and boot the new one. But that's pretty much=20
>> how it was. It was self-hosting, and was running, and that's about it.=20
>> It just evolved organically on the host(s) it existed on.=20
>
>Some systems have a more organized system, and some less.
>The OS/360 sysgen uses the assembler to generate JCL to do
>various different things. A strange use of an assembler, but that
>is what they do. But you can also do it all manually.

The Burroughs systems automatically configured the MCP to match
the hardware on boot, based on a set of configuration cards
read during the initial coldstart. Later systems had ID bytes
in each I/O controller so the configuration cards were only
technically needed for legacy devices.

There was no need to recompile or relink the MCP, it would
bring in whatever segments were necessary to support the
current hardware at boot or runtime. An example coldstart deck:

------ coldstart_206s.crd ---------------
HOSTNAME SYSTEML
DLP 3 TPR
UNIT 3/0 FUL96 TPR
DLP 5 DISK
DISK 5/0 ID 01 SUBSYSTEM 1 0 221183
DLP 6 GCR
UNIT 6/0 GCR SHARED
UNIT 6/1 GCR SHARED
UNIT 6/5 GCR SHARED
DLP 1 CRD
UNIT 1/0 CRD SAVED
DLP 10 CONSOLE
UNIT 10/4 PRISPO ODT LEVEL 9 HLSPO AD DEF
DLP 16 PACK HSTLAD
PACK 16/0
PACK 16/1
DISK 16/2 ID 02 SUBSYSTEM 2 DEFAULT
CONTROL DEBUG MCP
USE BOJ
USE EOJ
USE STOQ
USE DUMP DISK
USE PBD
USE SLOG AUTO 10000 WRAP
USE ZIPM
STOP
--------- end --------------

The DLP (Data Link Processor) (or CHANNEL) card specified
the channel and associated hardware type (which was matched
against the ID byte in the DLP). The UNIT card specified one
or more units on the channel (including Operator Display
Terminals (ODT), printers, tapes, card readers/punches).

(DISK was 100-byte sectors, PACK was 180-byte sectors).

The USE cards selected optional MCP features, e.g.

STOQ (Storage Queues for inter application communications),
SLOG (System Log)
PBD (Printer Backup to disk)
CRCR (Core-to-Core IPC)
DCP (Data Communications Processor support)

etc.

Most of these could be also specified dynamically at runtime
to add/remove hardware or change the set of supported features.

On Monday, June 19, 2023 at 8:36:03 AM UTC-7, Scott Lurndal wrote:

(snip)

> The Burroughs systems automatically configured the MCP to match
> the hardware on boot, based on a set of configuration cards
> read during the initial coldstart. Later systems had ID bytes
> in each I/O controller so the configuration cards were only
> technically needed for legacy devices.
> There was no need to recompile or relink the MCP, it would
> bring in whatever segments were necessary to support the
> current hardware at boot or runtime.
(snip)

Static configuration is nice for keeping things small, important
in the earlier days.

The smallest OS/360 fits in 20K, allowing 44K on a 64K machine
for user programs. The PL/I (F) compiler is supposed to fit
in 44K. It is made up of a large number of tiny modules,
all loaded dynamically when needed. At the end of every run,
it tells how much memory was used, and how much was needed
to keep the symbol table off disk.

The first one I remember doing all this for is SunOS.
I/O device configuration assigns the major and minor numbers
for I/O devices that go into /dev.

Solaris does it dynamically, and rewrites /dev each time.
(Or maybe only if it finds that something changed.)

gah4 <gah4@u.washington.edu> writes:
>On Monday, June 19, 2023 at 8:36:03=E2=80=AFAM UTC-7, Scott Lurndal wrote:
>
>(snip)
>
>> The Burroughs systems automatically configured the MCP to match=20
>> the hardware on boot, based on a set of configuration cards=20
>> read during the initial coldstart. Later systems had ID bytes=20
>> in each I/O controller so the configuration cards were only=20
>> technically needed for legacy devices.=20
>=20
>> There was no need to recompile or relink the MCP, it would=20
>> bring in whatever segments were necessary to support the=20
>> current hardware at boot or runtime.=20
>(snip)
>
>Static configuration is nice for keeping things small, important
>in the earlier days.

I'll point out that the burroughs systems were designed in the early
1960's and first customer ship was 1966. Their ease of installation
and use was a definite benefit when comparing with the contemporaneous
IBM 360 systems they were competing with.

>
>The smallest OS/360 fits in 20K, allowing 44K on a 64K machine
>for user programs. The PL/I (F) compiler is supposed to fit
>in 44K. It is made up of a large number of tiny modules,
>all loaded dynamically when needed. At the end of every run,
>it tells how much memory was used, and how much was needed
>to keep the symbol table off disk.

The Burrough B2500/B3500 supported 10K to 500K byte systems
using the same MCP binary. See 1025475_B2500_B3500_RefMan_Oct69.pdf
on bitsavers.

>
>The first one I remember doing all this for is SunOS.
>I/O device configuration assigns the major and minor numbers
>for I/O devices that go into /dev.
>
>Solaris does it dynamically, and rewrites /dev each time.
>(Or maybe only if it finds that something changed.)

The SVRx derivatives (and Solaris) weren't good examples
of ease of installation, although later SVR4 and Solaris
systems eventually supported dynamic loading of drivers.

bilegeek <bilegeek2@gmail.com> writes:

I'll give a long answer at the bottom. Most of what you're saying below makes
little to no sense,

> So there's the 1974-era WAITS image, but as far as I can tell, nobody has
> been able to log in and DO anything. Has anybody been successful in logging
> in?

> I can get it[skyvisions] to boot using Open-SimH pdp10-ka and "go 200", but
> that's it.

> Saildart.org has some demonstrations[demos], but also apparently he's not
> able to log in either[nologin]?

What 1974 image? I have no idea what Rich C. has.

> ~~~~~

> I'm also contacting Bruce Guenther about this specifically, but I should also
> ask here:

> Does anybody here have the "9.7G ecc815253d76dffc615e311bfbb4c090
> dart_records_from_229_reels.tar.lzma" file[lzma], or could show me where to
> download it? The SAILDART archive is supposed to have all the files, but he
> only teases a single-file archive, and says to search for the md5... which
> just leads back to his website.

> I know he has most of the individual files wrapped in HTML, but... I don't
> want to miss anything by downloading them manually, or screwing anything up
> or hitting some rate limit on the server by writing a script.

Besides the HTMLized files, there are (or were) binary dumps of everything
Bruce G. and Martin F. put on the SAILDART site, way back when. These avoid
the use of Unicode characters for WAITS ASCII.

> ~~~~~

> For Rich Alderson specifically, if you're allowed to answer (not sure if LCM
> had any NDA's), I have a few questions about the WAITS system you revived:

Who would have asked for an NDA????

> 1. Did you use Bruce's archive, or have other sources?

I used Bruce and Martin's archive. There are no other sources.

> 2. Is the documentation you used publicly available anywhere? (Only docs I
> could find are some textfiles on saildart.org, some user-level PDF's on
> Bitsavers, and the UUO and FAIL manuals on Lars' Github)

Documentation? What documentation?

> 3. Did you have to rebuild the system from scratch, or was there some disk
> images and a final 9.18/M dump?

HAHAHAHAHAHAHAHAHAHAHA!!!!!!!!!

> 4. Any special modifications to the KL10 hardware specifically for WAITS? Or
> did you manually patch out the unsupported hardware?

The SAIL KL-10 was a stock 1080, with a XEROX 1Mbps Ethernet card (NB: Not
even 3Mbps!) in the front end 11/40. LCM+L was lucky enough to have such a
card in the collection.

> 5. Would there be any technical or legal issues (aside from the obvious
> shutdown and layoffs) with releasing the disk images from the LCM's working
> system? Was there any talk about something like this when you were employed
> there?

You would have to ask the legal department at Vulcan about that.

> 6. If you can release them, any known passwords for the 1974 system?

Again, what 1974 system???

> ~~~~~

> Sources:

> [demos] https://www.saildart.org/j5/index.html
> [nologin] https://www.saildart.org/simple/index-book-simple.html#Chapter15
> ^ https://github.com/PDP-10/waits/issues/5
> [lmza] https://www.saildart.org/simple/index-book-simple.html#Chapter09
> [skyvisions] http://sky-visions.com/dec/waits.shtml

Look. When Paul Allen asked me to get WAITS running, we had no idea how
difficult a project it might be. I asked my friend Martin F. at Stanford for
some advice, and concluded that everything was lost. (That was long before the
museum opened, when it was just PGA's collection and some hacks which
interested him, like Greenblatt's chess program.) Part of the issue was the
memory mapped terminals, which attached to the KA-10.

He kept asking over the years, and eventually SAILDART came up, so I kept
looking into it, and pinging Martin from time to time. It finally became clear
that WAITS in its final form ran on the uniprocessor KL-10, with neither the
KA-10 (whose funeral I attended) nor the PDP-6 (which never moved to Margaret
Jacks Hall from the D. C. Power Laboratory, and was lost to the Computer Museum
in Boston) connected to it.

Martin was a guest at the LCM Grand opening in April 2013, along with my
friends Ralph Gorin (a SAIL alum) and Len Bosack (founder/CEO of XKL, among
many other accomplishments). The 4 of us managed to download a copy of the
latest WAITS monitor (1990), and force it into the memory of the KL-10 in the
computer room at LCM. It started, and immediately complained about missing
disks and stopped. Proof of concept, at least.

I began looking into what was available on SAILDART, talking to Martin and to
Ralph about how one might go about setting this up. (Ralph was known as
"Mr. File System", having written utilities at SAIL to recover from a massive
disk catastrophe, and to move from KA-10 disks attached to an IBM style bus and
tag channel to RP06 and RP07 disks on the KL-10 Massbus.) He gave me the basic
layout of the RP06 file system over lunch, and sent me off to research how to
create such a thing.

Anm.: There was never such a thing as an installation tape for WAITS. It grew
organically from the PDP-6 monitor, and officially diverged from the DEC
monitor ("Tops-10") at the 4S72 release ("Level 4 monitor, Swapping, 1972").
There were only 3 machines that ever ran WAITS: SAIL, on a triprocessor 6+KA+KL;
CCRMA, on a Foonly F-1; and LLNL, on a KL-10 used to run SUDS for the S-1
supercomputer project. If a new release was created, it was loaded onto a
bootable disk and carried to the other sites.

In my browsing at SAILDART, I encountered a program written by Ralph for the
head crash recovery, which contained a detailed description of the RP07 layout
of the WAITS file system. This program utilized a feature of WAITS which
allowed direct access to the disk controller hardware, to lay out the home
blocks, BAT blocks, etc. It obviously required a running WAITS system to
perform its task.

It was also written in FAIL, the fast single pass assembler created at SAIL and
maintained by Fred Wright II and Ralph Gorin. He's everywhere you look in the
PDP-10 world.

I used the LCM+L KL-10 running Tops-10 7.04 as a development system/guinea pig.
I translated FAIL to Macro-10, and created a highly instrumented version of the
program (as in, every system call was reported as it was executed or emulated,
with the results of each calculation and BLT being typed out).

That was too slow, so I transferred my work onto a KLH10 instance running
Tops-10, so that I could swap disk images in and out quickly.

Once that was working, I used it to give me an ASCII typeout of all of the
nonzero blocks on an empty WAITS file system spread across three RP07 disks
(the layout at SAIL in 1990, when the KL-10 was shut down). I turned this
printout into a Tops-10 MIC file, in which these values were input to the
FILDDT program to scribble onto 3 emulated drives using the LCM+L Massbus Drive
Emulator (MDE). I now had an empty WAITS file system, so forcing the monitor
to boot didn't immediately crash.

OK, how to populate the system? As noted above, there was no such thing as an
install tape, so SOL there. There were, on the other hand, tons of binaries at
SAILDART, if only I could get them onto our KL-10.

What I did was to manipulated the file system internals I had created to
contain a single program in the operator directory [1,2]: A copy of DART, the
Disk Archive and Retrieval tool. Now, if only I had DART tapes I could restore
files ot the emulated disks.

I read through the DART source file, and the relevant parts of the SAIL UUO,
Monitor Commands, and FAIL manuals, and developed a set of programs which would
massage Bruce G.'s binary blob files into images of the contents of a DART
tape, utilizing Bruce's catalog pages on SAILDART to get file dates and author
info and such. I downloaded a metric boatload of files onto a Toad-2 (the
private one, not the public one), and proceeded to create tape images which I
fed into the MTE (like MDE but tapes) attached to the KL-10, and populated the
file system with lots of useful system programs.

Because I could also boot WAITS on KLH10, I was able to give a working system
to Martin down at Stanford. You see, although WAITS expected to be run with
KLDCP on the 11/40, it could also run with RSX-20F by starting at different
offset (IIRC, 202 instead of 200). That's documented in the monitor source.

Overall, it took roughly 5 years of effort to get a working WAITS system up and
running, just in time for PGA to see it and pronounce it good (what's next?).

Since then, Bruce G. has tied down a whole bunch of stuff, so I don't think I
could do all of that now.

HTH.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

> What 1974 image? I have no idea what Rich C. has.

Bruce and Rich were apparently able to get a WAITS system from 1974 booting, but were not able to get past that. The files are at http://sky-visions.com/dec/waits/; though they need to be downloaded individually, at least it's only 17 files or so.

I tried. With Open-SimH's[1] pdp10-ka, "waits.ini" file boots up as "Stanford 6.17/K 08-16-74", the "wabbn.ini" boots up as "STANFORD 7.01/C 04-22-75?". Unfortunately, as far as I can tell, no one's been able to get past the login screen.

They've also implemented the III display, so that does work with "waits.ini".

Trying to login with some random usernames:
1. "waits.ini" results in "BAD RETRIEVAL; UUO AT EXEC 41552"
2. "wabbn.ini" (using the BBN Pager emulation; had to comment out 'load -d SYSTEM.DMP.X' as well) results in "BAD RETRIEVAL; UUO AT EXEC 46511"

If I try to logout, it says "LOGIN PLEASE", so it's not entirely broken, just veeeeery limited without being logged in.

> Who would have asked for an NDA????

Just being careful asking. Ya never know.

>> was there some disk images and a final 9.18/M dump?
> HAHAHAHAHAHAHAHAHAHAHA!!!!!!!!!

LOL I thought not, never hurts to ask tho.

> You would have to ask the legal department at Vulcan about that.

I'm gonna email livingcomputers.org first, see what the remaining people (person?) there says.

> The SAIL KL-10 was a stock 1080, with a XEROX 1Mbps Ethernet card
> Because I could also boot WAITS on KLH10,

Good, that eliminates a whole slew of headaches if anyone tries to get things going again.

> managed to download a copy (...) and force it into the memory of the KL-10 (...) It started, and immediately complained about missing disks and stopped.
> I now had an empty WAITS file system,
> manipulated the file system internals I had created to contain (...) A copy of DART
> downloaded a metric boatload of files (...) proceeded to create tape images which I
fed into the MTE (...) and populated the file system with lots of useful system programs.

Think you for the detailed breakdown and history, it was exactly what I was looking for. I'm personally not technically capable enough to replicate your work, but it's important info if anybody wants to try.

On a side-tangent: maybe ITS could help out in such an endeavor? It has FAIL[4] and DECUUO[2][3] which emulates the WAITS UUO's circa 1976 (it's capable enough to run SUDS), so perhaps running DART there could be a much easier starting point. Might need work to support low-level stuff tho...

> I used Bruce and Martin's archive. There are no other sources.

Unfortunate, but good to know it's possible to bootstrap WAITS with just that and... a few tanker ships of elbow grease.

> Since then, Bruce G. has tied down a whole bunch of stuff, so I don't think I could do all of that now.

That's unfortunate. I sent an email today asking him about this, so hopefully he eventually replies and helps me out there.

Thank you for your reply, and your hard work in preserving history. The lack of non-cryptic info and horrible searchability of anything WAITS-related was starting to get to me. Unfortunate in that it looks like a lot of work could be lost if the LCM heads are uncooperative, but fortunate in that it could at least be replicated.

[1] https://github.com/open-simh/simh
[2] https://github.com/PDP-10/its/blob/master/doc/info/decuuo.8
[3] https://github.com/PDP-10/its/blob/master/src/decsys/decuuo.314
[4] https://github.com/PDP-10/its/blob/master/src/sail/fail.200

bilegeek <bilegeek2@gmail.com> writes:

> > What 1974 image? I have no idea what Rich C. has.

> Bruce and Rich were apparently able to get a WAITS system from 1974 booting=
> , but were not able to get past that. The files are at http://sky-visions.c=
> om/dec/waits/; though they need to be downloaded individually, at least it'=
> s only 17 files or so.

> I tried. With Open-SimH's[1] pdp10-ka, "waits.ini" file boots up as "Stanfo=
> rd 6.17/K 08-16-74", the "wabbn.ini" boots up as "STANFORD 7.01/C 04-22-75?=
> ". Unfortunately, as far as I can tell, no one's been able to get past the =
> login screen.

> They've also implemented the III display, so that does work with "waits.ini=
> ".

> Trying to login with some random usernames:
> 1. "waits.ini" results in "BAD RETRIEVAL; UUO AT EXEC 41552"
> 2. "wabbn.ini" (using the BBN Pager emulation; had to comment out 'load -d =
> SYSTEM.DMP.X' as well) results in "BAD RETRIEVAL; UUO AT EXEC 46511"

> If I try to logout, it says "LOGIN PLEASE", so it's not entirely broken, ju=
> st veeeeery limited without being logged in.

The operator job is logged in on the console by typing "L" at the dot. That's
as random a userid as you might wish.

The bad retrieval stuff is how it's reporting "I can't find a file system on
this fn disk."

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

> The bad retrieval stuff is how it's reporting "I can't find a file system on this fn disk."

Ah, so it's much less further along than I thought. Still, better than nothing!

> The operator job is logged in on the console by typing "L" at the dot. That's as random a userid as you might wish.

Good info if progress ever gets made.

bilegeek wrote:
> So there's the 1974-era WAITS image, but as far as I can tell, nobody
> has been able to log in and DO anything. Has anybody been successful
> in logging in?

I'm glad you're interested in WAITS! Much too few are working actively
on it. Yes, I have successfully used it with Rich Cornwell's KA10
emulator. I was able do demo the E editor to a group of people last
year, but there are still a few issues with the DataDisc display emulation.

> I'm also contacting Bruce Guenther about this specifically

That would be Bruce Baumgart, right?

> Does anybody here have the "9.7G ecc815253d76dffc615e311bfbb4c090
> dart_records_from_229_reels.tar.lzma" file[lzma], or could show me
> where to download it? The SAILDART archive is supposed to have all the
> files

The full archive is not available to the public. Some select files are
avialable from saildart.org, and others in the 1974 image. I have
suggested to Bruce it would be good if a few more snapshots were
available. He agreed, but these things take a lot time to do.

> Bruce and Rich were apparently able to get a WAITS system from 1974
> booting, but were not able to get past that.

I don't think they were unable to get past that, but so far the work has
not been done. In 1976 or so WAITS was moved to the KL10, and the
emulator may need updates to get that version running.

> Trying to login with some random usernames

Try "1,REG". There is no password.

By the way, to move files in and out of the system, experiment with
fresly built monitors, etc, I have a tool to read and write tape images
in the DART format(s):

https://github.com/larsbrinkhoff/pdp10-its-disassembler/blob/master/dart.c

It seems to work ok most of the time. The KA10 emulator needed a fix
to have DART work, so I'm not sure everything is 100% ship shape yet.

I.e. one thing I have not been able to do is to read data directly off a
tape with COPY MTA0: to a file; there is some kind of I/O problem. I
wanted to do this to install DART.DMP on an empty file system after
having run the monitor disk refresh dialog, but so far no luck.

So there's the 1974-era WAITS image, but as far as I can tell, nobody has been able to log in and DO anything. Has anybody been successful in logging in?

I can get it[skyvisions] to boot using Open-SimH pdp10-ka and "go 200", but that's it.

Saildart.org has some demonstrations[demos], but also apparently he's not able to log in either[nologin]?

~~~~~

I'm also contacting Bruce Guenther about this specifically, but I should also ask here:

Does anybody here have the "9.7G ecc815253d76dffc615e311bfbb4c090 dart_records_from_229_reels.tar.lzma" file[lzma], or could show me where to download it? The SAILDART archive is supposed to have all the files, but he only teases a single-file archive, and says to search for the md5... which just leads back to his website.

I know he has most of the individual files wrapped in HTML, but... I don't want to miss anything by downloading them manually, or screwing anything up or hitting some rate limit on the server by writing a script.

~~~~~

For Rich Alderson specifically, if you're allowed to answer (not sure if LCM had any NDA's), I have a few questions about the WAITS system you revived:

1. Did you use Bruce's archive, or have other sources?
2. Is the documentation you used publicly available anywhere? (Only docs I could find are some textfiles on saildart.org, some user-level PDF's on Bitsavers, and the UUO and FAIL manuals on Lars' Github)
3. Did you have to rebuild the system from scratch, or was there some disk images and a final 9.18/M dump?
4. Any special modifications to the KL10 hardware specifically for WAITS? Or did you manually patch out the unsupported hardware?
5. Would there be any technical or legal issues (aside from the obvious shutdown and layoffs) with releasing the disk images from the LCM's working system? Was there any talk about something like this when you were employed there?
6. If you can release them, any known passwords for the 1974 system?

~~~~~

Sources:

[demos] https://www.saildart.org/j5/index.html
[nologin] https://www.saildart.org/simple/index-book-simple.html#Chapter15
^ https://github.com/PDP-10/waits/issues/5
[lmza] https://www.saildart.org/simple/index-book-simple.html#Chapter09
[skyvisions] http://sky-visions.com/dec/waits.shtml

On Monday, April 17, 2023 at 11:57:47 PM UTC-7, Lars Brinkhoff wrote:
(snip)

> I.e. one thing I have not been able to do is to read data directly off a
> tape with COPY MTA0: to a file; there is some kind of I/O problem.

I remember some of the fun from 45 years ago with MTA0:

There are a few different ways to read/write 9 track
(8 bit plus parity) tape to/from 36 bit words.

I used to test tapes by writing the COBOL compiler to them, and
then reading it back again. (I had a lot of questionable tapes,
not to mention the questionable tape drive on the KA-10.)

I did have a Fortran program that could read tapes and extract
EBCDIC data from them, I suspect writtten RECFM=FB, LRECL=80.

gah4 <gah4@u.washington.edu> writes:

> On Monday, April 17, 2023 at 11:57:47=E2=80=AFPM UTC-7, Lars Brinkhoff wrote:

> (snip)

>> I.e. one thing I have not been able to do is to read data directly off a
>> tape with COPY MTA0: to a file; there is some kind of I/O problem.

> I remember some of the fun from 45 years ago with MTA0:

> There are a few different ways to read/write 9 track
> (8 bit plus parity) tape to/from 36 bit words.

DART tapes were 7 track, and the internal data structures describing the file
metadata reflect that.

Martin and colleagues transferred the data from old 7 track tapes to new 9
track tapes in the 1990s, in order to shrink the number of tapes held in
storage. Those 9 track tapes are what Martin and Bruce Guenther Baumgart
transferred to CDROM while building SAILDART.

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

On Tuesday, April 18, 2023 at 5:57:13 PM UTC-7, Rich Alderson wrote:

(snip)

> DART tapes were 7 track, and the internal data structures describing the file
> metadata reflect that.
> Martin and colleagues transferred the data from old 7 track tapes to new 9
> track tapes in the 1990s, in order to shrink the number of tapes held in
> storage. Those 9 track tapes are what Martin and Bruce Guenther Baumgart
> transferred to CDROM while building SAILDART.
By the time I got to TOPS-10, there were only 9 track tapes,
and we had only 800 BPI. I used to sometimes, at most a few times a year,
tapes from IBM system to TOPS-10.

At one point, I learned the fun with IBM dual density tape drives, in that
you can write tapes with more than one density. The system will verify
the label, and skip existing files on the tape, even if the density requested
isn't the one you want. Then write with the new density.

But yes, before S/360 IBM liked 7 track drives. Some systems used odd
parity, and some, mostly the scientific machines, even parity.
But you can't write the all-zeros character NRZI in even parity.

So, they write the 7-track data on 9-track tape, putting in zeros for
the other two bits?

gah4 <gah4@u.washington.edu> writes:

> But yes, before S/360 IBM liked 7 track drives. Some systems used odd
> parity, and some, mostly the scientific machines, even parity.
> But you can't write the all-zeros character NRZI in even parity.

*Everybody* liked 7 track tape. Those 7 track tapes NASA needed to recover,
what, 15 years ago?, were written on a Univac system, IIRC.

> So, they write the 7-track data on 9-track tape, putting in zeros for
> the other two bits?

Of course not. They read the 36 bit word data (6 bits/frame) into memory, then
wrote it out in standard core dump format as 5 frames containing bits 0-7, 8-15,
16-23, 24-31, and 0 x 0 x 32 33 34 35. (The "x" bits are 0 on a TU7x tape drive,
or 1 on a TE16 oder so etwas.)

--
Rich Alderson news@alderson.users.panix.com
Audendum est, et veritas investiganda; quam etiamsi non assequamur,
omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
--Galen

> The "x" bits are 0 on a TU7x tape drive, or 1 on a TE16 oder so etwas.

That sounds like a hanging tale worth hearing.

De

On Monday, April 17, 2023 at 11:39:29 AM UTC-7, bilegeek wrote:
> So there's the 1974-era WAITS image, but as far as I can tell, nobody has been
> able to log in and DO anything. Has anybody been successful in logging in?

This is reminding me of the way Unix works.
If there is a /etc/nologin file, then people aren't allowed to log in, except
I believe, root.

When making a full system backup, you don't want people changing files
while you are doing it. And if whatever stops people from login in gets written
into the backup ...

With Lars' help and the instructions he provided
(https://github.com/PDP-10/waits/wiki/WAITS-on-Cornwell%27s-PDP10-emulator),
I was FINALLY able to login to the system with 1,REG.

He was right, there's no passwords... which unfortunately means that I
can't login
via remote terminal (giving me the limited ARPA commands), only the
console or Triple-I terminal. Which is annoying, as the Triple-I
emulation is a bit rough currently.

So I'm missing some basic admin instructions (seems to have been an
internal process done purely by established SAIL people, see ".help
login" below) and graceful shutdown instructions, but it DOES in fact
work, and I can list the directories and such.

~~~~~

After some tinkering around on the limited remote terminal commands:

..help arpa
JOB 1 Stanford 7.01/C 04-22-75
Alas, we have had to close the guest account on this system
as a result of persistent misuse.

There are still some programs that can be run without an account, as
listed below. If you need to know more about any of these, type
"HELP <topic><carriage return>". For information on special control
characters and commands, type "HELP TTY".

WHO, FINGER, WHERE provide information about people and jobs currently
running.
MAIL, SEND, GRIPE, TALK permit you to send messages and converse
with people on the system.
DIR lists the files in specified directories.
TYPE lets you type out the contents of text files.
FIND searches text files and prints those paragraphs that contain
specified keywords.
PARRY runs the paranoid model program.

If you need to do more than the above programs permit, say "HELP LOGIN"
..
KJOB
..

~~~~~

..help login
JOB 1 Stanford 7.01/C 04-22-75
Only people with authorized accounts may log in on this system,
though a number of programs can be run without logging in. Say
"HELP ARPA" for a list of these "free" programs.

Since our system is chronically overloaded, we provide outside
accounts only for projects in which we have a direct interest.
If you want to apply for an account, you should communicate with
Lester Earnest, by telephone at (415) 497-4202, by mail at the
address
Computer Science Department
Stanford University
Stanford, California 94305
or by network mail to programmer name LES. Your request should
cover the following points:
1. A brief description of your project and its goals,
2. Expected duration of the project,
3. Proposed account designation (e.g. "1,XYZ", where both the
project designation, "1" in the example, and programmer initials,
"XYZ", may be up to 3 letters). To check whether your initials
are already being used by someone, give the system command
"FINGER <initials>". If the initials are not in use, this
will type a message with the phrase "... not an authorized user".
4. Your network mail or ordinary mail address.

To log in, type the word LOGIN (this may be abbreviated L) followed
by a space, your project name, a comma, and your programmer name:
L PRJ,PRG
This will log you in, and type out any system messages or personal
mail for you which may exist. You can stop the message typeout by
typing the CALL key (CONTROL-C twice from Teletypes). There are some
options in login invoked by using other characters in place of the ","
namely,
from the network, you must have a password. have been posted since

For a more complete description of LOGIN options, say TYPE LOGIN.BH[UP,
DOC].
KJOB
..

~~~~~

So no "fill out a form and we'll give you an account" like on ITS, but
"contact a higher-up and he'll set up an account for you".

Tinkering around on the Triple-I though, can definitely see the TOPS-10 lineage.

gah4 wrote:
> bilegeek wrote:
>> So there's the 1974-era WAITS image, but as far as I can tell, nobody
>> has been able to log in and DO anything. Has anybody been successful
>> in logging in?
>
> This is reminding me of the way Unix works. If there is a
> /etc/nologin file, then people aren't allowed to log in, except I
> believe, root.

On WAITS (around 1974), some terminals are considered "local". On
those, you can login with any user name, and the directory will be
created for you. Others are "remote", and require a valid user name and
password.

bilegeek wrote:
> He was right, there's no passwords... which unfortunately means that I
> can't login via remote terminal (giving me the limited ARPA commands),
> only the console or Triple-I terminal.

At some point I found a table in the monitor sources which describe
which terminal lines are local and which are remote. It so happens that
the first is remote and thus requires a password to log in. I can't
find the table just now, but if you figure it out there should be a
local terminal line.

You may be interested in Brian Harvey's demo:
https://www.youtube.com/watch?v=BefgBDG2p8w

More info from Lars:

> I asked Baumgart about shutting down cleanly. He said to just exit
> the emulator, so that's all I know. Rumors have it the WAITS file
> system is very reliable against corruption, so maybe it's not an
> issue.

> I'm also not sure how to make a new user or directory. I asked Bruce
> about that too, but he said if you're logging in locally (which
> depends on which termail you're using) it's created automatically.
> E.g. an III or DD terminal is considered "local", but some text
> terminals are not.

~~~~~

> If you want to try them, I have the DD displays working like 90%.
> It's the lars/ddd branch on https://github.com/larsbrinkhoff/ka10-simh
> You need to enable both "dd" and "vds" [in the *.ini]

On Monday, April 17, 2023 at 11:39:29 AM UTC-7, bilegeek wrote:
> So there's the 1974-era WAITS image, but as far as I can tell, nobody has been able to log in and DO anything.

After so many days, I just remembered that WAITS is where TeX came from.

waits.mf is the Metafont file where all the printer specific stuff goes, presumable
a name left over from years ago.

gah4 wrote:
> After so many days, I just remembered that WAITS is where TeX came from.

And many other interesting and impressive things! Which unfortunately I
can't list off the top of my head; this is left as an exercise for the
reader.