"My son can do it a LOT cheaper than your estimate"
Lisa-Jeff
The other day, in discussing a $90,000 mainframe based system with a
user, the user replied that his son reviewed the Requirements and felt a
PC client/server system could be developed for $10,000 and that our
price was thus grossly excessive.
I've been hearing that for years, in the old days it was users with
mini-computers claiming they could do anything a mainframe did at a much
cheaper price. I've generally felt such comparisons were apples and
oranges, but it's never been easy for me to refute them.
In my feeling....
Our solution is a complete solidly constructed and fully tested
approach. The cheapo would be just that "cheap", very difficult to
maintain, no backup/restore capability, no training, poor user
documentation.
Comments invited.
Paul Tomblin
In a previous article, hanc...@cpcn.com (Lisa-Jeff) said:
>The other day, in discussing a $90,000 mainframe based system with a
>user, the user replied that his son reviewed the Requirements and felt a
>PC client/server system could be developed for $10,000 and that our
>price was thus grossly excessive.
Tell him that his son's bid will be considered when he can demonstate that it
can stay up for a week without any downtime, can do live backups without
interrupting the application, won't lose any data if you kick the plug at any
random time on either the client or the server, can restore from backups, etc.
I've never met a PC (running a Microsoft operating system, anyway) that could
stay up under a heavy load without being rebooted almost daily. (My linux box
stays up for months at a time, but it's not particularly heavily stressed.)
--
Paul Tomblin, PP-ASEL _|_ Rochester Flying Club web page:
____/___\____ http://www.servtech.com/public/
___________[o0o]___________ ptomblin/rfc.html
ptom...@xcski.com O O O
Simon Slavin
In article <DyFC7...@midway.uchicago.edu>,
hanc...@cpcn.com (Lisa-Jeff) wrote:
> The other day, in discussing a $90,000 mainframe based system with a
> user, the user replied that his son reviewed the Requirements and felt a
> PC client/server system could be developed for $10,000 and that our
> price was thus grossly excessive. [snip]
>
> Our solution is a complete solidly constructed and fully tested
> approach. The cheapo would be just that "cheap", very difficult to
> maintain, no backup/restore capability, no training, poor user
> documentation.
Depends what's important to your client. There's nothing inherent
in a micro-based solution that implies that there will be poor
maintenance, training or documentation. Why do you assume so ? I
was delighted earlier this year to see a package I wrote ten years
ago for an international bank was still in daily use.
However, breaking a network cable can cause problems with /all/
the machines. A faulty network card in one machine can be quite
difficult to diagnose, whereas crashing one terminal of a mainframe
system is rarely much of a problem. OTOH, the refitting and
staffing costs, insurance and future commitment for a mainframe
can be tremendously higher than merely adding one package to an
existing network of micros.
PS: Hi, Lisa-Jeff. I haven't worked out your agenda but I'm still
reading your posts.
Simon.
--
Simon Slavin -- Computer Contractor Ordinaire
"Waddaya want a fake ID for ?" "So I can vote." -- _The Breakfast Club_
This isn't much of a .sig, but then that wasn't much of a post.
Lon Stowell
In article <DyFC7...@midway.uchicago.edu>
hanc...@cpcn.com (Lisa-Jeff) writes:
>The other day, in discussing a $90,000 mainframe based system with a
>user, the user replied that his son reviewed the Requirements and felt a
>PC client/server system could be developed for $10,000 and that our
>price was thus grossly excessive.
POSSIBLE, but either the potential user had egregiously overstated
their requirements or this luser deserves what is gonna happen when
they let their kid do the PC system.
>I've been hearing that for years, in the old days it was users with
>mini-computers claiming they could do anything a mainframe did at a much
>cheaper price. I've generally felt such comparisons were apples and
>oranges, but it's never been easy for me to refute them.
Worse, simplistic benchmark and pilot projects can give a too
optimistic view of the workloads and therefore the real system
requirements in terms of compute horsepower, I/O bandwidth, and
networking thruput.
Those ARE your best weapons, but some users simply deserve to
find things out the hard way.
Of course, the whiz kid COULD be right. >:-)
Bennett Todd
On Sat, 28 Sep 1996 03:55:02 GMT, Lisa-Jeff <hanc...@cpcn.com> wrote:
>The other day, in discussing a $90,000 mainframe based system with a user,
>the user replied that his son reviewed the Requirements and felt a PC
>client/server system could be developed for $10,000 and that our price was
>thus grossly excessive.
Sounds perfectly normal to me.
>Our solution is a complete solidly constructed and fully tested approach.
>The cheapo would be just that "cheap", very difficult to maintain, no
>backup/restore capability, no training, poor user documentation.
Could well be. There may well be problems for which a mainframe remains the
best solution, though I haven't seen any in the kinds of work I've been
involved with. But mainframes, unsurprisingly for such vintage technology,
represent a stable, mature approach to solving classic business data
processing problems. They may cost 10-100 times as much as a well-engineered
modern solution, but they will be well-documented and stable.
Of course, a good job of systems analysis and systems engineering will
assemble you a much cheaper solution. For something as small as you are
describing, one good engineer oughta be able to spec out, assemble, and
configure the system. Now that engineer won't come cheap --- their salary will
eat the difference between a $10,000 hardware platform and a $90,000 box,
easily. But the problem with mainframes is that they don't cost you once,
they cost you over and over and over. A $90,000 box won't require the
environmental expendatures of a classic mainframe, but it'll still eat its own
weight in maintenance fees and service contracts. The real savings with a
well-engineered PC solution is that the maintenance costs are so low. They are
cheap enough so you don't carry any maintenance at all, you just replace parts
as they break. You also periodically replace non-broken parts to take
advantage of hardware improvements. For instance, 3 years ago a 486DX2-66 with
32MB RAM was a very reasonable platform for a medium-size multiuser box, e.g.
for an ISP. By now it would have been upgraded at least twice, each time
incrementally, just purchasing a few new parts and substituting them in; the
resulting box will have many times the capacity of the original, and the
entire monies expended in upgrading and in replacing things that break will be
maybe $5,000-$10,000. Now look at the annual fees to keep a mainframe running
over 3 years.
If you have money to burn, a mainframe solution does prevent you from having
to worry so much about finding good people. But it will cost and cost and
cost, until you finally get sick of it and upgrade to a cheaper and faster
hardware base.
-Bennett
Terry Kennedy, Operations Mgr.
In article <DyFC7...@midway.uchicago.edu>,
hanc...@cpcn.com (Lisa-Jeff) writes:
> The other day, in discussing a $90,000 mainframe based system with a
> user, the user replied that his son reviewed the Requirements and felt a
> PC client/server system could be developed for $10,000 and that our
> price was thus grossly excessive.
You might want to give your user a copy of Brooks' "The Mythical Man-Month",
in particular the section in the first chapter about "The Programming Systems
Product" where the "2 guys in a garage" story is debunked. This is from the
1982 edition - I don't know if it's in the original 1975 edition or the recent
updated edition.
Terry Kennedy Operations Manager, Academic Computing
te...@spcvxa.spc.edu St. Peter's College, Jersey City, NJ USA
+1 201 915 9381 (voice) +1 201 435-3662 (FAX)
Perry Lea
> I've never met a PC (running a Microsoft operating system, anyway)
> that could stay up under a heavy load without being rebooted almost
> daily. (My linux box stays up for months at a time, but it's not
> particularly heavily stressed.)
My NT 3.5 machine has been up for 2 months now. It was rebooted last
when someone came into my office and rebooted my machine without
permission. I always have these apps running : Netscape, Net mail, Net
News, Word, Excel, Visual C, and Exceed.
Doesn't seem to crash.
I remember a Unisys 1100 I worked on in school that would crash and
have to be rebooted for silly things like heat flow.
--
Perry Lea | E-Mail : per...@boi.hp.com
BLD R&D Lab Engineer | Phone : 208-396-6532
Hewlett Packard Company | Fax : 208-396-4806
http://hpbs4373.boi.hp.com/~perryl
Mark W. Aurit
In article <DyG7v...@midway.uchicago.edu>
ptom...@compass.xcski.com (Paul Tomblin) writes:
>In a previous article, hanc...@cpcn.com (Lisa-Jeff) said:
>>The other day, in discussing a $90,000 mainframe based system with a
>>user, the user replied that his son reviewed the Requirements and felt a
>>PC client/server system could be developed for $10,000 and that our
>>price was thus grossly excessive.
>
>Tell him that his son's bid will be considered when he can demonstate that it
>can stay up for a week without any downtime, can do live backups without
>interrupting the application, won't lose any data if you kick the plug at any
>random time on either the client or the server, can restore from backups, etc.
I agree with this, but to the unwashed (I'm assuming the sale is to be
made to a non-IS professional) a lot of it sounds esoteric and subtle.
Im my experience you're better off coming up with something the
customer can relate to and perhaps has experienced being hit with.
Analogies are very useful here.
But going back to the original post, the writer mentioned they he has
heard the "it can be done cheaper" for a long time. Tell me about it!
Along with these classics:
- it generates code, so you don't need any programming
- is so easy to follow, it's self-documenting
Unfortunate but true (and not just for our profession):
1. you get what you pay for (but you didn't know up front
what it would cost you!)
2. professionalism and discipline are not cheap
Mark
--
Mark Aurit
Business Systems
Northrop Grumman Data Systems (West)
mau...@world.northgrum.com
Alan Cashin
There are at least two comments that can be made:
(1) Many years ago I quoted $800 to do a particular job. The specs
were tight, the language and machine were fixed, it was just a matter
of delivering what was required. I completed the job in 80 hours for
$10/hr, good money in those days. As we were doing the final handover,
another person appeared and asked 'have you found someone to do the xyz
job yet' and the client said 'yes and we're just doing the handover'
and the person said 'but that job would take months' and went away
shaking his head.
I then asked how much the next quote was, and the client said $4000. I
had done the job (properly, to the spec) for 1/5 the next quote, and I
had made a reasonable margin. In the $90000/$10000 job, the developer
has the benefit of choosing techniques and development environment
which suit him - it is possible he could do the whole job for 1/10 with
those advantages. I have seen quite complex applications developed in
Delphi by an expert in hours. Without knowing the requirements it is
difficult to estimate the backup/training/documentation needed but
maybe the whole job could be done for the price using the right tools.
(2) Many clients are prepared to compromise on quality if they can save
on price. It is mainframe thinking that an application has to be
bulletproof, has to ride through power outages, has to be documented
within an inch of its life. I was friends with a garage proprietor who
had a really flakey system. Every few weeks he would lose his data,
restore from the previous backup and type in all the back transactions.
He claimed it was cheaper to do that than buy a better package which
had transaction journaling and could recover from an outage. I don't
think he was right, but it was what he wanted. The customer is always
right.
Alan
R. D. Davis
In article <DyFC7...@midway.uchicago.edu>,
Lisa-Jeff <hanc...@cpcn.com> wrote:
>The other day, in discussing a $90,000 mainframe based system with a
>user, the user replied that his son reviewed the Requirements and felt a
>PC client/server system could be developed for $10,000 and that our
>price was thus grossly excessive.
What you could have replied with: "All is not as it appears. What I'm
recommending won't crash as easily and won't need to be rebooted as
often. I'm sure that you'd rather entrust your company's data to a
reliable system, which will keep your data more secure as well, than
to risk tarnishing your company's reputation when problems arise. In
the long run, that IBM type PC based system could easily cost you more
money than the solution which I'm recommending."
>I've been hearing that for years, in the old days it was users with
>mini-computers claiming they could do anything a mainframe did at a much
>cheaper price. I've generally felt such comparisons were apples and
>oranges, but it's never been easy for me to refute them.
However, these little IBM type PCs are a horse of another color, so to
speak. Many executives know how to use them to write a few memos,
have one at home, etc., and think that they are computer experts
because of this. What one needs to keep in mind is that mainframes,
and minicomputers, frighten these people, because these systems are
alien to them. Furthermore, such people often also have a fear or
resentment of the employees that have to be hired to use these more
complex machines. These annoying psychological problems must be taken
into account when dealing with people whose only exposure is to
computers is exposre to microcomputers.
It's also good to be aware that companies like Microsoft, controlled
by the AntiLogic, play on these fears and feelings of technical
inadequacy. Hence, the people who know the least about computers in
large, and even small, companies often end up making purchasing
decisions after having their brains tinkered with by companies like
Microsoft.
>In my feeling....
>
>Our solution is a complete solidly constructed and fully tested
>approach. The cheapo would be just that "cheap", very difficult to
>maintain, no backup/restore capability, no training, poor user
>documentation.
Indeed. Your solution makes sense. Of course, if price is a problem
for the company, I'm sure that another good solution would be a used
mainframe or a suitable large, used, minicomputer. All better
solutions than those involving IBM type PCs.
Ob comp.folklore.society
------------------------
The story "VAXen, My Children, Just Don't Belong Some Places"
(filename on my ftp site in the DEC filk area: vaxen-my-children) is
very good reading material pertaining a bit to some of this. Granted,
it's slanted in favor of VAXen, but then, like the author of that
humorous little story, I like VAXen, PDP-11s, etc. :-) Perhaps it's
worthy of being posted here, if the moderator agrees.
--
R. D. Davis * Tel: +1 410 744-4900 (work) * http://www.access.digex.net/~rdd
===============================================================================
Computer preservationist - many types of unwanted older computer systems
disassembled, removed (mostly locally), and preserved.
Charlie Gibbs
>The other day, in discussing a $90,000 mainframe based system with a
>user, the user replied that his son reviewed the Requirements and felt
>a PC client/server system could be developed for $10,000 and that our
>price was thus grossly excessive.
>
>I've been hearing that for years, in the old days it was users with
>mini-computers claiming they could do anything a mainframe did at a
>much cheaper price. I've generally felt such comparisons were apples
>and oranges, but it's never been easy for me to refute them.
>
>In my feeling....
>
>Our solution is a complete solidly constructed and fully tested
>approach. The cheapo would be just that "cheap", very difficult
>to maintain, no backup/restore capability, no training, poor user
>documentation.
>
>Comments invited.
Mainframe ripoff artists notwithstanding, I agree. It's amazing
how many people fall for it - and subsequently wind up spending
far more in the end than they would have if they'd opted for the
properly designed system in the first place. See my .sig.
Charli...@mindlink.bc.ca
"There is nothing that someone cannot build a little poorer and
sell a little cheaper, and those who consider price only are
this man's lawful prey." -- unknown (source appreciated!)
R. D. Davis
In article <DyK98...@midway.uchicago.edu>,
Perry Lea <per...@hpbs2500.boi.hp.com> wrote:
>> I've never met a PC (running a Microsoft operating system, anyway)
>> that could stay up under a heavy load without being rebooted almost
>> daily. (My linux box stays up for months at a time, but it's not
>> particularly heavily stressed.)
>
>My NT 3.5 machine has been up for 2 months now. It was rebooted last
>when someone came into my office and rebooted my machine without
>permission. I always have these apps running : Netscape, Net mail, Net
>News, Word, Excel, Visual C, and Exceed.
>
>Doesn't seem to crash.
It's obvious that you have obtained a defective version of a Microsoft
product then - it obviously failed Microsoft's quality control
procedures: "Yeah, it crashes! - PASS" -- "Uh, oh, this won't
crash... FAIL!". Now you understand how the AntiLogic controlls
Microsoft, and wants to control YOU!
Remember all of those posters with Uncle Sam pointing at you, with the
wording "Uncle Sam wants you"? Well, my sources tell me that there
are rumours that deep down in the caverns below Microsoft
headquarters, there is a stockpile of posters with a certain little
twerp's picture on them, with the wording "The AntiLogic wants YOU!".
So you don't believe that the real Big Brother = the AntiLogic? Well,
you just wait.
>I remember a Unisys 1100 I worked on in school that would crash and
>have to be rebooted for silly things like heat flow.
Probably a result due to vandalism or improper cooling in the room
where it was located.
Ob comp.folklore.computers
--------------------------
Does anyone remember any other operating system related products in
the history of computing that are as poorly designed, or broken by
design, as Microsoft products?
Adam J. Thornton
In article <Dyr92...@midway.uchicago.edu>,
R. D. Davis <r...@access.digex.net> wrote:
>Does anyone remember any other operating system related products in
>the history of computing that are as poorly designed, or broken by
>design, as Microsoft products?
Well, only insofar as the real problem was lack of coherent design in the
first place, and too much design for too little computer in the second:
IBM's first cuts at OS/360 and TSS. TSS was actually well-designed and
elegant; it was just much, much too much program for the typical 360/67.
Norm Rasmussen at Lincoln Labs had a very early 360/67. Boot time of TSS
was about ten minutes, which was longer than his MTBF. That's mostly why
CP-67 got loose in the world. See Judy V. O'Neill's article on "Tarnish
Luster" and Melinda Varian's history of VM for the details.
As for OS/360, there's only one thing you need to read: Fred Brooks's
masterful _Mythical Man-Month_. It's amazing that MS can't afford a single
copy of the book.
Adam
--
ad...@phoenix.princeton.edu | Viva HEGGA! | Save the choad! | 64,928 | Fnord
"Double integral is also the shape of lovers curled asleep":Pynchon | Linux
Thanks for letting me rearrange the chemicals in your head. | Team OS/2
You can have my PGP passphrase when you pry it from my cold, dead brain.
jbuc...@kopt0126.delcoelect.com
R. D. Davis (r...@access.digex.net) wrote:
: Does anyone remember any other operating system related products in
: the history of computing that are as poorly designed, or broken by
: design, as Microsoft products?
Well, I have some pretty ugly memories of CALMADOS, which ran on a Data
General S-280 Eclipse. I beleive that it was based on Data General DOS, but
I just used/admined it, I didn't get too deep into its history.
I don't know much about the internals, but the CLI (aptly called CLI) was
quite unpleasant to use.
It crashed a lot too, but to be fair, that may have been hardware-related,
as the machine was rather old by the time I was given the job to admin it.
Rebulding the OS (sort of like linking different modules together) which was
done by a program that booted from a 9 track tape was an unpleasant and
frustrating activity. This was required almost any time a major change
wasmade to the system. Adding a program of any size (TCP/IP driver for
instance) or new hardware for instance.
Its idea of multitasking (if I'm even using the right word for its idea of
more than one program running at once) was rather strange, with a different
"ground" for each running task, and some grounds that were "swappable" and
other's that weren't.
Each ground was assigned memory when the system was built, and that was all
a program on that ground got without rebuilding. It also couldn't have less
than that. Swappable grounds were more flexible, but had disadvantages. I
remember that the plot spooler and some batch jobs ran on swappable grouds.
There was also only 1M of RAM for all of the grounds, which only became a
problem when I had to install TCP/IP.
We had four graphics terminals run by 2 Lexidata "microcomputers". I quote
it since, at least looking in at the boards, they didn't seem to use
microproccesors. Bit slice? The manuals didn't say.
That meant 4 designers working on GDSII which ran on the first ground (one
ground for four users, unless one wanted to detach and run CLI). All on 1M
of RAM and one maybe 250M partition on a 300M drive the size of a washing
machine. When it got too full, I'd move stuff to the second drive or 9 track
tape. GDSII, at least the way ours was set up, couldn't edit designs on the
secondary drive.
This is the system I learned to be a BOFH on...
I hope I didn't get anything too wrong, it's been years.
Despite the ugliness, I do have some good memories of that machine. It could
get very slow, but considering the 4 GDSII users, plus other jobs and
text-based terminals, it wasn't as bad as you'd think.
Jim Buchanan c22...@dawg.delcoelect.com jbuc...@holli.com
=================== http://www.holli.com/~jbuchana =======================
We stopped when we got a clean compile on the following syntax:
for(;P("\n"),R-;P("|"))for(e=C;e-;P("_"+(*u++/8)%2))P("| "+(*u/4)%2);
To think that modern programmers would try to use a language that
allowed such a statement was beyond our comprehension!
==================== http://hybiss.delcoelect.com ========================
Tom Wheeley
On Friday, in article <DyrCE...@midway.uchicago.edu>
ad...@flagstaff.Princeton.EDU "Adam J. Thornton" wrote:
> As for OS/360, there's only one thing you need to read: Fred Brooks's
> masterful _Mythical Man-Month_. It's amazing that MS can't afford a single
> copy of the book.
I keep on hearing about this book, and I think I'll have to get a copy,
but what exactly is it about? Is it a purely computer history book, or is it
more specific or general?
I can guess the `message' from the title!
.splitbung (pwei barmy army, essex paragraph) http://www.tsys.demon.co.uk
--
"We now hide things from our children that we used to hide from our parents" --
[nmer...@dial.pipex.com]
Lisa-Jeff
Mythical man month is a very good book. It was written by a key figure
in IBM's development of IBM's S/360 OS. He gives very good advice on
planning and developing data processing systems.
His basic premise is that a man and month are NOT interchangeable. That
is, a project requiring 1 person working 6 months can NOT be converted
to 6 people working 1 month.
Pedasmith
In article <Dyr92...@midway.uchicago.edu>,
R. D. Davis <r...@access.digex.net> wrote:
>Does anyone remember any other operating system related products in
>the history of computing that are as poorly designed, or broken by
>design, as Microsoft products?
You mean, like CP/M? Where the recommended way to make your
program handle different terminal types is to write a second
program to patch in the right escape sequences? And where, in
in a single byte, you get to decide if you're a paper tape or a teletype?
** shudder **
Or maybe like Electric Pencil, perhaps the first real word processor,
where if you type too fast, it drops characters?
Microsoft may bea thieving, monopolistic, paranoid company, but it
doesn't make _awful_ products, merely _annoying_ ones.
Peter
Michael Quinlan
Tom Wheeley <to...@tsys.demon.co.uk> wrote:
>On Friday, in article <DyrCE...@midway.uchicago.edu>
> ad...@flagstaff.Princeton.EDU "Adam J. Thornton" wrote:
>
>> As for OS/360, there's only one thing you need to read: Fred Brooks's
>> masterful _Mythical Man-Month_. It's amazing that MS can't afford a single
>> copy of the book.
>
>I keep on hearing about this book, and I think I'll have to get a copy,
>but what exactly is it about? Is it a purely computer history book, or is it
>more specific or general?
The Mythical Man-Month
Essays on Software Engineering
by Frederick P. Brooks, Jr.
Addison-Wesley Publishing Company
There is a new edition (the "Anniversary Edition") that may still be in
print. ISBN 0-201-83595-9
The book is a collection of essays based by the author's experiences
managing the development of OS/360, the operation system for IBM's
mainframe computers.
The basic theme is to answer the question, "Why is software so hard to
develop, and what can we do about it?".
Here is a summary from the back cover of the original edition:
"Brooks believes that large programming projects suffer management
problems different in kind from small ones due to the division of
labor. For this reason he feels that the critical need is for
conceptual integrity of the product itself, and in essay form he
explores both the difficulties of achieving this unity and the
methods for achieving it."
-------------------------------------
Michael A. Quinlan
mi...@primenet.com
http://www.primenet.com/~mikeq
"If it doesn't fit, you must acquit!"
-------------------------------------
Juergen Nickelsen
<jbuc...@kopt0126.delcoelect.com> wrote:
> Well, I have some pretty ugly memories of CALMADOS, which ran on a Data
> General S-280 Eclipse.
[...]
> That meant 4 designers working on GDSII [...]
Ah, GDSII! When I was a student, my first programming job was to write
an output module for GSDII data files. There was a page of EBNF to
describe the Syntax, and then 12 (I think) pages to describe the record
formats. With some effort I got this right.
Then I had to write the *input* module, i.e. a parser, and I barely knew
what that was! But my boss took me aside and said "Have a look at this
book. Read the first four chapters, but not more -- that would only
confuse you --, and you will see it is easy." He was right -- the book
was Niklaus Wirth's "Compilerbau", and the first four chapters told me
everything I needed to write the parser, which later worked like a
charm. I switched to study computer science *later*.
Can anyone tell some more about GDSII? All we had was the description of
the data files, and that this file format was quite common with CAD
systems for chip layout etc.
--
Juergen Nickelsen
Juergen Nickelsen
Tom Wheeley <to...@tsys.demon.co.uk> wrote:
[`Mythical Man Month' by Fred Brooks]
> I keep on hearing about this book, and I think I'll have to get a copy,
> but what exactly is it about? Is it a purely computer history book, or is it
> more specific or general?
It is a book with essays on software engineering. Very interesting and
well-written, even entertaining, it is not a book about computer
history, but about the lessons learned in large software projects.
--
Juergen Nickelsen
Carl R. Friend
jbuc...@kopt0126.delcoelect.com wrote in
article Nr.<Dyrrt...@midway.uchicago.edu>:
> R. D. Davis (r...@access.digex.net) wrote:
> : Does anyone remember any other operating system related products in
> : the history of computing that are as poorly designed, or broken by
> : design, as Microsoft products?
>
> I just used/admined it, I didn't get too deep into its history.
>
> I don't know much about the internals, but the CLI (aptly called CLI) was
> quite unpleasant to use.
The operating system you are referring to is actually a derivation
of Data General's "Real Time Disk Operating System" or, more simply,
"RDOS". Given the date of RDOS's genesis, it was quite an advanced
operating system. It took microcomputers years to "catch up" to it, and
in many ways the micros still haven't.
> It crashed a lot too, but to be fair, that may have been hardware-related,
> as the machine was rather old by the time I was given the job to admin it.
We (at my "day employer") retired our last Calma Eclipse system in
about 1992. I have the machine in my collection. It is an S/230. I learnt
RDOS in secondary school (enough to be an admin), and spent three years
operating it as such.
> Rebulding the OS (sort of like linking different modules together) which was
> done by a program that booted from a 9 track tape was an unpleasant and
> frustrating activity. This was required almost any time a major change
> wasmade to the system. Adding a program of any size (TCP/IP driver for
> instance) or new hardware for instance.
This is one of the "features" of "classic" operating systems that
saves an _enormous_ amount of mainstore, and a large number of CPU
cycles. Since the number of times you physically change the hardware
configuration is quite small (in relation to the number of times you
boot the machine), it makes sense to pre- define the configuration. It
saves time and code.
> Its idea of multitasking (if I'm even using the right word for its idea of
> more than one program running at once) was rather strange, with a different
> "ground" for each running task, and some grounds that were "swappable" and
> other's that weren't.
Calma derived it's OS, as I've mentioned before, from DG's RDOS which
had two "grounds", fore- and back-. Calma extended that to multiples.
> Each ground was assigned memory when the system was built, and that was all
> a program on that ground got without rebuilding. It also couldn't have less
> than that. Swappable grounds were more flexible, but had disadvantages. I
> remember that the plot spooler and some batch jobs ran on swappable grouds.
Sorry. The individual grounds could be assigned core at run-time (or
more precisely, at boot time). It was done via the "SMEM" command. Where
the original CLI (Command Line Interpreter) simply allowed you to specify
the memory allocated to the "back-"ground, Calma's implementation
allowed the specification for all the -grounds, the maximum number of
which, I believe, were specified during a sysgen.
> Despite the ugliness, I do have some good memories of that machine. It could
> get very slow, but considering the 4 GDSII users, plus other jobs and
> text-based terminals, it wasn't as bad as you'd think.
In all probability, it may have been better than some of the things
lurking in the wings today. I'm not sure whether we've _really_ moved
forward or not.
--
______________________________________________________________________
| | |
| Carl Richard Friend (UNIX Sysadmin) | West Boylston |
| Minicomputer Collector / Enthusiast | Massachusetts, USA |
| mailto:carl....@cliff.swec.com | |
| http://www.ultranet.com/~engelbrt/carl/museum | ICBM: N42:22 W71:47 |
|________________________________________________|_____________________|
jbuc...@holli.com
Juergen Nickelsen (j...@berlin.snafu.de) wrote:
: <jbuc...@kopt0126.delcoelect.com> wrote:
: > Well, I have some pretty ugly memories of CALMADOS, which ran on a Data
: > General S-280 Eclipse.
: [...]
: > That meant 4 designers working on GDSII [...]
: Ah, GDSII! When I was a student, my first programming job was to write
: an output module for GSDII data files. There was a page of EBNF to
: describe the Syntax, and then 12 (I think) pages to describe the record
: formats. With some effort I got this right.
You probably had the same book I used. It's at work, where I won't be for
another hour or two, but I think it's called "GDSII Stream Format Manual".
Yep, just checked on my web page. In case I lost access to it, I condensed
it a bit and put it into .html, it's at
http://www.holli.com/~jbuchana/stream_description.html
: Then I had to write the *input* module, i.e. a parser, and I barely knew
[...]
: confuse you --, and you will see it is easy." He was right -- the book
I found GDSII stream files to be surprisingly easy to parse. I suspect that
the people at CALMA put a lot of time into the specification to ensure that.
Perhaps more to reduce the amount of time it took to parse on the days slow
hardware than to make it easy for me.
: Can anyone tell some more about GDSII? All we had was the description of
: the data files, and that this file format was quite common with CAD
: systems for chip layout etc.
We used it to design hybrid circuits, which are a bit like circuit boards,
but the substrate is ceramic with screened on features that are then fired
in an oven. If you have a GM car made since the very late '60s, you have
some of these circuits. The first was the voltage regulator in the
alternator.
GDSII was a nice system for polygon pushing. If you could do it in 2D
without needing any "schematic driven" features, it was a *very* nice
system. We had a self-teaching course on audio tape. Take any non-luser, set
them down for a few hours with this course and then teach them a bit about
local procedures and hybrids and you had a productive user. Nowadays with
Mentor Graphics (which has *many* more features and abilities), it takes
months to get anyone up to speed, and if they go away for a while, they
forget it all. Progress... :-( It does do more though, and it has some real
advantages on the vastly more complex circuits we do today. It can be very
hard to ensure that a complex circuit matches the schematic with GDSII, with
Mentor, that's automatic.
To read and edit GDSII files nowadays, we use a product calle LTL (Layout To
Logic) form ISS (Integrated Silicon System) (Who I think were bought by
Ferranti). It's a nice system too. Runs very fast on an HP735.
Unfortunatly, some of our old 9 track Calma tape images which are stored on
DAT tapes now turn out to be corrupt. Usually just one byte, but... I wrote
a pair of programs, one which parses the file and converts it to
human-readable ASCII, another which converts it back. When the parser gets
confused, it starts spewing a hex dump, therefore it can usualy be read back
in even if it's corrupt. Since I convert from the floating point format that
started this thread to a native format and back again, there is no guarantee
that if the parser assumes something is a floating point number (by mistake
after it gets confused but before it realizes that it is confused) that
rounding error won't rear its ugly head...
Now I can convert to ASCII, grovel through it with emacs, remove the corrupt
element/structure, and convert back with only a minor loss of data. It's
saved a lot of work and it's a lot easier than doing the same thing with a
hex dump. Not too easy, as some of these files start out at 2 to 5 megabyes,
and get a lot longer when expanded to ASCII. I usually search for the string
"***ERROR***" in the ASCI file.
Interesting. I almost always bracket the word "ERROR" with three '*' on each
side. That's the wy GDSII did it, and I still do.
The extension language for GDSII was called GPL. Some people told me that
GPL was APL with all the weird characters converted to keywords and some
extensions added. I don't know for sure, having never used APL. GPL had
great matrix handling capabilities. It also had "automatic" variables, with
no typing. Convenient, but it did lead to errors.
GPL was interpreted, and it's biggest limitation was speed. It wasn't
uncommon to go get cofee or to run an errand while a GPL program ran. You
couldn't just pop up another window either. Each user had one graphics
terminal (big, but lousy resolution and convergance) and one green screen
ASCII terminal. When they were tied up, they were tied up.
LTL uses C as an extension language. The interface is pretty well thought
out and it's a pleasure to use. User-written (meaning me, not an actual end
user) programs are fast that way.
Well, I'm really rambling, and I have to get to work now. Maybe I'll
reminisce (sp?) some more later, if I haven't bored everyone too much
already.
Jim Buchanan c22...@dawg.delcoelect.com jbuc...@holli.com
=================== http://www.holli.com/~jbuchana =======================
"You are lost in a twisty maze of little standards, all different."
==================== http://hybiss.delcoelect.com ========================
jbuc...@kopt0126.delcoelect.com
Carl R. Friend (carl....@swec.com) wrote:
: We (at my "day employer") retired our last Calma Eclipse system in
: about 1992. I have the machine in my collection. It is an S/230. I learnt
We retired ours about the same time. We had a party. It was really sort of
sad. I thought about trying to take it home, but when my wife heard about
its size, power requirements, and coolinmg requirments, she freaked.
: This is one of the "features" of "classic" operating systems that
: saves an _enormous_ amount of mainstore, and a large number of CPU
That makes sense.
: cycles. Since the number of times you physically change the hardware
: configuration is quite small (in relation to the number of times you
Quite true, I only did this a few times over maybe a five year period.
: Sorry. The individual grounds could be assigned core at run-time (or
: more precisely, at boot time). It was done via the "SMEM" command. Where
I remember that command now. I didn't last Friday though...
: the original CLI (Command Line Interpreter) simply allowed you to specify
: the memory allocated to the "back-"ground, Calma's implementation
: allowed the specification for all the -grounds, the maximum number of
: which, I believe, were specified during a sysgen.
Yep, but available memory was a real limiting factor.
: In all probability, it may have been better than some of the things
: lurking in the wings today. I'm not sure whether we've _really_ moved
: forward or not.
We don't actually seem to get work done much faster. Response to a command
is faster on the new CAD systems, but you have to do so much more to get the
same image on film. But that's more of an application related thing...
Jim Buchanan c22...@dawg.delcoelect.com jbuc...@holli.com
=================== http://www.holli.com/~jbuchana =======================
"Remember that if computers are networked, they can talk to each other.
That is useful when you make an example of one." -ASR faq
==================== http://hybiss.delcoelect.com ========================
A.R. Duell
peda...@aol.com (Pedasmith) writes:
>You mean, like CP/M? Where the recommended way to make your
>program handle different terminal types is to write a second
>program to patch in the right escape sequences? And where, in
>in a single byte, you get to decide if you're a paper tape or a teletype?
Strictly, IOBYTE did not originate in CP/M. It came from the Intellec
MCS8i system monitor (and maybe the 8008 monitor that preceeded it).
The MCS8i was an Intel development system for the 8080 CPU, and it had a
real lights-and-switches front panel. Since the 8080 executed from
location 0 on a reset, the MCS8i had _RAM_ at that location, and the
recomended way to run a program from the panel was to put a jump to your
program at location 0, reset the CPU, and release the bus.
The system monitor was stored in 1702 EPROMs (8 of them, I think)
starting at location 3800 (hex). To run that, you toggled a JMP 3800 (C3
00 38) into the first 3 locations of RAM and let it run. The monitor
typed the sign-on message on the teletype and you could then use the
Tty's keyboard to enter commands.
One such command was A. This let you assign the logical devices (Console,
punch, reader, list) that the monitor would use. There were 4 choices for
each device (I forget what they all are) and the assignments were thus
stored in a single byte. This was stored in the first spare RAM location,
which, of course, was location 3 (0,1,2 were taken by the startup jump).
Thus, the MCS8i had a CP/M-like IOBYTE at location 3.
>Peter
--
-tony
ar...@eng.cam.ac.uk
The gates in my computer are AND,OR and NOT, not Bill
Alan Cashin
R. D. Davis wrote:
> Does anyone remember any other operating system related products in
> the history of computing that are as poorly designed, or broken by
> design, as Microsoft products?
International Computers Ltd (ICL) produced a 1900 series of computers
which used operating systems called GEORGE 2 and GEORGE 3. It was an
acronym for something like GEneral ORGanisational Environment but I'm
guessing. We used G2 quite successfully on a 1904A then moved to G3v2.
I think that was circa 1972. G3 had about 5 times the throughput of G2
but v2 had an MTBF of 20 minutes. Since it rebooted in less than a
minute we continued to use it as we were getting more throughput even
with the reruns. After a few more versions, it was quite stable with an
MTBF of months.
There was a G4 which was very advanced for the day - it was G3
with virtual memory. It needed a hardware upgrade to support the memory
management and we could not afford it. G3 was multitasking and supported
swapping and we used a high speed drum for that. It ran in a pressurised
helium atmosphere and the engineers had to 'pump it up' as part of the
maintenance schedule. It was a fast beasty - I think 2Mb/sec transfer
rate and 6ms latency. The only time it lit up was end of day when you
shut down the machine - the whole of memory (all 384Kb of it) was
transferred to the drum and the transfer light would blink momentarily.
Apart from that, the transfer light remained pretty quiet.
Alan
Rick Hawkins
In article <DysAy...@midway.uchicago.edu>,
>>Does anyone remember any other operating system related products in
>>the history of computing that are as poorly designed, or broken by
>>design, as Microsoft products?
>
>program handle different terminal types is to write a second
>program to patch in the right escape sequences? And where, in
>in a single byte, you get to decide if you're a paper tape or a teletype?
Ahh, but in some real-world stuff this was wonderously useful.
I had to write an MIS system in MBASIC on an Osborne (this wasn't
negotiable). The iobyte let me use the same code to write reports to
the screen & to the printer; I just changed the iogbgyte to turn the
screen into the lineprinter.
It was also useful for debugging: I could make the serial port the
console, and exercise the machine from a second system.
When I wanted to pull these tricks doing QA on CPM/86 later, i was very
irritated to find iobyte gone . . .
rick
--
R E HAWKINS
rhaw...@iastate.edu
These opinions will not be those of ISU until they pay my retainer.
Mike Dedek
In article <DyJvA...@midway.uchicago.edu>,
|> Could well be. There may well be problems for which a mainframe remains the
|> best solution, though I haven't seen any in the kinds of work I've been
|> involved with. But mainframes, unsurprisingly for such vintage technology,
|> represent a stable, mature approach to solving classic business data
|> processing problems. They may cost 10-100 times as much as a well-engineered
|> modern solution, but they will be well-documented and stable.
A big question mark in the original question (90K vs. 10K system) is the
requirements. We don't know them, we don't know if they're accurate, and
we don't know if the user or his son understands them completely.
Here's an example of a system which, IMO, not only are several mainframes
the best solution, they are the only solution. Keep in mind that I really
dislike mainframes and much prefer distributed computing, but I also firmly
believe there are still some applications for which mainframes are the
proper solution.
At our company, we have > 1Tb data, all indexed and searchable. We
consistently have > 1000 simultaneous users and I believe the record is
around 2,500. Our average search time is about 11 seconds. So far YTD,
our systems have been up 99.67% of scheduled uptime (scheduled downtime is
15 min/day).
Guess where our data and search engines are located?
We've offloaded some of the user interface stuff to client-server, but have
yet to find a client-server solution that meets our (admittedly very
rigorous) reliability & perfomance requirements at a cost comparable to
that of our current 20+ 3090 platform. The complexity of such a system
would be enormous, due to the redundancy needed.
-Mike Dedek
Development Services/Tools
Lexis-Nexis, a division of Reed-Elsevier PLC
Bennett Todd
On Tue, 15 Oct 1996 21:42:58 GMT, Mike Dedek <de...@lexis-nexis.com> wrote:
>Here's an example of a system which, IMO, not only are several mainframes
>
>At our company, we have > 1Tb data, all indexed and searchable. We
>consistently have > 1000 simultaneous users and I believe the record is
>around 2,500. Our average search time is about 11 seconds. So far YTD,
>our systems have been up 99.67% of scheduled uptime (scheduled downtime is
This may come down to a definition of "what's a mainframe". If the answer is
"something that weighs many tons, requires a massive custom power feed and
special air conditioning, etc" then yeah, over 1TB fully-indexed data with
more than 1,000 simultaneous users will mean a mainframe. But if it also means
a system architecture from the mid-60s that thinks everything is a punchcard
including a "timesharing" user, well, then no, I'm not so sure a mainframe is
required.
If I had a database problem like that, I'd personally call up a DEC salesman,
and ask how much an engine like the one behind Altavista would cost. If I
needed higher availability than that offered (how often is Altavista out?) I'd
buy two of them, or four, or 15, or however many I needed to sleep soundly:-).
-Bennett
Valdis Kletnieks
[Posted and mailed]
In article <DzDqH...@midway.uchicago.edu>,
bet@nospam|interactive.net (Bennett Todd) writes:
> If I had a database problem like that, I'd personally call up a DEC salesman,
> and ask how much an engine like the one behind Altavista would cost. If I
> needed higher availability than that offered (how often is Altavista out?) I'd
> buy two of them, or four, or 15, or however many I needed to sleep soundly:-).
Just remember that Altavista is a read-mostly database - the number of hits is
a LOT higher than the number of updates. On the other hand, the average
financial database for a bank, or credit card clearinghouse, or insurance
company is taking a *LOT* of updates. Now, call up DEC, and tell them
you need something that can do as many hits as Altavista, be replicated at
least 4 ways in different parts of the country, and also sustain 100+
updates per second without losing any cache coherency.
Poke around on http://www.s390.ibm.com for more information on what
a *real* mainframe can do these days ;)
--
Valdis Kletnieks
Computer Systems Engineer
Virginia Tech
Pedasmith
It's not just huge problems that can be solved by mainframes.
My father, just two years ago, had the following
requirements:
low cost per user
limited power required per user (*)
24/7/52, 4-hour response from the manufacturer
for a jail application, comparing networked PCs vs.
an AS/400 and terminals. The PCs were looking
pretty good until the "response" requirement was
costed. All of a sudden, IBM looked _very_ good.
Moral of this story: IBM knows how to keep
a business happy.
Peter
(*) that is, a traditional mainframe "fill in the form
and press 'go'" user interface was
satisfactory.