Groups | Search | Server Info | Keyboard shortcuts | Login | Register
| From | billg999@cs.uofs.edu (Bill Gunshannon) |
|---|---|
| Newsgroups | alt.sys.pdp11, comp.sys.dec, vmsnet.pdp-11 |
| Subject | Re: Y3K for PDP-11 Operating Systems |
| Date | 2011-05-24 20:07 +0000 |
| Organization | Computing Sciences Dept., University of Scranton |
| Message-ID | <942hghFhukU1@mid.individual.net> (permalink) |
| References | (8 earlier) <ireupe$mqj$1@Iltempo.Update.UU.SE> <941ob1Fre1U1@mid.individual.net> <irgfp7$382$1@Iltempo.Update.UU.SE> <9425gcFhnpU1@mid.individual.net> <irgsnm$7ov$1@Iltempo.Update.UU.SE> |
Cross-posted to 3 groups.
In article <irgsnm$7ov$1@iltempo.update.uu.se>,
Johnny Billquist <bqt@softjar.se> writes:
> This is turning into a fun and interesting discussion, Bill.
> If others feels it's getting too boring, let us know, and we can carry
> on over emails instead...
Let me re-inforce that. But it would be nice to hear others comments
as well.
>
> On 2011-05-24 09.42, Bill Gunshannon wrote:
>> In article<irgfp7$382$1@iltempo.update.uu.se>,
>> Johnny Billquist<bqt@softjar.se> writes:
>>> On 2011-05-24 05.58, Bill Gunshannon wrote:
>>>> In article<ireupe$mqj$1@iltempo.update.uu.se>,
>>>> Johnny Billquist<bqt@softjar.se> writes:
>>>>> On 2011-05-23 17.16, Bill Gunshannon wrote:
>>>>>> In article<ireog6$ksn$1@iltempo.update.uu.se>,
>>>>>> Johnny Billquist<bqt@softjar.se> writes:
>>>>>>>
>>>>>>> In a way, a reimplementation of the PDP-11 OSes might be interesting.
>>>>>>> But I doubt many people today would see the point in using anything that
>>>>>>> didn't follow the Unix programming paradigms,
>>>>>>
>>>>>> I was waiting for this to come up. I think most people think that
>>>>>> there are really only two OSes left in the world. MS and Unix.
>>>>>> BUt, actually, thre are a lot of others out there including some
>>>>>> that predate MS and might even predate Unix and still have loyal
>>>>>> followings. (And I am not talking about VMS. :-)
>>>>>
>>>>> Well, Windows more or less allows you to follow the Unix paradigm as
>>>>> well, when it comes to writing programs for the net.
>>>>
>>>> Minus the security model. :-)
>>>
>>> True. But the security model of Unix itself isn't exactly something to
>>> boast about. :-)
>>
>> I'll take it over the MS model anyday.
>
> No argument from me there... But just because one sucks, that don't make
> the other one shine. I'd prefer neither...
OK, You got me there. :-) But then, isn't that part of the reason
behind this whole discussion? What we need is other options. I
just happen to think that the models/paradigms offered by RSTS/RSX
are worth consideration.
>
>>>>> And so do VMS.
>>>>
>>>> Minus little things like fork(); :-)
>>>
>>> Good point. There are some things that are more of an headache to emulate.
>>> Still, lots of Unix programs can be compiled and run on VMS systems with
>>> little, or no change.
>>
>> Yes, but not the majority of the ones people actually want. :-)
>
> Seems like quite a lot have been made to run over the years.
> tcsh, Apache, Netscape, gcc, emacs... Just to mention a few...
An interesting list. Especially emacs, which must be one of the most
ported programs in the history of IT. But, just out of curiosity,
how many of them are at the same release for VMS that they are for
Unix. Why not?
>
>>> And Unix programmers can write programs on a VMS
>>> system without really having to go outside their comfort zone for most
>>> of the time.
>>
>> Mostly depends on the complexity of the program. Hello World works
>> just fine on either. Try UXKermit which falt out requires the
>> functionality provided by fork() and it is really a trivial program.
>> or even something like "configure".
>
> Don't know about UXKermit, but I suspect it's a Kermit. What about
> C-Kermit? That's a Unix-smelly Kermit that also works on VMS.
Actually, if I remember correctly, C-Kermit was an attempt (successful)
to make a portable Kermit implementation so it specifically put all of
the system specific stuff in one place and limited requirements tied
to specific OSes like Unix. I used UXKermit as my example specifically
because it uses fork() a tthe very core. It spawns separate processes
(the Unix paradigm) to handle character input and output. Which, of
course, requires the two processes to share things like filehandles
so that they can do input and output to the same tty device.
>
>>> It might not be programs that really take any advantage of
>>> VMS, but then again, they don't care.
>>
>> And it is probably why so little of the Unix based Open Source stuff
>> ever makes it to VMS.
>
> Even so, surprising amounts of Open Source stuff actually do find its
> way to VMS. Not as much as you'd find on Unix or Windows by a longshot,
> but still a noticeable amount.
I have been porting Unix stuff to other OSes since the days when
comp.sources.unix was the primary distribution channel and even
most of that wasn't particularly portable to non-Unix OSes. But
this is pretty much irrelevant in the long run. If things like
STVOS had not withered on the vine we wuold have had a universal
API that was, by now, very well developed and porting would be
much easier.
>
>> ANSI-M/MUMPS. Well, not really an OS per se. It is usually hosted
>> on Unix, Windows and, yes, VMS. Think DSM!! It is a totally self-
>> contained system with its own DB built in and there is no desire to
>> have look, run, or be programmed as anything other than MUMPS. In
>> all these cases you see the same loyalty I would have had for something
>> like RSTS if it had grown beyond the limitations of the PDP-11 hard-
>> ware. Johnny, I get the feeling from reading your posts that you
>> probably look on RSX the same way.
>
> He. I still use RSX on a daily basis... :-)
> But MUMPS started on PDP-11s, unless I remember wrong.
No, PDP-7 was first. Then PDP-9, PDP-15, PDP-8, Data General,
and then the PDP-11.
> And as a
> standalone system on the machine as well...
Yeah, but a very portable one. :-)
> But I digress...
>
>>>>> (Hello select(), synchronous I/O, getting errors back which basically
>>>>> just means that you need to retry, because nothing is wrong, but we just
>>>>> got interrupted, and random dynamically allocated file descriptors, and
>>>>> all files are just streams of bytes.)
>>>>
>>>> Lot's of systems where that is not necessarily the case. Definitely not
>>>> the case with VMS.
>>>
>>> It's definitely the case with VMS. Yes, the above statements are not
>>> *neccesarily* true for VMS, but a programmer *can* program with this
>>> approach on VMS, and almost all programmers today implicitly assumes
>>> that these statements are truths.
>>
>> As one who hung out on c.o.v for a long time and worked with VMS
>> for a couple of decades I have to disagree. The idea that files
>> are streams of bytes without structure at the lowest level has to
>> be the most touted problem/shortcoming in Unix among that group.
>
> VMS deals with it just fine. It's called STREAM_LF on VMS systems. So
> programmers can pretend they never heard of anything else, even when
> running on VMS.
Wonder when that actually came into VMS? I would guess around POSIX
time.
>
> The people in c.o.vms are not representative of programmers. Most of
> them don't even write programs. They just like to vent their
> frustration. And yes, the stream of bytes concept has it's pros and
> cons. My point was that almost all programmers today just assumes that
> this is the case.
Yeah, another example of the failings of academia.
> So, on systems where this isn't the case, you get
> headaches. But more silly is the case when programmers then start
> implementing something similar to RMS atop of the stream of byte
> concept. Doing that on a system which actually do have structured files
> is both silly, inefficient, and incompatible with every other tool.
> Which just makes it pointless to have a more capable system, because
> noone will use it anyway, and they will continue to program like they
> were running on something that taste like Unix. Which brings me back to
> the start of my argument. The Unix programming paradigm is the only one
> around today.
See comment above. But people are trainable.
>
> Personally, I think that having streams of bytes as the only file
> structure sucks. It is one type of structure, and useful sometimes. But
> not the best way at other times. I prefer an OS that gives me many
> tools, and then I can adopt the one that fits my need for every specific
> situation instead of having to roll my own, or use some external library
> which exists in various flavors.
Well, I have to admit that I have long been amazed that no one ever
wrote an equivalent to RMS for Unix. But you do have to admit that
when you come right down to it all anything really is is a stream
of bytes (or bits if you want to go even lower) so having that as
the basis makes some sense.
>
>>> So, even though you have an OS that offers you other possibilities,
>>> noone knows, or can use them. (Ok, noone is an oversimplification, but
>>> you get the idea.)
>>
>> But with the amount of stuff that was already out there......
>
> No new programs are written using that stuff.
Well, after a point that probably was right, but if there had been
a future for OSes like RSTS and RSX do you really think that would
be the case?
>
>> And let's look at my list again. MUMPS? How many people use or are
>> proficient in it? And yet, it has a massive following and has moved
>> into niches it was never really intended to go to.
>
> No new programs are written for it.
You're joking, right? Mumps (now called ANSI-M) is still very much
in development and not just maintaining old systems. DSM-11 may have
died, but it certainly didn't take Mumps with it. I am still doing
my research but in just the one niche where it started (hospitals)
it is the prevalent system in use all over the world. It has also
established itself in other niches like the financial world.
>
>> And at a smaller level, what about COBOL? No longer taught in any
>> school I can find as more than an afterthought. (We dropped it as a
>> subject more than 10 years ago and at that point the department chair
>> cannot remember the last time it was actually offered. A single
>> credit's worth of COBOL was included in one course here but even
>> that was dropped 5 years ago.) And yet still so much in demand
>> the a company the size of General Dynamics recently advertised an
>> Internship where the primary function is to learn to program in
>> COBOL. Why? Because they are still writting and maintaining very
>> large COBOL systems and academia is not providing people with the
>> requisite skills so they have to revert back to the methods od the
>> 60's and early 70's and do it themselves.
>
> No new programs are written in COBOL. You just maintain existing systems.
Now you sound like a guy I know in NZ who thinks that COBOL died when
the COBOL Programmers refused to jump on the OO bandwagon. There are
still a lot of places where COBOL is the primary language of choice
for their market niche, and yes, it is the mainframe world which is
anything but going away.
>
>> Not all things are obsolete because one man thinks so, not even
>> if his name is Gartner.
>
> I think the term obsolete is misused. :-)
>
>>>>> and perhaps even more because the software they needed to run
>>>>> didn't run on PDP-11s any more.
>>>>
>>>> I would imagine the majority were running applications that were stable
>>>> and met their corporate needs just fine as they had been running them
>>>> for decades. The problem was the need to have additional functionality
>>>> that the hardware (primarily memory) limitations made impossible. If
>>>> it had been possible to add that functionality I would bet most would
>>>> have stayed with the OS they were familiar with. And, avoided the cost
>>>> of not only moving to a new platform but re-writting all their unique
>>>> application or changing their business model to match some other piece
>>>> of software's idea of how a business should be run.
>>>
>>> Well, in many cases, new requests for more functions, new features, or
>>> additional applications do come in. And that's when systems get replaced.
>>
>> But is that replacement because the OS is deficient or because the
>> hardware running it lacks the capability to handle the expansion?
>> Simple example. What about RSTS (not the PDP-11) makes X-11 un-doable?
>
> Nothing. But noone will write something like X11 for RSTS/E. No matter
> what platform.
I would.
> (I admit I have been toying with the idea for RSX, but I
> doubt I'll ever get around to it.)
Probably for the same reasons that would hold me back at the moment.
No time and no real need. But what if that need was there?
> Which leads us back to that the applications you want to run don't
> exist, so you don't run the OS.
Well, this is a chicken/egg thing. As they exist today the OS is not
capable of it. But if they were not constrained by the hardware they
run on? And, as far as X11 is concerned, it is getting a little long
in the tooth. Maybe it is time to think about something better?
> It's the same problem that VMS face. For VMS, the hardware is definitely
> there for all practical purposes.
That's arguable. Many think they backed the wrong horse.
> You even have X11.
An ancient version that has not been kept up.
> But VMS is a worse
> Unix than Unix, and so it looses.
VMS is rather unique compared to the other OSes I mentioned in that
its owners couldn't care less about it.
> And Unix is a worse Windows than MS
> Windows,
Not sure what you mean by this. There is not much that MS Windows
can do that can't be done using X-11 (well, sound support would have been
nice but we probably won't see that ever finished).
> and thus have a hard time competing as well. You need *office*.
>:-) (And a whole bunch of other applications.)
A perfectly good Office Suite is available for Unix. The only problem
there is lack of real marketing. But then, when you don't make any
money you don't have any to buy marketing. ;-)
>
> And things like office is what pushed PDP11s out in some places.
I agree. And Office products didn't come about because the hardware
couldn't do it, not because the OS somehow was deficient. RSTS and
RSX spent their lives tied to an anchor (a nice anchor, but an anchor
just the same). The only path forward offered by its owner did not
include those OSes. Interesting to note the difference in the success
(and even existence) of companies who did offer forward paths onto new
hardware compared to those that forced a total change of everything.
>
>>> So yes, the current applications are stable and working. But that is not
>>> enough. If that was all there is, then there wouldn't be any need for
>>> more computing power either. If the current setup already fulfills the
>>> needs, that would imply that the current computing power also is
>>> sufficient, no?
>>
>> No, not necessarily. Something as simple as the amount of data
>> that needs to be handled has increased beyond the addressing
>> capabilities of the host hardware. Best example for this is to
>> drop back to RT-11. I can put SCSI disks on RT-11. But I have
>> break them up into a whole lot of really samll partitions. Or,
>> look at Ultrix-11 or BSD-2.11. What is there about either of
>> these that would prevent most modern programs from being built
>> that isn't actually due to a hardware limitation of the platform?
>> Rhetorical question that is answered by looking at BSD 4.x and
>> the current crop of BSD's.
>
> I don't think I really agree. The amount of data don't in most cases
> change that much over time.
Say what? Let me give you just one example. The Internal Revenue
Service of the US. A major Unisys - COBOL shop. The number of
returns they have to deal with has at least doubled in my lifetime
alone. Thats a lot of data.
> The requirements for faster processing times
> because all other stages have become faster might play a role sometimes
> though.
And that, too!!! :-)
>
> RT-11 is a bad example by the way, since it's by far the most limited
> platform on the PDP-11. I can put huge disks on RSX without a problem.
> Using the default parameters, disks gets capped at 8GB though (24 bit
> disk block numbers). But you can change RSX to use 32 bit disk block
> numbers, meaning you get 4 billion disk blocks. That means a limit of
> about 2T disk size. That should last you a while longer... :-)
I was not aware of that with RSX. I expected the limit was larger
than RT-11 but much smaller than most modern systems.
>
> As for the problems with 2.11BSD, yes, the limit is the 16-bit address
> space, which is a hardware restriction.
> But the growth path from 2.11BSD was a simple and easy one, which just
> about everyone have taken long ago. Just continue with another Unix.
> But the reason for that migration was new programs. Not that the current
> crop of programs suddenly couldn't run on 2.11BSD anymore.
But what was that migration path? Unix was made to run on other hardware.
And as the hardware grew so did the OS. I just wish the same had been
true of RSTS and would like the chance to actually try it. :-)
>
>>>>> It all have very little to do with technical competence of the
>>>>> underlying OS.
>>>>
>>>> Oh, I can agree with that. As I said, "It's the applications!!"
>>>> But, by the same token, the move to a new OS was not because of
>>>> a shortcoming in the old OS. Unisys has been very successful by
>>>> making systems that still allow old code to continue to run only
>>>> with greater resources available (I remember a particular problem
>>>> I had to solve in my Univac COBOL days that was eventually tracked
>>>> down specifically to memory availability!! That same code would
>>>> run on OS2200 today without ever exhibiting the problem I had to
>>>> fix by modifying the supporting ECL.) IBM has had great success
>>>> by doing the same for SYSTEM-360 programs.
>>>
>>> Yes. It's the typical question of being able to run the applications.
>>> Rewriting, and porting applications can be both expensive and difficult.
>>> Cheaper to continue running on the old systems, when possible.
>>>
>>> I guess we forgot about one reason why people move off old OSes. Cost of
>>> running and maintaining old hardware. At some point it might just become
>>> impractical to continue running on the old machines.
>>
>> Which is the point I was trying to make. Frequently it is not the
>> application or the OS that causes the impracticality. It is the
>> hardware. And thus my interest in seeing RSTS and yes, RSX run on
>> other platforms. It seems to have worked out quite well for Unisys.
>
> An RSX for some other hardware? Well, I doubt you could make it run old
> RSX applications without some big headaches.
Not really my intent although, you have to admit, with built in PDP-11
emulation it probably could and be faster than original hardwar at that.
My desire is source level compatability. Have a version of RSTS or RSX
for x86/x86-64 that supports everything the PDP-11 versions did. And
new stuff can be added later. Who knows, if there actually was interest
I suppose you could VEST old immages. :-)
> But it is doable. The
> problem is that there is no real need. The old RSX applications runs
> just fine on the old machine. What need would a port to new hardware
> fill? We've already established that with current emulators speed is no
> longer an issue. Disk space neither. More memory is definitely not
> needed for the old applications. They already work within the current
> memory limits.
The desire to add new functionality. Instead of going to Windows for
new stuff be able to run it under RSTS/RSX. Is there a need? Most
people would say, "no". But then, was there really a need for Unix
when the CSRG started their research?
> So we're talking about totally new applications. I just don't see that
> happening. People will write for Unix instead.
Some would write for other systems. And my thought is that there may
be niches that decide they are not happy with the Unix/MS solution.
Or, it will just be an academic endeavor.
>
> Put another way: the drive for new hardware have mostly been new
> programs. New programs are written for certain OSes.
Not sure which is driving which. :-) New programs can be written
for anything. Big push here for teaching Android programming. Two
yeara ago the only "android" was Data and you couldn't program him.
>
>>> The PDP-11 was in that aspect perhaps a bit unfortunate, in that there
>>> was a long gap between when DEC more or less wanted (forced?) people to
>>> to migrate to VAXen, and before commercial emulators became available.
>>> Thus forcing a lot of migration to take place, because to viable options
>>> existed.
>>
>> Well, it is probably all academic at this point, but, who knows,
>> maybe there are still enough people out there doing stuff that
>> there is a remaining need for a port of RSTS or RSX to modern
>> hardware. It would be fun to do in any case.
>
> There are still people doing stuff on RSX, but they have no need of a
> new hardware platform for the system.
> At least that is my view and belief.
> Running on a fast emulator solves the only issues they have/had. Speed,
> cheap hardware, and big disks.
Yeah, both RSTS and RSX are probably real close to true EOL. I guess
the only saving grace is maybe that will be enough incentive to actually
see the source to all the old Digital stuff released. (But I am not going
to hold my breath waiting.)
>
>>>>>>> (Then again, a lot of programming today takes place in HLL, which have
>>>>>>> also adopted to the Unix paradigms, which makes it even harder to use
>>>>>>> any other OS, not to mention that you'd need to develop compilers and so
>>>>>>> on, for this reimplemented OS.)
>>>>>>
>>>>>> Once you moved to a mchine without the memory limitations of the PDP-11
>>>>>> you could use any of the GNU Compilers. Or pretty much anything else
>>>>>> out there today.
>>>>>
>>>>> No. You already failed right there. The GNU compilers them self assumes
>>>>> a whole lot of Unixy things.
>>>>
>>>> Hmmm.... Not so sure about that, but even if true I would imagine it
>>>> would not be a major undertaking to make the needed modifications.
>>>
>>> The horrors! I have peeked under the hood of gcc. It's not a piece of
>>> code I would ever consider easy to modify. :-)
>>
>> And, depending on the language, there are other alternatives. Heck,
>> you want C? Any guess how hard it would be to write a new backend
>> for DECUS-C? :-)
>
> Don't need to guess. I've done quite a lot of digging inside DECUS C as
> well. :-)
> Its intermediate code, as well as backend, is very much tied to the
> PDP-11. But atleast it's pretty clean.
> Oh, and most people would be tremendously unhappy with DECUS C. K&R
> style, and no local variables inside blocks...
Most, but not all. :-) If it ain't K&R is ain't C. That's my mantra. :-)
And you have to start somewhere, especially if gcc is so bad.
>
>> And then we also have Algol. :-) And isn't there
>> a Pascal in the DECUS collection? What other languages are languishing
>> on tapes in various peoples storage lockers?
>
> Gha! Swedish Pascal... Another DECUS program. It's actually kindof neat,
> but I tried modifying it a number of years ago as I wanted it to
> generate code that could be run with split I/D space. I gave up. The
> source code for the compiler is horrible, and generated code is even worse.
Yes, but at least you wouldn't need to worry about Split I&D. :-)
>
> I've never played with Algol, so I can't really comment on it.
>
>>>> And,
>>>> there are other options. Again, all of it depends on the model that
>>>> needs to be used. If all the original code were to be released with a
>>>> commercial friendly license one could modify the back-end to support
>>>> the new architecture. If you have to start from scratch then you need
>>>> to start by finding a suitable compiler (and language). And, speaking
>>>> of language, even if the original code was released much of it is in
>>>> PDP-11 Macro and would need to be re-written using the original only
>>>> as a model. That adds the question of what language do you write it
>>>> in? Don't get me wrong, I like C. I am good at C. I do not make a
>>>> lot of the mistakes that C is famous for. But...... I would probably
>>>> not choose C as the language to use for reasons I should not have to
>>>> deliniate here!! :-)
>>>
>>> Good question. I have no idea what I would write in. I love MACRO-11,
>>
>> There is an interesting point in itself. Is there really any reason
>> you can think of that would prevent someone from writting something
>> that took MACRO-11 and output executable code for some other CPU?
>
> Nothing prevents it, except that people in general are not happy with
> assembler, and nowadays it seems like almost noone even understand how
> to program in assembler. It's also a lot slower than writing in a HLL.
> (But the resulting code might be nicer.)
But some of us are still OK with it.
>
>> Isn;t that what was done ont he VMS move to Alpha? Wasn't there a
>> program that could take MACRO-32 and generate Alpha binaries?
>
> Yes. MACRO-32 is still an available compiler, even on Itanium machines.
> (Or so I've heard.)
>
>>> but I'm not sure people in general would want to fool around in
>>> assembler. And I also agree that C is not always ideal. But I don't know
>>> what language I would recommend.
>>
>> PL/I is pretty good. Much of Primos was written in a dialect of it.
>
> Never used PL/I.
>
>> Ada? I understand that has become king in Europe. And I am certainly
>> comfortable coding in it. And with a few decent extensions that can
>> be found in most dialects anyway Pascal is a pretty good system level
>> language.
>
> Ada? King of Europe? Where do you hear such things??? :-)
Well, the only real Ada Conference is now held in Europe (might be
coming up real soon now). Stuff I read from their website seemed
to at least hint that Europe was big on it. I thought ESA did most
of their stuff in Ada. What about Airbus? Isn't the embedded
stuff being programmed in Ada?
> Ada exists, but only among the really obscure places, like the military.
> Where I believe it's also still popular in the US.
Not really. Some contractors still use it, but I don't think there has
been a contract that required it in ages. I know of a lot of embedded
stuff still being done in Fortran.
>
> I should keep quiet about Pascal, I'll become a ranting, raving lunetic.
> Pascal has been used for system level stuff. It's not something I would
> recommend. :-)
> I'd rather do it in Fortran. Not that I'm particularly fond of Fortran...
Some of Primos was done in Fortran, but it always required a lot of
non-Fortran routines in order to do serious system level stuff.
>
>>>>>> All you would really need to develop would be the
>>>>>> support libraries. I am still trying to find the time to dig out an
>>>>>> old version of GCC with the PDP-11 support in it to play with, just
>>>>>> lack the time.
>>>>>
>>>>> Support libraries are also an issue, yes. We need all the Unixy
>>>>> functions,
>>>>
>>>> Eventually. They open up a lot of possibilities. But then, if
>>>> you are re-writting from scratch it makes it a good time to make
>>>> the needed changes and additions.
>>>
>>> Yes. If we do something from scratch, all the options are there. But
>>> other programmers will probable have a hard time to understand how to
>>> use it all. They'd try to write the Unix way, I'm afraid. :-)
>>
>> People can be taught and can learn. I've programmed in a lot
>> of different environments. All of them have advantages and
>> disadvantages. I still believe that if things continue in the
>> direction they seem to be heading now the time will come when
>> necessity will require people taking a new look at things like
>> security and efficiency. Much of what is out there today can,
>> at best, be patched into something that appears to meet those
>> requirements. Something done right is always a better bet.
>> Models and paradigms change constantly. Many things that were
>> abandoned long ago have come back into vogue today. Why can't
>> RSTS and RSX be the next examples? ;-)
>
> Really? Have you actually seen people that have been taught? :-)
I was, but not under the current teaching paradigm. :-)
> I think with time, we will only more and more come to a state where
> people have no clue what goes on under the hood, and the solution is to
> just add more layers. I already see a lot of that. (stream communication
> over rpc, using html, which talks over tcp, which is a stream connection
> - wohoo).
What goes around comes around. Eventually all of this abstraction is
going to come back to bite the industry. And I'll have long reired by
then. :-)
>
>>>>> or else it's pretty useless. :-/
>>>>
>>>> Do your current RSX users find it useless?
>>>
>>> Current RSX users do not have gcc. :-)
>>
>> But the question really is; Is that a minus or a plus? :-)
>
> Depends on who you ask. :-)
>
>>> Very few RSX users even program in C (on RSX).
>>> But the DEC C compiler for RSX does its best to present something that
>>> is Unix-y, including as much of the standard C libraries as possible.
>>
>> Isn't the same true of DECUS-C? (I have it here, but never had the
>> chance to actually set it up and use it. As you said about RSX, I
>> can say the same about RT-11 and RSTS. Never really did any C other
>> than playing with Small-C on RT-11.
>
> To a lesser degree, yes. DECUS C also presents you with an environment
> that taste like Unix. But much less so.
> (In DEC C, you can even do things like getenv("HOME") in RSX, and get a
> reasonable answer.)
>
> And most people never did anything sensible in DECUS C. :-)
What no Rogue?
>
>>> Things that are missing is mainly fork(), select() and pipes. And
>>> anything socket related. But skipping that, you can write a program in
>>> RSX pretty much the same way as on any Unix system. Not that you take
>>> any advantage of anything that RSX is good at, but that was my point.
>>
>> Another reason why I don't necessarily think C is the best choice for
>> a language to use. Too much baggage.
>
> I probably agree.
>
>>> Most typically, that would be such a simple concept as strings for example.
>>
>> Well, I would expect that most any language could use (read: would
>> need) those same string functions. I have a Pascal Compiler from
>> an 80's Z80 system (Alcor Pascal) that has pretty much all the
>> standard C String functions.
>
> Those same string functions? Why? Why would I want a strcpy which copies
> bytes until it hits a NUL character?
Oh, I didn't mean with all the warts. I just meant the functionality. ;-)
The ole' null-termination thing is one reason to avoid C. Now, granted, I
don't have a problem with it, but a lot of programmers just never did
learn that they are responsible for what their program actually does as
opposed to what they think it does.
>
>>>>>>> However, RSTS/E with a Unix RTS would be cool. :-)
>>>>>>
>>>>>> Had that 30 years ago. Like so many ideas it was too far ahead of its
>>>>>> time and, withered on the vine, all the work was lost and now we will
>>>>>> have to re-invent the wheel once again.
>>>>>
>>>>> Cool. I didn't know that anyone had actually done this, even though it's
>>>>> such an obvious thing to do.
>>>>
>>>> OK, to be honest, it was not what you would call an RTS. :-) I was
>>>> refering to one of my pet peeves. The Software Tools Virtual Operating
>>>> System which was probably more of a POSIX-like API than an RTS. But
>>>> the idea was there. Let Unix software run on non-Unix systems. And
>>>> the list of supported systems is mind-boggling!!
>>>
>>> Ah. Darn. I was thinking of a real RTS. Just copy your Unix binary onto
>>> your RSTS/E system, set it to use the right RTS, and then just run it.
>>> That should be very doable (maybe even easy), with the RSTS/E RTS
>>> design. It's a really cool concept.
>>
>> I guess the problem with that would be which Unix? :-)
>
> The ones that were relevant at the time. It gotta be PDP-11 unixes,
> because otherwise the rest of the code wouldn't work anyway. But you
> could have different RTSes for Ultrix, 2BSD, V7 and V6, if needed.
> RTSTS/E make that all possible.
See, I think you have missed the whole point of my side of the discussion.
I am not talking about extending PDP-11 RSTS or RSX. I want to see it
ported to other hardware, primarily, Intel. (Although a 68K port would be
fun, too, as I actually have a couple of 68K boards that go in the QBUS
and access all the devices that the PDP-11 could. :-)
>
>> And even among similar OSes that doesn't always work. BSD has
>> "Linux Compatability" but I have seen more programs that didn't
>> work under it than did.
>
> I know. That's because the compatibility layer is incomplete, and
> because Linux is such a mess that changes behavior from time to time.
>
>> Oh well, as I said, it is all really academic as:
>> 1. I don't expect the source to RSTS or RSX to be released.
>
> Me neither.
>
>> 2. Even if I am wrong about 1. above it is likely to be done
>> under a license that is not commercially friendly.
>
> Not sure about that one.
>
>> 3. Given 1. above it is unlikely that any attempt to re-write
>> RSTS or RSX is ever likely to happen.
>
> If a rewrite took place, 1 and 2 are not really that relevant. You'd
> have to write the whole thing anyway. That's what a rewrite means.
>
>> 4. Even if I am wrong about 3. above it would probably end out
>> being something as stupid as FreeVMS which in the long run will
>> be nothing but a DCLish shell running on top of Linux which is
>> not and never could be any kind of VMS.
>
> That is probably true. It's more or less not possible to translate some
> of the concepts in RSTS/E or RSX into Unix equivalents. Emulating the
> hardware, and then run everything on top of whatever.
And, as long as we have talked of emulation. I wonder if anyone has
ever thought of "modifying" the PDP-11 inside an emulator? Add address
lines. Give it more memory. maybe even make the address space flat. :-)
So many projects, so little time. And to think I thought when I came
to academia that they would support, even push, some of my research
projects. Go figure.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
billg999@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Back to comp.sys.dec | Previous | Next — Previous in thread | Next in thread | Find similar
Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-04-04 09:12 -0400
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-04-30 22:27 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-01 10:01 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-01 10:27 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-01 20:53 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-01 21:16 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-01 20:54 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-01 21:07 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-02 09:37 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-02 08:39 -0700
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-02 05:15 +0000
Re: Y3K for PDP-11 Operating Systems jjh <jjhudak@gmail.com> - 2011-05-02 18:20 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 08:18 -0500
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 12:51 -0400
VAXTREK koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-03 12:50 -0500
Re: Y3K for PDP-11 Operating Systems Henry Crun <mike@rechtman.com> - 2011-05-03 21:39 +0300
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 15:56 -0400
Re: Y3K for PDP-11 Operating Systems onedbguru <onedbguru@yahoo.com> - 2011-05-03 15:52 -0700
Re: Y3K for PDP-11 Operating Systems billig999@cs.uofs.edu (Bill Gunshannon) - 2011-05-04 00:07 +0000
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-04 01:16 -0400
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-04 13:01 +0000
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-04 10:19 -0400
Re: Y3K for PDP-11 Operating Systems kludge@panix.com (Scott Dorsey) - 2011-05-04 10:58 -0400
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-04 16:33 +0000
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-04 21:51 -0400
Re: Y3K for PDP-11 Operating Systems G Cornelius <cornelius@eisner.decus.org> - 2011-05-06 13:08 -0500
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-06 14:47 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@update.uu.se> - 2011-05-06 16:13 -0600
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-07 21:00 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-07 19:51 -0600
Re: Y3K for PDP-11 Operating Systems "Richard B. Gilbert" <rgilbert88@comcast.net> - 2011-05-08 07:19 -0400
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-09 17:32 -0400
Re: Y3K for PDP-11 Operating Systems Rob Brown <mylastname@gmcl.com> - 2011-05-09 09:40 -0600
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 09:43 -0600
Re: Y3K for PDP-11 Operating Systems vandys@vsta.org - 2011-05-09 21:47 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 16:05 -0600
Re: Y3K for PDP-11 Operating Systems vandys@vsta.org - 2011-05-09 23:05 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 17:20 -0600
Re: Y3K for PDP-11 Operating Systems vandys@vsta.org - 2011-05-10 00:12 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-09 19:36 -0600
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-10 02:01 +0000
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 08:31 -0500
Re: Y3K for PDP-11 Operating Systems John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-10 09:56 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 12:50 -0500
Re: Y3K for PDP-11 Operating Systems G Cornelius <cornelius@eisner.decus.org> - 2011-05-11 11:04 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-04 10:02 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-04 12:20 -0500
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-04 18:10 +0000
Re: Y3K for PDP-11 Operating Systems John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-04 12:21 -0700
Re: Y3K for PDP-11 Operating Systems MetaEd <metaed@gmail.com> - 2011-05-04 15:06 -0700
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-04 20:17 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 08:20 -0500
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 08:29 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-10 09:29 -0600
Re: Y3K for PDP-11 Operating Systems G Cornelius <cornelius@eisner.decus.org> - 2011-05-10 12:16 -0500
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 12:45 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-10 15:34 -0600
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-10 12:58 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-10 15:36 -0600
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 12:38 -0400
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-03 11:28 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-03 12:09 -0400
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-23 03:41 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-22 21:51 -0700
Re: Y3K for PDP-11 Operating Systems jjh <jjhudak@gmail.com> - 2011-05-23 07:47 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-23 15:04 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 15:52 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 00:16 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 17:40 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 12:58 +0000
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-24 14:02 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 07:36 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 16:42 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 11:17 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 20:07 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-24 21:07 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 03:34 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-25 15:46 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 16:00 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 17:50 +0200
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 09:53 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 22:20 +0200
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-28 18:01 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-25 20:58 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-26 01:23 +0000
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-26 08:01 -0500
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-27 00:54 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-26 16:15 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-26 23:56 +0000
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-27 14:37 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-27 00:02 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 20:17 -0700
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-27 14:51 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-27 12:48 -0700
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-27 14:35 -0400
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 21:14 -0400
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-26 01:32 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-26 16:39 -0400
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 17:50 +0200
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-24 21:01 -0400
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-26 07:53 -0500
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 09:59 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-26 10:03 +0200
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-26 14:21 +0000
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-26 18:50 +0000
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-27 11:58 +0000
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-27 17:23 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 10:04 -0700
Re: Y3K for PDP-11 Operating Systems Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> - 2011-05-27 03:30 +0200
Re: Y3K for PDP-11 Operating Systems kludge@panix.com (Scott Dorsey) - 2011-05-26 22:17 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 20:26 -0700
Re: Y3K for PDP-11 Operating Systems John Wallace <johnwallace4@yahoo.co.uk> - 2011-05-30 14:09 -0700
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-30 18:15 -0700
Re: Y3K for PDP-11 Operating Systems jjh <jjhudak@gmail.com> - 2011-05-31 11:02 -0700
Re: Y3K for PDP-11 Operating Systems koehler@eisner.nospam.encompasserve.org (Bob Koehler) - 2011-05-31 15:54 -0500
Re: Y3K for PDP-11 Operating Systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2011-05-31 21:37 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-24 22:59 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 03:51 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 08:36 -0400
Re: Y3K for PDP-11 Operating Systems "Tom Lake" <tlake@twcny.rr.com> - 2011-05-25 13:25 -0400
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 14:01 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-25 11:44 -0700
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-25 21:20 -0400
Re: Y3K for PDP-11 Operating Systems Rob Brown <mylastname@gmcl.com> - 2011-05-26 10:53 -0600
Re: Y3K for PDP-11 Operating Systems Rich Alderson <news@alderson.users.panix.com> - 2011-05-26 16:27 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 20:27 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-26 16:38 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-26 21:44 -0700
Re: Y3K for PDP-11 Operating Systems paramucho@hotmail.com (paramucho) - 2011-05-24 12:02 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-23 10:48 -0400
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 15:46 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 00:19 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-23 17:43 -0700
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 14:41 -0400
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-24 02:54 +0000
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 13:03 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 07:39 -0700
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-24 15:10 +0000
Re: Y3K for PDP-11 Operating Systems Johnny Billquist <bqt@softjar.se> - 2011-05-24 08:48 -0700
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 16:54 +0000
Re: Y3K for PDP-11 Operating Systems billy@MIX.COM - 2011-05-24 14:42 +0000
Re: Y3K for PDP-11 Operating Systems billg999@cs.uofs.edu (Bill Gunshannon) - 2011-05-24 16:56 +0000
Re: Y3K for PDP-11 Operating Systems "Jerome H. Fine" <everyone@nospam.com> - 2011-05-25 14:05 -0400
csiph-web