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


  • Subject: Re: What makes Java so special?
  • From: Chris Rehm <Mr.AS400@xxxxxxx>
  • Date: Fri, 5 Dec 1997 22:16:56 PDT

** 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 thread ...


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.