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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-26 09:53 -0700 |
| Message-ID | <irm0id$s2n$1@Iltempo.Update.UU.SE> |
| In reply to | #506 |
On 2011-05-26 08.50, Fritz Wuehler wrote: > 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. :-) However, I suspect you live in a diminishing world. >> We're going to be stuck with the Unix ideas for the forseeable future, > > That's only if you use UNIX. I might sound like the doomsday is coming, but you'll probably see more Unix and Windows even at your place over time. I bet 20 years ago, you saw neither, and now they do exist around you... >>>>>>> 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! That is true. However, questions like if the earth is flat or not is at least a provable statement. What we talk about here is so much more just a question of opinions, trends and taste. There are no provable right or wrong. Which makes it so much more problematic. And which makes it possible for products with a high suck-factor so succeed. >> 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. He. I was using it a just a couple of years ago, and were sitting in this meeting with a printed copy of a word document when I realized that the pagination became different and when everybody else talked about page x, I sometimes had to go to page x+1. Very difficult to discuss the contents of the document under those circumstances... :-/ It would appear that under some circumstances, OO overflowed the text to the next page earlier than MS Office do. And it wasn't too complex a document either. Figures, and just text. >>>> 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. Couldn't agree more. And it's also because competent programmers are expensive. Heck, even incompetent programmers are expensive. Software development is expensive, so all corner cutting that you can come up with are used. >> 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 ;) Good question, actually. Maybe IBM mainframes? :-) Probably not, but anyway... The trend will not stop here. More roadkill is to be expected. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> |
|---|---|
| Date | 2011-05-26 22:20 +0200 |
| Message-ID | <692fa4c3da8b25daef82cba4092ea173@msgid.frell.theremailer.net> |
| In reply to | #508 |
Johnny Billquist <bqt@softjar.se> wrote: > On 2011-05-26 08.50, Fritz Wuehler wrote: > > Johnny Billquist<bqt@softjar.se> wrote: > > > > 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. > > :-) > However, I suspect you live in a diminishing world. That's true of everything good but unless a miracle happens it will still be around for a long time. > That is true. However, questions like if the earth is flat or not is at > least a provable statement. What we talk about here is so much more just > a question of opinions, trends and taste. There are no provable right or > wrong. Which makes it so much more problematic. And which makes it > possible for products with a high suck-factor so succeed. I don't agree. You can prove technology is superior or inferior. What you can't prove is what you should like or not like, and since unqualified people are making technology choices (too many MBA CTOs and no engineering CTOs) the issue isn't what's better. It's what they like, or more to the point what is the cheapest thing they can do this quarter. > He. I was using it a just a couple of years ago, and were sitting in > this meeting with a printed copy of a word document when I realized that > the pagination became different and when everybody else talked about > page x, I sometimes had to go to page x+1. Very difficult to discuss the > contents of the document under those circumstances... :-/ > It would appear that under some circumstances, OO overflowed the text to > the next page earlier than MS Office do. And it wasn't too complex a > document either. Figures, and just text. I am sure this can be dealt with by people who know how but I agree what happened is not a good situation. Anyway I never had it come up. > > Itanium, VMS, what's next ;) > > Good question, actually. Maybe IBM mainframes? :-) They have been saying that since 1975 but here we are in 2011 and IBM is worth more than Microsoft on the stock market. True we have many less jobs, orders of magnitude less, but it's a great platform with an endless life left. It's going away for many reasons, none of them technical or quality related. Those of us in the business are pained over it as much as you guys who love DEC and PDP. We've worked on this stuff for 40 or 50 years. > Probably not, but anyway... The trend will not stop here. More roadkill > is to be expected. Yep. :-(
[toc] | [prev] | [next] | [standalone]
| From | billg999@cs.uofs.edu (Bill Gunshannon) |
|---|---|
| Date | 2011-05-28 18:01 +0000 |
| Message-ID | <94crjeFtm7U2@mid.individual.net> |
| In reply to | #495 |
Johnny, This is one of the most interesting dicussions I have had on USENET in a long time, however.... I am goingt o have bow out for a bit and hoe we can pick things up later. This weekend is our University's Commencement and this year it is not only work for me and my wife but we are also both graduates ourselves. And, immediately after that we are going away on a much needed vacation and I have no idea what if any network access I will have. So, I thought I should excuse myself now before I just disappeared and people thought the black helicopters had come and snatched me, :-) Take care, and I hope we can have even more discussions when I make it home (and sadly, back to work.) 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-25 20:58 -0400 |
| Message-ID | <mddk4de2s77.fsf@panix5.panix.com> |
| In reply to | #489 |
billg999@cs.uofs.edu (Bill Gunshannon) writes:
> 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!!)
I'd just like to point out that the sectors ("blocks") on a TOPS-20 file
system are 256 18-bit+parity halfwords long, with 4 sectors per page.
Tops-10 works in blocks instead. Those amounts of data are what show up
in buffers made up of 36-bit words. So-called "byte" streams are parochial.
:-)
> 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!)
I write professional documentation in LaTeX. (Then again, I'm probably
an old guy, so it doesn't count.) I can move my documentation sources
from Windows (mandated by the IT department) to Mac OS X (at home) to
any Linux or BSD version (JBIFLI), and get the same results on any of them.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-05-26 01:23 +0000 |
| Message-ID | <irka34$sqr$1@dont-email.me> |
| In reply to | #496 |
In vmsnet.pdp-11 Rich Alderson <news@alderson.users.panix.com> wrote:
> billg999@cs.uofs.edu (Bill Gunshannon) writes:
>> 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.
(snip)
> I'd just like to point out that the sectors ("blocks") on a TOPS-20 file
> system are 256 18-bit+parity halfwords long, with 4 sectors per page.
> Tops-10 works in blocks instead. Those amounts of data are what show up
> in buffers made up of 36-bit words. So-called "byte" streams are parochial.
> :-)
It has been a while since I thought about this. I did used to read
EBCDIC tapes from OS/360 on TOPS-10, with my own conversion program
written in Fortran. I don't remember how the blocking came out now,
but the favorite format (RECFM) at the time was fixed length 80
byte records, blocked at something like 3200 bytes.
DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200)
I believe it comes out four bytes per PDP-10 word.
I also remember doing direct access files in Fortran, I believe
with records that were multiples of the disk block size.
(snip)
> I write professional documentation in LaTeX. (Then again, I'm probably
> an old guy, so it doesn't count.) I can move my documentation sources
> from Windows (mandated by the IT department) to Mac OS X (at home) to
> any Linux or BSD version (JBIFLI), and get the same results on any of them.
That is part of the design of TeX. All calculations that affect the
typesetting output are in fixed point. (With varying numbers of
bits after the binary point, mostly 16.) Some messages use floating
point, though. Do you have TeX on TOPS-20?
There is one place in TeX where it needs to multiply two values
with 16 bits after the binary point, with the result also having 16
bits after the binary point, and similarly for divide. That isn't
easy (or fast) in Pascal, so it is suggested to use an assembly
routine to do it, as appropriate for the hardware. Though maybe
machines are fast enough now, that no-one notices.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | koehler@eisner.nospam.encompasserve.org (Bob Koehler) |
|---|---|
| Date | 2011-05-26 08:01 -0500 |
| Message-ID | <8muWrc1fNvZf@eisner.encompasserve.org> |
| In reply to | #499 |
In article <irka34$sqr$1@dont-email.me>, glen herrmannsfeldt <gah@ugcs.caltech.edu> writes: > > It has been a while since I thought about this. I did used to read > EBCDIC tapes from OS/360 on TOPS-10, with my own conversion program > written in Fortran. I don't remember how the blocking came out now, > but the favorite format (RECFM) at the time was fixed length 80 > byte records, blocked at something like 3200 bytes. > DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200) Once upon a time 80 byte EBCDIC records (one per block) on an 800 BPI tape was the all-purpose media for data exchange. A VAX 11/780 running VMS 1.x was the first system I ran into that didn't ship with an EBCDIC tape reading progream. The next 11/780 I ran into went into a shop with 3 IBM 360, so the local DEC office gave us a program that would read and write EBCDIC tapes. > > I also remember doing direct access files in Fortran, I believe > with records that were multiples of the disk block size. I've done a lot of direct access in Fortran, and never had to worry about the disk block size. I was suprized to discover that the IBM Fortran H Extended Enhanced I/O subsystem would do direct access on a veriable-length record file, but not a fixed length record file. Perhaps IBM figured they only had to do the harder part. We had an IBM Macro routine that would do direct access on a fixed length record file. It had a variable calling sequence. When we ported the code to our VAX, I wrote a Fortran subroutine to do the direct access file I/O and a Macro-32 routine to accept the variable length argument list and fill in the arguments to the Fortran subroutine.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-05-27 00:54 +0000 |
| Message-ID | <irmsov$kjp$1@dont-email.me> |
| In reply to | #503 |
In vmsnet.pdp-11 Bob Koehler <koehler@eisner.nospam.encompasserve.org> wrote: (snip) > I've done a lot of direct access in Fortran, and never had to worry > about the disk block size. I was suprized to discover that the > IBM Fortran H Extended Enhanced I/O subsystem would do direct access > on a veriable-length record file, but not a fixed length record file. > Perhaps IBM figured they only had to do the harder part. I am surprised, too. The Fortran G and H direct access requires a fixed record length. Just to be sure, while the record length is fixed, you are allowed to choose any length you want between 1 and the disk track size. It just uses BDAM, which goes directly to the disk hardware, which has the ability to format the track to any record length you want. On first open, the system formats the whole file to the specified length. I am pretty sure that is still supported, though there is a recommendation to use VSAM instead. The disk hardware writes blocks similar to the way data is written on 9-track tape. Well, not exactly. The format is called CKD, Count-Key-Data. Each block has a count field (with key length and data length), an optional key (for keyed access filed), and data field. In between, there is an inter-block gap, just like on tape. BDAM uses unblocked files, so one physical block per record. VSAM formats the CKD disk in fixed size blocks, such as 4K, and then uses the resulting data similar to other fixed block disk systems. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Rich Alderson <news@alderson.users.panix.com> |
|---|---|
| Date | 2011-05-26 16:15 -0400 |
| Message-ID | <mddvcwxkylh.fsf@panix5.panix.com> |
| In reply to | #499 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> It has been a while since I thought about this. I did used to read
> EBCDIC tapes from OS/360 on TOPS-10, with my own conversion program
> written in Fortran. I don't remember how the blocking came out now,
> but the favorite format (RECFM) at the time was fixed length 80
> byte records, blocked at something like 3200 bytes.
> DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200)
> I believe it comes out four bytes per PDP-10 word.
Yes. However, there are no system calls for *disk* data capable of
treating a file as anything other than blocks of 128 words. The
content is then either 7 ASCII characters packed per word, or 36 bits.
No other choices are available.
In fact, in order to write your 4 8-bit bytes back to tape such that
it reads natively on the 360/370, you must open the file as 36-bit
data, then programmatically insert an 8-bit byte pointer into the
file descriptor block allocated by the OPEN call. (Well, technically,
you could open it as 7-bit ASCII data and do the same thing. That
just seems more wrong, somehow.)
> I also remember doing direct access files in Fortran, I believe
> with records that were multiples of the disk block size.
Yup. No "bytes" need apply.[1]
>> I write professional documentation in LaTeX. (Then again, I'm probably
>> an old guy, so it doesn't count.) I can move my documentation sources
>> from Windows (mandated by the IT department) to Mac OS X (at home) to
>> any Linux or BSD version (JBIFLI), and get the same results on any of them.
> That is part of the design of TeX. All calculations that affect the
> typesetting output are in fixed point. (With varying numbers of
> bits after the binary point, mostly 16.) Some messages use floating
> point, though. Do you have TeX on TOPS-20?
As a matter of fact, we do. It is seriously down-rev from modern TeX
implementations, still requiring postprocessors like dvitops, so I don't
make much use of it there any longer. Oh, and it only supports LaTeX 2.09;
LaTeX 2\epsilon requires a more modern TeX...
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-05-26 23:56 +0000 |
| Message-ID | <irmpbd$rm0$1@dont-email.me> |
| In reply to | #512 |
In vmsnet.pdp-11 Rich Alderson <news@alderson.users.panix.com> wrote: (snip, I wrote) >> It has been a while since I thought about this. I did used to read >> EBCDIC tapes from OS/360 on TOPS-10, with my own conversion program >> written in Fortran. I don't remember how the blocking came out now, >> but the favorite format (RECFM) at the time was fixed length 80 >> byte records, blocked at something like 3200 bytes. >> DCB=(RECFM=FB,LRECL=80,BLKSIZE=3200) >> I believe it comes out four bytes per PDP-10 word. > Yes. However, there are no system calls for *disk* data capable of > treating a file as anything other than blocks of 128 words. The > content is then either 7 ASCII characters packed per word, or 36 bits. > No other choices are available. > In fact, in order to write your 4 8-bit bytes back to tape such that > it reads natively on the 360/370, you must open the file as 36-bit > data, then programmatically insert an 8-bit byte pointer into the > file descriptor block allocated by the OPEN call. (Well, technically, > you could open it as 7-bit ASCII data and do the same thing. That > just seems more wrong, somehow.) That was all in Fortran, and about 35 years ago. I wasn't so sure how much was done by the Fortran library, and how much by the OS. Also, it was using old tapes and the always unreliable 800 BPI NRZI coded tape. I don't remember now if I ever wrote tapes to bring back to S/370. About two years later the PDP-10 was replaced with a VAX, and I had to learn how to write AL tapes on the 370. The non-obvious problem was that OS/VS2 knew how to read/write/mount AL tapes, but ASP (later JES3) did not. After much discussion, I learned about deferred mounting such that ASP didn't have to see the tape. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Rich Alderson <news@alderson.users.panix.com> |
|---|---|
| Date | 2011-05-27 14:37 -0400 |
| Message-ID | <mddy61souqu.fsf@panix5.panix.com> |
| In reply to | #517 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> About two years later the PDP-10 was replaced with a VAX, and I
> had to learn how to write AL tapes on the 370. The non-obvious
> problem was that OS/VS2 knew how to read/write/mount AL tapes,
> but ASP (later JES3) did not. After much discussion, I learned
> about deferred mounting such that ASP didn't have to see the tape.
HASP (later JES2) *did*.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-05-27 00:02 +0000 |
| Message-ID | <irmpml$rm0$2@dont-email.me> |
| In reply to | #512 |
In vmsnet.pdp-11 Rich Alderson <news@alderson.users.panix.com> wrote: (snip, I wrote) >> I also remember doing direct access files in Fortran, I believe >> with records that were multiples of the disk block size. > Yup. No "bytes" need apply.[1] Maybe some here will remember PCAVES. The program using Fortran direct access files was a translation of the BASIC program PCAVES. It allows one to move between caves, write on the walls, read what others have written and even dig new caves. This was just after we got FILDAE to allow world access to a file by one specific program. It also did record locking, such that more than one person could use it at the same time, as long as they didn't run into each other. The record locking was done using small MACRO-10 programs written by someone else. Very simple, and, as far as I could tell, they didn't even need to know which file I was reading. As with the BASIC program (written for a HP TSB-2000 system), the direct access files were based on fixed length records, allowing for a fixed amount of writing. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Johnny Billquist <bqt@softjar.se> |
|---|---|
| Date | 2011-05-26 20:17 -0700 |
| Message-ID | <irn54h$87p$1@Iltempo.Update.UU.SE> |
| In reply to | #518 |
On 2011-05-26 17.02, glen herrmannsfeldt wrote: > In vmsnet.pdp-11 Rich Alderson<news@alderson.users.panix.com> wrote: > > (snip, I wrote) >>> I also remember doing direct access files in Fortran, I believe >>> with records that were multiples of the disk block size. > >> Yup. No "bytes" need apply.[1] > > Maybe some here will remember PCAVES. The program using Fortran > direct access files was a translation of the BASIC program PCAVES. > It allows one to move between caves, write on the walls, read what > others have written and even dig new caves. This was just after > we got FILDAE to allow world access to a file by one specific program. > > It also did record locking, such that more than one person could > use it at the same time, as long as they didn't run into each other. > The record locking was done using small MACRO-10 programs written > by someone else. Very simple, and, as far as I could tell, they > didn't even need to know which file I was reading. > > As with the BASIC program (written for a HP TSB-2000 system), > the direct access files were based on fixed length records, > allowing for a fixed amount of writing. You are all missing the point with regards to disks here. It don't matter what the OS presents you with. That is an abstraction layer. The actual, physical disk use disk blocks. Not a stream of bytes. (Well, there were actually some disks in the old days who almost did, but that is another story, and besides, it's not totally a stream of bytes even for those). Johnny
[toc] | [prev] | [next] | [standalone]
| From | Rich Alderson <news@alderson.users.panix.com> |
|---|---|
| Date | 2011-05-27 14:51 -0400 |
| Message-ID | <mddvcwwou3u.fsf@panix5.panix.com> |
| In reply to | #522 |
Johnny Billquist <bqt@softjar.se> writes:
> You are all missing the point with regards to disks here. It don't
> matter what the OS presents you with. That is an abstraction layer. The
> actual, physical disk use disk blocks. Not a stream of bytes. (Well,
> there were actually some disks in the old days who almost did, but that
> is another story, and besides, it's not totally a stream of bytes even
> for those).
No, as a matter of fact, we are *not* missing the point: Disk access is
in blocks. On the PDP-10 under Tops-10, TOPS-20 and TENEX (and probably
ITS, those blocks are 128 words long (plus some overhead for parity,
checksums and the like that are invisible to the programmer), while on
IBM System/360 family systems, the size of the block is under programmer
control but is still the addressable unit of storage on the disk.
The abstraction layer from the OS may or may not hide block size from you.
Tops-10, for example, does not. TENEX/TOPS-20 presents disk data to the
programmer in 512-word (4 block) pages (or in bytes or byte-strings or
integers or floating-point numbers, depending on system call, but the OS
buffers are in pages).
Prior to the introduction of virtual memory to IBM's computers, the OS
never hid the block size from you. With the advent of VSAM (Virtual
Storage Access Method), disks could be blocked at something other than
the programmer's whim, though the older access methods could still be
used as well.
But in none of these cases does the OS force the view of a disk as a
stream of bytes.
--
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-27 12:48 -0700 |
| Message-ID | <irov6i$ph6$1@Iltempo.Update.UU.SE> |
| In reply to | #530 |
On 2011-05-27 11.51, Rich Alderson wrote: > Johnny Billquist<bqt@softjar.se> writes: > >> You are all missing the point with regards to disks here. It don't >> matter what the OS presents you with. That is an abstraction layer. The >> actual, physical disk use disk blocks. Not a stream of bytes. (Well, >> there were actually some disks in the old days who almost did, but that >> is another story, and besides, it's not totally a stream of bytes even >> for those). > > No, as a matter of fact, we are *not* missing the point: Disk access is > in blocks. Well, the comment wasn't directed at you, Rich. Sorry if it came across that way. Johnny
[toc] | [prev] | [next] | [standalone]
| From | Rich Alderson <news@alderson.users.panix.com> |
|---|---|
| Date | 2011-05-27 14:35 -0400 |
| Message-ID | <mdd1uzkq9dn.fsf@panix5.panix.com> |
| In reply to | #512 |
Rich Alderson <news@alderson.users.panix.com> writes:
> Yes. However, there are no system calls for *disk* data capable of
> treating a file as anything other than blocks of 128 words. The
> content is then either 7 ASCII characters packed per word, or 36 bits.
That should read "7-bit ASCII characters packed 5 per word." Typing got
behind thinking.
> Yup. No "bytes" need apply.[1]
Forgot the footnote.
[1] On the PDP-10, "byte" is defined as any subportion of the 36-bit word
(which is the addressable unit of memory), rather than "8-bit addressable
piece of memory".
--
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 | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-05-25 21:14 -0400 |
| Message-ID | <irk9fg$pp9$1@dont-email.me> |
| In reply to | #489 |
[Multipart message — attachments visible in raw view] — view raw
>Bill Gunshannon wrote:
>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!!
>
Just thought I would add a bit of information about overlays
in response to "Now there was a science!!".
I made some modifications to MACRO-11 which counts the
number of times an overlay is read into memory in addition
to the number of times the overlay is called - the difference
being the number of times the overlay was called, but was
already memory. The numbers are displayed at the end
of the listing along with the elapsed time.
A sample output follows this post. Note that the same assembly
takes over 11 minutes on a PDP-11/83.
MACRO-11 has one root section (or permanent overlay) and 13
overlay segments distributed across 3 regions:
Region 1: 1 2 3 4
Region 2: 5 6 7 8 9
Region 3: 10 11 12 13
Outside of initialization and termination code, only overlays 4,
9 and 11 seem to be used or one from each region.
Summarizing the results is very easy. Most overlays are read
into memory (after being called, of course) a limited number
of times no matter how large the source code. Overlays 4,
9 and 11 can be called (without being read into memory)
hundreds of thousands of times. An order of magnitude
estimate is about 1 million total calls for each 1000 blocks
of source code.
BUT, THE TOTAL NUMBER OF READS IS LESS
THAN 100 FOR EVERY EXAMPLE THAT WAS
TESTED!!!!!!!!!!!!!!!!!
The overlay handler uses only about a dozen instructions to
call an overlay segment which is already in memory. So the
overhead in minimal if the subroutine being called does not
need to be read into memory.
I agree that DEC had many decades to optimize MACRO-11.
Perhaps DEC even wrote its own test code which did the same
as my modification. The counts were not hard to keep once I
saw the expected results - 32 bit count for the number of calls
and a 16 bit counts for the number of reads or 3 words for each
overlay. For extra insurance, I also kept a 48 bit count for the
total number of calls and the total number of reads (just in case)
since each additional word required only the "AdC (R0)+"
instruction with no testing or branches after the first word used
"Add #1,(R0)+" to advance the count. Since I initially had no
idea how many calls or reads were being made, a 48 bit
count was guaranteed to be sufficient. Printing out the results
was the difficult part.
If anyone is interested, let me know. After I finish the documentation,
I will release the code. Meanwhile, if you have an example you want
to check, I can download the files if they are more than 1 MB. Otherwise,
use Zip or BZip2 and e-mail me the files which should reduce them to
less than 1/2 MB. Please include a SYSMAC.SML file if you need
a particular version.
Jerome Fine
------------------------------------------------------------------------------------------
Sample Set of Count Values - Approximately 1100 blocks of Source Files
Errors detected: 0
*** Assembler statistics
Work file reads: 943
Work file writes: 756
Size of work file: 38984 Words ( 153 Pages)
Size of core pool: 21760 Words ( 85 Pages)
Use of Overlays: 1 2 3 4 5 6 7 8 9 10 11 12 13 Total
Segment Calls: 11 5 3 528006 1 1 3 7 494138 106 135960 12 0 1158253
Required Reads: 11 5 3 10 1 1 3 5 6 10 20 10 0 85
Operating system: RT-11
Program File Name: LD2:MACRO.SAV[93]
Names of .FETCHed: None
Device Drivers: None
Elapsed time: 00:00:39.07
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2011-05-26 01:32 +0000 |
| Message-ID | <irkaih$sqr$2@dont-email.me> |
| In reply to | #497 |
In alt.sys.pdp11 Jerome H. Fine <everyone@nospam.com> wrote: (snip) > I made some modifications to MACRO-11 which counts the > number of times an overlay is read into memory in addition > to the number of times the overlay is called - the difference > being the number of times the overlay was called, but was > already memory. The numbers are displayed at the end > of the listing along with the elapsed time. I used to know how the overlay for OS/360 worked. I believe it is only two instructions if the segment is already in memory. It uses self-modifying code to write the load and branch instructions to not call the overlay handler. (Branch to an arbitrary address takes two instructions, load the address into a register, and then branch.) I do remember using the RT-11 overlay system with Fortran, but not how many instructions it took. I would think it could use something similar to the self modifying branch, though. -- glen
[toc] | [prev] | [next] | [standalone]
| From | "Jerome H. Fine" <everyone@nospam.com> |
|---|---|
| Date | 2011-05-26 16:39 -0400 |
| Message-ID | <4ddeba69$0$302$14726298@news.sunsite.dk> |
| In reply to | #500 |
[Multipart message — attachments visible in raw view] — view raw
>glen herrmannsfeldt wrote: >>In alt.sys.pdp11 Jerome H. Fine <everyone@nospam.com> wrote: > >(snip) > > >>I made some modifications to MACRO-11 which counts the >>number of times an overlay is read into memory in addition >>to the number of times the overlay is called - the difference >>being the number of times the overlay was called, but was >>already memory. The numbers are displayed at the end >>of the listing along with the elapsed time. >> >> >I used to know how the overlay for OS/360 worked. I believe >it is only two instructions if the segment is already in >memory. It uses self-modifying code to write the load and >branch instructions to not call the overlay handler. >(Branch to an arbitrary address takes two instructions, >load the address into a register, and then branch.) > > I just looked again at the RT-11 overlay handler for low memory overlays. The exact instruction count is 15 instructions in total (including the instruction which CALLs the instruction which CALLs the overlay handler with the required arguments) when the subroutine is in an overlay which is already in memory. 15 instructions includes a redundant PUSH and POP of R0 when the overlay is in memory - although it was convenient to keep them in order to use R0 as the base address of the table which keeps track of the number of times an overlay is CALLed. The code is also self modifying, but ONLY the very first time an overlay segment is CALLed so that all of the memory used by overlays can be zeroed. The method adds an extra CALL instruction, but reduces overall code size when many calls are made to the same subroutine in an overlay. >I do remember using the RT-11 overlay system with Fortran, >but not how many instructions it took. I would think it could >use something similar to the self modifying branch, though. > The overlay handler code is identical no matter which language is used. The instruction used to CALL the instruction which CALLs the overlay handler with the correct arguments is also compatible with FORTRAN conventions as well as every other language since other than the initial CALL instruction, everything else is hidden from the user application program. Jerome Fine
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201105.rodent.frell.theremailer.net> |
|---|---|
| Date | 2011-05-26 17:50 +0200 |
| Message-ID | <6461433cc98387dd993772772b0b91f3@msgid.frell.theremailer.net> |
| In reply to | #489 |
billg999@cs.uofs.edu (Bill Gunshannon) wrote: > 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. That's not true. Many IBM access methods are based on the contents of blocks, tracks, or cylinders. Depending on whether you let the system do the blocking and deblocking or not, you can be presented with a whole block. That is the unit of transmission. Access methods like VSAM read a whole cylinder at a time. Access methods like VSAM LDS let you work on the block level. BDAM cares about cchhr. > 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. There is new COBOL written as in new systems. It isn't written by as many people as write Java, C++ etc. but the linecount of all COBOL is still probably lines of Java raised to the power of lines of C++. > 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. :-) He's just running a BSD-based kernel with an Apple userland. I guess it's more like Linux than BSD. In the end, graphical user interface is what killed all the great software. Now all you have to do is a write a good GUI and nothing else matters.
[toc] | [prev] | [next] | [standalone]
| From | Rich Alderson <news@alderson.users.panix.com> |
|---|---|
| Date | 2011-05-24 21:01 -0400 |
| Message-ID | <mddaaeb7fvd.fsf@panix5.panix.com> |
| In reply to | #481 |
Johnny Billquist <bqt@softjar.se> writes:
> On 2011-05-24 09.42, Bill Gunshannon wrote:
>> 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...
Actually, MUMPS originated on the PDP-15. But then, so did RSX!
Of course, Unix originated on the PDP-7, an earlier part of the same
family. ;->
>> 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.
Not according to the company that sells it (renamed Cache'), or people I
know who make a living writing it.
--
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]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.sys.dec
csiph-web