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

** Reply to note from Buck Calabro <mcalabro@commsoft.net> Mon, 8 Dec 1997 
12:20:35 -0500

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

Then you have no apps to talk to. Then you are faced with a full rewrite, or
modifying one of your maintenance apps to accept a request from a data queue
instead of a screen. 

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

So quickly? I've been using a client/server model since before the AS/400
was introduced. But not on everything! Only where I thought it made sense or
was necessary. By the way, if you are "batch driven", that is another issue
you can address without rewriting. 


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

Sometimes going to c/s is just an incremental mod. Sometimes it's just a
matter of modifying a batch program to process requests from a different
input. Sometimes you still process from a file, but the calling program
simply checks for an active server and calls one if there isn't one. (was
that IFF ACTIVE-xxxxxxx on the S/36?)

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

Well, I know you are at the mercy of your users. We all are. I have written
code that replaced an interactive process with a call to a batch job that
returned it's reponse via a data queue. That's how I handle big file
reads that use opnqryf. The operator is still sitting there interactive
staring at the same screen they would have been staring at if the job was
running locally. However, the job is runnning at a priority of 50 rather
than 20, so I feel a little better. The operator doesn't know they are
waiting a few seconds more so that all the other interactive jobs don't get
flushed while the query finishes. 

But sometimes, like with credit card handling, there isn't any choice but to
wait. Your users must wait until a credit card authorization is returned.
There is only one port to make requests through. A data queue is a natural
solution.


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

Hey, if you are happy with the existing logic, leave it alone! I am NOT
trying to tell you to use data queues. I am pointing out that they are not
evil. 

If your existing batch update process is fine with everyone concerned, leave
it alone. Write a client that creates records in the same files that your
existing data entry apps do, and process the entries in batch. 

All I am trying to point out is that data queues are not a flaw in Java.
They are not an evil destroyer of object oriented coding. They are just
another tool with a time and a place for use. There are existing situations
where using a data queue is called for. If yours is not one of those
situations, don't use them. 

But all things have trade offs. Batch processing means updated balances
aren't ready right now. Interactive processing means that each client must
be responsible for maintaining data integrity. 

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

"It ain't easy bein' me!" 

I feel for you, Buck. I know that ahead of lots of programmers is a tough
hill to climb.

All I can tell you is that Java is a damn nice tool for climbing it. If you
ever enjoyed programming, Java will make you again wonder why anyone pays
you to do this! 

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