Date:         Wed, 18 Jun 2003 23:20:00 +1000
Reply-To:     reply@sasl.no.spam
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         ListServer <reply@SASL.NO.SPAM>
Subject:      Re: JCL and SAS
Content-Type: text/plain; charset="iso-8859-1"

Hello Yanal,

the reason System administrators set up job queues and priorities is so that
all the work the mainframe needs to carry is given an appropriate slice of
resources.  Fast start, high resource queues like Class A are common, and it
is usual to set up one or more slower queues for longer running jobs with
users grouped according to some criteria that defines either their business
continuity importance or functional area.  In this way, the resource should
be shared appropriately.  If there is an imperative need for some area to
run high resource long running jobs quickly, then you need to talk to your
Sys Ops to have this arranged.

On many systems, there is a limitation applied to Class A jobs. At one site
this was done with a process that trotted around the running jobs every ten
minutes, and terminated every job on class A that had accumulated more than
a given amount of CPU time.  This prevented people from using the high
priority queues to the detriment of others. I should be surprised if
something similar does not apply on your machine.

Connect sessions are a little different however.  They are usually a Telnet
or other terminal session running on the mainframe.  In a sense they are
something of a cheat anyway, since they are given the priority of a terminal
session and may not be subject to the same restrictions as Class A batch
jobs. (MAY NOT!!!).  The reason terminal sessions get high priority is
because some poor bunny is sitting looking at a screen waiting to answer a
question.  Clearly, you don't want them waiting long, so you give terminal
sessions certain priorities that keeps human users less dissatisfied.  That
this priority is also given to a SAS/Connect session is obviously not in the
spirit of the response time demands.

Bear in mind with your site that 120 CPU seconds represents a lot of
activity, and for the terminal users, may never be reached.  It is possible
then that terminal connections will also be timed out when their CPU usage
exceeds the limits set.

One other comment on job priorities: starting a terminal session is done
with a high priority task.  The first _n_ seconds of activity attract that
same tasking priority.  However, after a time set by your Sys Ops, that
priority will be degraded.  This is to prevent users from abusing that high
priority to the detriment of other users.

Imagine the chaos if 6 people all ran long queries against your DB2 server
concurrently.  Such queries may be capped by the DB2 administrator, but I
have worked at a site where even that 10% utilisation cap was insufficient
in preventing month end DB2 queries from severely degrading performance to
other users. Bear in mind that it is not just your task query that is
significant here, you and very other user is also using a finite pooled
storage resource, and high i/o activity on your DASD can slow everyone quite
markedly.

So, the short answer to your question is that you cannot run large batch
jobs as Class A on a well managed system. If you do, then at best you will
become unpopular, at worst, your jobs will be terminated with extreme
prejudice. If you try to backdoor the system by using SAS/Connect then you
are also not likely to maintain high job priority for long, and also
probably subject to termination.  And if you believe that Job Class is
sufficient to guarantee fast responses then you are probably going to be
disappointed.

If you have a sound business reason for getting faster responses in your
work then you should be addressing your requirements to the IT work
management group who maintain the system.

Kind regards

David Johnson


Date:    Wed, 18 Jun 2003 05:57:06 GMT
From:    Yanal <fake@BYU.EDU>
Subject: JCL and SAS

Hi,

I am using a s/390 ibm mainframe. To write sas programs and run them, we
  use JCL. We classify the Job to be of class A if it takes less than
two cpu minutes to complete, and G if it takes longer than that.
A jobs execute immideatly, G jobs get in queue (which sometimes takes an
hour or two to start).

Someone told me that if you use PC sas to connect to the mainframe and
run your program it will run as a class A no matter how long the job
takes to execute. (using signon and then rsubmit on PC sas).

If that is the case, then there is a way (i think) to emulate what PC
SAS does in its communication with the mainframe to run jobs as class A.

does anyone know if there is some JCL code or some other setting that i
can use to emulate what PC SAS does to run long jobs as a class A in
this case?

thanks