Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.dec > #218 > unrolled thread
| Started by | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| First post | 2011-04-04 09:12 -0400 |
| Last post | 2011-05-25 14:05 -0400 |
| Articles | 20 on this page of 143 — 22 participants |
Back to article view | Back to comp.sys.dec
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
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | paramucho@hotmail.com (paramucho) |
|---|---|
| Date | 2011-05-03 11:28 +0000 |
| Message-ID | <4dc1e27c.40366475@news.tpgi.com.au> |
| In reply to | #218 |
On Mon, 04 Apr 2011 09:12:48 -0400, "Jerome H. Fine" <everyone@nospam.com> wrote: >Is there any interest in extending any of the PDP-11 operating systems >so that they are able to support dates at least until 3000? While my >personal interest lies with RT-11, I am curious if anyone has looked >at the requirements for any of the other PDP-11 operating systems >to determine what is required for Y3K date support? In addition, >are the resources (technical knowledge, files to make the required >changes and hardware to support the development) available? My notes here refer to RT-11-based systems only. RSX and RSTS present different sets of issues. The original RT-11 date field was Y2K-expanded from 5-bits to 7-bits extending the original 1972-2004 field to 1972-2099. These operating system extensions are available in RT-11 V5.7, RUST/SJ and via user modifications. RUST/XM also has the extensions but has not been released. I am not sure whether TSX/plus had a Y2K update. RUST and TSX do not include many of the significant RT-11 applications such as MACRO and LINK. Patches for some of these utilities have been made available separately. Without the patches the only problem is usually garbeled dates in listings. There was at least one operational issue, but it was easily resolved. TSX and RUST systems also (compatibly) implement a time-of-day field in RT-11 directories. The time-of-day, in seconds, is divided by three to fit into a 16-bit word, along with a flag bit. RT-11 V5.4 and RT-11 V5.5 were the last two really successful releases of the mother system. V5.6 had very little take-up IIRC, indeed, I seem to remember the RT-11 team being disappointed at the time. V5.7 was the MENTEC Y2K maintenance release--I doubt that it is very widespread. Thus, my guess is that most systems running DEC RT-11 today probably have incorrect date information being displayed. With MENTEC gone the original version of RT-11 has been orphaned. If RT-11 is ever placed in the public domain then I think we will probably see binary kits and documentation become freely available, and perhaps even sources. At present that is unknowable to this writer. But, in any case, we are clearly not going to see the date issue resolved in a future release of RT-11. I suppose it is conceivable that RT-11 might still be in real use in 2099 at a handful of sites, however, if that is the case then they will almost certainly be turn-key systems running a dedicated application and will not be affected by a nonsense date (and, indeed, probably already have nonsense dates today). Thus, I don't think there is much need to worry about real-world RT-11 use in ninety years time. There is, however, another reason to keep RT-11 systems ticking along and that's because of the role played by DEC operating systems in the history of computing. The argument that people who know the system in some detail are best placed to do the maintenance work is valid. So, assume we want to run RT-11 post-2099. Two solutions suggest themselves. The first solution is to extend the RT-11 date field. This would have typically been implemented by adding an extra word to the date field, extending the date by 2^16 years. The system API would have been extended to handle the getting and setting of the extended date. An additional word would have been added to RT-11 directory entries, perhaps flagged in the directory status word that was added in V5.6 (I think). All the utilities would have been updated. Users would have been responsible for their own applications. Now, let's assume that we do all this (even if it is at this more or less impossible). Would that actually help the "real use" folk? I think not. First, most of them would never find out that an updated version were available. Second, many of them would no longer be able to modify there own applications. There would be a significant amount of work to do in implementing the date extension, but there are two more serious problems. The first is that the code would probably never be properly tested by an audience of a reasonable size. The second is that even if the project were completed there is no way to establish the date extension as a "standard" in some sense. It would remain essentially private code. The second solution is to recognise the need to provide managed environments for historical systems such as RT-11. This is easy in emulators where it is just a matter of faking the date information passed to an operating system (if the emulator supplies that functionality). Even if the idea of extending the RT-11 date seems attractive (and I looked at idea in detail when doing the Y2K stuff to the RUST systems), in practical terms it would probably be a wasted effort. Thinking about how emulators might be better able to preserve and extend the lives of historical operating systems by providing managed environments would be more productive IMO. Ian
[toc] | [prev] | [next] | [standalone]
| From | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-05-03 12:09 -0400 |
| Message-ID | <4dc028fc$0$311$14726298@news.sunsite.dk> |
| In reply to | #355 |
[Multipart message — attachments visible in raw view] — view raw
If anyone else (other than Ian) has anything to suggest or opinions on Y3K, their suggestions and comments will be greatly appreciated - even if they are negative comments as some of Ian's are concerning Y3K, in particular for RT-11. One minor point with version numbers for RT-11. Officially, the version number is V05.07 for RT-11. However, many individuals use V5.7 and both are acceptable and mean the identical release. TSX-Plus uses V6.50 for the version number and both digits are required. The next minor release would be V6.51 of TSX-Plus. When Y3K is added, I suggest that V05.08 be used for RT-11 and V6.60 for TSX-Plus. >Ian Hammond (paramucho) wrote: >>On Mon, 04 Apr 2011 09:12:48 -0400, "Jerome H. Fine" wrote: > >>Is there any interest in extending any of the PDP-11 operating systems >>so that they are able to support dates at least until 3000? While my >>personal interest lies with RT-11, I am curious if anyone has looked >>at the requirements for any of the other PDP-11 operating systems >>to determine what is required for Y3K date support? In addition, >>are the resources (technical knowledge, files to make the required >>changes and hardware to support the development) available? >> >My notes here refer to RT-11-based systems only. RSX and RSTS present >different sets of issues. > > Actually, other than the fact that the dates (when various portions of the code which handles the date) breaks, I suggest that the issues are essentially the same. At some future year, (2100 for V05.07 of RT-11), the date will not be handled correctly. >The original RT-11 date field was Y2K-expanded from 5-bits to 7-bits >extending the original 1972-2004 field to 1972-2099. These operating >system extensions are available in RT-11 V5.7, RUST/SJ and via user >modifications. RUST/XM also has the extensions but has not been >released. I am not sure whether TSX/plus had a Y2K update. > V6.50 of TSX-Plus also supports the date until 2099. The only change to the date code was in the Resident Monitor (well also in the KMON equivalent which displays and sets the date) for the rollover from year to year. The EMT requests, .DATE and .SDTTM were essentially unchanged. The rest of the TSX-Plus code uses the standard DEC utilities. If Y3K support is produced for RT-11, then it will be a small additional effort to add Y3K support for TSX-Plus. >RUST and TSX do not include many of the significant RT-11 applications >such as MACRO and LINK. Patches for some of these utilities have been >made available separately. Without the patches the only problem is >usually garbeled dates in listings. There was at least one >operational issue, but it was easily resolved. > > Most RT-11 users are not aware, but the V05.06 release of MACRO.SAV in V05.06 of RT-11 in 1992 was already Y2K compliant. However, since only the last two digits of the year were displayed for the date, it was not apparent until January 1st, 2000 that was the case. The file MACRO.SAV released with V05.07 of RT-11 is identical to the MACRO.SAV released with V05.06 of RT-11, as are many of the other SAV files which did not have any date dependencies. For most users of MACRO.SAV, the primary bug (no support for running as a system job when a cross-reference table is requested) is not a problem. However, prior to V05.06 of RT-11, when a cross-reference table was requested or some of the device drivers were not loaded, running MACRO.SAV as a virtual job (using VBGEXE to initiate MACRO.SAV) was not always successful. These problems have been fixed, but the documentation is not complete. >TSX and RUST systems also (compatibly) implement a time-of-day field >in RT-11 directories. The time-of-day, in seconds, is divided by three >to fit into a 16-bit word, along with a flag bit. > > What is the flag bit used for? >RT-11 V5.4 and RT-11 V5.5 were the last two really successful releases >of the mother system. V5.6 had very little take-up IIRC, indeed, I >seem to remember the RT-11 team being disappointed at the time. V5.7 >was the MENTEC Y2K maintenance release--I doubt that it is very >widespread. Thus, my guess is that most systems running DEC RT-11 >today probably have incorrect date information being displayed. > > Actually, V05.06 was a significant improvement over V05.05 of RT-11, but I doubt that many programs use split I/D virtual space. The use of virtual jobs is must more transparent and the problem of running MACRO.SAV / CREF.SAV as virtual jobs when device drivers need to be loaded has also been solved. Users of previous releases of RT-11 still have those problems and the code in the versions of MACRO.SAV from prior releases of RT-11 has been fixed as well, just not released until the documentation is complete. >With MENTEC gone the original version of RT-11 has been orphaned. If >RT-11 is ever placed in the public domain then I think we will >probably see binary kits and documentation become freely available, >and perhaps even sources. At present that is unknowable to this >writer. But, in any case, we are clearly not going to see the date >issue resolved in a future release of RT-11. > > I assume then that you have decided to avoid adding Y3K code to RT-11. That might not be the case with everyone else, especially since the individual writing this response has the clear intention to add Y3K code to RT-11. In fact, the intention of starting this thread is to request comment from interested parties. >I suppose it is conceivable that RT-11 might still be in real use in >2099 at a handful of sites, however, if that is the case then they >will almost certainly be turn-key systems running a dedicated >application and will not be affected by a nonsense date (and, indeed, >probably already have nonsense dates today). Thus, I don't think there >is much need to worry about real-world RT-11 use in ninety years time. > > I agree. From the real DEC PDP-11 side of the fence, it seems obvious that there will be almost no real DEC PDP-11 hardware still in operation. It also seems doubtful that Ersatz-11 will still be supported in 89 years, certainly not by John Wilson. And I will not be here to support RT-11 after 2099. However, SIMH is written in "C" and will probably still be running. There just might be a few commercial sites which still want to run RT-11 and find that SIMH is a reasonable solution. For hobby users, the situation is somewhat different. Academic investigation of 16 bit CPUs may also maintain some interest in RT-11. It is possible that DEC was the primary cause of the PDP-11 falling by the wayside as VMS took over most of the resources at DEC. A much faster version of the PDP-11 CPU was produced by QED, but probably never sold enough to become popular. Plus, with DEC no longer a functioning company, there was no longer any commercial focus to support the PDP-11 operating systems and make any enhancements, let along bug fixes. >There is, however, another reason to keep RT-11 systems ticking along >and that's because of the role played by DEC operating systems in the >history of computing. The argument that people who know the system in >some detail are best placed to do the maintenance work is valid. > > Well, we do agree on this point!!!!!!!!!!!!!!!!!!!!!!!!!!!! >So, assume we want to run RT-11 post-2099. Two solutions suggest >themselves. > >The first solution is to extend the RT-11 date field. This would have >typically been implemented by adding an extra word to the date field, >extending the date by 2^16 years. The system API would have been >extended to handle the getting and setting of the extended date. An >additional word would have been added to RT-11 directory entries, >perhaps flagged in the directory status word that was added in V5.6 (I >think). All the utilities would have been updated. Users would have >been responsible for their own applications. > > The directory status word has been present in the very first version of RT-11. If you refer to a word in block 1 of a file structured device, it was just unused. If you refer to the file entry in the directory segments, then that word has been in use starting with the very first version of RT-11. The minimum number of words in each file entry is SEVEN, with 3 words (in Rad50 used for file name and type), the length of the file in blocks, the file creation date and that first word as status information about the file. The seventh word is used by RT-11 and TSX-Plus when a file is tentative in one manner - TSX-Plus uses the word as the creation time when the file is permanent. RT-11 ignores the word when the file is permanent. Since the 16 bit word which specifies the date is now fully utilized, you are correct that additional bits will be required. I agree with your proposal that an additional word be used for the Creation Date AND that the status word for the file entry be flagged to reflect that additional information. Actually you would have flagged the entire directory, but I suggest that it be done on a file by file basis so that old software prior to 2100 is still able to function. Obviously, users with programs which handle the date would be required to change those programs. That has always been the way. However, I also propose that all of the new software be compatible with the old software so that any old programs can use dates in the same manner after 2099, they just will not notice that the date is 2100 rather than 1972, etc. >Now, let's assume that we do all this (even if it is at this more or >less impossible). Would that actually help the "real use" folk? I >think not. First, most of them would never find out that an updated >version were available. Second, many of them would no longer be able >to modify there own applications. > > We start to disagree at this point. I believe that your points are reasonable, just that they are not as valid as you believe. >There would be a significant amount of work to do in implementing the >date extension, but there are two more serious problems. The first is >that the code would probably never be properly tested by an audience >of a reasonable size. The second is that even if the project were >completed there is no way to establish the date extension as a >"standard" in some sense. It would remain essentially private code. > > Actually, if only one person writes the code for the date extension, that will automatically become the standard. I agree that getting the word out will take a while, but over the next 89 years, it should be possible to provide that information for interested parties. The only real difficulty is that any code which is developed in the next 20 years will not be commercially useful since companies refuse to pay for a solution to a problem which is still more than 50 years in the future. So the code will have to be done for hobby users. As for testing, there is not much to really test. All of the code is for the CPU and the locations for the code are the same as was done for V05.07 of RT-11 when the Y2K bugs were fixed. In addition, the CE (Commercial Events, Common Era, Christian Era or Gregorian - choose based on your religious preference) Calendar has a 400 year cycle. There are 146097 days or exactly 20871 weeks of 7 days each. Dividing the year by 400 and using the remainder along with the month and day number produces the day of the week for all 400 year cycles. The code can easily be run 146097 times to test for each result. And the code would not remain private if V05.08 is released to all users. In fact, it would then become to standard. >The second solution is to recognise the need to provide managed >environments for historical systems such as RT-11. This is easy in >emulators where it is just a matter of faking the date information >passed to an operating system (if the emulator supplies that >functionality). > > A reasonable second solution which many RT-11 sites adopted rather than purchase V05.07 of RT-11. 28 years is sufficient to handle all dates until 2099. Since 2100 is NOT a leap year, that solution breaks down a bit. >Even if the idea of extending the RT-11 date seems attractive (and I >looked at idea in detail when doing the Y2K stuff to the RUST >systems), in practical terms it would probably be a wasted effort. >Thinking about how emulators might be better able to preserve and >extend the lives of historical operating systems by providing managed >environments would be more productive IMO. > You may be correct and probably are. However, I find I have more fun working with RT-11 code. Even if no one else provides any support, I may be able to complete enough of the Y3K for RT-11 that it becomes the standard. If anyone has any suggestions, they will be appreciated. Ian, if you think it would be worth while to add the same Y3K code to RUST so that the standard is compatible, please add your input and suggestions. The design is certainly far from frozen. Although I have added Y3K code to MACRO.SAV, I realize that the form of output from the .GETD (Get Extended Time and Date) EMT request could change. Jerome Fine
[toc] | [prev] | [next] | [standalone]
| From | billy@MIX.COM |
|---|---|
| Date | 2011-05-23 03:41 +0000 |
| Message-ID | <ircl1k$5a1$1@reader1.panix.com> |
| In reply to | #355 |
In vmsnet.pdp-11 paramucho <paramucho@hotmail.com> wrote:
> With MENTEC gone the original version of RT-11 has been orphaned.
Various considerations have been brought up in this thread, but
not having the sources, to say nothing of permission to work on
V5.7 (which has other improvements and bug fixes, and from which
it would be best to continue), is a real show-stopper in itself.
And then, the last support email I received for the RT-11 Kermit
was so long ago (many years) it's now archived, so I can't easily
check the date. The last for RSX was 11-Aug-2003, and the last
for RSTS was 20-Dec-2006. My point being I don't think any of
these operating systems are still widely used. Virtually all
of the inquiries over the last decade have been to ask how to
move data from a PDP-11 to another system.
That said, I still use RT-11 and TSX+, although their days as
videotape edit system controllers are now gone. Hardly anyone
is even using tape anymore, and more recently even finding tape
(raw stock) for those who do want to use it has become difficult.
The last edit system hardware vendor (Editware), which bought
and took over the Tektronix edit systems, used to have a notice
on their web site telling people -
| At midnight of December 31, 1999, the date will change to
| 01-JAN-:0. Instead of rolling from 99 to 00, it rolls to ":0"
| (colon-zero). Then in 2001, it will roll to ":1" and so on.
They eventually bought V5.7, though.
My feeling is if someone wants to run RT-11 a hundred years from
now, it's highly unlikely it will be to get any real work done,
and they can just set the clock back accordingly. Or this...
> Thinking about how emulators might be better able to preserve and
> extend the lives of historical operating systems by providing managed
> environments would be more productive IMO.
...would be a heck of a lot easier to do.
There are probably some improvements to be made, and bugs to be
fixed, but I'm happy enough with it now. The only real problem
I can recall is a handler can not be deassigned while a read
completion routine for it is queued (you must exit the program),
but that's a rather minor thing, and a trade-off I agreed to with
DEC many years ago - that is, fixing this would be more trouble
than it's worth...
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-22 21:51 -0700 |
| Message-ID | <ircp4g$18j$1@Iltempo.Update.UU.SE> |
| In reply to | #457 |
On 2011-05-22 20.41, billy@MIX.COM wrote: > In vmsnet.pdp-11 paramucho<paramucho@hotmail.com> wrote: > >> With MENTEC gone the original version of RT-11 has been orphaned. Rumors have it that someone have bought the PDP-11 software from what was Mentec... > Various considerations have been brought up in this thread, but > not having the sources, to say nothing of permission to work on > V5.7 (which has other improvements and bug fixes, and from which > it would be best to continue), is a real show-stopper in itself. Agree. It seems rather silly to fix code in an old version. It better to base the work on the latest release, which have already fixed a number of issues, and gives the opportunity to improve instead of repeating things > And then, the last support email I received for the RT-11 Kermit > was so long ago (many years) it's now archived, so I can't easily > check the date. The last for RSX was 11-Aug-2003, and the last > for RSTS was 20-Dec-2006. My point being I don't think any of > these operating systems are still widely used. Virtually all > of the inquiries over the last decade have been to ask how to > move data from a PDP-11 to another system. RSX is still used in a whole bunch of places commercially. I know of several places in Sweden at least, where RSX is still used for production. Mostly embedded, but some interactive use as well. I do not know of any RT-11 or RSTS/E places, though. But maybe someone else do? Johnny
[toc] | [prev] | [next] | [standalone]
| From | jjh <jjhudak@gmail.com> |
|---|---|
| Date | 2011-05-23 07:47 -0700 |
| Message-ID | <d2d268b6-643b-4b9c-8cbe-52ecc18f4482@x6g2000yqj.googlegroups.com> |
| In reply to | #458 |
On May 23, 12:51 am, Johnny Billquist <b...@softjar.se> wrote: > On 2011-05-22 20.41, bi...@MIX.COM wrote: > > > In vmsnet.pdp-11 paramucho<paramu...@hotmail.com> wrote: > > >> With MENTEC gone the original version of RT-11 has been orphaned. > > Rumors have it that someone have bought the PDP-11 software from what > was Mentec... > > > Various considerations have been brought up in this thread, but > > not having the sources, to say nothing of permission to work on > > V5.7 (which has other improvements and bug fixes, and from which > > it would be best to continue), is a real show-stopper in itself. > > Agree. It seems rather silly to fix code in an old version. It better to > base the work on the latest release, which have already fixed a number > of issues, and gives the opportunity to improve instead of repeating things > > > And then, the last support email I received for the RT-11 Kermit > > was so long ago (many years) it's now archived, so I can't easily > > check the date. The last for RSX was 11-Aug-2003, and the last > > for RSTS was 20-Dec-2006. My point being I don't think any of > > these operating systems are still widely used. Virtually all > > of the inquiries over the last decade have been to ask how to > > move data from a PDP-11 to another system. > > RSX is still used in a whole bunch of places commercially. I know of > several places in Sweden at least, where RSX is still used for > production. Mostly embedded, but some interactive use as well. > > I do not know of any RT-11 or RSTS/E places, though. But maybe someone > else do? > > Johnny Mentec gone? a pointer to details please? (When?) Hmmm, not that I have the cycles for this, but....What are the legal imediments to making an open source version of RT11, RSX11?? If there were patents, I am sure they would have run out. (if this has been bantied around before, forgive me for bringing it up again...) The technical challenges would be interesting but to paraphrase a quote from a "Field of Dreams", If you build it, who would come???
[toc] | [prev] | [next] | [standalone]
| From | billg999@cs.uofs.edu (Bill Gunshannon) |
|---|---|
| Date | 2011-05-23 15:04 +0000 |
| Message-ID | <93vbcaF3luU1@mid.individual.net> |
| In reply to | #459 |
In article <d2d268b6-643b-4b9c-8cbe-52ecc18f4482@x6g2000yqj.googlegroups.com>, jjh <jjhudak@gmail.com> writes: > On May 23, 12:51 am, Johnny Billquist <b...@softjar.se> wrote: >> On 2011-05-22 20.41, bi...@MIX.COM wrote: >> >> > In vmsnet.pdp-11 paramucho<paramu...@hotmail.com> wrote: >> >> >> With MENTEC gone the original version of RT-11 has been orphaned. >> >> Rumors have it that someone have bought the PDP-11 software from what >> was Mentec... >> >> > Various considerations have been brought up in this thread, but >> > not having the sources, to say nothing of permission to work on >> > V5.7 (which has other improvements and bug fixes, and from which >> > it would be best to continue), is a real show-stopper in itself. >> >> Agree. It seems rather silly to fix code in an old version. It better to >> base the work on the latest release, which have already fixed a number >> of issues, and gives the opportunity to improve instead of repeating things >> >> > And then, the last support email I received for the RT-11 Kermit >> > was so long ago (many years) it's now archived, so I can't easily >> > check the date. The last for RSX was 11-Aug-2003, and the last >> > for RSTS was 20-Dec-2006. My point being I don't think any of >> > these operating systems are still widely used. Virtually all >> > of the inquiries over the last decade have been to ask how to >> > move data from a PDP-11 to another system. >> >> RSX is still used in a whole bunch of places commercially. I know of >> several places in Sweden at least, where RSX is still used for >> production. Mostly embedded, but some interactive use as well. >> >> I do not know of any RT-11 or RSTS/E places, though. But maybe someone >> else do? >> >> Johnny > Mentec gone? a pointer to details please? (When?) Clarification, Mentec is still around but they have (apparently) stopped all development and even sales of PDP-11 products. > Hmmm, not that I have the cycles for this, but....What are the legal > imediments to making an open source version of RT11, RSX11?? I guess that depends on what you mean. If you mean using their code, it still belongs to them and is not free for use (although some of us are still hoping that might happen.) If you mean writting it from scratch using none of their code, that has always been a possibility. I once inquired after interest in doing it for RSTS many years ago. The result was zero interest. I expect the same would be true today. > If there were patents, I am sure they would have run out. Patents, maybe but copyrights will be in effect until long after the last PDP-11 is long forgotten. > (if this has been bantied around before, forgive me for bringing it up > again...) > The technical challenges would be interesting but to paraphrase a > quote from a "Field of Dreams", If you build it, who would come??? Probably depends on just what you build. A direct clone of any of them that only ran on PDP-11 hardware would be of little if any value. Now, a clone that ran on other hardware and allowed modernization of the OS, that would be another question. Possibly no interest there either but there is always potential. But, again, it really depends on the if the OSes do get released and what license they get saddled with. 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>
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-23 15:52 -0700 |
| Message-ID | <ireog6$ksn$1@Iltempo.Update.UU.SE> |
| In reply to | #461 |
On 2011-05-23 08.04, Bill Gunshannon wrote: > In article<d2d268b6-643b-4b9c-8cbe-52ecc18f4482@x6g2000yqj.googlegroups.com>, > jjh<jjhudak@gmail.com> writes: >> On May 23, 12:51 am, Johnny Billquist<b...@softjar.se> wrote: >>> On 2011-05-22 20.41, bi...@MIX.COM wrote: >>> >>>> In vmsnet.pdp-11 paramucho<paramu...@hotmail.com> wrote: >>> >>>>> With MENTEC gone the original version of RT-11 has been orphaned. >>> >>> Rumors have it that someone have bought the PDP-11 software from what >>> was Mentec... >>> >>>> Various considerations have been brought up in this thread, but >>>> not having the sources, to say nothing of permission to work on >>>> V5.7 (which has other improvements and bug fixes, and from which >>>> it would be best to continue), is a real show-stopper in itself. >>> >>> Agree. It seems rather silly to fix code in an old version. It better to >>> base the work on the latest release, which have already fixed a number >>> of issues, and gives the opportunity to improve instead of repeating things >>> >>>> And then, the last support email I received for the RT-11 Kermit >>>> was so long ago (many years) it's now archived, so I can't easily >>>> check the date. The last for RSX was 11-Aug-2003, and the last >>>> for RSTS was 20-Dec-2006. My point being I don't think any of >>>> these operating systems are still widely used. Virtually all >>>> of the inquiries over the last decade have been to ask how to >>>> move data from a PDP-11 to another system. >>> >>> RSX is still used in a whole bunch of places commercially. I know of >>> several places in Sweden at least, where RSX is still used for >>> production. Mostly embedded, but some interactive use as well. >>> >>> I do not know of any RT-11 or RSTS/E places, though. But maybe someone >>> else do? >>> >>> Johnny >> Mentec gone? a pointer to details please? (When?) > > Clarification, Mentec is still around but they have (apparently) > stopped all development and even sales of PDP-11 products. Or we could also say that Mentec Inc. seems to be gone, which was the part that actually did the PDP-11 stuff. Mentec of Ireland is still around, but they have not played with PDP-11s in a very long time. >> Hmmm, not that I have the cycles for this, but....What are the legal >> imediments to making an open source version of RT11, RSX11?? > > I guess that depends on what you mean. If you mean using their code, > it still belongs to them and is not free for use (although some of us > are still hoping that might happen.) If you mean writting it from > scratch using none of their code, that has always been a possibility. > I once inquired after interest in doing it for RSTS many years ago. > The result was zero interest. I expect the same would be true today. > >> If there were patents, I am sure they would have run out. > > Patents, maybe but copyrights will be in effect until long after the > last PDP-11 is long forgotten. Yes. That pretty much sums it up. There are no patents involved. You can make a clone any day. The actual code that makes up the OSes today is copyrighted by someone, which is what makes it impossible to just make that code "open source". Only the owner could make that. >> (if this has been bantied around before, forgive me for bringing it up >> again...) >> The technical challenges would be interesting but to paraphrase a >> quote from a "Field of Dreams", If you build it, who would come??? > > Probably depends on just what you build. A direct clone of any of them > that only ran on PDP-11 hardware would be of little if any value. Now, > a clone that ran on other hardware and allowed modernization of the OS, > that would be another question. Possibly no interest there either but > there is always potential. But, again, it really depends on the if the > OSes do get released and what license they get saddled with. 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, no matter if a lot of coding problems would be much easier to solve using some other paradigm. (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.) However, RSTS/E with a Unix RTS would be cool. :-) Johnny
[toc] | [prev] | [next] | [standalone]
| From | billg999@cs.uofs.edu (Bill Gunshannon) |
|---|---|
| Date | 2011-05-24 00:16 +0000 |
| Message-ID | <940bm5Fcc3U1@mid.individual.net> |
| In reply to | #463 |
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. :-) > no matter if a lot of > coding problems would be much easier to solve using some other paradigm. And if the paradigm actually made things better? One has to wonder how many of the people who eventually moved off of RSTS and RSX did so because the hardware it ran on was not capable of keeping up with the demands of their business. Remember, no one buys an OS for the OS, "It's the applications!!" > (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. 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. > > 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. 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>
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-23 17:40 -0700 |
| Message-ID | <ireupe$mqj$1@Iltempo.Update.UU.SE> |
| In reply to | #464 |
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. And so do VMS. And all other OSes that I know of. So really, I think that there is currently only one paradigm. (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.) >> no matter if a lot of >> coding problems would be much easier to solve using some other paradigm. > > And if the paradigm actually made things better? One has to wonder > how many of the people who eventually moved off of RSTS and RSX did > so because the hardware it ran on was not capable of keeping up with > the demands of their business. Remember, no one buys an OS for the > OS, "It's the applications!!" Many moved off just because of demands for more computing power, cheaper hardware, and perhaps even more because the software they needed to run didn't run on PDP-11s any more. It all have very little to do with technical competence of the underlying OS. >> (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. > 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, or else it's pretty useless. :-/ Heck, gcc even have its built-in versions for a bunch of library functions, in order to inline them. Making everything even more exciting. >> 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. Johnny
[toc] | [prev] | [next] | [standalone]
| From | billg999@cs.uofs.edu (Bill Gunshannon) |
|---|---|
| Date | 2011-05-24 12:58 +0000 |
| Message-ID | <941ob1Fre1U1@mid.individual.net> |
| In reply to | #466 |
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. :-) > And so do VMS. Minus little things like fork(); :-) > And > all other OSes that I know of. Primos? (Yes, it is still in use. I know the guy with the license to maintain it.) OS2200? (I just spoke with people about that and it is nothing but 1100 Exec all growed up. Old 1100 code still works just fine and even all that old old documentation I kept from 30 years ago is still valid!) xOS? (Well, you can run Linux on top of it.) Ansi-M/Mumps? (Probably twice as many users as VMS if not much more. I don't think any one is counting but there are 10's of thousands of users of just one major application that is written in Ansi-M). I have had my eyes opened quite a bit in the last year since I started looking at what was available outside of academia. < So really, I think that there is > currently only one paradigm. Or so academ,ia would have people believe. Just like the mantra"COBOL is Dead". > (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. > >>> no matter if a lot of >>> coding problems would be much easier to solve using some other paradigm. >> >> And if the paradigm actually made things better? One has to wonder >> how many of the people who eventually moved off of RSTS and RSX did >> so because the hardware it ran on was not capable of keeping up with >> the demands of their business. Remember, no one buys an OS for the >> OS, "It's the applications!!" > > Many moved off just because of demands for more computing power, cheaper > hardware, I agree up to here. > 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. > > 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. > >>> (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. 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!! :-) > >> 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. > or else it's pretty useless. :-/ Do your current RSX users find it useless? Then why are they still there? Same goes for all those OSes I mentioned above. Again, as much as I like Unix (and I have been doing it since 1980) it is not the only answer to any problem. > Heck, gcc even have its built-in versions for a bunch of library > functions, in order to inline them. Making everything even more exciting. Depending on the function, that's probably not really a problem. It is likely that in the long run those same functions might be wanted under RSTS and RSX as well. > >>> 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!! 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>
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-05-24 14:02 +0000 |
| Message-ID | <irgdpr$hhr$1@dont-email.me> |
| In reply to | #470 |
In vmsnet.pdp-11 Bill Gunshannon <billg999@cs.uofs.edu> wrote: (big snip) > 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. Well, z/OS supports OS/360 programs using the OS/360 addressing. ESA/390 supports both 24 and 31 bit addressing, such that old programs (user mode) still run the old way. z/OS supports 24, 31, and 64 bit addressing. Programs compiled (or assembled) and linked on OS/360 still run on z/OS. In most cases, though, they have enough more memory available that they run better. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-24 07:36 -0700 |
| Message-ID | <irgfp7$382$1@Iltempo.Update.UU.SE> |
| In reply to | #470 |
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. :-) >> 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. And Unix programmers can write programs on a VMS system without really having to go outside their comfort zone for most of the time. It might not be programs that really take any advantage of VMS, but then again, they don't care. >> And >> all other OSes that I know of. [List of other OSes...] I don't know for sure how any of those OSes look from a programming point of view, but if any work's been done on the core system the last 20 years, I wouldn't be surprised if it was to make it more Unix-like. >> (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. 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.) >>>> no matter if a lot of >>>> coding problems would be much easier to solve using some other paradigm. >>> >>> And if the paradigm actually made things better? One has to wonder >>> how many of the people who eventually moved off of RSTS and RSX did >>> so because the hardware it ran on was not capable of keeping up with >>> the demands of their business. Remember, no one buys an OS for the >>> OS, "It's the applications!!" >> >> Many moved off just because of demands for more computing power, cheaper >> hardware, > > I agree up to here. Since it was more or less what you wrote. ;-) >> 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. 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? >> 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. 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. >>>> (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, > 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, 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. >>> 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. :-) >> or else it's pretty useless. :-/ > > Do your current RSX users find it useless? Current RSX users do not have gcc. :-) 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. 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. If you provide a C compiler, you pretty much have to provide something that smells like Unix, or else it gets pretty useless, since people expect any C environment to also work like a Unix environment. > Then why are they > still there? Same goes for all those OSes I mentioned above. > Again, as much as I like Unix (and I have been doing it since > 1980) it is not the only answer to any problem. It definitely is not, but that was not my point. >> Heck, gcc even have its built-in versions for a bunch of library >> functions, in order to inline them. Making everything even more exciting. > > Depending on the function, that's probably not really a problem. > It is likely that in the long run those same functions might be > wanted under RSTS and RSX as well. They are very Unix-y and C-y. But sure, they are useful. Most functions in the C library are useful. They just might not match the paradigms of a non-Unix environment. Most typically, that would be such a simple concept as strings for example. >>>> 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. Johnny
[toc] | [prev] | [next] | [standalone]
| From | billg999@cs.uofs.edu (Bill Gunshannon) |
|---|---|
| Date | 2011-05-24 16:42 +0000 |
| Message-ID | <9425gcFhnpU1@mid.individual.net> |
| In reply to | #473 |
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.
>
>>> 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. :-)
> 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".
> 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.
>
>>> And
>>> all other OSes that I know of.
>
> [List of other OSes...]
>
> I don't know for sure how any of those OSes look from a programming
> point of view, but if any work's been done on the core system the last
> 20 years, I wouldn't be surprised if it was to make it more Unix-like.
I can assure you that there have been little if any attempts and probably
no desire for most of them.
Primos. No real development. Probably the worst example except for
the fact that as dead as it is (and for as long as it has been) it
still has a rather large user base. There was a layered system called
Primix but it has not survived as no one appeared to be interested in
it. (Think Eunice. :-)
OS2200. As I said, the only interest was in keeping it compatable
with 1100 Exec from 30 years ago.
One thing these both have in common was that there was a version of
The Software Tools Virtual OS for both of them giving them a Unix-like
API compatable with what Unix was 30 years ago.
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.
>
>>> (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.
>
> 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......
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.
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.
Not all things are obsolete because one man thinks so, not even
if his name is Gartner.
>
>>>>> no matter if a lot of
>>>>> coding problems would be much easier to solve using some other paradigm.
>>>>
>>>> And if the paradigm actually made things better? One has to wonder
>>>> how many of the people who eventually moved off of RSTS and RSX did
>>>> so because the hardware it ran on was not capable of keeping up with
>>>> the demands of their business. Remember, no one buys an OS for the
>>>> OS, "It's the applications!!"
>>>
>>> Many moved off just because of demands for more computing power, cheaper
>>> hardware,
>>
>> I agree up to here.
>
> Since it was more or less what you wrote. ;-)
>
>>> 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?
>
> 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.
>
>>> 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.
> 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.
>
>>>>> (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? :-) 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?
>
>> 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?
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?
> 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.
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.
>
>>>> 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? ;-)
>
>>> 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? :-)
> 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.
> 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.
>
> If you provide a C compiler, you pretty much have to provide something
> that smells like Unix, or else it gets pretty useless, since people
> expect any C environment to also work like a Unix environment.
See above. :-)
>
> > Then why are they
>> still there? Same goes for all those OSes I mentioned above.
>> Again, as much as I like Unix (and I have been doing it since
>> 1980) it is not the only answer to any problem.
>
> It definitely is not, but that was not my point.
>
>>> Heck, gcc even have its built-in versions for a bunch of library
>>> functions, in order to inline them. Making everything even more exciting.
>>
>> Depending on the function, that's probably not really a problem.
>> It is likely that in the long run those same functions might be
>> wanted under RSTS and RSX as well.
>
> They are very Unix-y and C-y. But sure, they are useful. Most functions
> in the C library are useful. They just might not match the paradigms of
> a non-Unix environment.
OK. C is out. :-)
> 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.
>
>>>>> 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? :-)
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.
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.
2. Even if I am wrong about 1. above it is likely to be done
under a license that is not commercially friendly.
3. Given 1. above it is unlikely that any attempt to re-write
RSTS or RSX is ever likely to happen.
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.
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>
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-24 11:17 -0700 |
| Message-ID | <irgsnm$7ov$1@Iltempo.Update.UU.SE> |
| In reply to | #478 |
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...
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...
>>>> 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...
>> 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.
>> 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.
> 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. And as a
standalone system on the machine as well...
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.
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. 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.
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.
>> 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.
> 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.
> 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.
> 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 admit I have been toying with the idea for RSX, but I
doubt I'll ever get around to it.)
Which leads us back to that the applications you want to run don't
exist, so you don't run the OS.
It's the same problem that VMS face. For VMS, the hardware is definitely
there for all practical purposes. You even have X11. But VMS is a worse
Unix than Unix, and so it looses. And Unix is a worse Windows than MS
Windows, and thus have a hard time competing as well. You need *office*.
:-) (And a whole bunch of other applications.)
And things like office is what pushed PDP11s out in some places.
>> 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. The requirements for faster processing times
because all other stages have become faster might play a role sometimes
though.
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... :-)
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.
>>>> 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. 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.
So we're talking about totally new applications. I just don't see that
happening. People will write for Unix instead.
Put another way: the drive for new hardware have mostly been new
programs. New programs are written for certain OSes.
>> 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.
>>>>>> (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...
> 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.
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.)
> 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??? :-)
Ada exists, but only among the really obscure places, like the military.
Where I believe it's also still popular in the US.
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...
>>>>> 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 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).
>>>> 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. :-)
>> 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?
>>>>>> 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.
> 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.
Johnny
[toc] | [prev] | [next] | [standalone]
| From | billg999@cs.uofs.edu (Bill Gunshannon) |
|---|---|
| Date | 2011-05-24 20:07 +0000 |
| Message-ID | <942hghFhukU1@mid.individual.net> |
| In reply to | #481 |
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>
[toc] | [prev] | [next] | [standalone]
| From | Rich Alderson <news@alderson.users.panix.com> |
|---|---|
| Date | 2011-05-24 21:07 -0400 |
| Message-ID | <mdd7h9f7flx.fsf@panix5.panix.com> |
| In reply to | #482 |
Oops. As Bill points out, MUMPS originated on the PDP-7 (like Unix). I had
forgotten that it predated the PDP-15.
--
Rich Alderson news@alderson.users.panix.com
the russet leaves of an autumn oak/inspire once again the failed poet/
to take up his pen/and essay to place his meagre words upon the page...
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-25 03:34 -0700 |
| Message-ID | <irilvv$p6t$1@Iltempo.Update.UU.SE> |
| In reply to | #482 |
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... :-/ 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. >>>>>> 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. >>> 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. :-) >>>>>> (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). >> 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. 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. >>>> 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. >>> 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, 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. >>> 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. >> (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... >> 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. >> 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. >> 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. >> 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. 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. >> 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. 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. 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. >>>> 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. >> 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. >> 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. 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.) >>>>>> 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. >> 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. 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. >> 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). >> 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. >>> 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. >>>>> 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. >> 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. >>> 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. > 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. :-) Johnny
[toc] | [prev] | [next] | [standalone]
| From | billg999@cs.uofs.edu (Bill Gunshannon) |
|---|---|
| Date | 2011-05-25 15:46 +0000 |
| Message-ID | <944mhrF19qU1@mid.individual.net> |
| In reply to | #486 |
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>
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-25 16:00 -0700 |
| Message-ID | <irk1m5$7fp$1@Iltempo.Update.UU.SE> |
| In reply to | #489 |
On 2011-05-25 08.46, Bill Gunshannon wrote: > 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. Indeed. But in many cases we're more arguing the finer points than the big picture. >> 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. It's a part of the same issue, in my mind. Everyone is now so set in the current paradigms that nothing can shift them. We're going to be stuck with the Unix ideas for the forseeable future, with more and more cruft grafted in to solve the problems. Look at various extensions for security that have come, such as capabilities, ACLs, doing things over ssh, using SSL, and now also hardware support for security issues. (In a way, the PDP-11 have some of that, since you can have execute-only memory, and memory from which you cannot execute. :-) ) >>>>>>>> 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. I don't agree with that. The "fixed" codebase many times make it into the central repository. However, new features are added, and they also sometimes needs fixing, and the original author have no interest in that for VMS. So the original porter gets to fix the new code as well. And at some point, the few people who do that tires of it, and stops. Since the "hard" work have already been done several times, I think this is proof enough that it can be done. So I think it simply that noone cares enough. And by noone I should probably have written noone who have the skill, since otherwise the work isn't done anyway. >>>>>>>> (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. DEC did not always lean towards structured files. RT-11, RSTS/E, TOPS-10, TOPS-20 (and OS/8) are all examples where the equivalent of a stream of bytes type of file was the most common thing. It's basically RSX (and from that VMS) that is the exception. RMS was available on other platforms as well, but there RMS is an addon, that you can skip if you want. For VMS it is very mandatory, and for RSX you have FCS, which is like a precursor to RMS, and compatible, as far as it goes. >>>> 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. The problem with the Unix way is that it is so scattered and unsupported. You could say that RMS is just a poor man's ISAM. But if you want to play with that, RMS is the way you do it. And there are plenty of tools that understand it, can manage it, and manipulate it. For Unix, there is no such thing. There are a whole bunch of different solutions, all incompatible, all with different capabilities, and all working on top of the stream of byte concept. Talk about addition another abstraction layer... >> 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. Say what? When you read from a disk, you always reads a whole block. When you write, you always write a whole block. If you want to modify just one byte on a disk, you need to read in the whole block, modify the single byte, then write the whole block out again. That is where this whole character/block distinction in device drivers in Unix comes in. It is there to abstract away the block characteristics of a disk, so that you can pretend it's actually a stream of bytes. > As for tape and ethernet, even > the blocking data is just other byte values. I don't understand what you said here. On a tape, you read the whole block with one read. You can't read just half the block, and then read the other half in the next read. Whatever read from the tape block in the first read that didn't fit into your buffer is lost. Thrown into the big bit bucket. The controller have to throw it away. Because the tape drive will deliver all of it with just one operation. The same is true for ethernet. You need to read the whole packet in one go. And then you can start fooling with that whole packet. It's not byte values. It's actual blocks. And each block have some meta-data attached to it. This meta-data for tapes is the block length, which is not stored anywhere on tape, but is a result of the actual operation. For ethernet the same is true about block length. But there you in addition also have the ethernet header, which gives source, destination and protocol (I'm not going to bother with preables, checksums, and so on, because that gets stripped away by the controller before being delivered to the system). For both, by the way, you also have an imposed minimum length. For tapes, I seem to remember that for tapes this is 14 bytes, while for ethernet it is 64 bytes. Nothing shorter than that is allowed. > 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!!) I don't see how a card differs from a tape block, or an ethernet frame... >>>>>> 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. True. And a good question. But for now, I think that this is an essential part why a reimplementation of any non-Unix OS is going to fail. And from program development companies point of view, I don't the pendulum will swing. Cost of software development is constantly rising. One way to keep it down is to use more canned solutions, and develop for less and less platforms. One thing that have hurt Unix tremendously is all the different dialects. And Linux in itself is hurting itself by all the different distributions, which makes it hard to develop and distribute programs for it, in binary form. >>>>> 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. Yes. It might be just a different definition of new here then. For me, new would be someone starting a new project from scratch, and deciding to write it in Cobol. Just doing maintenance, additions, updates and bugfixes to an existing system is not new development. >>>> (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. :-) Ah. Ok. Yes, doing some X client stuff might be more interesting. I've been thinking about that too, but for the same reason I doubt I'll get around to it. The X11 protocol is pretty complex and big. Not sure I'd be happy with the end result, not to mention having to work on the overlays... :-) However, the biggest reason why I have this so low on my list is that HTML have come such a long way that you can do pretty impressive stuff with it today, with less overhead than X. So I'm seriously thinking about doing a web server for RSX. That one is almost definitely happening. And then you can do all kind of fun programs on the PDP-11, and present the results graphically, or whatever. Heck, Google have even implemented much of an office suite usable over http. >>>> 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". Could be. But I think it's more that as developers tries to reduce cost, they cut the versions that generate the least amount of money. VMS basically generates much less money because its much smaller installed base than Windows (or Unix). And even in its heyday VMS user base was much smaller than Unix or DOS (back in that day). It's a simple game of numbers. (Sadly enough.) The owners are just reacting to that too. I don't doubt that HP would happily have seen VMS being a big hit, but it simply is not. And it does not justify plowing big money into it, compared to other businesses that HP do, which does return much more money. For DEC, it was partly a different deal. Back in that day, VMS was the biggest money thing they had. For HP, it is not. Companies are money driven. The thing that gives the best return back on money invested is the thing they will go for. What that is, is not always known, which is why companies do R&D, and have smaller things going in various directions. Just in case... And VMS simple isn't the big fish. Hasn't been since the 80s. And fewer software companies today go for niche markets, and when they do, it is for some particular reason. > 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. No, I don't agree. People didn't stop writing software for PDP-11 systems. Not until noone bought it anymore. DEC did try to make their customers migrate to VAX/VMS though. And even partially successful, that diminished the customer base for PDP-11 products. And that got more of the ball rolling. Once again, in my mind, this is all a numbers game. >>>> 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. That is the one thing I think can topple the Microsoft imperium. Cost. Even inferior products will win, if the price is right. Once more, the numbers game. >>>> 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. ;-) The problem is if everyone else is using Microsoft Office, and pass around documents written in there, you need to be fully compatible with that, or else you are at a disadvantage. And so far, Microsoft have been very successful at getting everyone to use Microsoft Office. I think I've argued the whole time that "perfectly good" is not good enough. It don't really matter if some software do the job better or not. What matters is if it allows you to get the job done, and if it's cheap enough. For RSX (to use as a theoretical example) is not good enough, because the user base would be too small, and porting too much work for developers to ever pay any interest to it. For users, it basically just mean that the software isn't there. No matter how good the OS is. For something like office, if everyone else uses Microsoft Office, and passes documents around, you need to be able to see those, and get them presented the same way on your system too, or else you will probably change. Getting everyone else to change is way harder. But it is interesting to see if this thing about getting everyone else changing might actually be happening because of cost issues from the user side. That would be a serious problem for Microsoft. >>>> 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!) Anyone remember back when Emacs was defined as WYSIWYG? :-) Definitions change, all the time. >> 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. We disagree then. > 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. Oracle dropping VMS looks more like VARs getting out of VMS before HP. HP will be the last guy standing. And this is not because HP said Oracle should. I suspect they are actually very unhappy with that announcement (as are Intel, I guess). But from Oracles point of view, it probably makes great sense. The earnings don't justify the costs anymore. They can make better money by another strategy. That's why they drop VMS. Once more the numbers game in operation. >> 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. I'm not denying that the underlying hardware needs to be capable enough. Otherwise the rest is already a lost cause. But developers go by actual numbers as well as predictions. If it sell, they will continue to sell it. If the continued selling is tied to doing additional development, they'll do that. But if they have two platforms to choose from, and one is selling much better than the other, they will always first do the development for the best selling platform, and the other will come second. And that in turn can cause an effect of users migrating to that primary platform, because that is where all the new stuff turn up first. And this is totally independent of what the perceived or announced future of the secondary platform is. And in time, this can cause the developer to stop development on the secondary platform, because almost all customers of that software have migrated to the primary platform. And so the ball starts rolling. And that is what I see have happened, when looking over time. Which is also why I don't think it would have made a difference if DEC had stuck with the PDP-11, or whatever. The biggest platform is normally the winner. The game changer can be pricing. The PDP-11 (as well as VMS) cannot compete on either of those strengths. Technical merits comes way down on any list. > 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. Well, I still think it's an even more dead horse than just continuing development on the PDP-11. But I will not stop you. :-) But if you plan on doing a reimplementation on x86, then I don't see why you are waiting for the fallout from Mentec. You'll have to write it all from scratch anyway. The documentation is out there. That is the base for your design. As for actual code, you'll have to write it, no matter what you plan. >>>>>> 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? A single record? In that case, it would suck. :-) But then again, at that point, more than just the limited addressing space is going to hurt you. The whole design of the OS will not be able to deal with it. Records in RMS can't be that big either, for instance. > 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. :-) If you mean splitting a record into several smaller type of records, I'd say much of the time a proper database should do that instead of just having gigantic records. Having those gigantic records means you access lots of data you are not interested in whenever you do some operation. I've been playing with some seriously big databases, but it's not that single records are that big, just that there over time become so darned many records. But that is a question of diskspace, and speed when accessing them (both CPU and disk). >>>> 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. Demise? RSX is still alive. DEC continued development until 1994, at which time they sold it to Mentec. Mentec continued development and support until atleast 2006 (when I last talked to them and bought software). And it would seem that Mentec have since sold the software again. >>>> 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. RSX software could run on VMS. You didn't even need to recompile it. It was somewhat popular. Heck, in VMS V1, most every application and tool were still the RSX programs. But it was only for userspace code. I'd say that VMS is very much a logical extension/expansion/continuation of RSX on the VAX. Yes, I've used both VMS and RSX. I'm getting a bit rusty on VMS, since I use it pretty seldom nowadays, but I even worked at DEC for a while, writing VMS software. Comparing VMS with RSX? The perhaps most obvious thing that differs, that people react to is that RSX seems obscure and weird, while VMS is more easy to use, and user friendly. VMS on the inside is very much RSX, but VMS on the outside is so much more like RSTS/E. Is that an advantage? For me - no. For most other people - yes. Is there anything that was done in VMS that couldn't have been done in RSX, if the memory limitations didn't mess things up? Of course not. Any computer can do what any other computer can do. I'm not sure the question is helpful, though. As for comparing RSTS/E with VMS, I can speak of several things in VMS, that are really hard to solve in RSTS/E. Mostly are with writing software, and what services RSTS/E provides. For example, in VMS (as in RSX) all I/O is by default asynchronous, and you get something very similar to an interrupt when the I/O completes. But unlike Unix (where you have signals for this), VMS and RSX actually have much more fine grained control. When you issue an I/O, you actually provide the address of a routine to call asynchronously when the I/O completes. So each I/O request (even for the same I/O descriptor) can result in a call to a different piece of code. Now, how do you do this in RSTS/E (or Unix for that matter)? The RSX (and VMS) way is so nice, and so difficult to accomplish, or even get close to, in some other OSes. >> 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!!) Indeed. >>> 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. I'm totally talking about MACRO-11 here, since very little of the interesting stuff is written in something else. Sure, HLL programs will be just fine. It's the MACRO-11 applications that are the show stoppers, and it those that I am talking about. >>>> 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. Actually, it was by law very available, for CSRG. Which is a good reason why they picked it. For free. What better reasons could there be? > And in the cases where it was made avaialble the price was prohibitive. For CSRG that was a non-issue. > 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!!) I think you got it backwards. The availability for *others* probably meant nothing to CSRG. They wanted to do research on OSes. That wasn't planned to ever go outside their own walls, except for academic papers and so on. So it was fully available, and for free. A perfect fit for their needs. No reason to try and look further than that. >> 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!!! I don't think so. Neither that it could have been any OS, nor that the results would have been the same. Part of the reason for the success was that it was written in a HLL. Any OS written in assembler would probably not have come to the same results. Second is that they started with an OS that was multiuser, and so on. Basing it on some single-user OS would also have lead to very different results (hello windows). But the basic premises of the whole thing, that AT&T had to give it away for free was a very important part here, and I doubt DEC would have been interested in doing the same, for any of their software. >>>> 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. It would take a big effort before it would even become a viable option, and even then I don't see anyone even seriously considering it. >>>>> 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!! I did the overlay schema for DUNGEON V3 for RSX-11M+. That was an interesting exercise. Just doing the compilation of the whole thing took on the order of two hours on a PDP-11/70. But yes, writing on any HLL, I never worry about memory layouts, or whatever. Not even on a PDP-11 (except for the possible overlay schema). But for some compilers I cannot use split I/D space, which upsets me. But that then becomes a question of working on the compiler. Not HLL code itself is still unaware. I guess that is the point of HLL. >>>>> 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. :-( Which University? And yes, I know there are still some academic interest in Ada, but it has lessened significantly over the years. Let me know if you are going, and I'll send a hello through you to some people I'm sure is going to be there. >>>> 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. Since talk about a theoretical reimplementation of RSTS/E isn't really meaningful at this point, I'll just stick with the current RSTS/E on PDP-11. Of course it can be done. It should in fact be almost trivially straight forward. You write the RTS. The RTS have vectors for some various instructions, such as EMT. Unix programs do EMTs for system calls. You translate the Unix system calls that are possible into RSTS/E calls (which means quite a few, but not all, especially not fork()), and then you run your programs. Many Ultrix-11 programs should then just run. Like magic. :-) And the kbm could be made to look like a simple shell. > 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. :-( Like I said. This should be pretty easy do to. >>>> 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. Why stay with the PDP-11 instruction set in this case? There is nothing to actually gain from that. You might as well expand/extend/change that too at the same time. It will only be (at best) semi-compatible with the PDP-11 instruction set anyway. > 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. It's the same problem DEC already had to solve in the PDP-11/70. That is what the Unibus map do. A layer between memory and devices, which do address remapping between the two domains, so that you can have an 18-bit Unibus address space go to a 22-bit physical memory space (on large PDP-11s) or a 30-bit physical address space (on most VAXen). Which also means that all device drivers needs to know about, and make use of the Unibus map in order to transfer data to/from devices. A new Unibus map design will require changes to all drivers as well. >>> 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!! Apart from that I only drink coke, that would be cool. You don't happen to be around San Francisco the next few weeks? Johnny
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> |
|---|---|
| Date | 2011-05-26 17:50 +0200 |
| Message-ID | <c832b411ed72d0490fd56f5d781efa44@msgid.frell.theremailer.net> |
| In reply to | #495 |
Johnny Billquist <bqt@softjar.se> wrote: > >>>>>>>>> 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. Not from where I stand as someone who is in the business of writing software for IBM mainframes (not in COBOL, btw!) However I could be accused of thinking there is really only one OS left in the world, z/OS. Don't get me wrong, I do like old stuff like DOS, PDP-11 (I'm reading the newsgroup) although it's been a long time since I used a PDP machine. > >>>>>>>>> that predate MS and might even predate Unix and still have loyal > >>>>>>>>> followings. (And I am not talking about VMS. :-) Yep! > We're going to be stuck with the Unix ideas for the forseeable future, That's only if you use UNIX. > with more and more cruft grafted in to solve the problems. Look at > various extensions for security that have come, such as capabilities, > ACLs, doing things over ssh, using SSL, and now also hardware support > for security issues. No question. I always get flamed and death threats for saying this, but as much as UNIX, LINUX, etc. are really the only modern way to go on PCs, they are still not enterprise quality. Linux is far far from it, Solaris better but still with the problems you mentioned and many many more. > >>>>> Yes, but not the majority of the ones people actually want. :-) Everybody in the dark ages said the world was flat, but it wasn't. The bad part was the people who said it wasn't got burned at the stake. Gee, nothing's really changed! > The problem is if everyone else is using Microsoft Office, and pass > around documents written in there, you need to be fully compatible with > that, or else you are at a disadvantage. > And so far, Microsoft have been very successful at getting everyone to > use Microsoft Office. I have used OO to deal with Windows users for a few years now without any compatability issues. That includes word doc and excel spreadsheets. I'm sure if you look you can find stuff that doesn't work but I never came across any. > >> 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. That's exactly right. It's all about GUI today, nothing else matters. And that's why today's code quality is so bad, because people don't know how to write code, they only know how to use libraries or APIs other people wrote. > Oracle dropping VMS looks more like VARs getting out of VMS before HP. > HP will be the last guy standing. And this is not because HP said Oracle > should. I suspect they are actually very unhappy with that announcement > (as are Intel, I guess). But from Oracles point of view, it probably > makes great sense. The earnings don't justify the costs anymore. They > can make better money by another strategy. That's why they drop VMS. Itanium, VMS, what's next ;) > Technical merits comes way down on any list. Except for the people who care, and there are only a few of us left.
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.sys.dec
csiph-web