|
I've let this thread go in two directions at once, mostly because I can't help but jump on the Interactive Feature soapbox. My initial technical questions were about tuning the system for jobs initiated from other interfaces. What I saw with the Lawson interface was that a client that ran the same work as a terminal session was being configured as a batch job. Web and client-server interfaces blur the lines between interactive work and batch work. Terminals originally ran in an interactive subsystem with their own classes, priorities and memory pools so that would have dedicated resources. The principle was that work done from the terminal would have short bursts of activity -- data entry, or enough database lookup and calculation to fill a single inquiry screen. The users' jobs would pause as the users read the screen or moved to the next data entry item. They were given a higher priority so that could get processing on demand regardless of the batch jobs that were running. Do these principles apply in the web, database server, application server world? The Lawson GUI example may not be the best one, since it was written purely to replace the 5250 session. Still, if you've written a web form to do payroll time-card entry, or account status lookup shouldn't it be tuned to an "interactive" priority, to give it the response it needs when running against a data mining process or a long running report? Or is there something else in new application architecture to cover this? -----Original Message----- From: Nathan M. Andelin To: MIDRANGE-L@midrange.com Sent: 4/20/01 10:31 AM Subject: Re: Interactive vs. Batch Jim, It seems to me that IBM found it necessary to price client-server work differently than traditional 5250 work. From that point forward the term "interactive" took on new meaning. Prior to client-server architecture, Interactive vs. Batch had much to do with work management (job priority, dedicated memory pools, maximum # of active jobs, etc.). Default system configurations allocated more system resources to interactive work. Now, in contrast, Web and other client-server jobs need the highest priority, the most memory, etc. The term interactive has taken on the more narrow meaning of a job that uses IBM's Workstation Manager. Any CPU used by those jobs is subject to the "interactive feature" limits placed on the machine. Nathan. > From: Jim Damato <jdamato@dollargeneral.com> > Subject: RE: Interactive vs. Batch > > Actually Steve, the Lawson GUI was what stirred up all of this for me. > After purchasing hundreds of thousands of dollars worth of Interactive > Feature we discovered that the Lawson GUI didn't use interactive CPW. (We > bought one of the first models to use Interactive Feature, and at the time > we, Lawson, IBM, and our business partner did not understand how to size for > the cards.) The GUI starts a sockets connection which is mapped to a Lawson > server program through a TCP/IP service table entry. Each connection > launches a server job on the AS/400 in a batch subsystem. Lawson's green > screen presentation runs one presentation program with one display file. > All inquiry programs, prompts, entry, etc. operate through calls to > application programs (RPG) which pass screen formatting information back to > the presentation program. The GUI's server job accomplishes the same thing > by calling the same application programs and passing the formatting > information to the client. The same formatting information is mapped on the > green screen into fields and function keys, and mapped on the client into > form elements, pull downs, and buttons. > > Lawson took pride in explaining that their client was thin (it was > positively obese from the installation and support side, but that's another > story) and that it required very little client processing resources. I > became confused as to why the same user actions and functions could be > accomplished through a TCP/IP sockets connection and a batch job, and yet > required a small fortune in extra hardware to run them interactively on a > terminal or emulator. This led to a two-year quest to get someone at IBM to > admit that Interactive Feature was software licensing and that there was no > productive technology on the cards (boy, you should have heard John Sears' > uncomfortable dodge when I asked him about it.) > > Nathan's web reference nails down IBM's definition very well, though the > definition still evades the whole truth. "iSeries 400 or AS/400 Advanced > Servers and AS/400e servers are intended for use primarily in client/server > or other non-interactive work environments. 5250-based interactive work can > be run on these servers with limitations." Just add the word "contrived" in > front of the word "limitations." > > While we still had users thrashing between 5250 and the Lawson GUI I notice > that the GUI did not perform as well, so I changed the Lawson server > subsystems, job descriptions, and classes to run GUI jobs at an interactive > level, and within the interactive pool. This brought GUI job performance up > to an interactive level. > > In the client-server, web-based, n-tier, whatever whatever, non-5250 > interface environment, do these issues come into play? Are data mining or > SQL-reporting tool interfaces configured to batch-oriented work management > parameters, while inquiry, lookup, and data entry forms invoke a more > interactive-type job? > > Interactive vs. Batch used to describe types of work being done on the > system. The terms have been co-opted to define a pricing structure. In the > process do you think we've dumbed-down system tuning for these different > types of work, are the concepts still applied, or are they moot with the > newer interfaces? +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-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 mailing list archive is Copyright 1997-2025 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.