Re: What makes Java so special? -- JAVA400-L

Chris wrote:

-snip-

>> 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? 

You're very, very right.  That's *your* situation.  
*I* haven't got any server apps running on my AS/400 except the database itself.

-snip- 

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

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

I re-positioned this quote so it would make more sense in what I was
trying to say.  Here, you very correctly say that there are lots of
installed programs, yet just above that, you seem to be saying that
your legacy code is of pretty recent vintage.  

How did you carry your systems from "original" batch-driven code to 
Client-Server code so quickly?  Or am I really the only AS/400
programmer left who has batch-driven application logic?  This is
important in a Java thread because the basic design tenets have to
be established, at least in my case.  I can hardly believe that all 
those S/36 shops re-wrote all that batch code when they bought
their shiny new AS/400.  

At a previous employer, I had resistance to the C-S model because:
1. Doing the incremental mods to the existing batch systems would
    be *much* faster than re-designing the app as C-S and then adding
    the "desired" mod.
2. Delays.  There was a perception that the C-S model was slower than
    doing the work interactively.  Single threading all those client requests
    is slower than fulfilling each request immediately.  And, yes, I know I
    can set up multiple servers to process from one DTAQ.  The principle
    still applies: There are many more clients than there are servers, and
    for people who are accustomed to subsecond interactive response
    times, a 2 second wait will generate phone calls.
3. Core database files and logic are implictly designed with batch timing
    in mind.   Tough to simply transition a part (say, the A/R Inquiry) to C-S
    when the database itself is updated after hours.  

Here, we don't have resistance to the idea, we just have a lot of batch
systems that are interlocking.  This means that it's not going to be an
easy transition to the C-S model until we sort out what batch things should
go where.

Buck Calabro
Commsoft

+---
| 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
+---