|
We do have a couple of machines where we still run under QBASE instead of the QBATCH/QINTER/etc combo. However the most 5250 users is 1 or 2, systems department staff only. And about the only QBATCH type job is the nightly backup. Primarily Dedicated Servers for Domino and that genre. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com "Ingvaldson, Scott" <SIngvaldson@xxxxxxxxxxxx> Sent by: midrange-l-bounces@xxxxxxxxxxxx 11/23/2004 03:27 PM Please respond to Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> To "'midrange-l@xxxxxxxxxxxx'" <midrange-l@xxxxxxxxxxxx> cc Subject RE: Why separate pools? Probably, but as easy as it is to separate the two (and assuming you are not memory constrained) why take the chance? The first thing I was ever taught about performance was to group like workloads. I don't believe that you need a separate pool for every subsystem or a separate subsystem for every 10 users, but it's relatively easy to separate batch from interactive and base. Why wait for a problem to manifest itself? (Besides, if your users are like mine they'll be screaming to VP's long before we would notice a problem...) Regards, Scott Ingvaldson iSeries System Administrator GuideOne Insurance Group -----Original Message----- date: Tue, 23 Nov 2004 12:54:11 -0500 from: "Walden H. Leverich" <WaldenL@xxxxxxxxxxxxxxx> subject: RE: Why separate pools? >Time slices can control some things, but do you want an interactive job to >have to wait for a batch job to complete its (comparatively long) time slice >before it can run? But won't the job also yield as soon as it goes into a long wait? And since IO is a long wait, unless you're calculating something very complex that doesn't include IO (SETI@HOME?) the batch job will yield LONG before it eats up it's time slice, no? -Walden ------------ This message and accompanying documents are covered by the Electronic Communications Privacy Act, 18 U.S.C. §§ 2510-2521, and contains information intended for the specified individual(s) only. This information is confidential. If you are not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, copying, or the taking of any action based on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
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.