Rather than increase subject drift on a thread I started
"UNIX on (not quite bare) System/370", here's a new thread.
Since the TUHS archive seems to now include documentation,
I decided to take a look and see if the earliest UNIX manual I have
is in the archive:
It was given to me by a friend at Stevens Tech in Hoboken NJ (c. 1980)
who had graduated, and worked for AT&T.
It's hole punched for a four ring binder
(I found an unused Bell System Project Telstar binder to put it in).
The cover page has:
Upper left corner:
Bell Telephone Laboratories Incorperated
PROGRAM APPLICATION INSTRUCTION
Upper right corner:
PA-1C300-01
Section 1
Issue 1, January 1976
AT&TCo SPCS
Center:
UNIX PROGRAMMER'S MANUAL
Program Generic PG-1C300 Issue 2
Published by the UNIX Support Group
January, 1976
The preface starts with:
This document is published as part of the UNIX Operating System Program Generic,
PG-1C300 Issue 2. The development of the Program Generic is the result of the
efforts of the members of the UNIX Support Group, supervised by J.F. Maranzano
and composed of: R. B. Brant, J. Feder, C. D. Perez. T. M. Raleigh, R. E. Swift,
G. C. Vogel and I. A. Winheim.
and ends with
For corrections and comments please contact C. D. Perez, MH 2C-423, Extension
6041.
Not knowing who else I could ask, I brought it to a Boston Usenix (in
the 90's or oughts), and asked DMR if he could identify it. He said
it was an early supported UNIX, and he signed the preface page for me.
The manual has sections I through VIII; all manual pages start with page -1-
I found https://www.tuhs.org/Archive/Distributions/USDL/unix_program_description_ja…
with cover page:
UNIX PROGRAM DESCRIPTION
Program Generic PG-1C300 Issue 2
Published by the UNIX Support Group
January 1976
contents:
NUMBER ISSUE TITLE
PD-1C301-01 1 Operating System
PD-1C302-01 1 Device Drivers Section 1
PD-1C303-01 1 Device Drivers Section 2
And consists of descriptions of kernel functions.
So it seems likely that my manual is a companion to that.
I have a Brother printer/scanner, but the paper is fragile, so unless
it's of immediate and burning value to someone, it's unlikely to rise
to the top of my ever-static list of documents to scan....
But if someone has specific questions I can look up, let me know....
I’m re-reading Brian Kernighan’s book on Early Unix (‘Unix: A History & Memoir’)
and he mentions the (on disk) documentation that came with Unix - something that made it stand out, even for some decades.
Doug McIlroy has commented on v2-v3 (1972-73?) being an extremely productive year for Ken & Dennis.
But as well, they wrote papers and man pages, probably more.
I’ve never heard anyone mention keyboard skills with the people of the CSRC - doesn’t anyone know?
There’s at least one Internet meme that highly productive coders necessarily have good keyboard skills,
which leads to also producing documentation or, at least, not avoiding it entirely, as often happens commercially.
Underlying this is something I once caught as a random comment:
The commonality of skills between Writing & Coding.
Does anyone has any good refs for this crossover?
Is it a real effect or a biased view.
That great programmers are also “good writers”:
takes time & focus, clarity of vision, deliberate intent and many revisions, chopping away the cruft that’s isn’t “the thing” and “polishing”, not rushing it out the door.
Ken is famous for his brevity and succinct statements.
Not sure if that’s a personal preference, a mastered skill or “economy in everything”.
steve j
=========
A Research UNIX Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986
M.D. McIlroy
<https://www.cs.dartmouth.edu/~doug/reader.pdf>
<https://archive.org/details/a_research_unix_reader/page/n13/mode/2up>
pg 10
3.4. Languages
CC (v2 page 52)
V2 saw a burst of languages:
a new TMG,
a B that worked in both core-resident and software-paged versions,
the completion of Fortran IV (Thompson and Ritchie), and
Ritchie's first C, conceived as B with data types.
In that furiously productive year Thompson and Ritchie together
wrote and debugged about
100,000 lines of production code.
=========
Programming's Dirtiest Little Secret
Wednesday, September 10, 2008
<http://steve-yegge.blogspot.com/2008/09/programmings-dirtiest-little-secret…>
It's just simple arithmetic. If you spend more time hammering out code, then in order to keep up, you need to spend less time doing something else.
But when it comes to programming, there are only so many things you can sacrifice!
You can cut down on your documentation.
You can cut down on commenting your code.
You can cut down on email conversations and
participation in online discussions, preferring group discussions and hallway conversations.
And... well, that's about it.
So guess what non-touch-typists sacrifice?
All of it, man.
They sacrifice all of it.
Touch typists can spot an illtyperate programmer from a mile away.
They don't even have to be in the same room.
For starters, non-typists are almost invisible.
They don't leave a footprint in our online community.
=========
--
Steve Jenkin, IT Systems and Design
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA
mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin
The discussion about the 3B2 triggered another question in my head: what were the earliest multi-processor versions of Unix and how did they relate?
My current understanding is that the earliest one is a dual-CPU VAX system with a modified 4BSD done at Purdue. This would have been late 1981, early 1982. I think one CPU was acting as master and had exclusive kernel access, the other CPU would only run user mode code.
Then I understand that Keith Kelleman spent a lot of effort to make Unix run on the 3B2 in a SMP setup, essentially going through the source and finding all critical sections and surrounding those with spinlocks. This would be around 1983, and became part of SVr3. I suppose that the “spl()” calls only protected critical sections that were shared between the main thread and interrupt sequences, so that a manual review was necessary to consider each kernel data structure for parallel access issues in the case of 2 CPU’s.
Any other notable work in this area prior to 1985?
How was the SMP implementation in SVr3 judged back in its day?
Paul
Greetings,
What's the canonical source for patches to 2.9BSD and 2.11BSD?
I see we have 2.11BSD patch 469 dated last month in the archive. Where does
it come from? Has anybody climbed the hill to import all the patches into a
git repo? I've found some mirrors, but moe.2bsd.org has been down for me
for ages... How does Warren keep things up to date?
I also have a (maybe faulty) memory of a similar series of patches to
2.9BSD because it was the last BSD to support non-split I&D space machines.
yet a quick google search turns up nothing other than a set of patches
dated August 1985 (also in our archive) and some changes for variants of
hardware (pro, mscp). Is that it?
Warner
Good afternoon, folks. I was wondering if anyone is aware of/possesses a scanned copy (or paper copy ripe for scanning) of the research V4 UNIX Programmer's Manual. I've found a few rendered PDFs from the available manpage sources, but I am looking to do some comparison of original typesetting re: my restorations of various other sets of manpages. I have scans of all the other research versions I believe, just not V4. Thanks in advance!
- Matt G.
Hi,
Has anyone been successful in communicating using cu or some
other method to transfer files between two SIMS running Unix V ?
If so I would appreciate some help.
Thanks,
Ken
--
WWL 📚
Good morning all, just emailing to notify that I'm once again in a position to work on scanning documents and the like, so want to throw out the offer of performing any scanning/archival gratis for materials relevant to TUHS and the broader UNIX picture. Included in this is I'll happily pay the shipping to and fro.
My setup is very simple, consisting of a CanoScan LiDE 100 over USB into my Raspberry Pi running SANE and ImageMagick. The former handles the scans obviously and then the results are reduced by ImageMagick into a PDF, cropping overscan in the process. I tend to favor 300dpi as a compromise between quality and size, as I've found that the archive.org OCR can do a good job with this. That said, if you particularly want a given DPI or scan quality, that is adjustable within the capabilities of the scanner. I'd probably still reduce the size for archive.org but could initially sample at a higher rate and send you the resulting PDFs on a CD-ROM/USB stick. Similarly, if for some reason the material can be scanned but can't be archived anywhere else (legal reasons, etc.) I can provide physical media in the return package, with the understanding that I absolutely would keep this stuff in a time capsule for some later date. If you only want scanning, no archival, sorry, that I'm not willing to do for free.
Anywho, short of anything new coming in, this is what I've got on my current plate:
- UNIX Release 4.0 Text Editing and Phototypesetting Starter Package
- UNIX Release 4.1 3B20 User's Manual
- UNIX Release 5.0 User's Manual BTL Edition
- UNIX System V Support Tools Guide
- UNIX System V Document Processing Guide
- UNIX System V Release 2.0 User's Manual BTL Edition
Of these, the first two are already archived in some fashion, these physical books just haven't been scanned. For the two BTL manuals, these are the extant SysV and SVR2 manuals with extra pages to represent things commonly found on BTL computers of the time (WWB, Basic-16 SGS, site-specific bits to PY, HO, IH, CB, and a few others.) Finally, the other two SysV docs are just successors to the Documents for UNIX papers, slightly reformatted and updated for SysV. Also I eventually want to *ROFF-ize anything that obviously came from typesetter sources, so like I did with the 4.1 manual, some of these may get the *ROFF treatment first, with scanning to occur on a day with nastier weather. All that to say, anything I receive obviously trumps this list in priority. Thanks all!
- Matt G.
Fortran question for Unix System-5 r3.
When executing fortran programs requiring input the screen will
show a blank screen. After entering input anyway the program
completes under Unix System V *r3*.
When the same program is compiled under Unix System V *r1* it
works as expected.
Sounds like on Unix System V *r3* the output buffer is not being flushed.
I tried re-compiling F77. No help.
Fortran code follows:
PROGRAM EASTER
INTEGER YEAR,METCYC,CENTRY,ERROR1,ERROR2,DAY
INTEGER EPACT,LUNA
C A PROGRAM TO CALCULATE THE DATE OF EASTER
PRINT '(A)',' INPUT THE YEAR FOR WHICH EASTER'
PRINT '(A)',' IS TO BE CALCULATED'
PRINT '(A)',' ENTER THE WHOLE YEAR, E.G. 1978 '
READ '(A)',YEAR
C CALCULATING THE YEAR IN THE 19 YEAR METONIC CYCLE-METCYC
METCYC = MOD(YEAR,19)+1
IF(YEAR.LE.1582)THEN
DAY = (5*YEAR)/4
EPACT = MOD(11*METCYC-4,30)+1
ELSE
C CALCULATING THE CENTURY-CENTRY
CENTRY = (YEAR/100)+1
C ACCOUNTING FOR ARITHMETIC INACCURACIES
C IGNORES LEAP YEARS ETC.
ERROR1 = (3*CENTRY/4)-12
ERROR2 = ((8*CENTRY+5)/25)-5
C LOCATING SUNDAY
DAY = (5*YEAR/4)-ERROR1-10
C LOCATING THE EPACT(FULL MOON)
EPACT = MOD(11*METCYC+20+ERROR2-ERROR1,30)
IF(EPACT.LT.0)EPACT=30+EPACT
IF((EPACT.EQ.25.AND.METCYC.GT.11).OR.EPACT.EQ.24)THEN
EPACT=EPACT+1
ENDIF
ENDIF
C FINDING THE FULL MOON
LUNA=44-EPACT
IF(LUNA.LT.21)THEN
LUNA=LUNA+30
ENDIF
C LOCATING EASTER SUNDAY
LUNA=LUNA+7-(MOD(DAY+LUNA,7))
C LOCATING THE CORRECT MONTH
IF(LUNA.GT.31)THEN
LUNA = LUNA - 31
PRINT '(A)',' FOR THE YEAR ',YEAR
PRINT '(A)',' EASTER FALLS ON APRIL ',LUNA
ELSE
PRINT '(A)',' FOR THE YEAR ',YEAR
PRINT '(A)',' EASTER FALLS ON MARCH ',LUNA
ENDIF
END
Any help would be appreciated,
Ken
--
WWL 📚
Matt G. suggested that I join the COFF <COFF(a)tuhs.org> mailing list.
He thought it might be a better site to post my questions
operational and technical ..
Thank,
Ken
--
WWL 📚
--
End of line
JOB TERMINATED
