HP3000-L Archives

September 2006, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Bill Lancaster <[log in to unmask]>
Reply To:
Bill Lancaster <[log in to unmask]>
Date:
Fri, 1 Sep 2006 11:52:34 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (205 lines)
Hi all,

I think that it's generally a bad idea putting jobs into the CS subqueue
when there are other users on the system.  I also agree with Joe that
it's generally unrewarding to mess with the queues.  

As always, it depends on what you are trying to do.  If you simply have
a need to give some jobs a bit more priority during the work day the
easiest this to do is to modify the ES subqueue (assuming you don't use
it for anything) to a small slice within the CS subqueue (say, 190 to
190) and put specific jobs within there through the job card (;PRI=DS)
or some other creative mechanism.

Even this can be unrewarding because most applications on the 3000 now
run in character mode versus block mode.  When that happens, each
process's priority is rescheduled to the base of the CS subqueue (152,
by default) at each transit between fields.  This means that online
transactions will tend to be very, very many with a very, very small
average time per transaction.  In this type of environment (for example,
Ecometry, Amisys or Summit) the other likely type of transaction would
be an online report like a SUPRTOOL or QUIZ report.  When these are run
interactively (not launched into a batch job) they will quickly get
decremented to the limit of the CS queue (200, by default).

This leaves a very common situation of the CS subqueue "haves" and
"have-nots".  When interactive use increases it starts to starve out the
reports in the CS subqueue, not to mention all other lower priority
batch processing.

If you put ";PRI=CS" on a job card you will effective do the same thing.
The longer transactions will very quickly gravitate to the limit of the
queue and, for the most part, stay there until done.  It's not until a
new stop occurs in the batch job that the job will execute additional
work at the base of the CS subqueue.  

(For the purists out there, I have deliberately omitted any discussion
of process priorities being raised in order to address an impede.)

So, the moral of the story is that you shouldn't usually mess with the
queues.  They tend to work as well as they can given that there aren't
many block mode applications left (the environment for which the queues
were optimized).  The most you should do with the queues will generally
be to simply create an ES subqueue that is contained within a lower
range of the CQ subqueue and assign occasion jobs there.

I'll say it again though, your results depend on the specific
environment and so YMMV.

Hope this helps.

Bill

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Reid Baxter
Sent: Friday, September 01, 2006 11:12 AM
To: [log in to unmask]
Subject: Re: [HP3000-L] TUNE

The method Gordon mentions is to include on the job card ";PRI=CS" for
jobs
you wish to execute in the CS instead of DS queue. If a job is already
executing you can use the "SHOWPROC JOB=#Jxxx" and use this information
to
change the priority via the command "ALTPROC JOB=#Jxxx;PRI=CS".

HTH,


Regards,

Reid E. Baxter



 

             Gordon Montgomery

             <gordon@LIVINGSCR

             IPTURES.COM>
To 
             Sent by: HP-3000          [log in to unmask]

             Systems
cc 
             Discussion

             <[log in to unmask]
Subject 
             TC.EDU>                   Re: [HP3000-L] TUNE

 

 

             09/01/2006 12:53

             PM

 

 

             Please respond to

             Gordon Montgomery

             <gordon@LIVINGSCR

               IPTURES.COM>

 

 





Why not just stream the jobs in the CS Queue? I don't remember
exactly how to do it, but I know it can be done. I also used to
alter jobs after they were streamed to run in the CS queue, but
again, it has been several years since I have done that. ( And lately
I'm lucky if I remember what I did yesterday.)

Gordon

----- Original Message -----
From: "Michael Caplin" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, September 01, 2006 7:58 AM
Subject: [HP3000-L] TUNE


I've read thru some of the posted messages regarding this but I could
use=

some help.  Our N class box used to be dedicated at night for batch jobs
=

but we're now allowing session users.  The session users don't need too
=

much but it looks like their presence is degrading the jobs running in
th=
e
batch queue.  Last night (month-end) was a real joy.

I'm planning to schedule a job to run at approx 10:00 pm that will alter
=

the DS queue and then put it back to where it was via a second scheuled
j=
ob
at 5:00 am.

This is the 10:00 pm job.  Any suggestions ?

Mike

!COMMENT * THESE ARE THE DEFAULT VALUES
!COMMENT
!COMMENT            ------QUANTUM-------
!COMMENT QUEUE BASE LIMIT MIN  MAX         BOOST  TIMESLICE
!COMMENT ----- ---- ----- ---  ---         -----  ---------
!COMMENT  CQ   152   200  1    2000        DECAY    200
!COMMENT  DQ   202   238  2000 2000        DECAY    200
!COMMENT  EQ   240   253  2000 2000        DECAY    200
!
!TUNE DQ=152,200,1
!EOJ

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *



-----------------------------------------
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law.  If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED.  Although this transmission and
any attachments are believed to be free of any virus or other
defect that might affect any computer system into which it is
received and opened, it is the responsibility of the recipient to
ensure that it is virus free and no responsibility is accepted by
JPMorgan Chase & Co., its subsidiaries and affiliates, as
applicable, for any loss or damage arising in any way from its use.
If you received this transmission in error, please immediately
contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format. Thank you.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2