Just sharing a copy of the Roff Manual that I had forgotten I scanned a little while back:
https://archive.org/details/roff_manual
This appears to be the UNIX complement to the S/360 version of the paper backed up by Doug here: https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf
From the best I could tell, this predates both 1973's V3 and the 1971 S/360 version of the paper, putting it somewhere prior to 1971. For instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc requests found in V3. The .ar and .ro, and .ta requests pop up in the S/360 paper, the rest are in the V3 manpage (prior manpages don't list the request summary).
If anyone has some authoritative date information I can update the archive description accordingly.
Finally, this very well could be missing the last page, the Page offset, Merge patterns, and Envoi sections of Doug's paper are not reflected here, although at the very least, the .mg request is not in this paper so the Merge patterns section probably wasn't there anyway.
- Matt G.
I had meant to copy TUSH on this/
On Wed, Jul 17, 2024 at 2:41 PM Tom Lyon <pugs78(a)gmail.com> wrote:
> I got excited by your mention of a S/360 version, but Doug's link talks
> about the GECOS version (GE/Honeywell hardware).
>
> Princeton had a S/360 version at about that time, it was a re-write of a
> version for the IBM 7094 done by Kernighan after spending a summer at MIT
> with CTSS and RUNOFF. I'm very curious whether the Princeton S/360 version
> spread to other locations. Found this article in the Daily Princetonian
> about the joy and history of ROFF.
> https://photos.app.goo.gl/zMWV1GRLZdNBUuP36
>
> On Wed, Jul 17, 2024 at 1:51 PM segaloco via TUHS <tuhs(a)tuhs.org> wrote:
>
>> Just sharing a copy of the Roff Manual that I had forgotten I scanned a
>> little while back:
>>
>> https://archive.org/details/roff_manual
>>
>> This appears to be the UNIX complement to the S/360 version of the paper
>> backed up by Doug here:
>> https://www.cs.dartmouth.edu/~doug/roff71/roff71.pdf
>>
>> From the best I could tell, this predates both 1973's V3 and the 1971
>> S/360 version of the paper, putting it somewhere prior to 1971. For
>> instance, it is missing the .ar, .hx, .ig, .ix, .ni, .nx, .ro, .ta, and .tc
>> requests found in V3. The .ar and .ro, and .ta requests pop up in the
>> S/360 paper, the rest are in the V3 manpage (prior manpages don't list the
>> request summary).
>>
>> If anyone has some authoritative date information I can update the
>> archive description accordingly.
>>
>> Finally, this very well could be missing the last page, the Page offset,
>> Merge patterns, and Envoi sections of Doug's paper are not reflected here,
>> although at the very least, the .mg request is not in this paper so the
>> Merge patterns section probably wasn't there anyway.
>>
>> - Matt G.
>>
>
> Yeah, but if you do that you have to treat the places
> acquired in the Louisiana Purchase differently because
> they switched in 1582. And Puerto Rico. Bleh.
Then there are all the German city states. And the
shifting borders of Poland. (cal -s country) is a mighty
low-res "solution" to the Julian/Gregorian problem.
Doug
The manpage for "cal" used to have the comment "Try September 1752" (and
yes, I know why); it's no longer there, so when did it disappear? The
SysV fun police?
I remember it in Ed5 and Ed6, but can't remember when I last saw it.
Thanks.
-- Dave
A few folks on the PIDP mailing lists asked me to put scans of the cards I
have on-line. I included TUHS as some of the new to the PDP-11 folks might
find these interesting also.
I also included a few others from other folks. Note my scans are in 3
formats (JPG, TIFF, PDF) as each has advantages. Pick which one you
prefer. I tried to scan in as a high a resolution as I could in case some
one wants to try to print the later.
I may try adding some of my other cards, such as my microprocessor and IBM
collections. In the future
https://drive.google.com/open?id=13dPAlRMQEwNvPwLXwlOC5Q_ZrQp4IpkJ&usp=driv…
ᐧ
I subscribe to the TUHS mailing list, delivered in digest form. I do not
remember having subscribed to COFF, and am not aware of how to do so. Yet
COFF messges come in my TUHS digest. How does COFF differ from TUHS and how
does one subscibe to it (if at all)?
Doug
Just had a quick look at 'man cat' on Uixes I've got 'at hand'. Just a 'cut
and past' of the relevant parts.
SCO UNIX 3.2V4.2
Limitations
Note that ``cal 84'' refers to the year 84, not 1984.
The calendar produced is the Gregorian calendar from September 14 1752
onward. Dates up to and including September 2 1752 use the Julian calen-
dar. (England and her colonies switched from the Julian to the
Gregorian
calendar in September 1752, at which time eleven days were excised from
the year. To see the result of this switch, try cal 9 1752.)
Digital UNIX 4.0g
DESCRIPTION
The cal command writes to standard output a Gregorian calendar for the
specified year or month.
For historical reasons, the cal command's Gregorian calendar is
discontinu-
ous. The display for September 1752 (cal 9 1752) jumps from Wednesday the
2nd to Thursday the 14th.
--
The more I learn the better I understand I know nothing.
All ...
----- Forwarded message from Poul-Henning Kamp -----
Subject: DKUUG, EUUG and 586 issues (3700+ pages) of Unigram-X 1988…1996
(Please forward to the main TUHS list if you think it is warranted)
A brief intro: Datamuseum.dk is a volunteer-run effort to collect,
preserve and present "The Danish IT-history".
UNIX is part of that history, but our interest is seen through the
dual prisms of "Danish IT-History" and the computers in our collection.
My own personal UNIX interest is of course much deeper and broader,
which is why I'm sending this email.
Recently we helped clean out the basement under the Danish Unix
User's Group (DKUUG) which is winding down, and we hauled of a lot
of stuff, which includes much EUUG - (European Unix Users Group)
material.
As I feed it through the scanner, the EUUG-newsletters will appear here:
https://datamuseum.dk/wiki/Bits:Keyword/PERIODICALS/EUUG-NEWSLETTER
And proceedings from EUUG conferences (etc.) will appear here:
https://datamuseum.dk/wiki/Bits:Keyword/DKUUG/EUUG
I also found four boxes full of "Unigram-X" newsletters.
Unigram-X was a newsletter, published weekly out of London. A
typical issue was two yellow A3 sheets folded, or if if news was
slight, a folded A3 with an A4 insert.
… and that is just about all I know about it.
But whoever wrote it, they clearly had an amazing Rolodex.
In total there a tad more than 3700 pages of real-time news and
gossip about the UNIX world from 1986 to 1996.
It's not exactly core material for datamuseum.dk, but it is a
goldmine for UNIX history, so I have spent two full days day scanning
and getting all the pages, sorted, flipped and split into
one-year-per-pdf files.
I should warn that neither the raw material nor the scan is perfect,
but this is it, unless somebody else feels like going through it again.
(The paper stays in our collection, no rush.)
I need to go through and check for pages being upside down or out
of order, before I ingest the PDFSs into the Datamuseum.dk bitarchive,
but here is a preview:
https://phk.freebsd.dk/misc/unigram_x_1986_0034_0058.pdfhttps://phk.freebsd.dk/misc/unigram_x_1987_0059_0108.pdfhttps://phk.freebsd.dk/misc/unigram_x_1988_0109_0159.pdfhttps://phk.freebsd.dk/misc/unigram_x_1989_0160_0211.pdfhttps://phk.freebsd.dk/misc/unigram_x_1990_0212_0262.pdfhttps://phk.freebsd.dk/misc/unigram_x_1991_0263_0313.pdfhttps://phk.freebsd.dk/misc/unigram_x_1992_0314_0365.pdfhttps://phk.freebsd.dk/misc/unigram_x_1993_0366_0416.pdfhttps://phk.freebsd.dk/misc/unigram_x_1994_0417_0467.pdfhttps://phk.freebsd.dk/misc/unigram_x_1995_0468_0518.pdfhttps://phk.freebsd.dk/misc/unigram_x_1996_0519_0616.pdf
My ulterior motives for this preview are several:
If you find any out-of-order or rotated pages, please let me know.
It's not a complete collection, the following issues are missing:
1…33 35 39…49 86…87 105 138 229 321 400 405…406 496 498
507 520 523…524 527…528 548 613 615 617…
It would be nice to fill the holes.
As a matter of principle, we do not store OCR'ed PDF's in the
datamuseum.dk bitarchive[1], and what with me still suffering from
a job etc, I do not have the time to OCR 3700+ pages under any
circumstances.
But even the most crude and buggy OCR reading would be a great
resource to grep(1), so I'm hoping somebody else might find
the time and inclination ?
And a "best-of-unigram-x" page on the TUHS wiki may be warranted,
because there are some seriously great nuggets in there :-)
Enjoy,
Poul-Henning
[1] I'm not entertaining any arguments about this: We're trying
to align with best practice in historical collection world.
The argument goes: Unless the OCR is perfect, people will do
a text-search, not find stuff, and conclude it is not there.
Such interpretations of artifacts belong in peer-reviewed papers,
so there is a name of who to blame or praise, and so that they
can be debated & revised etc.
[2] The PDF's are archive-quality, you can extract the raw images
from them, for instance with XPDF's "pdfimages" program.
----- End forwarded message -----
> From: Dan Cross
> These techniques are rather old, and I think go back much further than
> we're suggesting. Knuth mentions nested translations in TAOCP ..
> suggesting the technique was well-known as early as the mid-1960s.
I'm not sure what exactly you're referring to with "[t]hese techniques"; I
gather you are talking about the low-level mechanisms used to implement
'system calls'? If so, please permit me to ramble for a while, and revise
your time-line somewhat.
There are two reasons one needs 'system calls'; low-level 'getting there from
here' (which I'll explain below), and 'switching operating/protection
domains' (roughly, from 'user' to 'kernel').
In a batch OS which only runs in a single mode, one _could_ just use regular
subroutine calls to call the 'operating system', to 'get there from here'.
The low-level reason not to do this is that one would need the addresses of
all the routines in the OS (which could change over time). If one instead
used permanent numbers to identify system calls, and had some sort of 'system
call' mechanism (an instruction - although it could be a subroutine call to a
fixed location in the OS), one wouldn't need the addresses. But this is just
low level mechanistic stuff. (I have yet to research to see if any early OS's
did use subroutine calls as their interface.)
The 'switching operating/protection domains' is more fundamental - and
unavoidable. Obviously, it wouldn't have been needed before there were
machines/OS's that operated in multiple modes. I don't have time to research
which was the _first_ machine/OS to need this, but clearly CTSS was an early
one. I happen to have a CTSS manual (two, actually :-), and in CTSS a system
call was:
TSX NAMEI, 4
..
..
NAMEI: TIA =HNAME
where 'NAME' "is the BCD name of a legitimate supervisor entry point", and
the 'TIA' instruction may be "usefully (but inexactly) read as Trap Into A
core" (remember that in CTSS, the OS lived in the A core). (Don't ask me what
HNAME is, or what a TSX instruction does! :-)
So that would have been 1963, or a little earlier. By 1965 (see the 1965 Fall
Joint Computer Conference papers:
https://multicians.org/history.html
for more), MIT had already moved on to the idea of using a subroutine calls
that could cross protection domain boundaries for 'system calls', for
Multics. The advantage of doing that is that if the machine has a standard
way of passing arguments to subroutines, you natively/naturally get arguments
to system calls.
Noel