>
> I always laughed at the early quiz shows where they had a ``computer'
> selecting the questions -- where the computer was really a card sorter that
> would select the picked question into a specific bin.
>
> Bill
Knowing Hollywood, it was probably a prop, with a human behind it sorting the
cards!

It is not surprising how much I forgot from almost 30 years ago.

--
MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Sat, 2008-10-25 at 10:17 -0500, David G. Mackay wrote:
> <snip>

> Then came CANDE, TD8xx terminals, and editing on your head-per-track
> disk. Ah for the good old days, when men were men, and memory upgrades
> involved fork lifts.

I tried to stay out of this thread, I really did. But the "forklift"
reference hooked me.

Circa 1971/2(?), we had an IBM S360/30 with 64K (that's right, "K", "M")
bytes of "core" (back then, no simms, dimms, ...). Running IBM DOS, we
had three partitons going, 1 bg, 2 fg. It was decided that an
aftermarket upgrade would allow us to consolidate the two foreground
functions into one and use two background partitions for batch
production processing.

The aftermarket expansion was bought and took us up to a "whopping" 96KB
of "core" memory. The expansion unit (best I can recall) was about 5.5'
x 8' x 3', or 132 cubic feet. 8-O

Anyway, a forklift took it off the truck. And large hand pallet jack was
used to roll it across the raised flooring.

It did the job too. It was several years before we upgraded to a S360/50
with 512K (IIRC).

>
> Dave
> <snip sig stuff>

--
Bill

BTW: It wasn't "old farts", it was "curmudgeon", which one poster
thought was heavialy age related. It often is, but the "classical"
definition (IOW, not "Wikipedia" definition) relates that it is only
"often" related to age.

Regardless, I'm an "old fart" too. OFOFMC = Old fart On Fast Motorcycle.
1994 Yam YZF750. Its nicknames: Holy S**T and OMG! =>:-O


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Sat, 2008-10-25 at 12:14 -0400, William L. Maltby wrote:
> <snip>

> Circa 1971/2(?), we had an IBM S360/30 with 64K (that's right, "K", "M")
s/"M"/not "M"/

--
Bill

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

https://secure.motu.com/developer.html
i can't remove havp.
--
JUAN CARLOS TENORIO.


--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

On Sat, Oct 25, 2008, William L. Maltby wrote:
>
>On Sat, 2008-10-25 at 10:17 -0500, David G. Mackay wrote:
>> <snip>
>
>> Then came CANDE, TD8xx terminals, and editing on your head-per-track
>> disk. Ah for the good old days, when men were men, and memory upgrades
>> involved fork lifts.

>I tried to stay out of this thread, I really did. But the "forklift"
>reference hooked me.
>
>Circa 1971/2(?), we had an IBM S360/30 with 64K (that's right, "K", "M")
>bytes of "core" (back then, no simms, dimms, ...). Running IBM DOS, we
>had three partitons going, 1 bg, 2 fg. It was decided that an
>aftermarket upgrade would allow us to consolidate the two foreground
>functions into one and use two background partitions for batch
>production processing.
>
>The aftermarket expansion was bought and took us up to a "whopping" 96KB
>of "core" memory. The expansion unit (best I can recall) was about 5.5'
>x 8' x 3', or 132 cubic feet. 8-O
>
>Anyway, a forklift took it off the truck. And large hand pallet jack was
>used to roll it across the raised flooring.
>
>It did the job too. It was several years before we upgraded to a S360/50
>with 512K (IIRC).

And our Burroughs B-3500 would run circles around the 360/50.
The Burroughs had a whopping 200KB of memory, ran an average of
20 jobs in the mix, and didn't require 40 JCL cards to compile
and run a one line Hello World FORTRAN program.

Burroughs invented virtual memory in the early 60s in their large
systems allowing them to run large programs in small memory.
When IBM invented thrashing, called it virtual memory, the
minimum memory requirements to run it was 1MB requiring major
updgrades to support it. IBM never wrote a line of code that
was not designed to sell more hardware.

Bringing this back to Linux, at that time IBM occupied the place
of honor that Microsoft has now with an effective monopoly, a
cumbersome and inefficient system requiring an army of support
people to keep it running, and required constant patching.

Bill
--
INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186

Find out just what people will submit to, and you have found out the
exact amount of injustice and wrong which will be imposed upon them; and
these will continue until they are resisted with either words or blows, or
both. The limits of tyrants are prescribed by the endurance of those whom
they oppress. -- Frederick Douglass.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Sat, 2008-10-25 at 12:16 -0400, William L. Maltby wrote:
> On Sat, 2008-10-25 at 12:14 -0400, William L. Maltby wrote:
> > <snip>
>
> > Circa 1971/2(?), we had an IBM S360/30 with 64K (that's right, "K", "M")
> s/"M"/not "M"/

Yep. The first computer I programmed on was an IBM 1130 with 16K of
core. You could power down for the weekend, and the memory contents
would still be there when you powered up on Monday.

Dave


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Sat, 2008-10-25 at 10:30 -0700, Bill Campbell wrote:

> And our Burroughs B-3500 would run circles around the 360/50.
> The Burroughs had a whopping 200KB of memory, ran an average of
> 20 jobs in the mix, and didn't require 40 JCL cards to compile
> and run a one line Hello World FORTRAN program.

The good old Master Control Program at work.

> Burroughs invented virtual memory in the early 60s in their large
> systems allowing them to run large programs in small memory.
> When IBM invented thrashing, called it virtual memory, the
> minimum memory requirements to run it was 1MB requiring major
> updgrades to support it. IBM never wrote a line of code that
> was not designed to sell more hardware.

Of course, there was the time that the large systems group put the
segment-not-present handler in an overlayable segment. The good folks
at the factory had machines with max memory, so it wasn't a problem for
them. It was a nice hard hang for those that didn't have enough memory.

> Bringing this back to Linux, at that time IBM occupied the place
> of honor that Microsoft has now with an effective monopoly, a
> cumbersome and inefficient system requiring an army of support
> people to keep it running, and required constant patching.

Yes, but at least IBM tested their equipment, and HAD sufficient support
folks. I used to work for Burroughs, and that was a source of
frustration for all concerned.

Dave


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Sat, 2008-10-25 at 10:30 -0700, Bill Campbell wrote:
> <snip>

> >
> >It did the job too. It was several years before we upgraded to a S360/50
> >with 512K (IIRC).
>
> And our Burroughs B-3500 would run circles around the 360/50.
> The Burroughs had a whopping 200KB of memory, ran an average of
> 20 jobs in the mix, and didn't require 40 JCL cards to compile
> and run a one line Hello World FORTRAN program.
>
> Burroughs invented virtual memory in the early 60s in their large
> systems allowing them to run large programs in small memory.
> When IBM invented thrashing, called it virtual memory, the
> minimum memory requirements to run it was 1MB requiring major
> updgrades to support it. IBM never wrote a line of code that
> was not designed to sell more hardware.
>
> Bringing this back to Linux, at that time IBM occupied the place
> of honor that Microsoft has now with an effective monopoly, a
> cumbersome and inefficient system requiring an army of support
> people to keep it running, and required constant patching.

Yep. I was very fortunate to have worked in that environment so long. It
gave me a very good living because I seemed to have a better than
average ability to handle all that stuff. I was one of those that
actually read the docs (IBM seemed to be very thorough about that) and
could recall/reference many months later the answers to some problem.

Even back then when folks bad-mouthed them, I didn't care. I made good
$$, the only criteria that mattered to me then.

--
Bill (the other one)


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Sat, Oct 25, 2008, David G. Mackay wrote:
>On Sat, 2008-10-25 at 10:30 -0700, Bill Campbell wrote:
>
>> And our Burroughs B-3500 would run circles around the 360/50.
>> The Burroughs had a whopping 200KB of memory, ran an average of
>> 20 jobs in the mix, and didn't require 40 JCL cards to compile
>> and run a one line Hello World FORTRAN program.
>
>The good old Master Control Program at work.
>
>> Burroughs invented virtual memory in the early 60s in their large
>> systems allowing them to run large programs in small memory.
>> When IBM invented thrashing, called it virtual memory, the
>> minimum memory requirements to run it was 1MB requiring major
>> updgrades to support it. IBM never wrote a line of code that
>> was not designed to sell more hardware.
>
>Of course, there was the time that the large systems group put the
>segment-not-present handler in an overlayable segment. The good folks
>at the factory had machines with max memory, so it wasn't a problem for
>them. It was a nice hard hang for those that didn't have enough memory.

My first Burroughs experience was on the B-5500, and it had some
``interesting' quirks. Using Burroughs extended ALGOL, one could do what
they called array row writes to very efficiently write large chunks of
memory with a single hardware command. The hitch was that if one tried to
write more than 1024 48bit words, it would crash the entire system, with a
side effect of losing the accounting information for all running programs,
which could be useful when paying $750/hour for time sharing :-).

>> Bringing this back to Linux, at that time IBM occupied the place
>> of honor that Microsoft has now with an effective monopoly, a
>> cumbersome and inefficient system requiring an army of support
>> people to keep it running, and required constant patching.
>
>Yes, but at least IBM tested their equipment, and HAD sufficient support
>folks. I used to work for Burroughs, and that was a source of
>frustration for all concerned.

Are you retired Air Farce? A fair number of Burroughs field engineers had
learned the Burroughs equipment in the AF (and could afford to work at BGH
low pay because of their retirement pay).

One might say that I worked for Burroughs too as I debugged their Remote
Job Entry (RJE) software for Medium systems, including patching MCP,
because the company I worked for needed it to work. I talked Burroughs out
of the source code for RJE and the current version of MCP so that I could
fix things. After I sent them the fixes, I never had any problem getting
anything I asked for.

FWIW, the entire source code listing for MCP fit in a single file drawer.
Reading the comments in the code, it was obvious that a very small group of
people worked on it which resulted in quite nice integration and
consistency.

Can you imagine`Microsoft making the source code for Windows available to a
small customer for free, and with no NDA so the customer could fix a
problem that was critical to them? Even if they supplied the source, do
you think anybody could figure it out?

One of the most important features of open source software is the
availability of the source code so people can quickly fix bugs critical to
them or add features they need. As an example, in January 2000, groff had
a y2k problem with dates which I found printing a letter that needed to go
out. It took me about 15 minutes to find the problem in the code, fix it,
and send that patch back to the maintainers. Imagine how long it would
take to get a similar problem fixed in M$-Word.

Bill
--
INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
Voice: (206) 236-1676 Mercer Island, WA 98040-0820
Fax: (206) 232-9186

Bagdikian's Observation:
Trying to be a first-rate reporter on the average American
newspaper is like trying to play Bach's "St. Matthew Passion"
on a ukelele.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

On Sat, 2008-10-25 at 12:10 -0700, Bill Campbell wrote:

> My first Burroughs experience was on the B-5500, and it had some
> ``interesting' quirks. Using Burroughs extended ALGOL, one could do what
> they called array row writes to very efficiently write large chunks of
> memory with a single hardware command. The hitch was that if one tried to
> write more than 1024 48bit words, it would crash the entire system, with a
> side effect of losing the accounting information for all running programs,
> which could be useful when paying $750/hour for time sharing :-).

I'm surprised that the bug lasted very long, or did it just go
unreported?

> Are you retired Air Farce? A fair number of Burroughs field engineers had
> learned the Burroughs equipment in the AF (and could afford to work at BGH
> low pay because of their retirement pay).

No, I was just young and foolish. Then someone explained that Burroughs
wanted to get their techs hired away by the customers. They'd most
likely continue to support Burroughs equipment, but on someone else's
nickel.

> One might say that I worked for Burroughs too as I debugged their Remote
> Job Entry (RJE) software for Medium systems, including patching MCP,
> because the company I worked for needed it to work. I talked Burroughs out
> of the source code for RJE and the current version of MCP so that I could
> fix things. After I sent them the fixes, I never had any problem getting
> anything I asked for.

It's impressive that you managed to talk them out of the source, and
that you fixed it.

> FWIW, the entire source code listing for MCP fit in a single file drawer.
> Reading the comments in the code, it was obvious that a very small group of
> people worked on it which resulted in quite nice integration and
> consistency.

Legend had it that the medium systems MCP was mostly written by one guy
who lived in a beach house in California with two women.

> Can you imagine`Microsoft making the source code for Windows available to a
> small customer for free, and with no NDA so the customer could fix a
> problem that was critical to them? Even if they supplied the source, do
> you think anybody could figure it out?

Well, I did have a go at their Device Driver kit at one point.
Convoluted is the first printable word that comes to mind.

> One of the most important features of open source software is the
> availability of the source code so people can quickly fix bugs critical to
> them or add features they need. As an example, in January 2000, groff had
> a y2k problem with dates which I found printing a letter that needed to go
> out. It took me about 15 minutes to find the problem in the code, fix it,
> and send that patch back to the maintainers. Imagine how long it would
> take to get a similar problem fixed in M$-Word.

Yes. Trying to support a black box (It took YEARS before they released
the source code to the B1xx systems to their support employees outside
of the plant) made me a firm believer in open source.

Dave


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos