|
I wrote > > Encourage the use of JOBQ for any job that negatively impacts interactive > > response time for everyone when run on-line. > > Seek corporate policy to that effect. Tom Liotta commented > As nice and handy as *jobqs may be, if I seriously wanted to control this, I'd > probably use routing programs. The routing program basically would check if > the job is batch or not, and if it is, then route it appropriately possibly > either by TFRJOB or RRTJOB. Then it won't matter what *jobq is used. I was not referring to choice of *JOBQ although that is another valid point. I was referring to whether a job that really belongs on in batch form gets run by someone on-line. Our users generally have a variety of freedoms to run individual jobs on-line, on-jobq, leave reports on-hold & delete what not need, or let all print & pitch what not need. For most of our jobs it makes little difference if something on-line or on-jobq but we do have some jobs that are hogs, that are not healthly to be running on-line when there are lots of users. Most users understand that JOBQ uses system efficiently ... they not understand how, they not need to understand how, they accept this. Most users understand that certain jobs run so fast on-line that their system impact is minimal. What we need policy for are those people who not understand this, who try to run a hog job on-line in middle of day. We also have several JOBQ. Some are intended for jobs that will take a while to run. Others are intended for jobs that will be over pretty quickly. Some are intended for particular departments, like all shipping tasks. Another post reminded me of one of the first major software projects I had here, many years ago & several platforms back. The Inventory Clerk complained about long wait times between screens consistently. I studied the code to see what the program was doing & realized that the file access logic was counter-productive to how our inventory was structured, and rewrote the architecture. It took me several months to do the rewrite ... a big job. When I got done, transaction time was reduced from 5-10 minutes average each to sub second every time. MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac) BPCS 405 CD Manager / Programmer @ Global Wire Technologies Incorporated http://www.globalwiretechnologies.com = new name same quality wire engineering company: fax # 812-424-6838
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.