|
Well, I disagree with your assertation for several reasons, but these two are the biggest. In a client/server environment (be it message based or shared memory, or any one of a dozen other strategies...) you have moved processing logic into the client part, and that part is just as likely to be in error as a server module that does the same logic. In other words, moving the logic doesn't make it correct. Secondly, even if *most* of the programs in a client/server environement would be correct, either through an insensitivity to dates like you mention, or because of some other reason, you don't *know* that until you *examine* them. In short, you haven't really avoided any work, and in many cases, you have made it more difficult, since Client/Server programs often escape the scrutiny given to host based programs in terms of standards and testing. There are several other reasons that could come into play, not the least of which is that several systems were remediated with a windowing date system. That can cause havoc if you have to do long term extensions. The business I work in routinely does 100 year time series projections, and client/server fixes are much more difficult than pure server based fixes. -Paul ----- Original Message ----- From: "Joe Pluta" <joepluta@PlutaBrothers.com> To: <midrange-l@midrange.com> Sent: Sunday, November 18, 2001 3:38 PM Subject: RE: ODBC (was RE: Green screen - it's time is over ) > > -----Original Message----- > > From: Paul Raulerson > > > > 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. > > I said message-based client/server, not "server based". And for that > architecture, my statement is absolutely true. Let's look at the situation: > in a message-based client/server architecture, the client program (such as > an inquiry or a print report) requests data from a server. The client fills > in some fields in a data structure, sends it to a server, then receives data > one message at a time back from the server. In the simplest case, each > message corresponds to a record in the file being queried. > > Prior to Y2K, the dates in those messages would have been six-digit dates. > And that would have matched the way they were stored in the file. Now for > Y2K, we expand the dates in the file, but we DO NOT EXPAND the dates in the > message. When the server returns the message to the client, it simply moves > in only the YYMMDD portion of the date. > > So let's take a print program as an example. Most print programs did no > date calculations; they simply read data in a specific order and printed it > out. If they had used a server program to retrieve the data, the server > would have returned the data in the correct order. Even though the data on > the record was eigth digits, the dates in the messages returned to the > client would have had six digits. The programs would have done their > YYMMDD->MMDDYY comversion, and printed them with the appropriate separators, > and the reports would have looked perfectly normal. > > Without a single line of code in the report program changing. > > Does this make sense? > > Joe Pluta > www.plutabrothers.com > > _______________________________________________ > 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 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.