× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



MM- Well, I have been following this and *I* don't get your point either.
If I understand it correctly, you are saying that 85% of all programs would not 
have
needed Y2K remdiation if they had been "server based."

I find this rather ludicrious, as the greatest majority of programs I know of 
that that
did need remeditation were server based - based in fact on very "server 
centric" hosts.
Including OS/390, OS/400, UNIX, and others.

-Paul


----- Original Message -----
From: "Joe Pluta" <joepluta@PlutaBrothers.com>
To: <midrange-l@midrange.com>
Sent: Sunday, November 18, 2001 2:57 PM
Subject: RE: ODBC (was RE: Green screen - it's time is over )


> Brad, it seems we don't communicate very well.  I'm going to point out one
> specific instance of where we're just not communicating, and then leave it
> at that.  The fact that I can't seem to frame my ideas in a way that makes
> sense to you means that we're just going to waste the time and bandwidth of
> this forum.
>
> > -----Original Message-----
> > From: Brad Jensen
> >
> > ----- Original Message -----
> > From: "Joe Pluta"
>
> > > > > over 85% of the application code WOULD NOT
> > > > > HAVE REQUIRED A SINGLE CHANGE.
> > > >
> > > > Sure, and all the date calculations would have worked fine....
> > > > I don't think so.
> > >
> > > I said 85%.  Do you think more than 15%
> > > of programs had date calculations?  What would your estimate be?
> > > Actually, far less than 15% had date calculations - more had date
> > > COMPARISONS rather
> > > than date calculations, but even so those were less than 15%.
> >
> > See, I started as a machine language and assembler program, and I
> > know that ever comparison is a calculation, so that hair split
> > went right by me.
> >
> > Adn you find your programs with date calculations by - reviewing
> > ever single program.
> >
> > And date calculations are just one of many changes that would be
> > necessary - any real data structure changes is likely to cause a
> > need for a programming change - the program is onlky there to
> > support the data structure and its use.
> >
> > > How do I
> > > know?  My product, Focus/2000, was used to convert hundreds of
> > > systems worldwide.
> >
> > Congratulations.
>
> See, this isn't a discussion or even an argument.  I made a statement: over
> 85% of programs would not have needed changes for Y2K if they had been
> server-based.  You disagreed with a rather flip "I don't think so."  I
> answered your point with a concise statement about how dates are used in
> programs, with corroborating information about my experiences in converting
> systems.
>
> Your point about comparisons and calculations doesn't relate to the 85%
> figure; less than 15% of business programs use date comparisons or
> calculations, regardless of your machine language background.  Your comment
> about reviewing every program doesn't relate to the 85% figure; after
> review, less than 15% of the programs would have needed changes.  Your
> comment about data structures might have been relevant, if you had any
> numbers to back it up.  However, my experience was that less than one out of
> five systems ever put dates in data structures, and even then it was only a
> few isolated instances where programmers got clever.  While that point had
> the distinction that it might have actually been marginally relevant, in the
> end it doesn't affect the 85% figure, either.
>
> Then, to add insult to irrelevancy, when I detail my experience, you give me
> another flip comment: "Congratulations".
>
> All I tried to do was point out that, given my experience in both Y2K
> conversion and client/server architecture, I found that a message-based
> client/server architecture was less affected by Y2K than a non-message-based
> one.  I used a real example, real figures, and honestly attempted to
> communicate.  You went off on three different tangents - your machine
> language experience, having to review every program, and data structures -
> none of which contributed anything to the discussion, and then finally you
> were rather insulting on top of it.
>
> Zero communication in either direction.  Zero addition to the conversation,
> zero addition to the knowledge base of this list (from either of us).  These
> discussions add nothing for anyone.  So, from now on, I suggest we simply
> ignore each other's posts.  For whatever reason, we seem not to have enough
> common ground to communicate effectively and that means that we'll just be
> wasting time and bandwidth.
>
> I'm sorry we haven't been able to discuss this productively.
>
> Enjoy the rest of the weekend.  I'm off to watch my beloved Bears.
>
> Joe
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.