Re: ODBC (was RE: Green screen - it's time is over )

Paul,

It is not ridiculous. If msg based client/server is similar to OO programing 
where objects are accessed via msgs ( public method calls ) instead of direct 
access to their data elements, than the concept is very sound.

It is better to code a chg to a date in the order hdr rcd as a function call:  
OrdHdr.SetDate( CurrentDate ) instead of direct access to the data fld:  
OrdHdr.EntryDate = CurrentDate. This way a chg to the OrdHdr rcdfmt ( store 
dates in iso form instead of ymd form ) will not break the code using the 
function call , but will break the direct access code.

Using ODBC to directly access a tables columns is the same as code that 
directly access a fld in a data struct. Sending a "set entry date" msg to the 
server is more sound than the equivalent ODBC stmt that direct access the 
column in the table.

Steve Richter


---------- Original Message ----------------------------------
From: "Paul Raulerson" <praulerson@hot.rr.com>
Reply-To: midrange-l@midrange.com
Date:  Sun, 18 Nov 2001 15:00:29 -0600

>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.
>>
>>
>
>_______________________________________________
>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.
>
>