AS/400 Power 8 (Subsystems)

5 pts.
Tags:
AS/400
I have a client who says their IBM rep said they should only have one batch subsystem, and they are adamant that this is gospel. How do I prove this wrong?

Answer Wiki

Thanks. We'll let you know when a new response is added.

It’s common enough. We use multiple batch subsystems because we have 4 divisions sharing 1 machine. Each division had it own batch subsystem to keep things clean. As RealRaven mentioned a lot depends on the size of your machine, and it’s intended use… If you are only running a few jobs at a time it may not make sense. If you have 4 divisions running 6 jobs at a time, that is a different story.  Provide more details on your current set-up and we might be able to provide more detailed reasoning.

Discuss This Question: 13  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.
  • TheRealRaven
    Without knowing the base configuration, it might not be reasonable to try to "prove" it wrong. Before anything else, is the system configured to use QBASE or QCTL as the controlling subsystem?

    But either way (and potentially even if you create your own controlling subsystem), there will be multiple "batch" subsystems starting up. Should we assume that you mean batch subsystems that are customer-created and that are used for your own custom work?

    Short answer is that it might matter what the system is used for. And except for some dedicated usages, multiple "batch" subsystems are almost always good for any but the low-range systems. For those, it can also be a good idea if performance management is taken seriously.
    20,170 pointsBadges:
    report
  • WoodEngineer
    We had about 8 divisions submitting jobs to a single QBATCH subsystem.  To make submitted jobs play nicely with each other each division submitted to their own job queue.  Then you can tune that by specifying how many jobs can run simultaneously in one job queue by using the CHGJOBQE command.

    7,115 pointsBadges:
    report
  • TheRealRaven
    BTW, does the client have any form of Performance Tools installed? "Proof" is meaningless without measurements. IMO, even with Tools, it's nearly futile to try to get useful measurements without first creating at least two (better, three) new subsystems just to isolate many IBM-supplied server jobs into their own dedicated pools. Without separation, you effectively can't know what measurements mean, which work causes what activity.
    20,170 pointsBadges:
    report
  • GregManzo
    We use two batch subsystems, one for 'permanently' running background tasks and high priority jobs (plus day-end while the main batch subsystem is down), and the 'main' batch subsystem that has multiple concurrent job queues feeding into it. It gives us what we consider reasonable control over the workload on the machine, without needing to spend time watching & micro-managing it.
    1,190 pointsBadges:
    report
  • Subhendu Sen
    What is the main configuration is there? In what situation the IBM representative said like that that must be reviewed. Is the person an authorized from IBM. Basically this is shipped with a standard set of subsystems. Subsystems are user-defined operating environments on the AS/400 that coordinate the flow of work. If possible, please come back with more details.
    74,930 pointsBadges:
    report
  • WoodEngineer
    It has been a while . . . I think we just did a CRTDUPOBJ of QBATCH *SBSD with a new name. *SBSD is one of the object types supported by the command which seems to indicates this is an acceptable method to create a new subsystem.
    7,115 pointsBadges:
    report
  • mmanley
    I think the key here is what you're trying to accomplish. The way you configure a batch subsystem also matters. When people talk about a batch queue, they generally mean a first-in-first-out pipeline that jobs will flow through one after another. If what you're trying to do is make sure that one job doesn't get ahead of another, or access files that might be locked by another job, then this is the way to go... a single queue in a single batch subsystem, allowing only one job to run at a time. On the other hand, if you're just trying to run batch jobs with no dependencies, etc. then any combination of batch subsystems and job queues should work as long as you don't overload the system with more jobs running at the same time than you have resources for.
    110 pointsBadges:
    report
  • pdraebel
    Is there also not a limit to the number of simultaneous jobs a subsystem can handle?
    The overhead of having extra subsystems running is minimal, so the rep's statement is in my opinion not of great value.
    7,290 pointsBadges:
    report
  • WoodEngineer
    QBATCH is delivered by IBM with maximum number of jobs as "*NOMAX".  However, the ability of a system to handle multiple jobs is dependant on a number of factors, one of the most important is memory.  However, the job queue definition controls how many jobs it will allow to run concurrently.  For example, if you have 9 job queues each allowing one job at a time, a maximum of 9 jobs will be active in QBATCH.  If one of those job queues allows 4 jobs then the max jobs active in QBATCH will be 12.
    Try different configurations and observe paging in DSPSYSSTS.  Do your best to avoid a configuration which has jobs in "Wait-Inel" and "Act-Inel".  When jobs go into these statuses system performance will suffer. 
    If most users are off the system at night, you can assign more memory to QBATCH and speed throughput, then move the memory back to QINTER during the day.
    7,115 pointsBadges:
    report
  • TheRealRaven
    By default, IBM i systems run either four or nine "batch" subsystems (though any active subsystem can run "batch" jobs simply by attaching a "batch" *JOBQ). Since it's almost guaranteed that the "client" is already running more than one "batch" subsystem (and I've never heard of an IBM i system that didn't), it's not clear how there would even be a question.
    20,170 pointsBadges:
    report
  • GregManzo
    All good advice on how to configure batch subsystems & use it to control workflow, but the original question was about how to prove to a client that they had been given bad (ok, suspect) advice by a sales rep. The difference between multiple batch subsystems & a single subsystem with multiple job queues is minimal, and really comes down to personal preference on how you want to control your own machine. How do you convince a client of this when they don't have the knowledge to see it for themselves? Maybe showing them this question thread... Maybe suggest the sales rep was talking through his hat, or someone has misinterpreted what he said? Dunno. I can configure your machine for you, but my people skills suck.
    1,190 pointsBadges:
    report
  • jpanzenhagen
    I agree that the answer is, "It depends." There is nothing inherently wrong with one batch subsystem or multiples. The proof is in what business problem are you trying to solve by utilizing multiple subsystems. If it improves performance, security, maintainability, etc. then you can build a case for multiples. If it is just because that is the way that you have done it before, then there really isn't a justification for it.
    55 pointsBadges:
    report
  • azohawk
    I have never come across a system with a single batch subsystem running. Part of this might be terminology. I guess which batch subsystem is the only one that should be running: QBATCH, QPGMR, QSERVER, QSPLF. We have a half dozen jobq's that feed into QBATCH, they are all single threaded. Is that what the rep was referring to?
    2,110 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.

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

Following

Share this item with your network: