× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks very much to all that responded.  Once again, this list (and the experts that so selflessly give of their time and advice) have proven to be invaluable!
 
Have a great day!

Warmest Regards,

Richard Reeve

From: Jim Oberholtzer <midrangel@xxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Monday, October 17, 2011 9:39 AM
Subject: Re: Prestart job problem

I routinely move the QZDASOINIT and QSQSRVR  jobs into shared pools. 
You do have to change the prestart job entry as well as the routing
entries in the those cases.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 10/17/2011 9:14 AM, Charles Wilt wrote:
Jim

Great info, but not going to help in this case I think...assuming that
more than just this app uses QZDASOINIT.

The OP said that "All DB updates from the server side are done via
stored procedures that update that database using SQL."

So I think he's dealing with QZDASOINIT jobs running in the QUSRWRK subsystem...

Richard, take a look at this article showing you step by step on how
to route certain QZDASOINIT jobs to their own pool...
http://www.centerfieldtechnology.com/publications/archive/August%202005%20Newsletter.pdf

HTH,
Charles


On Mon, Oct 17, 2011 at 6:40 AM, Jim Oberholtzer<midrangel@xxxxxxxxxx>  wrote:
  Richard,

  You don't really need another subsystem.  What you need to do is add
  another subsystem memory pool.  Steps are:
  CHGSHRPOOL POOL(*SHRPOOL12)
              SIZE(3000)
              ACTLVL(10)
              PAGING(*CALC)
              TEXT('For my Java Jobs')
  Pick a shared pool, size, and activity level (number of jobs that will
  be active at once)  that makes sense to you.
  Add the memory to the subsystem in question.  I picked QBATCH, use the
  correct one for you.

  CHGSBSD SBSD(QBATCH)  POOLS((2 *SHRPOOL12 10))

  Now the part most folks miss; change the routing step used for the job
  to use the new memory pool.  To find the routing step display the
  subsystem and pick option 7.  It may list several routing steps.  You
  want the one the prestart jobs use.  Check the job description for the
  prestart job.  That may give you a clue about the routing data that is
  used.  I usually change the default first then test to see if that
  routes properly.  In the case of QBATCH the routing step is 9999, so;

  CHGRTGE SBSD(QBATCH)
          SEQNBR(9999)
          POOLID(2)
  You may have to fully qualify the name of the subsystem, in this example
  I did not.

  Now restart the jobs.  They should route to your new memory pool.  Be
  sure to watch it and tune it for a day or two.  Add or subtract memory
  as appropriate and change the activity level so it is just high enough
  to not cause wait transitions.(Active or Wait to ineligible)

  Creating a new subsystem is the exact same series of steps once you run
  the CRTSBSD command first.

  Keep tuned for a System i News article I wrote about this entire
  process.  It goes into much more detail.

  Jim Oberholtzer
  Chief Technical Architect
  Agile Technology Architects


  On 10/16/2011 9:01 AM, Richard Reeve wrote:
  All,

        I'm looking for a sanity check........

        We have an application that runs both on the i (using RPG) and from a windows server (using Java).  The DB resides on the i.  All DB updates from the server side are done via stored procedures that update that database using SQL.

        Recently, I have noticed a terrible response time (from green screen as well as through the Java application) and think that I see the problem.....The prestart job that processes the SQL transactions is running in the base pool (which is where everything else runs as well) and at times there is an indexing issue.  I know that the indexing issue must be addressed, but in the mean time I'm thinking that I could segregate the prestart job(s) to alleviate the the poor response times that are being caused by these troubled prestart jobs.

        Would it not make better sense to define the subsystem (and therefor memory pool) that the prestart job runs in to be different than where all the other jobs (both batch and interactive) run?  At times these prestart jobs are consuming upward of 70% of the resources.

        Any advice/places to look for additional info would be much appreciated.

  Warmest Regards,

  Richard Reeve

  P.S.  Unfortunately, we are still on 5.4  :o(
  --
  --

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.