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-25 15:46 +0000 |
| Organization | Computing Sciences Dept., University of Scranton |
| Message-ID | <944mhrF19qU1@mid.individual.net> (permalink) |
| References | (10 earlier) <irgfp7$382$1@Iltempo.Update.UU.SE> <9425gcFhnpU1@mid.individual.net> <irgsnm$7ov$1@Iltempo.Update.UU.SE> <942hghFhukU1@mid.individual.net> <irilvv$p6t$1@Iltempo.Update.UU.SE> |
Cross-posted to 3 groups.
In article <irilvv$p6t$1@iltempo.update.uu.se>, Johnny Billquist <bqt@softjar.se> writes: > Oh, boy. This is getting to be long posts... > And there isn't that much I can trim, since I have comments on most of > the stuff... :-/ Amazing how much opinions can vary on some of this stuff. > > On 2011-05-24 13.07, Bill Gunshannon wrote: >> In article<irgsnm$7ov$1@iltempo.update.uu.se>, >> Johnny Billquist<bqt@softjar.se> writes: >>> 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. > > Hmm. I hadn't thought about that aspect explicitly, but you got a point. You have to admit it is interesting how so many people (professionals, not geeks and nerds) complain about the problems; security, performance development conmplexity, etc. in both Windows and Unix and yet there is little effort (none in academia where one would expect people with time and resources for research) to come up with alternatives. Don't get me wrong, there was, but sadly just about the time any of these started getting close to being usable the creators lost interest and walked away. Plan-9 and Amoeba come immediately to mind. > >>>>>>> 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? > > I'd say none of them are up to date. And the reason being that no one > really cares enough to do the work. It can obviously be done. Actually, I think there are multiple reasons of which that is only one and possibly not a real concern. First would be the lack of interest of the owners which results in VMS changes not making it into the base code resulting in having to re-do it everytime a change occurs. Second would be the application being so tightly coupled to Unix that making the necessary changes for VMS is difficult if not impossible. And then after doing it for version 1.0 version 2.0 comes out with a change that totally invalidates your previous VMS work. I think from the VMS side there is a strong desire to have a lot of the Open Source stuff but there is a definite lack of people with the needed cross-platform skills to actually make the ports work. Most of the stuff you see that works are simple data manipulators like ZIP. emacs being the one exception, but then, it is probably the most ported package ever. I have seen versions of Emacs on more machines than anything else, ever. > >>>> 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. > > Oh well. MUMPS is not something I've ever used, or even seen myself. > Can't blame me for not having all the facts straight there. :-) It's another light under a basket. > >>>>>>> (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. > > No, unless I remember wrong, it was there before that. Unfortunately, I > don't have any dates for it, but I suspect it might almost trace its > roots back to V1. Actually, RSX have it too, for RMS. But since FCS > don't support it, noone ever uses it, and you hardly ever see a file > with those attributes. But I've tested it just to check, and it works > just fine in RSX too. > (Although the RSX support is somewhat more limited, in that there are > only STREAM files, not both STREAM_LF, STREAM_CR and god knows what > other variants). OK. I thought it was a later addition as things like RMS pre-date even VMS so I figured Digital always leaned toward structured files. > >>> 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. > > There are several. For different needs. But berkely db is one pretty > common part. > But since this needs to be done by libraries, there is no standard, and > no common concept. Nor any ability to manage such files in any sensible > way outside of that program. I never thought of Berkeley DB as more than a poor man's ISAM. To be honest, giving it a little thought as we have been going over this I would guess one of the reasons Unix never had anything like RMS is because it had DB capabilities from early on. Ingres was one very early option. > > And no, not everything is a stream of bytes. There are plenty of > examples of devices which are record oriented, and for which Unix tries > to hide this from the users. Disks are the most common example. Disks at > the lowest level always deals with blocks. Tapes is another, where tapes > have records, but they are of variable length. > And punched cards is yet another example. :-) > Heck, ethernet is not a stream of bytes either, but frames or variable > length between 64 and 1500 bytes. > > So, no, I don't really think it necessarily makes sense. OK, I guess that is another point of view thing. While i agree that disks tend to be blocked they do deliver the raw data when asked and the actual sectoring never makes it off the disk. As for tape and ethernet, even the blocking data is just other byte values. Now, card, there is the anomaly. But I guess in the long run regardless of what the card looked like the date was delivered as single characters. (I really wish I could get a card reader for my collection!!) > >>>>> 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? > > Probably. Developers don't want to develop for several different OSes. > It's costly. Better to just have to develop for one. So it would > converge over time anyway. And I don't think it would go much different > even if you had had more options for OSes on x86 architectures. Hmmm... I guess this is the result of another trend in the modernization of IT. The move from locally written and maintained applications to canned, generalized applications. I wonder when that pendulum will swing back the other way? I have already been to many places that complan loud and long about how these canned systems do not meet their needs but as yet no one is go ing back. > >>>> 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. > > I might be wrong about that one, then. I have never seen it, never seen > it mentioned anywhere, nor ever seen anyone ask for any competence in > Mumps, I have seen some rather high paying jobs offered that required ANSI-M experience. I, too, had thought Mumps was long gone but a little research really opened my eyes. It is actually my desire to move on to something better than I have now for that last big leap before retirement (I really would like to go back to being an applications programmer and especially if it were with COBOL) that caused me to look into just how marketable my old skills are. I have been uterly amazed at how much of the IT world is not what you read in The Register or Infoweek. > so I just assumed that it is dead. But you are right, it might > very well have a niche market somewhere. Cool in that case. Interesting that it started in one niche and actually expanded to several others when a lot of systems were being squeezed into one or out entirely. > >>>> 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. > > COBOL is not dead. That is not what I said. I just said that no *new* > programs are written in COBOL. As in from scratch. Lots of code still > get written. But its for existing systems. Well, I guess it depends on what you consider new. To my way of thinking if it isn't maintenance it is new. A lot of the places still using COBOL get new requirements for doing business every day and that requires new programs to manipulate the data and generate reports. yes, it is in support of an existing business but the code is all done from scratch and requires going thru the SDLC just like anything else. And, of course, the maintenance end of COBOL is going to be around long after I am dust. > >>> (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? > > Why would there be a need? An X server is just for handling a display. > There are plenty of X servers already. There is very little need to > implement any new X servers. Clients, on the other hand... Problem of clarity. Not sure i actually said "server" but either way what I meant was X-11 as a system so that one coud use X to access RSTS applications and RSTS applications could display on X. Then we could have Open Office on RSTS, too. :-) > >>> 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. > > No denying that they backed the wrong horse. But there is also no > denying that VMS can run on pretty current hardware. You have gigabit > ethernet, graphics, lots of memory and disk, and pretty fast CPUs. So > for practical purposes, for VMS you have modern hardware. It's not > making any difference. People still do not write much software for VMS. The question is why? I think the reasonm we see less and less VMS software available is that outside its own little clique the world thinks it is dead. And its owners are doing nothing to counter that perception. I have said it before and I will say it again. "Perception is Reality". Just as another point of curiosity, I have copies of one of the last Software Sourcebooks for the PDP-11 (two volume set!!) and one from the hey-day of the VAX VMS era. The PDP-11 had more. Why did they all suddenly go away? Because DEC said "RSTS/RSX/RT is dead, long live the VMS". That's the nature of things. people stop developing for systems that they see no future in. But, again, it was not any shortcoming int he OSes that led to this it was shortcomings in the hardware. Too bad DEC didn't just deicde to continue with products called RT-32, RSTS/32 and RSX32+. :-) I would bet those OSes would have ported really well to the VAX. > >>> You even have X11. >> >> An ancient version that has not been kept up. > > I haven't checked lately, but just because it's not Xfree86 with all its > bells and whistles, don't mean that it don't work just as well anyhow. A lot of modern X software will not port to that odl aversion. But then that has always been the bane of VMS. > >>> 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). > > It wasn't a question of capabilities, but of applications. Unix is > trying to emulate Windows as far as applications go, and it's never > going to beat Windows at its own game. KDE, OpenOffice, and all that > cruft... Not going to get people turning their heads in any real way. I don't know about that. A couple of high-profile cases have already hit over here and I know one customer in particular whou could have a major impact. And may be forced into it for purely financial reasons. And has the ability to drive change by other people who aren't willing to back away from the money trough. > >>> 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. ;-) > > What perfectly good Office Suite are you refering to? Open Office is not > good enough. I've used it, and it has some incompatibilities with MS > Office, which will bite you. Wait a minute here. Are we arguing "perfectly good" or "perfectly MicroSoft"? I do know of a few incompatabilites but they are avoidable and if you are willing to not ride MS's coat-tails it is fine. And it is much more compatable than it was 5 years ago. ;-) > And then you get upset because you do not > get the same result as the same document viewed under MS Windows, and > you basically come to realize that you need MS Office. Or you come to the realization that you need to get others off MS Office. All depends on who is driving the bus. All it would take is a couple of places in control to make the move and others will be forced to follow. And I know of a couple really large organizations who are in the right position to drive the bus rather than just riding it. > >>> 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. > > There were word processing and other stuff available for RSX. But it > wasn't pretty enough. People started wanting very graphical interfaces > to those things, and at that point it became a question of the hardware > couldn't do it. Well, as far as I, and I would imagine most people today, are concerned if it isn't WYSIWYG it isn't a "word processor" it is a document processor. (I still have a professor here, and not some old guy, one of our youngest, who still does all of his academic stuff in LaTex!) > Apart from that (well, and speed), even the old PDP-11s could handle it > just fine, yes. > > Not sure what the point was here, though. I believe the big issue was/is > that nobody really saw a market in developing and maintaining such > software for RSX (for example), which caused such software to cease to > exist. And that caused RSX systems to become less viable. I see it the other way around. there was a rather large Sourcebook for all the PDP-11 OSes. All that software went away in a very short period of time that just happened to coincide with DEC giving up on the PDP-11. The same thing VMS people are seeing today. HP shows no interest in VMS and everyday more and more VARs are moving on to other platforms. > > In my opinion, having the applications is all that counts. If you have > them, people will run the system. They don't care how the OS really > looks like. If you don't have the applications people need/use, they > will not use the OS, no matter how the OS looks like. Agreed. And I have said that at least twice in this conversation. But, in order to have applications you really need two other things. The hardware needs to be capable of handling the demands of what are constantly growing applications and the developers have to see a future for their work. If the OS vendor doesn't present the perception of a future, people will assume there is none and will invest no effort in continued products. And, getting back to the original idea (at least for me) in this whole thread, given a number of possible corolaries is there any possibility that a premise can be derived that showed a renewed possible future for something like RSX or RSTS? A stretch at best, but the IT world is very fickle and it is hard to tell what will fly tomorrow. I would have fun just doing the OS porting part and as I near retirement I get closer and closer to actually having the time to do it. There is no doubt I have the computing resources both old and new. :-) All that remains to be seen is wether or not I am going to have to start from scratch or if I am going to get to just pick up where DEC/Mentec left off. > >>>>> 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. > > A doubling of data should not be enough to push something over the limit > of what can be handled. > A doubling of a significant part of a lifetime is not what I'd call any > larger change. Well, looking at the PDP-11 again (as that's are subject case) what happens when the records you need to work with at any pointin time exceed 64K? I can assure you that 30 years ago when I was doing COBOL/DMS-11 full-time we had record descriptions in our working storage that the PDP-11 could never create. I expect there are many applications today that deal with even larger datasets. Yes, you could probably deal with them in smaller chunks, but that is not what the customer wants. :-) > >>> 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. > > RSX is really pretty neat, clean and nice already. There is not much > that I actually thinks needs to be fixed with it. Not with the hardware > platform. Even more proof that the demise of these OSes was probably unnecessary and they could have had continued lifetimes. > >>> 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. :-) > > One reason why Unix had such an easy migration path was because of no > assembler. Neither for the OS itself (more or less), but more > importantly for the applications. You had to recompile, but that was > about it. And I see no problem with that. If RSTS/RSX had been made available on the VAX instead of that upstart VMS thing (do I sound like JF now?) we would have had that big two volume sourcebook of applications that could have continued to be developed and we wuold not have had to abandon all of it and start again from scratch. Again, just out of curiosity, you have used both VMS and RSX, correct? Forgetting the hardware shortcomings, just what advantage does VMS have over RSX-M+? I can't think of anything it has over RSTS/E that couldn't have been added given the new hardware capabilities with much less effort and for a much lower cost than writting a whole new OS. > For RSX, that would be more difficult, even if you regarded MACRO-11 as > a language for which you have a compiler. > Because of the way the system works, RSX programs in general are more > tied into the system than similar Unix programs, making it harder to > port them, even to a system using the same design. So many fields, > pointers, ids and so on which would need to change. > It would be complex to even have a compatibility mode. > > RSX have way less abstraction than Unix do. Good in some ways, bad in > others. For porting, abstraction is very good. For efficiency, > abstraction is bad. > (But I'm sure you know that.) Not the specifics of RSX as I never got beyond the user level but I understnad what you are saying. But I still think porting was not only possible (especially for the initial move tot he VAX, to x86 today would likely be much more difficult) but would have been justifiable froma business standpoint. But we all know that by that time it was more politics than technical fact that drove decisions. (Just like what is keeping MS on top today. It is hardly technical superiority!!) > >>>>>>> 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. > > Probably, yes. > >> 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. :-) > > Source level compatibility for atleast RSX would be difficult, I think. > There is just so much more information from the OS that leaks out to > programs. That surprise me. I can see where emulation and compatabilty modes might be difficult, but I would have thought that programs written in HLL's would be fine. Of course applications in MACRo would be real show-stoppers. And they were still very common during the PDP-11 hey-day. > >>> 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? > > First of all, Unix was an already existing OS, which CSRG just picked as > a good choice for doing research on. Yes, an already existing OS that was, by law, not commonly available. And in the cases where it was made avaialble the price was prohibitive. I wasn't there so i am just speculating but I think this forced lack of availability is what made the CSRG pick Unix. Because they were not a business they could get it cheap. Because it was not commercially viable they could do pretty much anything to it (and they did!!) > CSRG was doing research. That is a > different ballgame. Research really don't relate to "need" in the same > way. Research is done for its own purpose. No other need is required. > > And research itself wasn't about how to just get Unix running, but it > was just a platform on which to try implementing new ideas and concepts > that they came up with. > True. But I think it was probably not to long into the research when people started seeing the potential this research had. And the fact is it could have been any OS. And the result would likely have been the same. Had they picked RT-11 and come to a similar agreement with DEC that they had with AT&T we would be running BSD/RT today and it would be multi-user, multi-tasking with full networking. :-) What a different world that would have made!!! >>> 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. > > I doubt very many (if any) would write for other systems. Any commercial > developer is going to write for the platform where he sees the most > customers. The platforms merits are irrelevant (more or less). I guess it depends on where one sees the niche for RSX/RSTS being. Just like VMS, I don't look into my crystal ball and see it on every desktop. But, just like OS2200 and zOS, I can see them as very viable candidates for the datacenter instead of things like Windows Server 2003 and 2008 which like NT are really just desktop OSes with some of the user cruft hidden away. > >>> 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. > > You do know that Android is just Linux, right? Yet another plaform > following the Unix paradigm. I know it is Linux under the hood, but again, the level of abstraction is even greater. I do not know if students learning "Android Programming" actually know (or care) that it is just Linux. Kind of like trying to tell a Mac fanatic that he really is just running BSD. :-) > >>>> 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. :-) > > If you want to be source compatible, then yes. You could ignore split > I/D space. However, most modern computers are not very happy with mixing > code and data. It messes up caches, and can even cause unexpected > results. So in general, all modern machines requires a kind of split > between instructions and data for different reasons than why you did it > on a PDP-11. Yes, but outside the PDP-11, when was the last time you actually had to worry about it as a programmer? Or figuring out overlays. Now there was a science!! > >>>>>> 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. > > That is a very small number. > >>>> 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? > > Most is in C, or getting into C++ nowadays actually. (Ewwww) > I have not seen anyone mention Ada in quite a number of years now. Intersting as I just recently got invited to the Conference and, no, the University won't fund my attending. :-( > >>> 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. > > Sounds like a similar scene, then. > >>>>> 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. > > But that is what gcc provides for you. It sees you calling strcpy, and > instead of generating code that actually calls strcpy, it will really > put in code that implements strcpy for you, at that point in your code. > With the semantics that C and Unix have for strings. > >>> 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. :-) > > Well, for such a port, obviously it would be cool with RTSes for current > Unix dialects. Now that I think i see what you mean, you're right. But I wonder if it could be done. I guess you could always try making an Ultrix-11 RTS as a proof of concept. Now, if I only had a legitimate RSTS system to play with. :-( > >>>> 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. :-) > > No can do without very serious brain surgery. A lot of OS design details > depend on the size of physical addresses. And there are no free bits in > there. So to extend the physical address means redesigning the bit > layout of the MMU registers. That will carry a big change everywhere. > Not to mention that you'd need to change all devices to have new bits > for DMA addresses. Which means you'd have to change all device drivers > that do DMA. > Changing the virtual address space is perhaps even more exciting. That > means expanding the word size of the machine. That will break just about > everything. > > Did you know that the memory bus on the PDP-11/70 already specifies a > 24-bit physical address. But the PDP-11/70 always holds the high two > bits to zero. But you could theoretically have expanded the physical > memory to 16MB there. But once more, that would have meant changing the > bit fields in the MMU registers, which would have broken a lot of code. > > RSX have a provision for this, but it never have much practical > importance. In all the MMU-related system calls, you can specify if your > pages should aligned on 64 byte boundaries, or 256 byte boundaries. With > 256 byte boundaries, you would actually be able to accomodate two more > physical address bits. I guess I worded that wrong. What I would make wouldn't really be a PDP-11 any more. I would want something with greater capabilities that still had the PDP-11 Instruction Set. But, your right about the devices. I had been thinking strictly aboutt he CPU and had not looked at otehr stuff. Of course, it is interesting that most of those same devices worked with the VAX which had a totally different address map so it is probably doable. > >> 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. > >:-) I sure would enjoy meeting you someday. We must be pretty close in age. The conversations we could have over tall mugs of pilsner!! 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