|
** Reply to note from Buck Calabro <mcalabro@commsoft.net> Fri, 5 Dec 1997 16:02:51 -0500 > > 1. What kind of host interface has no bearing on the > > portability of the client. > Right. I don't get #1. > #2 seems self-evident (even to me! <ear-grin-ear>) What kind of interface the host has does not affect the portability of the client. > > I *thought* you were telling me that if I write data queue > code in the client that I could use it to talk to NT, too. > Did I mis-read you? Sorry if I did. I thought that ODBC/JDBC > was the "server independent" interface. Technically, yes, you can use the data queue to speak to an NT server. But that isn't what I was telling you. I was trying to point out that what method you use to talk to the server doesn't affect the portability of the client. Also, ODBC and JDBC are two different things. They are not associated, although there is a JDBC/ODBC bridge for machines which have ODBC connection but no JDBC support. > I mention Java specifically here in the context of > including data queue code because it is Java that has > the promise of allowing a fresh start, without the > baggage of vendor-specific C++ classes, etc. I don't think any new language or platform offers anyone a "fresh start". Q: "How could God create the Universe in six days?" A: "He had no installed base." Businesses have billions (trillions maybe) of dollars worth of code installed. They just aren't going to throw it away any time soon. It doesn't make economic sense for them to. > When we're sooooooo close to being able to write truly, > completely portable code (client runs on any platform, > talks to any server platform) it seems such a shame to > limit the Java client to a single server by using server- > specific interfaces (like data queues) when "generic" > alternatives (JDBC) already exist. But again, JDBC and data queues are two different things. Meant to handle two different issues. If I have an application running on a host machine, and I want to talk to it, what value has JDBC got for me? Let's suppose I have an AS/400 running POSPort for AS/400s. It accepts requests via a data queue. Now, you are rewriting the point of sale application. How do you get your authorization? What kind of JDBC call can you make? > That's what I was trying to say. We can't chuck all the > legacy code and start anew. > > The "But..." is that we have very little Client-Server > code in those legacy apps. Because of this, virtually > *all* the GUI efforts are starting from scratch. We > can't increment up to GUI client replacing Green Screen > client, because the Green Screen stuff is not written > as Client-Server. Well, your system must be quite a bit different from the ones I am familiar with. In a lot of cases, people can make good use of having a client on a PC and running reports, making requests, call applications, etc. off the host. Since you are trying to access pieces that are in place on a 400, it doesn't seem wrong to use AS/400 interfaces to reach them. > Buck Calabro Chris Rehm Mr.AS400@ibm.net How often can you afford to be unexpectedly out of business? Get an AS/400. +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "JAVA400-L@midrange.com". | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
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.