Re: Hmmmm.....$1 Billion

[Steve Richter <stephenrichter@xxxxxxxxx>]

On Fri, 4 Mar 2005 09:46:07 -0600, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
> > From: rob@xxxxxxxxx
> >
> > Going back to the origin, I think he is basing it on the fact that
> > interactive does not support threads but batch does.  He's trying to
> > figure out why interactive has this limitation.  I guess if it's on
> OS/400
> > we'll call it a limitation, but if it's on Windows we'll call it a
> bug.
> 
> Can you point to a single instance where I called a limitation of
> Windows a bug?  I call security holes bugs, but those are hardly
> limitations.  I call blue screens bugs, but those aren't limitations
> either.  I call loss of data due to crashes in Microsoft applications
> bugs, but that's not a limitation, it's a bug, and a nasty one at that.
> 
> The lack of thread support for interactive jobs is a limitation.  Why
> don't interactive programs allow multi-threading?  Perhaps because it's
> not needed, and IBM made an architectural decision that helps
> interactive performance by removing overhead required for
> multi-threading.  That's at least as plausible a reason as some massive
> bug.
> 
> The point is that none of us know the reason, and in fact IBM is pretty
> clear about saying it's simply something they don't support, and so the
> label "bug" is awfully presumptuous.

call it what you want.   When my code is in such a state that when
changes made to it introduce other "problems", I call that code buggy.

I am just trying to help. Presenting the user with a GUI popup window
that works in conjunction with their green screen application is as
the now thankfully free Martha would say, a good thing.   Program wise
it is also relatively easy to do.  But implementation wise, in an
interactive job, it is just about impossible.

-Steve