Change max number of running jobs in QBATCH subsystem

45 pts.
Tags:
AS/400
QBATCH
There's a limit of 10 jobs running in the QBATCH subsystem. How can I increase the number without stopping the subsystem itself?

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 8  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    Subsystem descriptions can be updated without ending the subsystems. (...Unless you're running a very old OS version.) -- Tom
    125,585 pointsBadges:
    report
  • EttoreMenguzzo

    Could you give a hint on how to do that? I know this is very basi question but our experts are out (skiing?) and we have a problem related to this limit.

    :-)

    Ettore

    45 pointsBadges:
    report
  • TomLiotta

    First, run WRKSBS to see a list of your active subsystems. It will be easier if QBATCH is active. If it is active, use option 5='Display subsystem description' against QBATCH. Then take menu option 1, 'Operational attributes'. Verify that QBATCH does not have a limit for 'Maximum jobs in subsystem'. This will usually be set at *NOMAX. If a limit is set, then different steps will be needed. Press <Enter> to return to the subsystem menu.

    Then, take menu option 6, 'Job queue entries'. Review the list of job queues that are assigned to QBATCH. Each job queue can have a separate configuration for jobs that the subsystem will handle. You should ignore any job queues named QS36EVOKE or QTXTSRCH; those are probably not of interest to you. You should see an entry for a job queue named QBATCH, and there might be others (except the two to ignore).

    The 'Max Active' column tells you how many jobs from each job queue the subsystem will allow to be active at one time. You might see that the QBATCH job queue can send 10 jobs at a time into the QBATCH subsystem. To raise the limit to 12, for example, run this command:

    CHGJOBQE SBSD(QBATCH) JOBQ(QBATCH) MAXACT(12) SEQNBR(10)

    If you compare that command to the values shown in the list of job queues, most of it should be clear.

    So, in short:

    Essentially, to raise the number of jobs in a substem, you first make sure its operational settings allow the number of jobs you want. Then you run CHGJOBQE to set the job queue attributes for how you want jobs to come off of the job queue.

    All of that assumes that the QBATCH *SBSD is set for *NOMAX and that the QBATCH *JOBQ is set for 'Max Act' of (10). If anything doesn't fit, if some other values show up, then it needs to be done differently.

    As it sounds, you already have an unusual QBATCH setting. It's certainly not something I would do on my systems. The QBATCH *JOBQ should be (1) and not (10). To handle 10 jobs in QBATCH, it should be done differently rather than setting the QBATCH *JOBQ for more than (1). But if yours already is more than (1), it's not likely to make things worse by setting a higher number.

    Tom

    125,585 pointsBadges:
    report
  • EttoreMenguzzo

    Tom, our configuration (AS starting in Control SubSys = QCTL) is that the QBATCH *SBSD is set = 14 and the QBATCH *JOBQ = 10 (we have other JOBQs set to 1).

    I checked the docs and the reason why QBATCH *JOBQ si NOT = 1 is because, if the only job allowed to run from that queue stops for any reasons, than everything is blocked.

    The probelm we're having now is that for a urgent business activity users launched 30 1-day-loing batches and 11 of them became active thus preventing other jobs from the batch jobq to run.

    A solution would be rising the number of QBATCH *SBSD to 40, lowering the 30 jobs priority and letting at leaset 5 other jobs to start running.....

    Any hint?

     

    45 pointsBadges:
    report
  • TomLiotta

    I checked the docs and the reason why QBATCH *JOBQ si NOT = 1 is because, if the only job allowed to run from that queue stops for any reasons, than everything is blocked.

    A single-thread *JOBQ should be used for jobs that must be run consecutively. E.g., Job1 should finish before Job 2 is allowed to run. If Job 1 gets stuck, then later jobs should not run.

    If there are jobs that do not have dependencies and can run at the same time, additional *JOBQs can be created and added to the subsystem. There is nothing wrong with having QBATCH *JOBQ set for multi-threading. It usually only affects 3rd-party software or perhaps IBM functions that expect QBATCH to run jobs in sequence. (These are problems when those software developers don't think to verify the setup of the system.)

    For your circumstances, you might create an additional *JOBQ with the CRTJOBQ command, and assign it to the QBATCH subsystem with the ADDJOBQE command. If a single-thread *JOBQ gets blocked, the jobs that are waiting on the queue can be changed to run in the alternate *JOBQ.

    Regardless, your suggested solution to raise QBATCH to (40) jobs should be fine. It could even be a temporary change.

    I'm not sure about this part:

    ...lowering the 30 jobs priority...

    That's a choice you'll have to make. I have no way to know if that's a useful idea or not, since I don't know the programming that's running. I wouldn't normally expect it to be very helpful, but it might. If your system is constantly in use running multiple jobs, one possible consequence is that the 30 jobs could take a very long time to finish. I just have no way to guess from here.

    Tom

    125,585 pointsBadges:
    report
  • EttoreMenguzzo

    Tom,

    thanks for your comments.

    The question is in fact about "Regardless, your suggested solution to raise QBATCH to (40) jobs should be fine. It could even be a temporary change."

    The question is: how can we do that (=increasing the # of active jobs allowed n the subsystem) without stopping and restarting the subsystem QBATCH?

    Thanks, Ettore

     

    45 pointsBadges:
    report
  • TomLiotta

    That's done through the process noted in my comment posted Dec 30, 2013   2:27 PM GMT. Ensure that the QBATCH *SBSD operational attributes do not limit the maximum jobs. If they do, then raise the limit. E.g.:

    CHGSBSD SBSD(QBATCH) MAXJOBS( 50 )

    Once the absolute limit for the *SBSD is raised, the CHGJOBQE command will be effective for the *JOBQ.

    Tom

    125,585 pointsBadges:
    report
  • EttoreMenguzzo

    Ok, great.

    Thanks for you support.

    Ettore

    45 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following