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