** Reply to note from Buck Calabro <email@example.com> 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: firstname.lastname@example.org +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.