Re: Interactive Response Time

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