Hello!
For some time now I've had both this address, and my original address
which was on another service altogether subscribed to this list. And
starting some time earlier, it would not show a full thread, it would
show partial contents, the latest was the work by Dan Cross. In fact
With that being last, ah, straw I decided to do that.
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
“soldering iron…”
i do remember the fun of changing the baud rate of an async line on the Honeywell level 66 mainframe at college. This required shutting the whole machine down, removing one of the cards, and the (very careful) use of a wire wrap tool.
-Steve
Good evening folks, I'm doing some research lately into the typesetting style apparent in the various UNIX System V guides I've scanned to archive.org. Their typesetting style is unlike that of the MM papers published with 3.0 and 4.0, but the contents seem to have continuity with the text in these collections.
Well, in my searches sometimes telecom documents from the Bell System come up too and in materials from the 70s and 80s I started noticing that familiar typesetting in telecom stuff such as that hosted here https://www.telephonecollectors.info/index.php/browse/bsps-bell-system/bsp-…
The earliest example I could find is 1969, so certainly at least a publication style that predates UNIX, but what I can't tell from my searches alone is if this style implies some non-UNIX typesetting system through and through or if there was a macro package dreamed up at some point between 1969 and 1982 that was in place by the time of the System V documentation.
Just to detail specifics of the publication style, the commonalities I've found are the use of specifically bold numbers for page numbers, having the doc title and call number in the outer upper corner of pages, and just the fonts themselves look very similar. As an added note, the fonts used in the telecom documents and System V guidance documentation also resemble those in the copyright statement pasted on the cover of the extant PDF of the fifth edition UNIX manual. There is also some resemblance to the visual style observable in USG Program Generic and adjacent documentation (for instance the 1976 kernel description of PG 2 or the MERT 0 documents). This typesetting style is not seen in known research, CB, nor PWB until 5.0. Was there some separate typesetting system used in the broader System that, say, WECo may have taken up when they took over documentation between 3.0 and SVR2?
- Matt G.
Hi folks, sharing another project that I've been tinkering on for a little bit since I like having a lot of irons in the fire: https://gitlab.com/segaloco/v2src
After the link is a repository which over time will be accumulating the results of disassembly and analysis of files found in the s2-bits.tar.gz file in the archive. Details of my process are contained in the repository's readme. The short of it is I'm disassembling the binaries one by one, and where possible am comparing them with known sources to massage these into a pretty close restoration of the original sources.
A few discoveries I've made in the process thus far:
- These binaries appear to represent a version between the first and second editions. The binaries themselves are a mix of "naked" binaries as well as V1 and V2 a.out formats. Where it matters, things are much closer in character to V2 than V1.
- All section 1 content that would be gone by V2 is removed here. Curiously, mount(1), type(1), and umount(1) which are in both V1 and V2 are absent from the s2-bits.
- The sources marked "V2" in the UNIX source tree may be a bit closer in character to V3. Notable examples are that, while string references to /etc/uids remain, all data references have been updated to /etc/passwd, and several mathematical operations in the disassembled binaries map to KE-11 Extended Arithemtic Element registers where in the sources labeled "V2" in the tree have instead shifted to doing these calculations differently, presumably as these sources target the 11/45, not the 11/20. Additionally, the cat.s in "V2" on the tree contains the '-' stdin option, which was first documented in V3. The most likely story is that they're somewhere between, just like the s2-bits are between V1 and V2, but all of these observed differences thus far have aligned the sources with their descriptions in the third edition manual.
Anywho, as usual, if anyone spots anything amiss or that could be done better, happy to accept contributions, or fork it and tinker away. Also, if anyone has already done this, speak up and tell me now so I don't double up on something so involved =P
- Matt G.
> From: Paul Ruizendaal
> something like a boot rom only became the norm in the late
> 70's. Before that, one keyed in two dozen words with a tiny program to
> load the first boot stage.
A little wrong on that date. Even the PDP-11/20 (the first -11) had a boot
ROM:
https://gunkies.org/wiki/BM792_ROM
which appreared in mid-1971 (about a year after the release of the /20). DEC
sold them pre-programmed, but one could 'program' one onself, if one wanted -
with a soldering iron! (Check out the image! I actually did that to one that
I was given, that had been eviscerated by someone.) From then on (follow the
category link), the rest used PROM chips.
> From: Warner Losh
> Oftentimes, the interrupt vector was in the lowest core addresses
It's worth remembering that in the early period, that restriction to low
addresses was built into the hardware (in an amusing way :-).
Take the DL11:
https://gunkies.org/wiki/DL11_asynchronous_serial_line_interface
which was sort of mandatory as the 'console' serial interface on most early
-11's (until the DL11-W appeared; more on its big improvement in a second).
It set the interrupt vector with _jumpers_. (You want to change the interrupt
vector? Dig out your soldering iron! :-) There were only 6 jumpers - one each
for address bits 3 through 8. So the largest vector you could set was 0770.
The DL11-W was a big step forward - it replaced the jumpers with a DIP
switch! :-) Still only six bits, though. :-)
Noel
Hi Matt,
I’ve responded on list about the early unix development process as I understand it, but I want to avoid discussing things that are not directly related to the history of Unix. Hence this PM as well.
> Where I'm trying to put this sort of knowledge into use is I'm starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (ARM32 and RISCV64 respectively) that is not only sufficient to start a V7-ish kernel on each, but that are ultimately based on the same design, varying literally only where the hardware strictly necessitates it, but similar enough that reading the two assembly files side by side yields essentially the exact same discrete operations.
I have a similar interest, working with early Unix and modern RiscV hardware for a compare and contrast experience.
- My development targets are (i) an FPGA based RV32 SoC implementation, (ii) a Sipeed D1 RV64GC board and shortly (iii) a Pine64 Pinetab-V.
- My software targets are: (a) xv6-rv, (b) SysIII, (c) Linux, (d) experiments around SysIII
Linux is for me a secondary target, just for comparison and to see if ideas are “Linux capable”. I’m not overly interested in Arm at the moment.
My ideas are still evolving, but currently more or less along the below lines:
- Boot rom loads SPL, this is custom in each case and set by the SoC's designers.
- SPL initialises DRAM system and loads next stage. Unfortunately, this too would seem to be quite system specific, but the BSP should provide the baseline for this. As BSP’s are often a mess, milage may vary.
- The next stage is a hybrid of BBL, OpenSBI and Virtio. The idea is to provide a standard abstraction layer that all of my software targets can work with. This idea is used for the FPGA target and allows booting a Linux kernel with just the generic Virtio device drivers (so far just disk and console).
- The last layer is the classical OS layer. If I get it right, each OS can run on all h/w targets without customisation.
At the moment I’m playing with USB, and how that might layer into the structure of V7, SysIII or 8th Edition -- and also the above.
> Date: Mon, 10 Apr 2023 18:27:51 +0000
> From: segaloco
> ... or was there no single guiding principle and each machine came up, at that level at least, in a relative vacuum, with only the machine interface to UNIX being the guiding principle?
I stumbled into the same question last year, when doing my SysIII to RV64 port. I managed to turn that into a somewhat chaotic discussion, mixing old and new, and history with ideas. From that chaotic discussion I got the impression that it was indeed mostly ad hoc. In context, hardware was much easier to boot and drive back then -- it probably was not seen as complex enough to warrant much research into layering and abstraction.
Also bear in mind that something like a boot rom only became the norm in the late 70’s. Before that, one keyed in two dozen words with a tiny program to load the first boot stage.
That said, there is an implicit layering in v7 and beyond:
- “low.s" does hardware setup, incl. such stuff as setting up interrupt tables. As this is closely tied to the hardware, it would have been a custom job in each case.
- “mch.s” (later also mch.c) has the basic routines that are hardware dependent (switching stacks, changing priority levels and modes, etc.). It also has emulation for ‘missing’ instructions, such as floating point ops where this is not available in hardware. Same as above, I think. Maybe h/w related memory protection operations should live here as well, but the hardware was still quite divergent in this area in the 70’s and early 80’s.
- low-level device drivers live in the ‘dmr’ or (later) ‘io’ directory. Here there is some standardisation, as all device drivers must conform to the (char/block) device switch APIs. It seems to me that most of these drivers were written by taking one that was similar to what needed to be written and to start from there. Maybe this is still how it works in Linux today.
- To the extent that there is such a thing as 'high-level device drivers’ in early Unix, the structure is less clearly visible. The file system (and there was only one at the time of v7) is placed between the block device switch and the mount table so to speak. This was structured enough that splicing in other file systems seems to have been fairly easy in the early 80’s (the splicing in, not the writing of the file system itself, of course). Starting with 8th edition, the ‘file system switch’ created a clear API for multiple file systems. Arguably, the ‘tty’ subsystem is also a ‘high-level device driver’, but this one lives as custom code together with the serial port device drivers. Also in 8th Edition, ‘streams' were introduced. One could think of this as a structured approach to high-level device drivers for character mode devices, incl. the ’tty’ subsystem.
- I don’t think there was ever anything in early Unix that merged ’streams’ and the 'file system switch' into a single abstraction (but maybe 9P did?).
> Where I'm trying to put this sort of knowledge into use is I'm starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (ARM32 and RISCV64 respectively) that is not only sufficient to start a V7-ish kernel on each, but that are ultimately based on the same design, varying literally only where the hardware strictly necessitates it, but similar enough that reading the two assembly files side by side yields essentially the exact same discrete operations.
I have a similar interest, but to avoid the same chaos as I created before, I’ll respond to this with a pm.
> Does anyone know of any of the tools, formats, practices, etc. used in producing the actual graphical covers of various published UNIX manuals?
The Bell Labs publication department at Whippany did the physical
design for the bound versions of the Research Unix manual--from v7 as
a trade brook through v10, also a trade book.. They did the cover
designs for v8-v10 in house. I am not sure whether they did the v7
cover, farmed it out, or left it up to Holt Rinehart. Whippany handled
the printing of v8 and v9. Saunders College Publishing did it for v10.
Unfortunately, I do not remember whom I dealt with in Whippany, and my
records of the interactions are long gone.
Doug
Good evening, I'd like to share a listing I've taken of the various extra pages present in the BTL version of the SVR2 User's Manual I picked up a little while ago.
https://pastebin.com/18uTzyfS
Like the Release 5.0 BTL version before it, many of the added pages are DIV 452 standard pages for Writer's Workbench as well as the Basic-16/BELLMAC-4/BELLMAC-8 development environments.
To quote the preface:
"This manual was designed through a cooperative effort of the BTL Computer Centers in Division 452. It represents a collection of nearly all the commands that are running on any Computer Center UNIX machine.
...
The header of each manual page identifies the classification of the command along with any machine or site dependencies.
...
Any page marked LOCAL indicates the sites that are running that command.
...
Pages marked DIV 452 STD are from the collection of Computer Center standard commands, and are available on machines administered by Division 452 Computer Centers. The pages that are designated as INTERIM or 5.0 are those commands which are scheduled to be included in a separate WECo software add-on package."
This manual is just sections 1 and 6, presumably 1m, 7, and 8 are in a corresponding administrator's manual and 2, 3, 4, 5 are in a programmer's manual, making SVR2 the start of the user's manual being further subdivided. I seem to recall one or the other of this same issue of manuals show up on eBay at some point, I'm kicking myself for not springing for it at the time, but hopefully one or the other (or both) turn up again to be documented someday.
Additionally included in the above listing is a list of references from various "SEE ALSO" sections throughout the manual, as well as some other odds and ends from the text. Finally, there is a short listing of teach(1) classes as provided by a couple variants of the application.
If any particular page piques an interest, let me know and I can scan it for you, otherwise this one is a ways away on my scan backlog.
- Matt G.
Good day everyone, I'm in search of a bit of esoteric information regarding published UNIX works. Does anyone know of any of the tools, formats, practices, etc. used in producing the actual graphical covers of various published UNIX manuals?
Some that come to mind:
The alphabet blocks cover of the HRW V7 Manuals
The simple 70's Bell-style cover of the UNIX System III manual
The nice 3B-20 picture on the UNIX 4.1 manual
The grid patterns design on the UNIX System V documentation
The blue "big V" SVR4 manuals (given the time disparity, these could have totally different underpinnings)
Where I'm particularly curious is how these covers were actually set, defined, the image data to print on them stored, formatted, etc. In other words, <???>:troff::covers:manpages where ??? may also represent more than just the specific tools/formats. Anyone have the scoop on the actual raw materials and technologies used for preparing the covers and/or if any of those original assets, in their raw form, would potentially still exist somewhere? To be honest, I am particularly interested in the original, highest fidelity possible image of the 3B-20 from the corresponding manual (https://commons.wikimedia.org/wiki/Category:Unix_Manuals#/media/File:UNIX4.…) but am happy with any info illuminates what went into the actual physical production. Thanks all!
- Matt G.
P.S. If it provides any leads, the closest thing I've found in actual document sources to material related to these aspects of physical publication are the files M.folio and M.tabs here: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/man/tools
I figure it won't cost me much more than $5 to ship domestically, which
I'll pay for. International is more hassle so let's discuss.
BSTJJuly-August 1978 ("the" issue)
Elements of Programming Style 2nd Ed, Kernighan and Plauger
The UNIX Programming Environment, Kernighan and Pike
The C Programming Language 2nd Ed, Kernighan and Ritchie (includes printout
of errata posted by dmr(a)alice.JUCP "5 Jun 89")
Good day everyone. I'm taking a bit of a break from my documentation stuff and veering back towards some embedded systems work and have the burning question on my mind this morning: Was there any coordination between different groups engaged in porting efforts at Bell regarding machine layer implementations?
In other words, was there any sort of common design of "get a stack pointer, do <XYZ> on the protection hardware, move the binary to address <ABC>, clear bss, etc." that was followed as lore when working up new machine bootstraps, or was that sort of work a bit more siloed? For instance, when working on the VAX port, was the crew more likely stepping through mch replicating things based on what the PDP-11 was doing, was the startup more derived from DEC literature, or was there no single guiding principle and each machine came up, at that level at least, in a relative vacuum, with only the machine interface to UNIX being the guiding principle?
Where I'm trying to put this sort of knowledge into use is I'm starting to spec out a kernel bootstrap for the RPi Pico and Pine64 Ox64 boards (ARM32 and RISCV64 respectively) that is not only sufficient to start a V7-ish kernel on each, but that are ultimately based on the same design, varying literally only where the hardware strictly necessitates it, but similar enough that reading the two assembly files side by side yields essentially the exact same discrete operations. What I don't know is if I'm barking up the wrong tree and it was already settled in the 70s that machines are sufficiently different enough that you can't really just set forth one abstract "machine startup" design that actually includes all those CPU-level concerns such as protection, stack config, context switching, etc. I know even today peering into sources of stuff like Linux and seL4, the "ml" for each seems to have been built by a different person/group rather than someone setting out with a CPU bootstrap design and implementing the same on each chip.
So boiled down to a one liner: Was there a guiding document/design/memoranda for the mch/ml components of UNIX in Bell, or was each one designed more "on-the-fly" as the particulars of the hardware were sorted out?
- Matt G.
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
Hello,
I received word from someone who went to Case Wester Reserve
Univsersity, and is willing to send early 1970s ephemera to someone
interested in going through it. The description is:
"I've go stuff from my course work done on our Univac 1108/ChiOS system,
program listing, cpu code cards, etc."
Any takers?
Best regards,
Lars Brinkhoff
Hello all,
I am working on restoring the 2.9BSD PUCC distribution as provided on the
CSRG CD/DVD set, hopefully as closely as possible to the original system.
I am at a point where I have a setup that boots 95% of the way to multiuser
but I have encountered some difficulties with the final few steps. I would
appreciate it if anyone who is familiar with the login procedure could
contact me off-list.
-Henry
Once again, I must dredge up this post from 1991….
From spaf(a)cs.purdue.EDU Thu Apr 4 23:11:22 1991
Path: ai-lab!mintaka!mit-eddie!wuarchive!usc!apple!amdahl!walldrug!moscvax!perdue!spaf
From:
spaf(a)cs.purdue.EDU (Gene Spafford)
Newsgroups: news.announce.important,news.admin
Subject: Warning: April Fools Time again (forged messages on the loose!)
Message-ID: <
4-1-1991(a)medusa.cs.purdue.edu>
Date: 1 Apr 91 00:00:00 GMT
Expires: 1 May 91 00:00:00 GMT
Followup-To: news.admin
Organization: Dept. of Computer Sciences, Purdue Univ.
Lines: 25
Approved:
spaf(a)cs.purdue.EDU
Xref: ai-lab news.announce.important:19 news.admin:8235
Warning: April 1 is rapidly approaching, and with it comes a USENET
tradition. On April Fools day comes a series of forged, tongue-in-cheek
messages, either from non-existent sites or using the name of a Well Known
USENET person. In general, these messages are harmless and meant as a joke,
and people who respond to these messages without thinking, either by flaming
or otherwise responding, generally end up looking rather silly when the
forgery is exposed.
So, for the few weeks, if you see a message that seems completely out
of line or is otherwise unusual, think twice before posting a followup
or responding to it; it's very likely a forgery.
There are a few ways of checking to see if a message is a forgery. These
aren't foolproof, but since most forgery posters want people to figure it
out, they will allow you to track down the vast majority of forgeries:
o Russian computers. For historic reasons most forged messages have
as part of their Path: a non-existent (we think!) russian
computer, either kremvax or moscvax. Other possibilities are
nsacyber or wobegon. Please note, however, that walldrug is a real
site and isn't a forgery.
o Posted dates. Almost invariably, the date of the posting is forged
to be April 1.
o Funky Message-ID. Subtle hints are often lodged into the
Message-Id, as that field is more or less an unparsed text string
and can contain random information. Common values include pi,
the phone number of the red phone in the white house, and the
name of the forger's parrot.
o subtle mispellings. Look for subtle misspellings of the host names
in the Path: field when a message is forged in the name of a Big
Name USENET person. This is done so that the person being forged
actually gets a chance to see the message and wonder when he
actually posted it.
Forged messages, of course, are not to be condoned. But they happen, and
it's important for people on the net not to over-react. They happen at this
time every year, and the forger generally gets their kick from watching the
novice users take the posting seriously and try to flame their tails off. If
we can keep a level head and not react to these postings, they'll taper off
rather quickly and we can return to the normal state of affairs: chaos.
Thanks for your support.
Gene Spafford, Net.God (and probably tired of seeing this message)
Good evening or whatever time of day you find yourself in. I've just finished the first tag in a git repository I've put together to track UNIX developments as documented in the manual. In preparation for this, I also created restorations of the V1 and V2 manuals in roff based on the available V3 sources. The repositories for all this can be found here:
https://gitlab.com/segaloco/mandiffhttps://gitlab.com/segaloco/v1manhttps://gitlab.com/segaloco/v2man
There are most certainly typos and minor discrepancies still to be found between sources and the PDF scans, but given all the cross-referencing involved I believe the manual restorations to be largely complete.
As for the mandiff repository, the commit log (which might shake up in format...) should capture relatively complete transactions of either a particular feature or comparable additions, deletions, or modifications. That said, there may be little fixes in later commits of edits that really should've been in other ones, and the toc and index accuracy at any given commit is dubious at best. However, the content of the pages themselves should be pretty well broken up in to noteworthy transactions.
If you find a problem or have a correction, feel free to send it my way or even better, open a pull request with an explanation for the change. This repository will accrete more UNIX releases as time goes on, with a first goal being getting to V6, after which the fragmentary pathways will be a little harder to reconcile to a single informative trunk. I might start branches at that point.
By the way, in this process I found that the V2 manual scanned by Dennis Ritchie [1] contains references to nroff(I) in the TOC and permuted index, but the page may not have been in his copy. Given this, just to not hang up on it, I simply dropped in the V3 page with a note about this in the BUGS section.
1 - https://www.tuhs.org/Archive/Distributions/Research/Dennis_v2/v2man.pdf
- Matt G.
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
